I recently came across across a request on a bounty program that took user input and generated an image for you to download. After a little bit of a journey, I was able to escalate from XSS inside of an image all the way to arbitrary local-file read on the server. It’s a private program, so I’m going to do my best to redact as much information as possible.
Airbnb recently created a new feature called Experiences which allows you to book things to do rather than places to stay. With the new code changes that came along with Experiences, we discovered a page that allowed you to send yourself a text message with a link to download the Airbnb app. This sent a POST request to an API endpoint we had never seen before. Using the JS Parser tool we built we discovered another API call associated with it. We found that these API calls were vulnerable to Insecure Direct Object Reference (IDOR) and allowed you to view all messages on Airbnb by ID.
@nahamsec and I discovered a Cross-Site Scripting vulnerability a few months ago related to Rails typecasting request variables into JSON. This caused the output to be JSON formatted and the JSON indexes would avoid XSS encoding. We decided to run with this concept and explore the rest of the website to see if we could identify other vulnerabilities using the same method. Along the way we discovered an interesting output from the /api/v1/listings/[id]/update API request. This led us to finding a Remote Code Execution vulnerability on Airbnb due to Ruby on Rails string interpolation.
- LivePerson reached out to me (3/9/17) after this write-up was posted and pushed out changes to patch the open redirect vulnerability. Props to their security team for following up on that!
Ben and I spent more time on Airbnb the past few months and discovered a new endpoint that we had never seen before. After spending a year or so on the program, we were at the point of trying to find a new approach looking for vulnerabilities.
We had the idea of going through all of the js files on Airbnb looking for new endpoints. We were already doing this manually to some degree, but decided to try and automate it. So we built a new tool that grabs js files and looks for relative URLs:
Doing this we quickly found new endpoints that we had missed and found a few new vulnerabilities to report. One of the new endpoints discovered led to finding a Server-Side Request Forgery vulnerability on Airbnb.
We recently started participating in Airbnb’s bounty program on HackerOne. We heard a lot about this company in the past but had never used their service before. Overall they have a pretty solid website, but we were still able to discover a handful of issues. There is one vulnerability that we wanted to write about because of the level of protection in front of it. The goal of this write-up is to show others that sometimes it takes a little bit of creativity to discover potential flaws and fully exploit them.
The vulnerability we discovered is a series of Cross-Site Scripting attacks that involved bypassing JSON encoding, an XSS filter, a pretty decent WAF, CSP rules, and eventually getting it to bypass Chrome’s XSS auditor.
Council of 9 ventured forth to DEFCON 24 to compete in this year’s badge challenge, brought to us each year by 1o57. There was determination among the team to win at DC24 to ensure that last year’s win was not a fluke. After many sleepless nights in Vegas, we emerged victorious for a second year in a row.
Full write-up: http://co9.io/post/148716614744/defcon-24-badge-challenge
Participating in bounty programs the past few years I have seen a lot of discrimination against what has been dubbed Self Cross-Site Scripting (XSS). This is a version of XSS that can only be exploited by the victim due to either protection by the server or the method of attack is strictly client-side with no way for an attacker to force a victim to execute.
Lately I have seen programs state that they do not accept any form of self-XSS. I will give some scenarios to explain the various types of self-XSS, their impacts, and how they can be exploited to hopefully debunk some misconceptions that these are not vulnerabilities.
Scenario 1: DOM Based Self-XSS
Google CTF – Web 11 – Flag Storage Service
A challenge involving injecting into Google’s Query Language (GQL) using a blind boolean technique to extract a password from the database.
For anyone familiar with the Counter-Strike competitive scene, you know about ESEA. They just recently launched a bounty program that puts their website, game client, and game servers in scope for security research.
I spent a night taking a look over the website and found a few vulnerabilities. The most interesting discovery was a Server-Side Request Forgery vulnerability. Using a cool trick that Ben Sadeghipour (@NahamSec) showed me, I was able to pull private information from ESEA’s AWS metadata.