Thursday, November 1, 2018

[Open Redirect] When your PoC doesn't work because of the server load balancers

References:
- Report #ID: Undisclosed
- Reporter: tolo7010
- Weakness: Open Redirect
- Asset: Web Application
- Bounty: $300

Note:
To focus on the technical discussion, this blog post uses example.com as a demonstration domain.

Summary:
On Feb 2nd, 2018, I found an Open Redirection vulnerability on a new private program web application to which I was invited. This bug occurred because the server failed to construct redirection links. By design, the web application redirected all endpoints to www prefix version, for example:

https://example.com/page1

redirects to:

https://www.example.com/page1

In this case, when I visited :

https://example.com/page1

the server redirected to:

https://www.example.compage1

Apparently, the server did not add slash '/' between the domain and the path. I reported the bug to the program with the following PoC:

Steps to reproduce:

  1. Go to https://example.com, the browser redirects to https://www.example.com (intended behavior),
  2. Go to https://example.com/test -> https://example.comtest (unknown host),
  3. Go to https://example.com/.attacker.com, the browser redirects to https://www.example.com.attacker.com
See the following sample request/response:
[Request]:
GET /.attacker.com HTTP/1.1
Host: example.com
User-Agent: ...
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
Cookie: ...
Connection: close
[Response]:
HTTP/1.1 302 Found
Date: Fri, 02 Feb 2018 11:44:56 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 219
Connection: close
Server: ...
Location: https://www.example.com.attacker.com

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.example.com.attacker.com">here</a>.</p>
</body></html>

However, after a few days, the team responded saying that the PoC did not work. Here is the message:

We need some more information before we can properly review this report. Is it possible you could provide a clear step-by-step PoC? I'm not able to reproduce the URL redirect, requesting https://example.com/.attacker.com redirect me to https://example.com, Thanks again for your report and we hope to hear back from you soon.

After that, I rechecked again and was surprised that, by executing the same endpoint multiple times, sometimes the server redirected to the attacker domain, and most redirected to the home page correctly.

I executed the nslookup (> nslookup example.com) command to check for the server addresses, the web was using Amazon server service to host their load balancers. I asked the team to check that and they responded on the next day:

Thanks for the great report!
We confirmed the existence of the issue and have worked on fixing it.
Thank you so much for your help, Tolo!

After confirming the issue, the bug was fixed in a week and I was awarded a $300 bounty.

Impact:

The impact was quite low since this happened on one of the server load balancers. The victims had to follow the attacker crafted link multiple times until the vulnerable load balancer redirects them to the attacker domain.

Advice for hackers:

When your PoC doesn't work, try to determine if it happens on a load balancer by executing your endpoint multiple times.


If you have any opinions or suggestions, please leave comments below.

2 comments: