There was a lot of attention paid to a new type of browser attack recently called the Boy in the Browser. To find out more about this technique, we contacted Amichai Shulman of Imperva to answer a few questions.
Shulman is Co-Founder and CTO of Imperva, where he heads the Application Defense Center (ADC), Imperva’s internationally recognized research organization focused on security and compliance. Shulman regularly lectures at trade conferences and delivers monthly eSeminars. Under his direction, the ADC has been credited with the discovery of serious vulnerabilities in commercial Web application and database products, including Oracle, IBM, and Microsoft. Prior to Imperva, Shulman was founder and CTO of Edvice Security Services Ltd., a consulting group that provided application and database security services to major financial institutions, including Web and database penetration testing and security strategy, design and implementation. Shulman served in the Israel Defense Forces, where he led a team that identified new computer attack and defense techniques. He has Bachelor of Science and Masters Degrees in Computer Science from the Technion, Israel Institute of Technology.
What is the Boy in the Browser attack and what are the consequences for compromised victims?
The Boy in the Browser is a sophisticated Trojan, a “dumbed-down” version of Man in the Browser. In essence, a BitB is a less mature version of the MitB Trojan, hence the name.
With a BitB, the Trojan takes control of the victim’s traffic and re-routes the information through an attacker’s proxy site. The attacker achieves this by tampering with hostname to network address mapping in the victim’s machine (through changes to the ‘hosts’ file). It is very difficult to detect since the victim’s address bar continues to present the address of the intended destination.
Consequences to a compromised victim include:
- The logging of sensitive information by an attacker.
- The modification of requests (such as a payment).
You say that BitB relies on victims to access websites not protected by SSL. Is it just a matter of accessing sites with sensitive information via SSL to prevent this attack?
BitB defeats SSL mainly because users usually type www.yourbanknamehere.com which is automatically translated by the browser to http://www.yourbanknamehere.com (a non-SSL connection). Thus, a user should ensure accessing the site via SSL (i.e. httpS://www.yourbanknamehere.com). In such a case, if the traffic is re-routed to the attacker controlled server, the browser returns a warning stating the name on the certificate is incorrect. (Assuming that the attacker cannot obtain a certificate for the address www.yourbanknamehere.com).
What are some of the most common malware variants that are utilizing this method? Do you find that BitB malware doing anything other than remapping entries in the Windows host file?
The BitB’s malware payload just remaps the entries in the Windows ‘hosts’ file. It executes only once and then the exploit code is removed from the victim’s machine.
Common malware variants include BitB Trojans that re-route addresses of:
- Common banks
- Popular retailer applications
When the victim attempts to access the regional search engine site, the request is in fact sent to the malicious server in the UK, unknowingly to the victim. This server intercepts the request and responds with its own search page as shown in Figure (1). As a result, any time the victim provides a search query, the request is re-directed to another attacker-controlled server, hosted too in the UK. The attacker at this point may commit ad-fraud. The ad fraud is performed by stealing the victim’s persistent cookies or attributing ad clicks to the attacker-controlled server.
Do you have any best practices the security community should adopt to prevent host file tampering?
There is some software which detects changes to hosts file (which should really be empty). Unfortunately we have witnessed some AVs taking over a week to detect a BitB malware. So while consumers are always urged to use the latest AV updates, to be careful not to download and execute unsolicited (and suspicious) software and even monitor critical system files on their machine, BitB is ultimately a business threat to online services.
Why would a malware author choose a BitB attack rather than a more full featured payload found in malware such as Zeus?
There a few reasons hackers are using the dumbed-down versions which achieve the same effect as a full featured malware.
- BitB code is two orders of magnitude simpler to write: no hooking code, no device driver code, no online traffic manipulation and drop server communications. No need for code that defeats browser sandbox solutions. Simpler code is cheaper to get! It is also easier to create new variations of this code that would evade current AV signatures.
- BitB code does not stay long on victim’s machine and leaves fewer traces (in terms of files, registry keys, etc.). This makes it much harder to identify by AV researchers and therefore extends the lifetime of exploit code (again, more economic).
- Because the BitB exploit code only runs once on the victim’s machine, when AV is updated with signatures for that specific exploit code it is too late for detection.
- The lower cost involved in running BitB operations allows the attacker to use them for a wider variety of targets. Rather than focusing exclusively on the high end banking applications, an attacker can now extend the list of potential targets to less lucrative ones (which in terms extend the lifespan of an attack campaign)
What are the primary infection vectors utilized by BitB malware?
A user usually gets infected with a BitB malware in the following ways:
- Drive by downloads / Malvertizements
- Torrent and P2P sites
- Physically installing the malware
Compare and contrast the effectiveness of the BitB attack with the Man in the Browser Attack.
As mentioned above, BitB achieves the same effect as a full featured MitB malware where its main advantage is being effective for a quick, cost-effective sting operation.
Yet, BitB attacks also have some limitations which MitB do not suffer from:
- The attack relies on the victim to make the initial access to the target application through non-SSL address (i.e. type www.yourbanknamehere.com or http://www.yourbanknamehere.com rather than https://www.yourbanknamehere.com).
- They have no built-in redundancy. If the attacker’s server is taken down the victim’s machine cannot be redirected to a different server (MitB usually have a number of drop and C&C servers. Using DNS Fast Flux they can also synchronize on such new servers in real time).
- Attackers are also restricted to only certain servers to act as a proxy as not all servers are willing to accept requests addressed to a different host name.
- Some client security software is also able to detect illegitimate changes to the local DNS mapping,
- The attacker is also unable to extend the attack at will to other applications.
Has Imperva or anyone else researched the servers/sites that BitB attack is redirecting people to?
Yes, Imperva has followed up an attacker site — to which the victim’s traffic was being redirected— in one of the large campaigns we have witnessed. This specific campaign targeted nine large Latin American banks.
In this case, the attacker-controlled server contained full-blown phishing sites for each targeted bank in order to deliver the victim the correct content to match his original request. We were even able to see which tool the attacker used in order to create the copies of the actual banking applications. By infiltrating the attacker server, we could see the list of files and folders all mimicking – whether entirely or partially – the original application.
Since we do not have credentials to these banking applications, we cannot describe the behavior following a victim’s log-on. However, from analyzing the kit itself and from prior experience of researching other phishing sites, we can imagine that once the sensitive information is logged by the attacker, the victim proceeds to the actual banking application.
Who do you think is behind the recent rash of BitB attacks detected by Imperva?
We did not track the activity to a single known source or group of attackers. However, hacking has become an industry and such attack schemes are very much part of this lucrative business. We see that behind such attacks is not just one single individual, rather different roles come into play here. Some of these roles include a researcher who sole job is to find vulnerable sites to hack into. Another cyber-criminal who purchases controls of these servers in order to rent them out to a fellow cyber-criminal. The latter sets them up as the proxy servers. Then there is also the creator of the kit, in addition there is the kit’s distributor and of course, the purchaser of the kit itself.