1 Executive Summary

Everybody is talking about Man-In-The-Browser (MITB), so I thought we’d do a little 101 session on how these Man-In-The-Browser Trojans work. As there is way too much focus on the big guns such as Zeus/SpyEye out there, I thought we’d use one of the less known Trojans as an example and even discuss the implications on Mac OS X as well.

While the exact details are different, Man-In-The-Browser threats are also valid on Apple’s OSes (on iOS, sand-boxing and signing makes things pretty difficult, theoretically not impossible, and a lot easier if the device is jail-broken).

2 Introduction

For this paper, we’ll use a sample with MD5 of 3618ff28e3c0d48a09dbae5b5b42585a which seems like a new variant of BankPath/Multibanker trojan. It has a Virustotal detection of 9/43 (20.9%) – http://www.virustotal.com/file-scan/report.html?id=5fc899cbaa6e22aa8bbffb43bee778c7e6d4ad07597a14d5e280719941e33270-1306853690

While we looked at a Bankpatch Trojan in very much detail in an earlier post (http://www.trustdefender.com/trustdefender-labs-blog-banking-malware-bankpatchc-shows-that-the-bad-guys-are-extremely-innovative.html), this one seems to be different and we only want to focus on the MITB features as a part of the broader MITB discussion.

Man-In-The-Browser threats are malware that operate within your browser and have full access to the current Internet session and can change the web-page, add content, remove content, steal information and much more. Please note that it doesn’t matter whether the site is using SSL (or even EV-SSL) as the malware gets access to the content before its encrypted.

3 How does MITB work?

3.1 Windows

Now let’s have a look how all major Trojans do this at the example of Bankpatch and Internet Explorer. When the Internet Explorer opens a connection to the Internet, it will call a function named “InternetConnect” which resides within the wininet.dll module that every Windows installation has.

This is illustrated below:

MITB Trojans will now just “hook” into this first call between the Internet Explorer Application and the Windows System, so that the Trojan get full control over everything that is transmitted in this “call”.

3.2 Mac OS/X

But what about Mac OS X? As mentioned earlier the details are a little different, but the result is same. If a web browser is using the system API to manage its Internet connections, then malware simply needs to hook CFReadStreamOpen(), CFReadStreamRead() or CFReadStreamWrite()  in a similar way to the one described above.

3.3 Hooking

On a high level, it looks now as follows

 

On Windows, we will be able to accomplish this with just a change of 5 bytes in the Internet Explorer process! wow.

On Mac OS X we could take advantage of the lazy linking system used for resolving external symbols, and simple overwrite the resolved address with one of our own. So it would only take 4 bytes on Mac OS X (simply the address we want to call inserted into the appropriate location). This could be done either before or after the symbol resolution has occurred.

The interesting thing is that this is very easy to accomplish, so let’s have a look what Bankpatch is doing:

On a good system, a call to “InternetConnect” will go to the following location

 

Don’t be scared at the technical details, most of the info is not relevant, but what’s relevant is that the first three lines are always the same for every single function and is called “prologue”. An obvious question is why do we need this prologue?

3.3.1 Works as designed

And you can believe this or not, but this prologue was designed to enable “hot-patching” (see Microsoft http://blogs.msdn.com/b/ishai/archive/2004/06/24/165143.aspx). Wait a sec… hot patching??? You heard right… The first two bytes are not needed at all, but it is designed to allow a redirection of this function.

Can someone repeat this for me??? Man-In-The-Browser by design from Microsoft??? wow.

That’s pretty much what it is.

In order to “hook” into this call, the malware needs to do two things.

• Firstly it needs to jump to its own codebase so that the malicious code is executed.
• Secondly it needs to make sure that the original code is called (otherwise no internet connection would be established) as well.

 

The first part can be accomplished with 5 bytes (a JUMP instruction + 4 bytes address). As the prologue (that is not really needed) is exactly 5 bytes long, the malware can just overwrite the prolog and everything is fine… That’s convenient and easy.  The picture isn’t much different on Mac OS X. We just need to overwrite the address of the destination function (say CFReadStreamOpen) in the target executable look up table.

3.4 Let’s put this all together

Let’s see how Bankpatch uses these first 5 bytes to get access to the full internet traffic

 

So instead of the normal prologue, there is an unconditional jump (jmp 009b841f) basically telling the CPU to execute the Bankpatch code whenever InternetConnect is called. After Bankpatch does its work, it will then obviously call the original function so that the internet connection is established.

That wasn’t too hard, was it?

3.5 Mitigation approaches

If we replace the original prologue, then Bankpatch will not do any harm anymore. On Mac OS X, we can simply force the dynamic linker to look up the correct symbol again. Problem solved… without knowing any details, … Without any blacklist, heuristics, … Straight and simple…

Well, in reality its not so simple as the Trojan can just change those few bytes again and restore the hook, but we hoped to shed some light on how MITB Trojans do their dirty work, regardless of platform.

To make matters worse, signed binaries don’t help here either. On Windows, only the disk image is signed and once the file is loaded into memory, anyone can make any changes to it as there is no signature to the memory image.

On Mac OS X, lazy symbol resolution is part of the OS design and unavoidable.

4 Conclusion

As you can see the actual hooking of the browser isn’t a major hurdle and can be done easily. What is obviously more interesting is what Trojans do once the hooking has been done. This is where the MITB malware configuration comes into play with its bank-specific definitions and different behaviours depending on a particular situation. We have covered real-world examples in a number of other post re Zeus, Carberp, Gozi, etc.

The thing that is more amazing is actually that every single MITB Trojan uses these kind of hooking techniques, but hardly any Antivirus Engines or Security Suites look at these things.

Of course the TrustDefender Forensics Engine does.