In September, we released our XSS Payloads collection of scripts and they went down really well within the pen-testing community. There are lots of other fun things you can do to exploit cross site scripting and so we’ve recently added another couple of payloads.
The payloads described in this post can be found at https://github.com/nettitude/xss_payloads.
Finding a cross site scripting vulnerability isn’t always as simple as having <script>alert(1)</script> returned back to you. Sometimes, tools like Burp Collaborator or Sleepy Puppy can identify XSS in areas which you won’t even have access to. I still recall being blown away by Burp Collaborator identifying that the web service I was injecting into was having its data reflected in an entirely inaccessible Intranet, allowing browser code execution within the client’s own internal network. The payload that Burp had generated to find this was suitably ninja-like:
But what next? How do you go from a simple request generated by a Burp Collaborator event into access to the client’s internal Intranet? Step one is to understand what you’re looking at, and that’s where recon.php comes in. If executed on a remote page, recon.php will gather as much information as it can about where it was executed:
- Non-HttpOnly cookies
- The current URL
- The HTML of the current page
- The user agent string
- User’s IP
and send it back to itself where it can be logged to either a file or a database.
You can then plan, based on what comes back, what your next attack might be. In many cases the contents of this response might contain enough information to immediately launch an exploit.
Another potentially valuable attack, especially in the context of a phishing campaign, is to hijack an existing form so that any information entered into it is captured, sent back to the attacker and then forwarded back on to the original site without the user noticing. This would work really well in areas such as login forms – with an XSS vulnerability you could carry out a credential harvesting campaign against a site, without having to go through the hassle of cloning the original login page and hosting it on a look-a-like domain; the user would be going to the real site.
On it’s own this is powerful, but we can exploit browser functionality and make it even better. By adding in and then hiding other form fields, we can exploit browser autofill and trick the user’s browser into giving away all the personal information that it has stored.
What formjacker.php does then, is to change all of the action URLs of all forms on a page to itself, add in a load of common personal information fields such as phone number, address and credit card information and then allow the user’s browser to automatically propagate them. All this info is transmitted back to us, the attacker. The script then dynamically creates a copy of the original form and submits it back to where it was originally supposed to go, all without the user noticing.
Here is a demonstration of the attack within a test environment:
The user just sees the same form they normally would:
They can even view source. Note that we have our script included in the page header.
However, if we look at what HTML the browser has in memory…
We can see that we’ve just added in a load of contact information fields. Note that they all have an absolute position of -500px which positions them outside of the browser view, effectively rendering them invisible. Despite this, Chrome will still autofill the fields with any information it has, so when a user hits submit…
All of this information is received by the script, which then writes it all to file or database.
The script then responds by creating an auto-submitting form to send the user back to where they were expecting the form to submit to, hopefully leaving them none the wiser that we just stole their data.