When conducting the quarterly comparative quality assessments, we – MRG Effitas – evaluate the reliability and efficiency of security solutions against financial threats.
We tested a group of internet security suits and anti-financial fraud applications.
Out of all the products we tested, only four managed to pass all stages of the tests throughout of the last four quarters. Out of those four applications, two were dedicated anti-financial fraud products – Quarri POQ and Wontok Safecentral, and the other two were internet security suites. These internet security suites, Kaspersky Internet Security and Webroot SecureAnywhere, actually harden the existing user’s browser with their SafeMoney (Kaspersky) and IdentityShield (Webroot) technologies.
Throughout the four tests the solutions had to combat collections of recently-discovered, active financial malware, and to prevent any leakage of payment data during transactions made from already-infected systems that were designed to imitate the most commonly-seen botnets. In Q2 2014, the researchers simulated a Man-in-The-Middle attack, in Q3 2014 and Q1 2015 the tests tried to deceive security systems by redirecting API calls, and in Q4 2014 they bypassed browser protection with the help of Windows Application Compatibility and the Windows AppInit DLL method.
The Online Banking/Browser Security Award trophy is shaped like a shield with a coin bearing the Effitas logo positioned on a pedestal behind it. The focus can be on the shield or on the coin resting on the pedestal. The shield symbolizes protection and security, while the coin symbolizes value and wealth. The shape can also be interpreted as an open shell in which a coin is shown instead of a pearl. The carbon fiber frame on the shield and the pedestal symbolizes the use of advanced technology, security and safety. The award was designed by IndividuARCHT, Hungary.
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.
There are two types of attacks. Socially engineered attacks and exploits.
Socially engineered attacks
Socially engineered attacks are about that attackers convince the victim user to download the malware and run it.
The first type of attack can be solved easily with already available technologies. For example one can use MEGA for malware delivery. By passively listening on the network, it is impossible to recover the malware, because the fragment / named anchor part of the URL is needed (you know, the string after the # sign). If the URL was sent via web/e-mail, the appliance can recover the full URL and decrypt the malware. But I’m sure not many appliance does this.
The second type of attack is using exploits. 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, so the encryption becomes obfuscation 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 no real encryption there, but obfuscation (e.g. encryption with keys embedded in the traffic). Also, delivering the malware in an obfuscated (not encrypted) way 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, I see no point to reiterate it here. 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.Read More