I don't do bug bounties due to a lack of time. Although I have a HackerOne profile, you can see that I'm not so active. However, a coworker of mine spends quite some time on different bug bounty programs.
On 2017-02-06 evening, when we were both connected to our work Jabber server, he told me that YouPorn had launched their bug bounty program on HackerOne:
him: youporn bug bounty launched today btw
me: on hacker one?
me: no time, i'm migrating my DNS servers
As I was reading documentation on bind, he wrote me back:
him: oh shit, exploitable XSS in the search bar, can't believe it
Now, things were interesting! I had to hop in. I was also surprised that nobody had ever found it before. XSS in the search form is the base case. I often go to errr, some of my friends often go to YouPorn, and they've never found such a vulnerability on it before.
Time was of the essence, because we wanted to have a working exploit and report it before someone else did.
From lack of filtering to open redirect
I fired up my browser and Burp, and sent a request on the search form. I
foobar". As you can see in the following screenshot,
the search term is output, without any filtering (except for the capitalization)
in a meta tag:
Disappointed, we still decided to exploit the meta HTML tag. It's a powerful
tag, because it has the
http-equiv directive. This directive allows
you to define the equivalent of an HTTP header in the HTML code.
http-equiv directive can take a value of
can be used to redirect a user to another page. This kind of open redirect
vulnerability can be very useful in case of a phishing attack:
- You send someone a link to http://youporn.com, with your payload;
- Your payload redirects them to a site you control, imitating YouPorn's CSS;
- You ask them for their credentials, their credit card number, etc.
We put the following payload to test our vulnerability:
As you can see, there is a slight problem: the dash in
is not inserted in the source code. I decided to use some XSS voodoo bypass,
and so, I decided to HTML encode, then URL encode the dash.
-, HTML-encoded is
-, which, URL-encoded, is
Boom, we now had a working payload, and were able to redirect users to a URL of our choosing. Sweet!
Marked as duplicate
Just as I had found the correct syntax, my coworker, who had already notified YouPorn, got the following answer:
In fact, this was reported already, but the original reporter did not provide a working exploit. What I should do is to close it as duplicate, because the original bug was already reported. However I will leave it open so you have a chance to provide a working payload. Note that the original ticket was triaged. If you find a working payload, I will triage your ticket as well as you managed to go further in the exploitation.
Thanks and happy hacking
From open redirect to full reflective XSS
So that was it, somebody had already reported the vulnerability. However, YouPorn had kindly decided to let the report open, so that we could find a working payload, and we already had one with the open redirect payload.
But then I thought "Wait a second, maybe I can use the same trick to put
< instead of a dash!"
We continued to do some tests afterwards, and we found out something weird about YouPorn's HTML rendering: no matter how many recursions of HTML-encoding we did on our payloads, they were still fully decoded server-side. This means that:
Weird behaviour, but very interesting to bypass some filters!
Anyway, I still have to migrate my DNS servers.
- 2017-02-06: Report sent to YouPorn
- 2017-02-06: Response from YouPorn saying that this bug was already reported, but that we could keep trying to find a working payload
- 2017-02-06: Working payload sent to YouPorn
- 2017-02-06: Report triaged
- 2017-02-10: Bounty paid, $250
- 2017-02-03: Bug fixed
- 2017-03-04: Request to disclose publicly the report
- 2017-03-28: Public disclosure of the report granted