Rootkits in your web application
Abstract
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.
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.
Research Areas
