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

大家好离我上一篇文章已经有一段时间了,但是我回来了,我想告诉你们一个关于我迄今为止最伟大的发现的短故事(我的第一个 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:

它在 Google VRP 程序中,为什么你总是可以在301/302/403/404状态页面中检查 dirs,因为你会惊讶地发现有些目录列表会起作用:

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

2019年11月19日: 我被邀请参加谷歌年度安全事件 ESCAL8,我的演讲是关于我如何发现这个漏洞的更多细节,以下是关于这个漏洞的推特摘录和幻灯片:

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/fastrecon-ESCAL8-2019.pdf …

感谢你们邀请我在 # escal8 # bugswat # initg@GoogleVRP 活动、超级毒品活动、超级毒品人@sirdarckcat Tomasz@wtm offensi@WHHackersBR@LiveOverflow & all VRP Hunters 上发言,这样美好的一周 Fast reconcon 幻灯片的 https://twitter.com/omespino/status/1191224520646045696是如此的 https://omespino.com/fastrecon-escal8-2019.pdf ..



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

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

标题: springboard.google.com 产品/URL 中的认证绕道: 通过谷歌 VRP 程序发送的 springboard.google.com/redacted_dir / https://goo.gl/vulnz 报告



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

Https://springboard.google.com/redacted_dir 中的授权旁路,请参阅“ OnContent Debug for”迷你仪表板



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

1.-去 https://springboard.google.com/ ,然后被重定向到 https://cloudsearch.google.com/cloudsearch/error?et=6,看看这条信息

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

2.-然后导航到 https://springboard.google.com/redacted_dir ,看到一个迷你仪表板,上面有以下格式:

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.

3天后,我收到一条消息: 乍看之下,这可能不够严重,不足以获得奖励,尽管评审小组很快会进行调查。



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

不幸的是,一个星期后,我收到了来自谷歌 VRP 面板的回复: “作为我们脆弱性奖励计划的一部分,我们决定它不符合金钱奖励的标准。”



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

由于 bug 可能不会挽回获得金钱奖励,我开始思考更深入的“ Auth 绕道”,我的意思是,由于某些原因不支持是开放的,所以我决定再试一次,然后在一些新的目录枚举与 wfuzz,我得到了真正有趣的东西,我能够升级简单的 Auth 绕道 bug 到 LFI 在生产服务器上的管理员在谷歌生产服务器。注意: 对于那些想知道我是如何找到 REDACTED dir 的人,我使用 wfuzz 在 https://springboard.google.com/文档中强制一个目录列表,并过滤非302重定向响应,这些响应给出了我的 https://springboard.google.com/redacted_dir ,因为302重定向我到 http://cloudsearch.google.com 文档,我在重定向之前强制执行了这个目录列表

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

标题: 同一子域中生产服务器上的 LFI 产品/URL: springboard.google.com/redacted_dir/another_dir



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

我已经能够升级这个鉴定绕过对 LFI 在谷歌生产服务器上作为“ gxx-xxxx”用户(管理员权限) !



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

1.-首先看到仪表板面板的“ Redacted status main”(FrameworkInfo)在 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

图2。- 然后,如果你导航到“显示 REDACTED”(最后一个选项) ,你将被重定向到 https://springboard.google.com/redacted_dir/another_dir?file=/proc/self/environ ,/proc/self/environ 将被加载

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!

图3。- 只是为了确保是一个完整的 LFI 工作,我试图加载另一个文件,我检查了/proc/version 和工作正如预期!

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)

然后我的心脏停止了一秒钟,我刚刚在 google 生产服务器上获得了一个 LFI 作为管理员(服务器是复数形式的,因为每次刷新/proc/self/environ 文件时主机名都会更改)

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.

说实话,我曾经尝试升级到 RCE,但是没有成功,因为很明显它非常坚固,我无法读取/proc/*/fd、 ssh 密钥、服务器密钥或任何日志。



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

任何浏览器(我使用的是谷歌 Chrome 最新版本)不需要认证或任何谷歌帐户

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)

特殊媒体提及: Intigriti (Bugbounty 平台)2019年5月28日 Intigriti Bug 字节 # 20 write up of the week (另一个 Google LFI)

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

Hackerone (Bugbounty 平台)2019年5月29日 Hackerone Zero Daily 2019-05-21(我们正在阅读的其他文章)

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

报告时间轴2019年3月22日: 发送报告给谷歌 VRP (只是旁路授权部分)2019年3月22日: 从谷歌收到消息,该漏洞已被分类2019年3月25日:2019年4月1日: 收到一条消息说他们将用这个 LFI 信息填补另一个漏洞2019年4月4日: 收到一条消息说第一个漏洞无法挽回经济回报,2019年4月23日: 因为所有的事情都发生在同一份报告中,而且 bug 也被修复了,我问团队这两个 bug 是否不是挽歌或者发生了什么: 我收到了一条消息,对于这种混乱表示抱歉,我只能等待 LFI 部分的新奖励决定。2019年5月21日: 13,337美元奖金和发表这篇文章的许可收到

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

就这样,分享你的想法,你觉得他们是怎么处理安全问题的?如果你有任何疑问,评论或建议,只要在这里或 Twitter@omespino 给我留言,稍后再读你。


Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 注销 /  更改 )

Google photo

您正在使用您的 Google 账号评论。 注销 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 注销 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 注销 /  更改 )

Connecting to %s