Boy-in-the-Browser attacks are hard to detect, BUT easier to execute
The Boy in the Browser is a sophisticated trojan, a "dumbed-down" version of MitB. 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. It is very difficult to detect since the victim's address bar continues to present the address of the intended destination. For example, you as an infected victim are surfing to a bank's website, but in fact, that traffic is sent to the attacker. Yet, on your browser, you continue to the bank's normal website.
Once all traffic is re-routed via the attacker, the attacker can do whatever it wants with that data. For example:
- It can act as a proxy just logging sensitive information before passing the request on to the original destination.
- It can act as an "active" proxy modifying requests (for example, to transfer sum to a different bank account) before passing it on.
- Committing fraud schemes. For example, we have seen a scheme which defrauds Google.
This is a growing, resurging, trend amongst hackers, since, in short, it works. Since these trojans are so quick to evolve, anti-viruses do not always detect variants. More people fall prey to these attacks as they are so difficult to detect. Hackers have realized this and are continuing to release more and more variants of BitBs.
A Man in the Browser intercepts user requests and server responses while "sitting" on the victim's browser. In effect, it listens directly on that communication. For example, when the victim is authenticated to the bank and requests a transfer from his checking account to savings account. The trojan may modify that request in order to make a transfer from the checking account to an account in the Ukraine.
In the case of a BitB, the trojan redirects the traffic to a 3rd-party site which is an attacker-controlled server. This means that all traffic does not go immediately to the bank, rather it passes through that extra link. Only at that server, can the attacker modify the transaction request before continuing to pass it along to the original destination.
Let's consider first MitBs – these are a huge deal for enterprises and banks to deal with for the following three reasons:
- Impact user transactions.
- Very difficult to detect. - They last a long time.
Similarly to the MitB, BitB is just as dangerous and just as hard to detect. However, this sort of attack requires much less resources for attackers to execute. There are two main required resources:
1. The trojan code.
2. Attacker- controlled server.
As opposed to MitB, the BitB trojan code is much simpler to write. It is a very short piece of code to redirect the traffic. As for the server, they just require a domain. Today's automated tools will set up the server within just a couple of clicks. The BitB setup is a no-brainer. However, the MitB code is much more complicated. Consider your banking application. It has tabs for different operations, different options for transactions and in general, quite a complex application. The MitB code needs to be customized for each of these operations in order to hook into each of the application's feature. The big guns are required to carry out these MitB schemes.
Each of these Trojans have the same impact and scare banks and businesses alike. BitB is much easier for an attacker to pull off. However, they are most useful for a one-shot sting operation. Once uncovered, the attacker-controlled server is shut down and business is as usual. On the other hand, MitB attacks are a continuing process much more difficult to fight out once uncovered. In that case there is no single pain-point to bring down.
Imperva have witnessed BitB as a resurging as a tool of attack. Below are a couple of notable ones that they have seen:
1. Nine Latin American banks were targeted. This is one more supporting evidence that BitB is in fact a lucrative scheme. As hackers gain from this sort of attack, they continue to target numerous banks.
2. Click fraud. This is an interesting scheme since the target is not a banking application, rather it is used in order to commit fraud. In this case, to defraud Google. The victim accessing a regional domain of Google, for example www.google.co.uk would be redirected to the attacker-controlled server. When a user performs a query, the attacker would fetch the results and ads from Google, but serve them on his own page. The result is that when a user clicks on a specific ad, the commission is attributed to the attacker, and not to Google. 36 Google regional domains were targeted in this scheme showing that the attacker's aimed to target victims worldwide.
The Latin banks were a classic case which provided no visual clues as to the traffic take-over. On the other hand, with the click fraud campaign, the visual clues were ridiculously apparent as we show in our advisory on the site.
Imperva's research arm, the ADC, has established the Hacker Intelligence Initiative (HII). Under this initiative, the researchers attempt to understand the threat landscape. Their research methods involved:
1. Tapping into hacker forums
2. Monitoring and recording attacker traffic
3. Analyzing attacker resources
As part of the HII ongoing research, they witnessed these campaigns being carried out. The team started investigating and this lead to further understanding of hacking operations.
Although BitB is presumably the consumer's problem, one cannot expect the user to know that his browser is under an attacker's control. For sake of comparison – even anti-anti virus do not flag most of these Trojans as malware as they are so quickly being modified. It is time then for online services, such as banks and retailers, to recognize this problem and provide solutions. Similar to the car industry where accidents drove the manufacturers to deal with car safety by providing seat belts, anti-brake lock systems, air bags, etc, the online banks need to consider how to deal with infected customers.
Boy-in-the-Browser attacks have the same impact as a Man-in-the-Browser attack and are just as hard to detect, BUT they are easier to execute. Banks need to start paying more attention to these types of attacks and provide the correct response to deal with them.