Submitted by Ziv Mador and Ryan Barnett
This blog post will summarize a recent talk that we (Ryan Barnett and Ziv Mador) gave at the RSA 2014 conference where we showed how tactics used by different cyber-criminal gangs could be used by defenders.
Turning the Bad Guys Against Themselves
You may be familar with the Ouroboros symbol where a Serpent is eating its own tail. It symbolizes cyclicality and self-recreation and is applicable to the constant battles that security vendors/researchers have when facing bad guys. For our presentation, we used a modified version called "Dual Ouroboros" where you have two Serpents eating each other's tails.
This is the essence of the concept that we wanted to promote in our talk where we want to leverage the tactics and techniques used by one group of criminals and apply them defensively to help protect against a different criminal element.
Standard Adversarial Relationship
Typically, there are are pairings of security vendors (products) vs. malware families. In the following diagram, we have Web Fraud Detection vendors squaring off against Banking Trojan malware such as Zeus/SpyEye.
During these battles, there is a constant "Arms Race" where defenders try to develop new methods for detection malicious behaviour and criminals try to evade or hide from defensive detection methods. The following cartoon is a perfect example of the type of iterative Arms-Race process we are fighting.
Let's take a quick overview look at these four key players.
Banking Trojans
Symantec released a very good infographic entitled "The State of Financial Trojans 2013" that provides relevant data as to scope and impacts. Here is a table from that report that lists the top banking trojan families.
Zeus' Webinject Functionality
One of the key capabilities of banking trojans are "webinjects" where the malware is able to dynamically modify the raw HTTP data just before/after the web browser. Here is an example of different webinjects that manipulate various login page HTML in attempts to phish extra data from users.
As a real example, we showed the following "webinjects.txt" data in our live presentation demo that attempts to trick the user into providing their ATM PIN number:
When an infected user goes to the "login.html" page on the fake banking site, the login form would look like the following:
If the user enters in this data, Zeus will grab the information and send it off to a Command & Control (C&C) web site where the banking trojan operator can use this information to conduct account takeovers or to initiate fraudulent Electronic Fund Transfers (EFTs) siphoning money out of the victim's account into money mule accounts. Here is an example screenshot of fraudulent EFTs from the Zeus C&C interface:
Client-side Web Fraud Detection Examples
Web Fraud Detection vendors use many different techniques to identify fraud activities but we will focus on the top two:
Client-side Device Identification/Browser Fingerprinting
How unique, and trackable, is your web browser? Web Fraud Detection vendors are able to identify an incredible amount of data about end users by enumerating various device/browser characteristics. If you want to test our your own web browser, go to the Panopticlick website to check. Here is an example snippet when I went there using Google Chrome:
The webpage checks many different characteristics of my web browser including:
- User-Agent
- Accept Headers
- Browser Plugin Details
- Time Zone
- Screen Size
- System Fonts
By correlating all of this data, my browser was considered unique amongst almost 4M browsers tested. This data, as opposed to IP Address information, is a much more robust method for tracking users of your web application. Here is an example of updated HTML for the fake banking login page with new javascript calls to Web Fraud Detection code:
The "md5.js" script simply provides client side hashing capabilities. The "fingerprint.js" file implements many of the same browser environment checks that Panopticlick looks for.
When this code executes, it will will generate a client fingerprint hash and then send this back to the server in a beacon request -
Server-side fraud detection processes can then check this fingerprint against reputation systems to see if this client has been associated with any fraud activities.
Webpage Integrity
The key defensive capability we need to identify if a banking trojan has manipulated the HTML data that left the web application is to be able to validate the data once it reaches the browser. With this concept in mind, we can leverage the work done by the University of Washington Computer Science and Engineering team on a project called "Detecting In-flight Page Changes with Web Tripwires." Here is a a quick visual -
The "webtripwire.js" javascript call in the HTML issues an XHR request back to the web server for the same page but this time is includes a new "WebTripwireCheck: On" header:
This results in the following request/response -
The HTTP response now includes the "WebTripwireHash" header. The client-side javascript then calculates the hash of the actual response and then compares it with the header hash. If they do not match, then an alert issued to the user:
Zeus Removes Fraud Code
The "webinject" functionality is actually a misnomer. In addition to being able to "add" extra data to the HTML, it also has the ability to REMOVE or manipulate data. It is this capability where Zeus can be used to neuter client-side fraud detection code. Here is an updated webinject entry that will strip out all data in between the "data_before" and "data_after" HTML.
This technique effectively renders the Fraud Detection code useless.... How can we protect our defensive code against webinject removal from Zeus?
Exploit Kits
Exploit kits are the mechanisms used to exploit client-side vulnerabilities to deliver malware payloads to victim's computers. Here is a quick list of the top Exploit Kits SpiderLabs tracked for Q4 2013 -
Here is the typical Exploit Kit attack flow where a user goes to a website that has been compromised and it includes a malicious IFRAME that points to the actual Exploit Kit code.
Use of Obfuscation
Here is an example of some Blackhole Exploit Kit code that checks for various plug-in/software versions before sending the exploit payloads -
This code would be easily identified by static signature detection systems. In order to evade detection, Exploit Kits use obfuscation techniques. Here is an example of the same code, however it has been put through a basic Ceasar Cipher data substitution change -
This is functionally equivalent code as web browsers would execute the javascript and it would return the original code.
Interestingly, both Exploit Kits and Web Fraud Detection Code have the same challenge: How can they protect their code and evade detection by their adversary?
Using Exploit Kit Obfuscation Techniques for Defense
Why can't we re-use the same type of Obfuscation used by Exploit Kits to protect our Web Fraud Detection code?
The idea is to take our stanard banking login HTML and place it inside a layer of javascript obfuscation. Here is what the new HTML looks like for our login page -
Again, the user notices no different in functionality as the page renders properly and our Anti-Fraud code triggers as normal. Zeus, on the other hand has problems. Zeus gains access to the raw HTTP data stream by using the wininet.dll library. It modifies the data outside the context of the Internet Explorer web browser. This means that, at the point in time where webinjects would run, the layer of javascript obfuscation prevents webinject from triggering on the normal HTML tags.
So Defenders Win, right?!?!?
The Arms Race Continues...
The use of Exploit Kit Obfuscation techniques used to protect defensive code is a novel idea, however in the end this is only a roadblock. Banking Trojan operators have way too much money on the line to just give up. Therefore, we surmize that they would respond to this type of defense by modifying Zeus source code to implement De-Obfuscation algorithms.
Here is an example of the modified "httpgrabber" Zeus code that includes the new De-Obfuscation algorithm -
This code can be used by specifying the new "O" flag in the "set_url" definition -
This modified configuration would result in the following -
- Zeus would de-obfuscate the raw HTTP data in intercepts with wininet.dll
- Strip out the Anti-Fraud Detection javascript code
- Issue a webinject to add in the fake "ATM PIN" form field
Backporting De-Obfuscation Routines to Secure Web Gateways
As we work through our gaming theory of probably response actions, we have come to the place in time where Banking Trojan authors have implemented de-obfuscation routines within their code to try and normalize the data. We could then take this updated de-obfuscation functionality and supplement the existing ones within the SWG appliances.
The end result being that one cyber criminal element (Banking Trojan authors) would be helping security vendors to better detect another cyber criminal element (Exploit Kits).
Beyond Obfuscation
We demonstrated one defensive technique in this blog post, obfuscation, however Exploit Kits also use other tacticts that we leverage. One example is polymorphic variable names where the values of key variables change upon each invocation of the page. Here is an example screenshot of the polymorphic variables in our demo -
By changing these variables each time the page is loaded, it makes it more challenging for static analyzers (or banking trojans) to normalize.
Conclusion
What we demonstrated in this blog post is a single tactical example (using Exploit Kit obfuscation to protect defensive code) of a more strategic concept (using attacker tactics for defense). While this particular use-case to break the functionality of banking trojan webinjects is cool, it is not panacea. What we really want to promote as a takeaway concept for this topic is this -
Know Your "Friend's" Enemy
Far too often, defensive security personnel are stuck in an echo chamber as they are locked in on battling their adversary. You may in fact gain inspiration and revelation by talking with security practitioners/researchers in a different knowledge domain. This often happens when the SpiderLabs Research malware, client/server and vulnerability teams interact with each other. The result is that each team comes away with new ideas to implement within their own security domains.
