SANS Internet Storm Center, InfoCON: green: Web security subtleties and exploitation of combined vulnerabilities, (Thu, Jun 25th)
The goal of a penetration test is to report all identified vulnerabilities to the customer. Of course, every penetration tester puts most of his effort into finding critical security vulnerabilities: SQL injection, XSS and similar, which have the most impact for the tested web application (and, indeed, it does not hurt a penetration testers ego when such a vulnerability is identified :)
However, I strongly push towards reporting of every single vulnerability, no matter how harmless it might appear (and my penetration team coworkers sometimes complain about this, but lets prove them wrong).
Here well take a look at how two seemingly low risk vulnerabilities can be combined into a more dangerous one.
Accepting parameters in GET and POST requests
When processing parameters/responses received from the client, most of the todays web applications rely on POST HTTP requests. This is a preferred way of sending client-related input/output from the browser since it will not be visible in web servers (or proxys) logs. One of the tests I normally do is to check if the application accepts same parameters in GET HTTP requests. Lets take a look at this.
The official”>POST /page HTTP/1.1
“>parameter=value”>GET /page?parameter=valuesecret=secret_value HTTP/1.1
If this worked it means that the tested web application (the tested page/script) accepts parameters from any request. While this by itself is not really a security vulnerability, it is not a perfect way for receiving and processing parameters as we will see below. Additionally, keep in mind that this makes an attackers job a bit easier instead of working with POST HTTP requests he can simply put everything into GET HTTP request (yeah, it works for the defenders as well since well see what he put into the request).
A seemingly harmless XSS vulnerability
While further testing this application we found an XSS vulnerability. For sake of simplicity lets say its an anonymous application that has no login forms. However, since the application depends on a certain workflow, and since the XSS vulnerability was found in the 3rd step of the workflow, it does require a valid session cookie (aJSESSIONID cookie).
What does this mean? It means that the attacker cannot exploit the XSS vulnerability: if the request to the vulnerable page is made without a valid JSESSIONID cookie, the application simply redirects the user to the front page (the first step of the workflow). Even if the victim now again clicked on the malicious link, it still wouldnt work because the tested application checks the workflow phase/step and if it is not correct again simply redirects the user to the front page.
Ahh, such a disappointment after finding a very nice XSS vulnerability: the attacker can really exploit only himself and thats no fun at all. Or is there another way?
Taking this a bit further
Remember how we figured out that the application accepts parameters in both GET and POST HTTP requests above?
Since the cookie is normally sent as part of a header, the attacker cannot get the victims browser to set the cookie for the target web application, at least not without exploiting another vulnerability such as an XSS vulnerability but remember that we cannot exploit it without a valid cookie. Catch 22 isnt it?
But, let”>GET /page?JSESSIONID=560308266F93351159D8D20732C637FAmeter=valuesecret=secret_value HTTP/1.1
Bingo! This worked the tested web application happily took and parsed all submitted parameters, even the JSESSIONID parameter that should be normally delivered as a cookie. The developers probably wanted to be as flexible as possible.
Combining the vulnerabilities into an exploit
So, the attacker can now deploy the following attack:
- Create a new session where he navigates to the required screen. The application now knows that the JSESSIONID cookie that was given to the attacker relates to a session that is at the vulnerable screen.
- Create a malicious URL that exploits the XSS vulnerability. Append the JSESSIONID parameter that contains the attackers cookie value to the malicious URL. This URL will work because the vulnerable web application will verify the session state and see that the user is accessing a valid screen in the workflow.
- Send the malicious URL to the victim, wait and profit.
Finally, last thing to discuss is maybe what we exploit with the XSS vulnerability in the first place: typically the attacker tries to steal cookies in order to gain access to the victims session. Since here sessions are irrelevant, the attacker will not use XSS to steal cookies but instead to change what the web page displays to the victim. This can be used for all sorts of phishing exploits and, depending on the URL and context of the attack, can be even more devastating than stealing the sessions.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.