Man-in-the-browser


Man-in-the-browser, a form of Internet threat related to man-in-the-middle, is a proxy Trojan horse that infects a web browser by taking advantage of vulnerabilities in browser security to modify web pages, modify transaction content or insert additional transactions, all in a completely covert fashion invisible to both the user and host web application. A MitB attack will be successful irrespective of whether security mechanisms such as SSL/PKI and/or two or three-factor Authentication solutions are in place. A MitB attack may be countered by using out-of-band transaction verification, although SMS verification can be defeated by man-in-the-mobile malware infection on the mobile phone. Trojans may be detected and removed by antivirus software with a 23% success rate against Zeus in 2009, and still low rates in 2011. The 2011 report concluded that additional measures on top of antivirus were needed. A related, simpler attack is the boy-in-the-browser. The majority of financial service professionals in a survey considered MitB to be the greatest threat to online banking.

Description

The MitB threat was demonstrated by Augusto Paes de Barros in his 2005 presentation about backdoor trends "The future of backdoors - worst of all worlds". The name "Man-in-the-Browser" was coined by Philipp Gühring on 27 January 2007.
A MitB Trojan works by using common facilities provided to enhance browser capabilities such as Browser Helper Objects, browser extensions and user scripts etc. Antivirus software can detect some of these methods.
In a nutshell example exchange between user and host, such as an Internet banking funds transfer, the customer will always be shown, via confirmation screens, the exact payment information as keyed into the browser. The bank, however, will receive a transaction with materially altered instructions, i.e. a different destination account number and possibly amount. The use of strong authentication tools simply creates an increased level of misplaced confidence on the part of both customer and bank that the transaction is secure. Authentication, by definition, is concerned with the validation of identity credentials. This should not be confused with transaction verification.

Examples

Examples of MitB threats on different operating systems and web browsers:
NameDetailsOperating systemBrowser
Agent.DBJPWindowsIE, Firefox
BugatWindowsIE, Firefox
Carberptargets Facebook users redeeming e-cash vouchersWindowsIE, Firefox
ChromeInject*Greasemonkey impersonatorWindowsFirefox
ClampiWindowsIE
GoziWindowsIE, Firefox
NuklusWindowsIE
OddJobkeeps bank session openWindowsIE, Firefox
SilentbankerWindowsIE, Firefox
SilonWindowsIE
SpyEyesuccessor of Zeus, widespread, low detectionWindowsIE, Firefox
Sunspotwidespread, low detectionWindowsIE, Firefox
TatangaWindowsIE, Firefox, Chrome, Opera, Safari, Maxthon, Netscape, Konqueror
Tiny Banker TrojanSmallest banking Trojan detected in wild at 20KBWindowsIE, Firefox
Torpig**WindowsIE, Firefox
URLZone****WindowsIE, Firefox, Opera
Weyland-Yutani BOTcrimeware kit similar to Zeus, not widespreadMac OS XFirefox
YaludleWindowsIE
Zeus***widespread, low detectionWindowsIE, Firefox

Protection

[Antivirus]

Known Trojans may be detected, blocked, and removed by antivirus software. In a 2009 study, the effectiveness of antivirus against Zeus was 23%, and again low success rates were reported in a separate test in 2011. The 2011 report concluded that additional measures on top of antivirus were needed.

Hardened software

A theoretically effective method of combating any MitB attack is through an out-of-band transaction verification process. This overcomes the MitB trojan by verifying the transaction details, as received by the host, to the user over a channel other than the browser; for example, an automated telephone call, SMS, or a dedicated mobile app with graphical cryptogram. OOB transaction verification is ideal for mass market use since it leverages devices already in the public domain and requires no additional hardware devices, yet enables three-factor authentication, transaction signing, and transaction verification. The downside is that the OOB transaction verification adds to the level of the end-user's frustration with more and slower steps.

Man-in-the-Mobile

spyware man-in-the-mobile can defeat OOB SMS transaction verification.
Web Fraud Detection can be implemented at the bank to automatically check for anomalous behaviour patterns in transactions.

Related attacks

Proxy trojans

are the most primitive form of proxy trojans, followed by browser-session recorders that capture more data, and lastly MitBs are the most sophisticated type.

Man-in-the-middle

SSL/PKI etc. may offer protection in a man-in-the-middle attack, but offers no protection in a man-in-the-browser attack.

Boy-in-the-browser

A related attack that is simpler and quicker for malware authors to set up is termed boy-in-the-browser. Malware is used to change the client's computer network routing to perform a classic man-in-the-middle attack. Once the routing has been changed, the malware may completely remove itself, making detection more difficult.

Clickjacking

Clickjacking tricks a web browser user into clicking on something different from what the user perceives, by means of malicious code in the webpage.

DDoS over WiFi and related exploits

Some phones and tablets in current use have a known vulnerability to DDoS over WiFi, and this has been documented on certain Android phones. The vulnerability is that if an attacker detects that someone is using sharing, it is possible to target the phone or tablet directly using a packet collision similar to the one found on LAN networks requiring guessing the device sharing password using a rainbow table and cloning the SSID, thus forcing a reboot after enough data has built up in RAM causing a buffer overflow. During this narrow window, malicious software can be used to install a rootkit or other malware over the diagnostics OTA channel before the antivirus has a chance to load in a similar way to how sideloading over USB works. It appears that there is no defense at present other than not using sharing or changing the password after a short random interval, e.g. WPA2-TKIP, which not all devices support.
WPA3-OTP may be a solution if a sufficiently large memory at both ends is used, e.g. 400GB.