Rootkits in your web application
28C3: Chaos Communications Congress, Berlin, Germany (2011)
Despite a few high profile cases of XSS worms, the exploitation of script injection vulnerabilities has historically been mostly limited to cookie-stealing and executing simple malicious actions in the context of the affected Web application. However, as a consequence of inter-document interactions allowed by 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 script injection attacks against Web clients, describe techniques to escalate an XSS into long-term account compromise, and introduce the concept of resident XSS where attacker-supplied code is injected into the user's main application window. Additionally, I explore the similarities between such Web bugs and traditional rootkits. In particular, I:
- Provide an overview of script injection vulnerabilities and describe real-world considerations for exploiting them against modern Web applications.
- 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.
- 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).
- 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.
- 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.