WRITE UP – GOOGLE BUG BOUNTY: LFI ON PRODUCTION SERVERS in “springboard.google.com” – $13,337 USD

Hi everyone It’s been a while from my last post but I’m back, I want to tell you a short story about my greatest find so far (My first P1)

It was in Google VRP program and why you can always check for dirs in 301 / 302 / 403 / 404 status pages because you will surprise that some times some directories listing will work:

[ U P D A T E ] 19 NOV 2019: I was invited to Google yearly security event called ESCAL8 as speaker and my talk was about how I found this bug in more detail, here is a tweet extract about and the slides:

https://twitter.com/omespino/status/1191224520646045696
Thank you for having me as speaker on #ESCAL8 #bugSWAT #initg @GoogleVRP event, super dope event, super dope people @sirdarckcat Tomasz @wtm_offensi @WHHackersBR @LiveOverflow & all VRP Hunters, such a nice week Fast Recon GG slides https://omespino.com/fastreconGG-bugswat2019.pdf …

FIRST ROUND

Title: Auth bypass in springboard.google.com
Product / URL: ​springboard.google.com/REDACTED_DIR

Report sent via google VRP program https://goo.gl/vulnz

Summary:

Authorization bypass in https://springboard.google.com/REDACTED_DIR and see “OnContent Debug for” mini dashboard

POC:

1.- Go to https://springboard.google.com/ and got redirected to https://cloudsearch.google.com/cloudsearch/error?et=6 and see the message

2.- Then navigate to https://springboard.google.com/REDACTED_DIR and see a mini dashboard with the form:

3 days after that I got a message:

At first glance, this might not be severe enough to qualify for a reward, though the panel will take a look shortly.

Spoiler:

Unfortunately, after a week, I got the reply that from google VRP Panel:

“As a part of our Vulnerability Reward Program, we decided that it does not meet the bar for a financial reward

SECOND ROUND

Since the bug probably won’t be elegible to get a financial reward, I started thinking to go deeper on that “Auth bypass”, I mean, for some reason is not suppoused to be open, so I decided to try again, then after some new dir enumeration with wfuzz, I got something really really interesting, I was able to escalate that simple Auth bypass bug to LFI on production servers as admin in google production servers.

Note: to any people that wonders how I have found the REDACTED_DIR, I used wfuzz to brute force a dir list in https://springboard.google.com/  and filter the non 302 redirect responses that gave me as result https://springboard.google.com/REDACTED_DIR  , since the 302 redirected me to http://cloudsearch.google.com  I did that brute force before the redirect

Title: LFI on production servers in the same subdomain
Product / URL: ​springboard.google.com/REDACTED_DIR/ANOTHER_DIR

Summary:

I’ve able to escalate this auth bypass to LFI on google production servers as “gxx-xxxx” user (admin privileges)!

POC:

1.- First see that the dashboard panel of “Redacted status main” (FrameworkInfo) is open in https://springboard.google.com/REDACTED_DIR/ANOTHER_DIR

2.- Then if you navigate to “Show REDACTED” (The last option) you are going to be redirected to https://springboard.google.com/REDACTED_DIR/ANOTHER_DIR?file=/proc/self/environ and the /proc/self/environ will be loaded

3.- Just to be sure that was a full LFI working I tried to load another file and I checked with /proc/version and works just as expected!

Then my heart stopped for a second, I just got a LFI on google production servers as administrator (servers on plural because each time that I refreshed /proc/self/environ file the hostname changed)

To be honest I tried to escalate to RCE but I hadn’t any success, since apparently it was very hardened I wasn’t able to read /proc/*/fd, ssh keys, server keys or any logs.

Environment

Any browser (I used Google Chrome Lastest version)
No authentication or any Google account was needed

Rank 62th in Google HOF (May 2019)

Special Media Mentions:

Intigriti (Bugbounty platform) May 28, 2019
Intigriti Bug bytes #20 write up of the week (Another Google LFI)

Hackerone (Bugbounty platform) May 29, 2019
Hackerone Zero Daily 2019-05-21 (Other articles we’re reading)

Report Timeline

Mar 22, 2019: Sent the report to Google VRP (Just the bypass auth part)
Mar 22, 2019: Got a message from google that the bug was triaged
Mar 25, 2019: Bug Accepted
Mar 25, 2019: Reply about that the bug was in revision in Googgle VRP panel
Mar 30, 2019: I found the LFI and sent the new POC in the same report
Apr 1, 2019: Got a message saying that they going to fill a another bug with this LFI information
Apr 4, 2019: Got a message saying that the first bug wasn’t elegible for financial reward
Apr 17 ,2019: Since the everything was happening in the same report and the bugs were fixed, I asked to the team if the 2 bugs wasn’t elegibles or what happened
Apr 23, 2019: Got a message saying that sorry about the confusion and I just had to wait to a new reward decision for the LFI part.
May 21 2019: $13,337 bounty and permission to publish this write up received

well that’s it, share your thoughts, what do you think about how they handle that security issue? if you have any doubt, comment or sugestion just drop me a line here or in twitter @omespino, read you later.

36 thoughts on “WRITE UP – GOOGLE BUG BOUNTY: LFI ON PRODUCTION SERVERS in “springboard.google.com” – $13,337 USD

    1. Hey Andreas, this actually why I share any finding that I can, so the people see that it is possible, if I can do it you can too, thanks for reading.

  1. No doubt thousands of hackers would have stumbled upon this subdomain but you managed to pull this one off. Congrats for the bounty and amazing writeup. Keep up the good work bro and you do have inspired me to start learning more. Thanks 🙂

    1. Hey Azaz, that’s why I write this blog, to share my grain of salt and give some back to the community, pretty cool, if I can do it you can do it, thanks for reading.

  2. Hi, when you do bug bounty, for example on Google, do you use some anonymity system, like tor? Or you use a specific header on your requests? Thanks.

    1. Hey thanks for reading. no actually I didn’t use anything like that, just perform the scans from Digital Ocean VPS without proxies, special configurations, headers, etc, the trick is that some google subdomains do not block the bruteforce / ports scans, specially the google corp ones

  3. Hi, thanks for your reply. May i ask which dir list did you use to find the non 302 responses? Cause it seems that i could not find the keyword “REDACTED_DIR” from wfuzz cloned in GitHub. Thank you.

    1. Hey the “REDACTED_DIR” means that I wasn’t able to make public that folder name, is “REDACTED” or non-public because google asked for hide that name before publish the write up, for the 302 I used wfuzz options, it has the –hc option to hide http status respones, that in my case since I was looking just for http status code 200, the command was something like this “wfuzz -c -w ./wlist.txt –hc 301,302,307,400,401,402,403,404,410,429,500,501,502,503,504 https://springboard.google.com/FUZZ“, and for the wlist I just use the danielmiessler’s seclists from github.

      thanks for reading

      1. Thanks for this amazing write-up, I really would like to know your recommendation on the wordlist to use, seclist has tons of wordlist and that makes it difficulty to choice the correct one for dir bruteforce and also I would love to Know if there is any wordlist for parameter bruteforce, not sure if that’s a thing. Thanks for the write up once again.

        1. Hey thanks for reading, I created a custom list from Fuzz and Discovery/Web-Content, but to be honest at the end I always use the all.txt from Jhaddix and wait, for parameter bruce forcing I never look for that but I have reading that Arjun by somd3v is really cool to do that https://github.com/s0md3v/Arjun

    1. Hey, I just update this blog with some slides about my talk in google security yearly event called ESCAL8 where I describe in more specific detail how I have found this but, and also explain how I have found that parameter, thanks for reading

Leave a Reply

Your email address will not be published.