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 very likely that what the user is seeing on his/her browser
window is not something which the actual server sent. Similarly, what
the 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
malicious 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?
This essay first appeared on FireEye’s Malware Intelligence Lab blog.
