|
Collin Jackson Stanford University |
Dan Boneh Stanford University |
John Mitchell Stanford University |
Current phishing attacks steal user credentials, either by directing users to a spoofed web page that fools them into revealing a password, or by installing key-logging malware that records user passwords and sends them to the phisher. In response, web sites are deploying a variety of back-end analytic tools [4,10,12] that use past user behavior to determine transaction risk, such as the time of day when the user is typically active and the user's IP address and location. Some sites are moving to stronger authentication using one-time password tokens such as RSA SecurID [14]. These methods, as well as many other anti-phishing proposals [13,6,9,7,15,5], focus primarily on reducing the value that phishers derive from stolen passwords.
Fortunately for thieves, and unfortunately for the rest of us, a new form of attack using a Transaction Generator (TG) allows criminals to manipulate user accounts directly without stealing user credentials or subverting authentication mechanisms. TG attacks generate fraudulent transactions from the user's computer, through malicious browser extensions, after the user has authenticated to the site. A TG quietly sits on the user's machine and waits for the user to log in to a banking or retail site. Once the authentication completes, web sites typically issue a session cookie used to authenticate subsequent messages from the browser. These session cookies reside in the application environment and are fully accessible to malware. A TG can thus wait for the user to securely login to the site and then use the session cookie to issue transactions on behalf of the user, transferring funds out of the user's account or purchasing goods and mailing them off as ``gifts". To the web site, a transaction issued by a TG looks identical to a legitimate transaction issued by the user -- it originates from the user's normal IP address at the usual time of day -- making it hard for analytic tools to detect. Since TGs typically live inside the user's browser as a browser extension, SSL provides no defense against a TG. Moreover, a clever TG can hide its transactions using stealth techniques discussed in the next section. To date we found only few reports of TGs in the wild [1], but we anticipate seeing many more reports as adoption of stronger authentication becomes widespread.
In Section 3 we explore a number of mitigation techniques, including transaction confirmation. A transaction confirmation system consists of isolated client-side software and a trusted path to the user that enables web sites to request confirmation for transactions that the site deems risky. We discuss the design of a web-based confirmation system and emphasize that a confirmation component is necessary in identification systems such as CardSpace and OpenID.
At a first glance, a Tranasaction Generator may appear to be related to Cross Site Request Forgeries [3] (CSRF). A CSRF attack is due to an incorrect implementation of user authentication at the web site. To prevent CSRF attacks the web site need only implement a small change to its user authentication system. The modification is transparent to the user. In contrast, transaction generators running inside client browsers are much harder to block. All the proposed defenses in Section 3 require changes to the user experience at the site.
TGs can lead to many types of illegal activity such as,
Transactions generated by a TG will show up on any transaction report page (e.g. an items purchased page) at the web site. A clever TG in the user's browser can intercept report pages and erase their own transactions from the report. As a result, the user cannot tell that fraud occurred just by looking at pages at the site. For example, the single JavaScript line in Figure 2 removes all table rows on a transaction history page that refer to a blender. We have tested this code on several major retailer web sites.
Moreover, suppose the user pays credit card bills online. The TG can wait for the user to log in to her credit card provider site and then erase the fraudulent transactions from the provider's report page, using the same one line of JavaScript shown above. The sum total amount remains unchanged, but the fraudulent transaction is not in the list of transactions. Since most consumers do not bother to check the arithmetic on report pages from their bank, the consumer will pay her credit card bill in full and remain unaware that the bill includes a stealthy fraudulent transaction. This behavior is analogous to how root-kits hide themselves by hiding their footprints on the infected system.
The net result of stealth techniques is that the consumer will never know that her machine issued a non-confirmed transaction and will never know that she paid for the transaction.
We discuss three potential mitigation techniques against the stealthy TGs discussed in the previous section. The first two are easy to deploy, but can be defeated. The third approach is the one we advocate.
Here we propose a simple web-based confirmation system that can be deployed with minimal changes to the web site. The system combines confirmation with the checkout process. On the client-side the system consists of two components:
Security relies on two properties. First, the agent's secret key must be isolated from malware. Second, the confirmation dialog must not be obscured by a malware popup to ensure that the user confirms the correct transaction details. Similarly, malware must be prevented from injecting mouse clicks into the agent's dialog. We discuss our prototype implementation in the next section. Note that simply spoofing the confirmation dialog is of no use to the TG since it cannot generate the necessary MAC itself.
Our prototype confirmation system is built on top of the CardSpace identity system in Microsoft's Vista. We could have used other anti-phishing proposals, based on passwords [13,6,7,15] or security tokens [14,9]. CardSpace, however, includes a convenient authentication UI. Although CardSpace has a ``private'' desktop designed for ordinary malware resistance, this desktop may be vulnerable to privileged malware or operating system flaws. We further isolate CardSpace from malware using VMware. CardSpace runs on the host OS while the browser runs in a guest.
The prototype is implemented as a browser extension for Mozilla Firefox. The confirmation agent is implemented as a helper application for CardSpace and runs on the host OS. The agent and the Firefox extension in the guest communicate via network sockets. The agent interacts with the user and with CardSpace to generate the transaction confirmation MACs.
Transaction generators are a source of concern for enterprises engaged in online commerce [2]. As stronger authentication systems are deployed, we expect transaction generators to pose an increasing threat. This emerging form of malware hijacks legitimate sessions and generates fraudulent transactions using legitimate credentials, instead of stealing authentication credentials. By operating within the browser, transaction generators can potentially hide their effects by altering the user's view of information provided by any site. Consequently, it is necessary to extend identity systems to include a Transaction Confirmation component. As an example defense, we designed SpyBlock, a browser extension and confirmation agent that provide a simple mechanism for web sites to request confirmation. Our prototype is available at www.getspyblock.com.
