Guide to understanding XSS – XSS payloads, attack vectors, BeEF hooking, MiTM with Shank and some hi
Cross site scripting is vulnerabilities in web applications that involves injecting valid HTML or scripts in some form or way.
XSS is a very widespread vulnerability (see OWASP TOP 10) on the internet today. It is both easy to eliminate and easy to detect. It is however usually harder to exploit than for example SQL Injection. According to OWASP it is also stated to have moderate impact when exploited, however I find this very debatable. According to Ed Skoudis this vulnerability can have catastrophic effects!
XSS Payload – Presented in 3 different ways
Non-persistent (often called reflected XSS)
A non-persistent XSS is when you are able to inject code and the server returns it back to you, unsanitized. Often this can be exploited by distributing an (usually innocent looking) URL in some form or way for others to click on. It is important to note that this type of payload is not stored on the system being attacked, e.g. in a database.
This type of a attack can be particular effective when you are dealing with focused attacks against someone. As long as you can make someone click an URL with the necessary payload there is a chance you can gain elevated privileges on the system.
If you are able to make the end system store your payload (persist) the attacks becomes much more dangerous very fast. A persistent XSS payload is reflected back to you from the server (not just by clicking a link), usually because the XSS has been stored in a database field or similar. The user is then presented with an attack served by the webserver itself thus making it look legal.
Consider the following input is stored to database and then presented back to you on your profile on the victim site:
<input type=”text” value=”Your name” />
If you are able to make the application accept and store unsanitized input, all you have to do is make other users view your profile (or wherever the XSS is reflected back). The payload would then be run on the client system in trust that the victim host was meant to send you the payload.
These kinds of XSS can be not only hard to spot, but very devastating to the victims. Just take a look at Samy worm which we described earlier on this article.
In the early days of the internet this XSS attack was very frequently exploited. Regularly you would see this kind of exploit all over guestbooks, forums, user reviews, chat rooms and so on. The following image describes a usual sight for an old school internet
In order to describe the seriousness of this type of attack consider if such an exploit was present in eBay’s auction service. Anytime someone visits your auction they automatically bid on the auction. This type of attack would most likely be trivially easy to exploit unless proper protection is put in place.
Of course criminals would modify the URL to make it more innocent looking for the untrained eye. The same payload as above just encoded differently:
It is suddenly much harder to tell it apart from non-harmful parameters.
You can even mask it better when sending to email clients that support HTML like this:
Two attack vectors
Now that you know the different ways of delivering a XSS payload I’d like to mention a few XSS attack vectors that can be very dangerous.
As you can see from the image, this exploit was found on Amazon.com. It is in fact a quite spectacular exploit because it involved the book XSS Attacks: Cross Site Scripting Exploits and Defense which was uploaded to Amazon. The book was made available for preview and thus, because no proper sanitation, the payloads in the book was executed against anyone looking to buy the book.
Cookie stealing and session hijacking
Ahh.. The classic cookie stealing exploit.
Like in one of the examples above, once you can access users cookies you can also grab sensitive information. Capturing sessionID’s can lead to session hijacking, which in turn can lead to elevated privileges on the system.
Sitting on the other end, at the webserver, you will be receiving visitors revealing the users cookie from the victim site. The data is sent through the x parameter where after the double space is the users cookie. Even if the file that is being used is a .GIF file it may still be a programmable script that stores the values in a database. You might strike lucky if an administrator clicks the link, allowing you to steal their sessionID , hijacking their session and allowing you to become administrator of the victim site.
Using techniques like spam email, message board posts, IM messages, Social Engineering Toolkits, this vulnerability can be very dangerous.
If the .GIF file does not exist on the server you are controlling it will simply show up as a 404 file not found, but still revealing the parameter to the file. The attacker can scrape the server logs or use a custom written script to pick up all the session ID’s and proceed to hijack them in order to further exploit the target. This is an example of what it could look like in the server log:
The value PHPSESSID is the valuable part in this attack. Using this value as your own may in most cases allow you to act as that person in the respective web-application. Simply by editing your own cookies and replacing the PHPSESSID value with the new value will usually allow you to become someone else.
Exploiting XSS with BeEF
To easy see how XSS can be exploited I recommend trying out BeEF, Browser Exploitation Framework. Once you unpack and run it on a webserver you can easily try spawning a simulation of a victim (called a zombie) where you can very easy try out different XSS payloads. To mention some:
•Get page HTML
•Create alert boxes and command dialogs
•Ask the user to reauthenticate
•Redirect user to other pages
•Integrated with Metasploit!
•Send java payload
•Ping sweep network
•Keylogger / event sniffer
•Find browser details
•Autorun exploits when connected to BeEF
Injecting XSS when Man in the Middle
If you can become Man in the Middle (MITM) on a target you may very well inject valid HTML code into the packets going through your computer. Although this is a rather new technique to me it is a very interesting and effective way of exploiting users. This type of exploiting users via XSS was known to me via a presentation done on Blackhat by Ryan Linn (web, twitter) and Steve Ocepek (twitter) from Spiderlabs.
By combining Shank with BeEF you have a very interesting attack vector. This type of attack will let you more easily persist hooks on victims. Some of the features this vector allows for can be:
- Poison anyone using HTTP with BeEF hooks
- Persist the hooks when browser changes pages
- Create more subtle and stealthy attacks on the browsers
History on XSS
The Samy worm (js.spacehero)
- 1 million friend requests (source:http://namb.la/popular/)
Remember MySpace? Yea, me neither.
Barack Obama’s site redirected to Hilary Clinton
An attacker managed to find a XSS vulnerability in barackobama.com. The payload involved redirecting all visitors to hilaryclinton.com. Even though it is quite harmless for visitors it coul
d potentially have an impact on Obama’s campaign.
CNN Forecasts false tornado warning in Florida
A couple of years ago there was a link to CNN about a hurricane warning that went viral in a very short time. The link contained information about an incoming hurricane that would hit Florida in a matter of time.
This type of XSS is what we call non-persistent XSS and will be explained further down in the article. The link itself contained the payload in one of the parameters, but people did not recognize as the site they arrived at was CNN and the story seemed like just like the rest of the page.
This type of “prank” could cause numerous effects, probably not intentional. To list a few:
- Hysteria / panic
- Increased sales of emergency ration
- Closed business deals
- Cancellation of travel tickets
- … Do feel free to leave a comment if you can come up with more side effects.
[important]This question appeared in my security.stackexchange.com feed a while back and I decided to answer it. The link to the original can be found here: http://security.stackexchange.com/a/1373/294.[/important]