28C3 - Version 2.3.5
28th Chaos Communication Congress
Behind Enemy Lines
| Speakers | |
|---|---|
|
Artur Janc |
| Schedule | |
|---|---|
| Day | Day 2 - 2011-12-28 |
| Room | Saal 2 |
| Start time | 20:30 |
| Duration | 01:00 |
| Info | |
| ID | 4811 |
| Event type | Lecture |
| Track | Hacking |
| Language used for presentation | English |
| Feedback | |
|---|---|
|
Did you attend this event? Give Feedback |
Rootkits in your Web application
Achieving a permanent stealthy compromise of user accounts with XSS and JS injection attacks.
XSS bugs are the most widely known and commonly occurring Web vulnerability, but their impact has often been limited to cookie theft and/or simple actions, such as setting malicious email filters, stealing some data, or self-propagation via an XSS worm. In this work, I discuss practical approaches for exploiting XSS and other client-side script injection attacks, and introduce novel techniques for maintaining and escalating access within the victim's browser. In particular, I introduce the concept of resident XSS where attacker-supplied code is running in the context of an affected user's main application window and describe its consequences. I also draw analogies between such persistent Web threats and the traditional rootkit model, including similarities in the areas of embedding malicious code, maintaining access, stealthy communication with a C&C server, and the difficulty of detecting and removing attacker-supplied code.
Despite a few high profile cases of XSS worms, most XSS exploitation attempts have so far been limited to cookie-stealing and executing simple malicious actions. However, as a consequence of the same-origin policy and a combination of other browser mechanisms, a single XSS vulnerability can often lead to a long-term compromise all of a user's interactions with an affected webapp in the same browser profile, long after the original bug has been fixed. In particular, an attacker can maintain access across window/browser closures, survive cookie and cache deletions, and compromise other user accounts accessed from the same browser. Yet more troubling is the fact that Web application authors currently have no means to detect or mitigate such threats once an attack has taken place.
In the talk I provide an overview of techniques to escalate an XSS into long-term account compromise, and explore the similarities between such persistent Web bugs and traditional rootkits. In particular, I:
1) Introduce the concept of resident XSS, where malicious JavaScript is executed in the context of the victim's main application window/tab. Contrary to the traditional methods of exploiting XSS via a hidden frame or malicious link which are opened in a separate, usually short-lived window, resident XSS gives an attacker full freedom to monitor and alter the user's interaction with the affected application.
2) Describe several techniques to convert various Web bugs into a resident XSS. Such techniques include backdooring client-side persistent storage mechanisms (WebSQL, localStorage, Flash LSOs), opening poisoned application windows with injected malicious scripts, exploiting persistent (self-)XSS and others.
3) Discuss the consequences of resident XSS, which usually allow the attacker to get permanent access to an affected user's account and/or obtain the user's application login credentials. On sensitive domains for which users have enabled access to additional browser or plugin features (geolocation, camera/microphone), it can enable persistent snooping on the exploited user. In a large number of cases it can also enable full compromise of the user's machine by exploiting the application-user trust relationship (e.g. by requiring the user to install attacker-supplied plugins to use the affected webapp, or by hijacking file download links within the vulnerable domain).
4) Analyze the techniques for maintaining access to a once-compromised origin. In addition to backdooring persistent storage APIs, this can be achieved by exploiting self-XSS bugs, spawning same-origin pop-unders with references to the original window, and hiding in frames created by advertising networks on popular websites. In most cases, a combination of those techniques suffices to bypass a variety of the most common "cleanup" actions taken by users, and allows an on-going compromise of the affected origin.
5) Present the difficulties faced by Web application authors when trying to clean up a compromised origin. Short of wiping/re-creating a browser profile, there are currently no fully reliable methods to restore a browser's state to a secure configuration once a malicious script has run in the context of an affected domain.
I will present the above with concrete examples of vulnerable applications and a demo.