XSS/CSRF to a real command-shell

[Joseph McCray <joe () learnsecurityonline com>]

Ok - I'm tired of beating my head against this wall on the subject - so
some friends and I decided to put something together. I'm calling in the
cavalry because I'd like to see if someone else is working on this
before we get knee deep into development.


Situation:
I usually categorize XSS as a medium unless it is on a public facing
and/or critical server in which case I classify it as a high. I'm
looking to be able to BETTER illustrate the dangers of XSS to customers,
and to move beyond cookie/session theft via XSS. If I could get XSS to
at least be a stepping stone to full control over a machine then I could
possibly classify it as a high, and for real fun of the job - have a
shell.


To make a long story short - I want to take XSS/CSRF to a REAL
command-shell.


What I've seen out there:
I've seen XSSshell/XSStunnel/XSS-proxy/beef/etc...

To the extent that I've seen the tools listed above (which IS NOT
extensive), and various other XSS-like attack tactics (CSRF/Java looks
promising with the socket capability) - I've yet to see someone able to
actually take an XSS vuln all the way to a command shell. (Yes, I did
see the DNS-Rebinding attack with LiveConnect but that seems very
limited - at least with my understanding of it).


My Guess:
1. I'm assuming that you'd be able to coerce the victim into clicking
the XSS link, browsing to a location where the XSS code will be
executed, or something similar. Fine....

2. I'm GUESSING, that we could further coerce the victim to download a
trojan of some sort, or vulnerable application/browser plugin/activeX
control that we can exploit and have it kick back a reverse shell giving
us control of the host at least in the context of the active user at the
time so no guarantee of admin rights but at least it's a shell.


Concerns:
A lot of clicking you'll have to make the victim do:
1. I'm figuring that the user is going to have to be coerced into doing
something stupid at least twice (once to be XSS'd, and twice to click
yes I will download/run this app). Honestly it seems like it'd be easier
for me to just email the user a trojan and skip even dealing with XSS in
the first place. No matter what it's still a user-interaction exploit.

Browser Hell:
2. Browsers are becoming increasing difficult with all of the SUCKurity
features (pop-up blockers, noscript, firekeeper, verification of digital
signatures, HTTP only cookies, etc). I'm thinking this attack
methodology will have to compensate for that. I'm really looking for
some input from someone that is comfortable with this stuff.


Is anybody working on this, or something similar?
I'm really looking to speak with someone that is ACTIVELY working on
something like this, or is interested in developing it. Maybe something
like the Javascript Attack API with the functionality to
download/execute other code. 

P.S...yes I have already joined the Javascript Attack API group so no
you don't need to recommend that to me.

Feel free to contact me offline - this is something I'm really
interested in and would like to dedicate some time to.


Thanks in advance guys....happy hacking.


-- 
Joe McCray
Toll Free:  1-866-892-2132
Email:      joe () learnsecurityonline com
Web:        https://www.learnsecurityonline.com


Learn Security Online, Inc.

* Security Games        * Simulators
* Challenge Servers     * Courses
* Hacking Competitions  * Hacklab Access

"The only thing worse than training good employees and losing them 
is NOT training your employees and keeping them." 

        - Zig Ziglar

Attachment: signature.asc
Description: This is a digitally signed message part