Meet beautiful XSS in your area: a YouPorn bug bounty [SFW]

Posted on mar. 28 mars 2017 in Bug bounty

youporn_logo.png

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?

him: yes

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 searched for 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:

first_payload.png

However, when we tried to close the meta tag, and open another one, to put our Javascript payload, we couldn't get it to work:

first_fail.png

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.

The http-equiv directive can take a value of refresh, which 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:

  1. You send someone a link to http://youporn.com, with your payload;
  2. Your payload redirects them to a site you control, imitating YouPorn's CSS;
  3. You ask them for their credentials, their credit card number, etc.

We put the following payload to test our vulnerability:

second_fail.png

As you can see, there is a slight problem: the dash in http-equiv 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.

A dash, -, HTML-encoded is -, which, URL-encoded, is %26%2345%3b:

first_success.png

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 > and < instead of a dash!"

And indeed, it worked. With the "HTML-encode-then-URL-encode" trick, we could insert arbitrary Javascript:

second_success.png

Obligatory pop-up:

w00t.png

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:

  • &lt; became <
  • &amp;lt; also became <
  • &amp;amp;lt; also became <
  • etc.

Weird behaviour, but very interesting to bypass some filters!

Anyway, I still have to migrate my DNS servers.

Timeline (YYYY-MM-DD)

  • 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