Man in the Browser

Man in the Browser a.k.a MITB is a new breed of attacks whose primary objective is to spy on browser sessions (mostly banking) and in that process intercept and modify the web page contents transparently in the background. In a classic MITB attack, It's a very likely that what the user is seeing on his/her browser window is not something which the actual server sent. Similarly, what server sees on the other end might not be what user was intending to send. Why MITB? How different is it from conventional browser hijacking? I'll explain that shortly.

As we have also seen in the past, browser hijacking is an evasive technique being used by modern password stealer and banking Trojans. Conventional hijacking is there to steal the user's credentials as they are entered into web forms. A shift from the conventional Key loggers who used to capture every key from the victim's keyboard and in that process used to send lots of irrelevant information to the attacker.Things were going quite well with conventional browser hijacking before modern banks thought of introducing multi-factor authentication.  With multi-factor authentication, conventional user name and passwords alone are not enough to login to a banking account, banks would require more than that. Let me explain multi-factor authentication by taking 'XYZ bank' as an example:

XYZ bank has an added security check with the name of 'Safety Pass'. Whenever a user tries to log in to any XYZ account from a machine which hasn't been used in the past to access this account, XYZ as a precaution will send a random code (via SMS) to the user's mobile phone and would require it before prompting for a password. This pass code, with a two minute expiry, will make sure that it is indeed the real user trying to log in . Once the user successfully pass through this added check, XYZ bank by default will not insist on the 'Safety Pass' again and user would go through conventional user name/password based authentication from next time onwards.

What this means is that without 'Safety Pass', logging into a compromised banking account from a different location, even with stolen credentials like user name and password will be nearly impossible. But "where there is a will there is a way". Here come the MITB attacks.

Case 1: (an imaginary situation)

Bob, an accountant in a local firm is a passionate guy who loves to work, even during off hours. One day while browsing the internet from home in search of some freeware software, he suddenly found his browser crashing unexpectedly. Hmm.. weird, may be it's some kind of software bug, he thought, and opened another browser window to continue his search.

At this point Bob had no idea that his machine had been infected with a nasty banking Trojan, Zeus/Zbot. Zeus had just exploited a vulnerability in his browser and installed itself silently on his PC.

Later that evening he thought about finishing some more of his work assignments so he decided to log into his company's XYZ bank account and do some wire transfers. Upon accessing the login page, he found something weird. Login page was asking him for the 'Safety Pass' as an added security measure. He was a little confused by this situation (as he had already gone through this check earlier). Then he thought maybe the bank is just being overcautious, so he requested for the 'Safety Pass' again and logged into his online banking account as normal. He was completely unaware of the situation that 'Safety Pass' was never actually requested by the banking server. It was the Zeus Trojan installed inside his browser that changed the server response coming in the form of html (just before the browser renders it) and injected this additional field.

The real purpose of this 'Safety Pass' injection was to snatch the 'Pass code' and send it to the attacker via IM along with other credentials. Now attacker with all the authentication factors in hand has two minutes (Pass code normally expires within minutes) to log into Bob's online bank account from other remote locations.  Once logged into Bob's banking account, attacker is in the position to start transferring the available balance to any other account. Normally for transferring stolen funds, "money mule" accounts are used. Money mules most of the time are innocent people who are recruited by the criminals behind the malcious software, via the internet & usually without letting the "money mule" know the actual type of activities they will be engaging in. The primary job of these money mules would be to transfer any amount transferred into their accounts into the attacker's account of choice, mostly via 'Western Union' in remote locations like Russia, Ukraine etc.  Money mule in turn keeps a small portion of this money as a commission.

How does Zeus do all this? All attack methodology is controlled through the Zeus configuration file. This configuration file is transferred on the wire in encrypted form, after decryption it looks like this:

This configuration file is prepared by the attacker and distributed to all the Zeus zombies. Based on this data, Zues then decides on the different banks to target. This configuration file also contains the html which needs to be injected into legitimate banking pages, fooling the user into answering all the secret questions/Safety pass, etc.

Case 2: (an imaginary situation)

It's Bob again, and this time his PC is infected with yet another MITB malware URLZone/Bebloh. After finishing his freeware search, he decides to log int to his XYZ Bank account to conduct some wire transfers. He logged into his account as usual, the login page did not ask him for the safety pass this time. He successfully makes a wire transfer in the amount of $10,000 to his client (Mr. David) and logged out afterwards. He had no clue that something really bad has happened during the wire transfer process. This is what happened in the background:

As Bob entered Mr. Davids account/wire information and submitted the transfer request to the bank, URLZone silently replaced Mr.David's account information with info from one of its money mule (Mr. Jerry) accounts. The bank, as instructed, transferred the $10, 000 and sent back a confirmation page indicating the successful transfer of $10, 000 to Jerry's account.  Well, Bob should have noticed this fraud after seeing the bank's response. Unfortunately this did not happen, URLzone played another trick and changed the bank's response, this time replacing Jerry's account information with David's and displayed it to Bob, leaving no tell-tale clues behind that the $10,000 never reached his client Mr. David.

            Bob                                                URLZone                                      Bank

Transfer funds to Mr. David         --->     [Request modification]    --->        Transfer funds to Jerry

Transferred funds to Mr. David    <---     [Response modification]   <---      Transferred funds to Jerry

Like Zeus, URLZone is also controlled through its configuration file. This configuration file contains complete information about the money mule accounts, names, etc. This file also contains the names of the banks to target etc.

Just like Zeus, URLZone is also created using a toolkit (available in underground markets). What this means is that the buyer of this toolkit can then create customized malware or botnets with different CnCs and configurations but having all the flexibility and power of the original toolkit.  Having such a tool kit in the hands of multiple criminal group paints a scary picture. It's simply not enough to eliminate a particular botnet and criminal group to solve this problem. Worst of all, Zeus and URLZone are not the only MITB malware currently active, other malware like Bzub, Torpig etc also fall in the same category.

May be its the time for all of us to closely monitor the security currently being offered by our banks. Can they protect us against MITB ?

For those who may want to read about a recent incident where Zeus was involved in a $ 150, 000 robbery:

http://www.krebsonsecurity.com/2010/02/hackers-steal-150000-from-mich-insurance-firm/

Atif Mushtaq @ FireEye Malware Intelligence Lab

Detailed Question/Comments : research SHIFT-2 fireeye DOT COM

Comments

[J Cooper]

Instead of offering a rss link how about a potential solution?or a link to a potential solution?

[L A]

This technique might be 2 years old, but until it becomes so well known that even the bankers themselves know what to look for and become smarter about their browsing, then I will thank Atif Mushtaq
for his efforts and tell him to keep it up, as this will someday hopefully make its way to all bankers too!!!

[Tom Welsh]

Could the bank servers not refuse to open more than one session at a time? That is, if you have logged in, you should not be allowed to log in again until you have either logged out or timed out. That seems elementary, so what am I missing?

[Oasisbob]

Here's something I've always wondered: Why don't the trojans just steal the cookie which is set during the MFA registration process, record the credentials (keystroke logger), and use the combination to login from elsewhere?

I find it hard to imagine that a trojan like Zeus can't find a way to get at stored cookies, even if there isn't an explicit API exposed.

[old]

it's not new; this technique is at least 2 years old

[IT Ninja]

btw, the National Security Agency was recently hacked. Yes hacked! But it was downplayed to the media for obvious shameful reasons. Here’s the link :

http://pinoysecurity.blogspot.com/2010/02/wwwnsagov-hacked.html