PLAN DE FACILIDADES DE PAGO. RÉGIMEN DECRETO N°

Url: [REDACTED].s3.amazonaws.com

Report Link:https://hackerone.com/reports/1280887

Date Reported: April 3, 2016 Bounty Paid: $2,500

Description:

Application Logic Vulnerabilities 43 We’re gonna do something a little different here. This is a vulnerability that I actually discovered and it’s a little different from Shopify bug described above so I’m going to share everything in detail about how I found this.

So, to begin with, the vulnerability described above was for a bucket which was publicly linked with Shopify. Meaning, when you visited your store, you would see calls to Amazon’s S3 service so the hacker knew which bucket to target. I didn’t - I found the bucket that I hacked with a cool script and some ingenuity.

During the weekend of April 3, I don’t know why but I decided to try and think outside of the box and attack HackerOne. I had been playing with their site since the beginning and kept kicking myself in the ass every time a new vulnerability with information disclosure was found, wondering how I missed it. I wondered if their S3 bucket was vulnerable like Shopify. I also kept wondering how the hacker accessed the Shopify bucket� I figured it had to be using the Amazon Command Line Tools.

Now, normally I would have stopped myself figuring there was no way HackerOne was vulnerable after all this time. But one of the many things which stuck out to me from my interview with Ben Sadeghipour (@Nahamsec) was to not doubt myself or the ability for a company to make mistakes.

So I searched Google for some details and came across two interesting pages: There’s a Hole in 1,951 Amazon S3 Buckets8

S3 Bucket Finder9

The first is an interesting article from Rapid7, a security company, which talks about how they discovered S3 buckets that were publicly writable and did it with fuzzing, or guessing the bucket name.

The second is a cool tool which will take a wordlist and call S3 looking for buckets� However, it doesn’t come with its own list. But there was a key line in the Rapid7 article, “�Guessing names through a few different dictionaries� List of Fortune 1000 company names with permutations on .com, -backup, -media�

This was interesting. I quickly created a list of potential bucket names for HackerOne like hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackerone.files, etc.

None of these are the real bucket - they redacted it from the report so I’m honouring that though I’m sure you might be able to find it too. I’ll leave that for a challenge. Now, using the Ruby script, I started calling the buckets. Right away things didn’t look good. I found a few buckets but access was denied. No luck so I walked away and watched NetFlix.

8_{https://community.rapid7.com/community/infosec/blog/2013/03/27/1951-open-s3-buckets} 9_{https://digi.ninja/projects/bucket_finder.php}

Application Logic Vulnerabilities 44 But this idea was bugging me. So before going to bed, I decided to run the script again with more permutations. I again found a number of buckets that looked like they could be HackerOne’s but all were access denied. I realized access denied at least told me the bucket existed.

I opened the Ruby script and realized it was calling the equivalent of the ls function on the buckets. In other words, it was trying to see if they were publicly readable - I wanted to know that AND if they were publicly WRITABLE.

Now, as an aside, AWS provides a Command Line tool, aws-cli. I know this because I’ve used it before, so a quick sudo apt-get aws-cli on my VM and I had the tools. I set them up with my own AWS account and was ready to go. You can find instructions for this at docs.aws.amazon.com/cli/latest/userguide/installing.html

Now, the command aws s3 help will open the S3 help and detail the available commands, something like 6 at the time of writing this. One of those is mv in the form of aws s3 mv

[FILE] [s3://BUCKET]. So in my case I tried: touch test.txt

aws s3 mv test.txt s3://hackerone.marketing

This was the first bucket which I received access denied for AND� “move failed: ./test.txt to s3://hackerone.marketing/test.txt A client error (AccessDenied) occurred when calling the PutObject operation: Access Denied.”

So I tried the next one aws s3 mv test.txt s3://hackerone.files AND� SUCCESS! I got the message “move: ./test.txt to s3://hackerone.files/test.txt”

Amazing! Now I tried to delete the file: aws s3 rm s3://hackerone.files/test.txt AND again, SUCCESS!

But now the self-doubt. I quickly logged into HackerOne to report and as I typed, I realized I couldn’t actually confirm ownership of the bucket� AWS S3 allows anyone to create any bucket in a global namespace. Meaning, you, the reader, could have actually owned the bucket I was hacking.

I wasn’t sure I should report without confirming. I searched Google to see if I could find any reference to the bucket I found� nothing. I walked away from the computer to clear my head. I figured, worst thing, I’d get another N/A report and -5 rep. On the other hand, I figured this was worth at least $500, maybe $1000 based on the Shopify vulnerability. I hit submit and went to bed. When I woke up, HackerOne had responded congratulating the find and saying they had already fixed it and a few other buckets that were vulnerable. Success! And to their credit, when they awarded the bounty, they factored in the potential severity of this, including the other buckets I didn’t find but that were vulnerable.

Application Logic Vulnerabilities 45

Takeaways

There are a multiple takeaways from this:

1. Don’t underestimate your ingenuity and the potential for errors from developers. HackerOne is an awesome team of awesome security re- searchers. But people make mistakes. Challenge your assumptions. 2. Don’t give up after the first attempt. When I found this, browsing each

bucket wasn’t available and I almost walked away. But then I tried to write a file and it worked.

3. It’s all about the knowledge. If you know what types of vulnerabilities exist, you know what to look for and test. Buying this book was a great first step. 4. I’ve said it before, I’ll say it again, an attack surface is more than the website, it’s also the services the company is using. Think outside the box.

7. Bypassing GitLab Two Factor Authentication