Online Banking/Browser Security Award for 2014/2015

 

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.

Online Banking/Browser Security Award for 2014/2015

Online Banking/Browser Security Award for 2014/2015

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.

MRG-Awarding-650-40710-272595

 

Award logo

Read More

Generic bypass of next-gen intrusion / threat / breach detection systems

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.

Introduction

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.

Drive-by-exploits

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:

ECDH

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 …

You can download POC here, the Wireshark dump here. If you can decrypt the Javascript code, please comment and let us know how did you do that.

FAQ

Do you have a cool logo for this?
No.

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

Stop using Virustotal to measure how AV sucks!

We recently came across an article which again is a FUD regarding how AV sucks. VirusTotal has been writing  about this years ago. Although we agree that most AV is not as good as it is stated in the marketing materials, but that is not the point.

Let’s look at this particular exploit for a moment. Quoting from the article, “The attack, originating from traffichaus.com, was launched though an iFrame which was not detected by 52 anti-virus products, researchers said.” Uploading a malicious Flash file to Virustotal, looking at the 0/57 detection rate is just lame.

Here are just a few AV components which can block the infection:

  • URL blacklisting (not effective, but still)
  • URL reputation – high false positive rates but can be very effective
  • Analyses of HTML/Javascript code to detect the exploit kit (this looks pretty effective when implemented properly)
  • Analyses of the exploit code itself, whether it is Flash, Javascript, Silverlight, whatever. Exploit kits are very good at obfuscating this layer.
  • Blocking the malware download – URL blacklisting/reputation/static AV signatures/heuristics. These detections can be bypassed, but works most of the time.
  • Blocking the execution of the malware – some AV engines do have real exploit protection, which can detect that an unknown exploit tries to start malware on the machine – and block it. I know it, I have seen it with my very own eyes. Multiple times. I also saw this protection being bypassed. It is not 100% perfect.
  • Block the malware by reputation – this can be very effective, when previously unknown binaries are blocked. A few AV uses this technique.
  • Block malware based on how it interacts with the OS – I don’t consider this as a real protection, as it means the malware already started, did something (malicious), and after some time one of the actions are flagged as malicious by the AV. Although this is somehow late, this can still block the real risk, e.g. banking trojans stealing your money.
  • Scheduled scans: Very late detection, but still, it is better late than never.

Looking at this particular exploit, I can confirm some AV did detect and block this threat on day 0. Others did not. Angler exploit kit is especially dangerous because of in-memory-malware – which renders a lot of AV protection components useless.

 

xhamst

And yes, all AV can be bypassed. Imagine an AV which provides 100% proactive protection, out of the box. If something like this could have happened, this will mean all the developers of the AV company should have been fired, as the AV does not need any maintenance/updates at all. Which means most of the update you get with your AV engine is about threats which bypassed the AV yesterday …

Only a real world protection test, testing all AV components can measure how effective today endpoint protections/internet security suites/AV engines really are.

We would like to thank Kafeine for sharing the sample with us.

Conclusion

Using Virustotal to compare AV protection is unprofessional, and lame. Don’t do that. Especially when it comes to exploit kits …

PS: using Virustotal to test Android AV is more realistic than Windows AV, or especially exploits. AV on Android is most of the time just plain static scanner.

Update (2015/01/30): the screenshot has been fixed

Read More