Thought the list might find this interesting . . .
-------- Original Message --------
Subject: [security] Remotely Controlling XSS Attacks - Announcing XSS-Proxy
Date: Thu, 10 Feb 2005 18:33:20 -0700
From: Rager, Anton (Anton) <arager@avaya.com>
To: <bugtraq@securityfocus.com>
All,
I presented on this topic this past weekend at Shmoocon, but wanted to
also brief the list on my persistent remote control XSS attack methods
and a demonstration tool I've developed.
I've combined common XSS exploitation techniques with Javascript
Remoting and Session-Riding to create an attack tool that uses an XSS
vulnerable site (or sites), and a victim that loads our XSS vector, to
create a remotely controlled, interactive, two-way attacker
command/control channel to the victim. The PoC demonstration tool is
called XSS-Proxy and is a lightweight, Perl based attacker tool that
provides the command/control channel to a victim browser by translating
attacker requests into victim Javascript and collecting/displaying
victim results to the attacker.
This tool provides a persistent attacker command/control channel to the
XSS'd victim and allows the attacker to provide additional commands to
the victim with the victim forwarding readable document contents
/results back to the attacker. It basically attack allows the attacker
to drive the victim browser over the vulnerable site and perform most
actions the victim could (like reading pages and submitting forms). The
victim browser continues to loop and look for additional commands from
the XSS-Proxy controller indefinitely, and can be controlled as long as
we can keep the original XSS'd site window open - I call these idling
victims "Browser-Zombies". We aren't just reading cookies anymore: we
are requesting the victim load arbitrary documents off a target XSS'd
server, submit forms (POST or GET) to XSS'd server and set/evaluate
javascript vars/functions within the victim browser. This is useful for
exploiting XSS vulnerable sites/users where cookies are not the primary
mechanism for authentication by allowing an attacker to leverage trust
relationships the victim may already have with target sites via cached
authentication, client side certificate auth, IP access controls and
perhaps even victims/targets behind firewalls. It is also possible to
leverage this platform/attack for Cross-Site-Request-Forgery (CSRF) /
Session-Riding attacks on non XSS vulnerable servers, multi-XSS site
redirection (a list of sites to see if this user may have privs on),
Masqueraded attacks on specific XSS vulnerable target servers (think
Nikto thru someone-else's browser), MITM attacks on interactive victim
windows and possibly even leverage CSRF traffic to look for other XSS
flawed servers.
I have a draft whitepaper that provides more detail on the basic XSS
based Javascript Remoting attack and outlines some approaches/details on
methods for extending the attack even further at
http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt. The XSS-Proxy
demonstration tool is available at the project section of the same site
(http://sourceforge.net/projects/xss-proxy). My Shmoocon slides and
links to additional primer information on XSS attacks can be found at
http://xss-proxy.sourceforge.net
I am not a WWW developer, so may have missed some other implications
and/or more elegant ways of implementing this sort of attack, but the
basic attack does work and the XSS-Proxy tool allows it to be explored
more. I had a lot of positive feedback from Shmoocon, but I'm very
interested in other researcher feedback as well as other related ideas
for extending persistent, intelligent and controlled
XSS/Session-Riding/CSRF attacks.
I think it's time folks pay more attention to XSS issues....This
attack/tool is way more evil than just cookie theft.
Regards,
Anton Rager
arager@avaya.com, a_rager@yahoo.com
_______________________________________________
security mailing list
security@lists.seifried.org
http://lists.seifried.org/mailman/listinfo/security
