Rootkits in your web application

In this work, I discuss practical approaches for exploiting cross-site scripting (XSS) and other client-side script injection vulnerabilities, 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 traditional rootkits, including similarities in the areas of embedding malicious code, maintaining access, and the difficulty of detecting and removing attacker-supplied code. Details 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. 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. 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. A video of the presentation.

• Security, Privacy and Abuse Prevention