In my previous column I took a look at one of the most popular strategies used by malware to commit fraud – the man in the browser. As a quick review, Man-in-the-Browser (MitB) malware works by infecting an end-user and injecting malicious code that silently runs in the victim’s browser. This allows the malware to not only control what the user sees in the browser, but also to take actions within the browser that appear to come from the user.
As an example, suppose that you have been infected by MitB malware. The next time you login to your bank, the malware could silently send a funds transfer from your account to the criminal’s or a mule account. You never see this transaction, but from the bank’s perspective it appears that it came from you. Worse still, when you check your bank account later, you don’t notice that any money is missing because the MitB malware can adjust the account balance you see in your browser. So let’s take a look at some of the more common defenses available today, and how they can work together.
Network-based signatures are useful for detecting and blocking many different types of network attacks, and most IDS/IPS products and WAFs include signatures to identify Man-in-the-Browser attacks. And while these signatures are an important layer of security, there are key challenges to this approach to keep in mind.
First, since the end-user’s computer is already compromised by malware, the true exploit that an IPS traditionally looks for has already occurred. Instead, the IPSs and WAFs must rely on detecting anomalies or artifacts associated with known pieces of malware such as distinctive user agents or IP addresses. Attackers can easily evolve to hide or change these indicators to avoid detection. Furthermore, we have to keep in mind that a great deal of a MitB lifecycle remains on an infected user’s computer and may not actually traverse a network at all. For example, MitB malware may locally inject a script into the user’s browser to create false form fields to harvest personal data, or alternatively may alter the data presented to the user in order to hide a theft. This behavior remains on the client side and would never been seen on the network.
However, and you may be detecting a pattern at this point, this approach is not a silver bullet either. Client-side protections for MitB suffer from many of the same challenges that have plagued the antivirus industry in many years. Namely, malware is constantly evolving both its executable code as well as the scripts it injects into a page in order to evade signatures. Additionally, there is always the circular problem of depending on client-side software to secure a system that is itself already compromised. Rootkits can undercut local AV, and savvy malware can attempt to disable security measures in the browser.
While client and network security are both important pieces of the puzzle, banks often depend most heavily on behavioral analysis of user transactions in order to detect MitB fraud today. By analyzing a user’s transaction history, the bank can often identify suspicious transactions before the transfer is finalized. Suspicious new payees tied to the user’s account or transfers to foreign banks can be an immediate red flag. Likewise, patterns such as small transactions that regularly accompany a legitimate transaction can highlight that MitB malware may be skimming from the user’s valid transfers. This approach has proven to be very powerful at finding and stopping fraud.
However, it is by its nature both reactive and dependent on anomalies – meaning that banking security teams must balance precariously between letting criminals walk out the door with stolen money versus potentially disrupting the legitimate transfers of their customers. Additionally, banks benefit from the ability to review transactions before they settle, which provides the time to analyze rich sets of data. As MitB continues to branch out to other non-financial targets such as the recent attack on Salesforce, this window of analysis may disappear. For instance, Salesforce is designed as a self-service data source, and must decide in real time whether or not to fulfill a request such as a list of all the company’s customers.
Application Self Protection
New approaches are also emerging in the fight against Man-in-the-Browser. Dr. Joseph Feiman at Gartner recently championed the concept of runtime application self-protection or RASP. As the name suggests, this approach focuses on the application itself, and in the case of Man-in-the-Browser, the application in a RASP context is the website or web app. The concept of RASP is that unlike an external security device, security that resides within an application can have native insight into the internal workings of that application including its logic, configuration, and data flows. This opens the door to see exactly how an attacker is attempting to abuse an application in ways that may not be readily apparent from the outside looking in.
In the case of MitB, the malware contains scripts that take advantage of the predictable nature of a web application to modify the end-user’s experience, or conversely, to impersonate a user transaction to the webserver. RASP technologies can disrupt these all-important scripts that attempt to automate the target application logic. Like the other countermeasures mentioned earlier, RASP is unlikely to provide a silver-bullet, but it does provide an enticing application-centric approach to MitB problem.
The most important aspect for us as security professionals is to realize that the man-in-the-browser is not going away, and to understand what exactly has made it so successful. As applications continue moving to the web, MitB is poised to be an ongoing thorn in the side of many applications across all industries. Safely serving an end-user who is already infected with malware is no easy task, and one that will require an intelligent, coordinated approach to security.