This being the weekend, I've decided to bring out Metasploit again. "Target" machine is a Slax 7.0.8 VM (one of the most gratuitously insecure distros I know of, and now outdated as well). This is one of the most gratuitously insecure (and now outdated) Linux distros I know of... Needless to say, one of the canned JS attacks works against its dated version of Firefox. So, I set about trying to see what blocks this. -> Noscript works. However, it stops working as soon as Javascript is allowed for attack page. (No duh.) This... could be a problem in the event of an actual Firefox zero-day, seeing as a lot of sites need third-party JS to work, etc. -> Blocking fork/exec does not appear to work at all. (Again, no duh, the payload is itself JS.) -> What does work, is outbound firewall rules. With iptables allowing only SSH, FTP, HTTP(s), and port 8080 (for the local attack page), the outbound TCP connection for the JS shell payload is blocked. The attack fails. -> I figured, okay - this could be worked around by exec()ing something instead. So I tried a Linux shell exec payload, set to start an xterm. This did not work, though, it just caused Firefox to segfault. (Maybe due to ASLR/NX?) -> Executing something direct from JS might be possible, given the nature of the attack... Not sure. You can see here that outbound firewalling raises the bar a bit. With unfiltered outbound packets, it's just a matter of "Here's a vulnerable browser, here's an exploit, here's a command shell running in your user account"; things like Metasploit's "Browser Autopwn" module work. Whereas with outbound filtering in place, the attacker has to know something about their target and what exploit they're using. Not great, but better. ... But that's Metasploit. Reality is another matter. -> If I wanted to be smart about this, the way to do it would be by NAT - have the reverse TCP server listening on some high port, but use iptables to redirect port 80 inbound to that, or suchlike. -> Most Windows drive-by attacks likewise don't seem to bother with reverse TCP shells; they just run a batch script to download some rubbish and execute it. That didn't work on Linux in my case, but probably only because I don't know how to pull it off. -> Also, I've personally seen cases where the initial attack came from a different IP than the one hosting the malicious files. There are other ways of doing this too - Apache virtualhosts for instance, serving up different content on the same port depending on the contents of HTTP requests. ... In conclusion: a) Keep your software up to date. This VASTLY reduces the chance of browser attacks etc. actually working. (We've all seen that most ITW attacks are not zero-day, right?) b) Don't trust any security mechanism, or combination of mechanisms, completely. Noscript, exec() blocking, firewall rules, etc. can all be bypassed under the right conditions. c) Don't assume that something will work in real life, just because it works in a controlled lab environment. "No plan survives first contact with the enemy."
I'm not sure if I understood it correctly, but I do know that certain payloads, like reverse shells, should be blocked by simply blocking the browser from the ability to accept incoming connections. Is this correct?
Although I agree with most of what you said, I must say that a combination of security mechanisms is the best one can get. For example, Firefox (ublock, http-nowhere, disconnect, NoScript, requestpolicy) running on top of firejail, and on a linux-grsec Kernel, should block pretty much every exploit known to man.
Guess I will need to do some more reading. But yes I agree, reverse shells are almost never being used in attacks on home users, it's all about ransomware and banking trojans nowadays. And even if they were used, they should be blocked with anti-exploit.
