Recently I’ve been working through pentesterlabs exercises to learn a bit more about identifying and exploiting security flaws in web applications.
During one of the labs I came across an awesome tool called socat this tool has the ability to listen to multiple connections and act as a TCP relay port. Netcat does have similar functionality, however it will stop after the first connection, whereas socat will keep forking.
socat can be configured to echo HTTP GET requests, this is particularly useful if we want to view session cookies in the HTTP GET header.
Lets say we wanted to steal a session cookie from a victim, possibly even the administrator of a web page. A fairly common way to do this is to find a persistent XSS flaw in the web app. This is what we could do:
First locate the XSS flaw, then drop the following Script tag which write an Image tag to the web page.
When a victim visits the web page, the image tag will be loaded. The image tags URL grabs the victims cookie and as a result, it will be sent to the malicious server located at .129.
In the mean time on .129 we have an instance of socat running listening on port 80 for HTTP GET requests.
The victims Session ID
qsp5uk0n9m6ctf568e928u5jc2 was passed along, and from here we can easily hijack their session using something like cookie manager:
So, what can be done to mitigate this? Without getting overly technical good start would be to use secure/safe coding practices and implementing adequate XSS filters.
Ultimately, using Image tags to grab Session ID’s isn’t exactly new, in fact, most modern web pages have decent XSS filters in place to prevent users sessions from getting hijacked. The whole point of this was just to show you how cool socat is and what could happen if there is an XSS vulnerability on your web site.