- Report #ID: Undisclosed
- Reporter: tolo7010
- Weakness: Open Redirect
- Asset: Web Application
- Bounty: $300
To focus on the technical discussion, this blog post uses example.com as a demonstration domain.
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:
In this case, when I visited :
the server redirected to:
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:
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
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.com302 Found Found The document has moved here .
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.comredirect 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.
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.