|Jun / 02 / 2015|
The focus of this blog post is to bypass network monitoring tools, e.g. good-old IDS or next-generation threat detection systems in a generic way. The focus is on the exploit delivery.
Drive-by-exploits are an important toolset for the attackers to attack home users and businesses, besides spam, trojanized applications and so on.
Nowadays one of the most popular exploit delivery is via web, using IE or Flash exploits. As to my knowledge, although some exploit kits use encryption (e.g. in Flash exploits, or CSRF exploits), but the encryption keys are sent in the same session. Which means it is trivial to decrypt the exploit at the end of the day. One very easy method of verifying this is to replay the recorded exploit traffic. If the replay is able to infect the victim again, there is a fixed-key encryption there. Also, delivering the malware using XOR,RC4 or XTEA encryption is very common.
Now, let’s see what we have done, with the help of Node.js, Browserify, Diffie-Hellmann key exchange on elliptic curves (ECDH) and AES encryption:
I think this image is rather self-explanatory. The main thing is that the decryption of the encrypted exploit code happens on the client side, and only the real client (and the exploit kit server) has the keys to decrypt it.
One easy way to defeat active sandboxes or URL crawlers (which will visit the exploit URL) from the attacker’s point of view is to serve every exploit URL only once, and hope the first visit will come from a user. It is important not to send the exploit URL to honeypots. And as it is also covered in FAQ, if the exploit URL is delivered via e-mail, and the e-mail system visits the URL before the user does, the exploit runs in the sandbox, and our evil plan is foiled. But sandboxes which visits URL’s found in e-mail’s can be quite dangerous …
Do you have a cool logo for this?
Is this exploit delivery trick new at all?
According to our knowledge, yes. If not, let us know.
Do you think this is a superleet hack?
Not at all. It is so simple I have no idea why no one is using it.
Stegosploit does something similar, isn’t it?
Not at all. Stegosploit is just obfuscation. See this post for details.
What browsers are supported?
Tested on IE 11, Chrome 38 and Firefox 36. Anything lower than IE 11 is not supported.
Are we all doomed?
Nope, there are plenty of other layers where the attack can be detected. E.g. on the desktop via endpoint protection (good-old traditional AV), or with security products focusing on killing memory corruption attacks (EMET, HitmanPro Alert, Malwarebytes Anti-exploit, etc.). Also, an e-mail based protection system can visit the URL first – and the exploit will work on the first visit, which is the e-mail appliance. But beware, this “automated link check” can be dangerous. The delivered malware can be detected on the endpoint , or in a worst case scenario, the C&C communication can be detected (even via next-generation expensive LED blinking appliances).
Why are you so irresponsible that you publish this without notifying the vendors before?
As there is no generic fix to this problem, there is not much to discuss. The whole HTML application can be flagged as suspicious via traditional signatures – but that is not a fix.
Do you think there is a generic approach to detect this?
On the network layer, not. One possibility is to calculate entropy and alert on high entropy, but this will create high false-positive ratio. If you think there is a good way to detect it in a generic way, let us know.
Why are you using Node.js?
I was just about to learn Node.js. It is really cool that I was able to use the exactly same crypto library on the server side and on the client side.
In Node.js, this or that can be done in a better way, why aren’t you doing that?
This is my first Hello World project in Node.js.
What if I want to use this technique in IE6?
Good luck modifying this crypto so it will be compatible with IE6. When I created this POC, my goal was to implement good crypto. This is the reason I’m using Diffie-Hellman on elliptic curves and AES. You can implement much worse crypto which will still work – but manual analysis might reveal the keys in these cases.
What is the difference between SSL and this technique?
Some enterprises use Deep Packet Inspection, and man-in-the-middle the HTTPS traffic. Which means the admins can log the full traffic where the SSL was MiTM-ed. So, SSL adds no generic protection to exploit kits.
Can this attack extended to Flash exploits?
I believe the answer is yes. E.g. Flash vars used to decrypt the Flash exploit code can use this common secret.
Is it possible that attackers are already using this trick but the public does not know about this?
Yes. It is possible.
Do you know that DH key exchange sucks because MiTM attack is possible?
Yes, I know. I know it does not provide authentication. I don’t care. I care about passive attackers (defenders).
I am selling these intrusion / threat / breach detection devices, and you are ruining my business. Any comments on that?
We are not ruining your business. These network devices are important part of a defense-in-depth approach. As every layer can be bypassed, this can be bypassed as well. Also, if you are selling e-mail appliances, or you have agents to be installed on endpoints, this article justifies the selling of those.
PS: Thx to Gabor Molnar for the XHR idea.
[Update 2017.02.16]: the post has been modified a bit to remove some confusing parts.