Fixing the Unfixable: Story of a Google Cloud SSRF | Hacker News Reader

Fixing the Unfixable: Story of a Google Cloud SSRF

bugs.xdavidhu.me

137 pointsmooreds17 comments

> A Cloud Storage bucket called cxl-services.appspot.com, which had hourly log files of all of the requests the cxl-services App Engine app has ever received, since 2017-10-18 up until today! These files could have contained some sensitive data of users interacting with the product page demos.

Ouch. Surely this is a violation of Google's own privacy policy and possibly GDPR? How did this make it to prod?

It is a violation of the GDPR if this data wasn't returned to people who asked for their data. I can almost guarantee it was not...

Someone might want to refer Google to one of the data protection authorities here...

It is also a violation of the GDPR (Art. 25) if Google cannot prove they implemented the "appropriate technical and organisational measures" to protect personal information, both at the time of designing that system, and at the time of actually exploiting that system with live traffic.

Nah also just the principle of data minimisation - if there is no good reason to save it (this long) then it shouldn't be saved. A DPA would probably have Google pay for that if it would come that far.

Smokescreen by Stripe [1] is the only reliable way I’ve seen apps handle untrusted URL accesses. It’s an open source CONNECT proxy project.

Validating the URL at the app layer is difficult because a redirect could happen to an attacker URL, or DNS rebinding attack, etc, proxying via Smokescreen seems the most reliable if you’re dealing with user controlled arbitrary URLs.

[1] https://github.com/stripe/smokescreen

I don't see how this could help. The main danger here seems to be that the custom proxy is adding an authentication token for internal resources which is leaked if an external resource is accidentally requested, but at the same time, the auth token being included is actually required for the functionality they're trying to implement.

It would have stopped the request being made to the attackers server in the first place.

Smokescreen sits between your app server and the destination URL that was requested, as a proxy server, that has ACLs/rules about what URLs and domains it allows to talk to on behalf of the app server.

You define allowed or blocked domains/routes in Smokescreen, and it’s the one that decides to access the remote URL or not.

So in the above example, the app server would still have been tricked to request the attackers URL with its auth token included, but smokescreen would have realised that server/domain isn’t in its allow list, and blocked the app server attempt to access the attackers sever with the auth token by refusing to even attempt to connect to the attackers server in the first place (and returns a HTTP error back to the app server).

Is smokescreen an alternative to Squid? Seems like they cover similar ground, but I’ve never heard of smokescreen before.

https://github.com/squid-cache/squid

Fun write up, and good on Google for letting him draw from the same well another two times in bypassing their patches.

$3K seems kind of small for this.

It's worse than a joke

It's the Mechanical Turk approach to pentesting. Find people who will work for small amounts of money, but find lots of them.

He got $3k and a $1k bonus the first time around, and another $3k for each of two failures to resolve the issue. At the end of the day, that's over $10k.

My point was that any one of these issues alone should have paid out more than $3K it was a RCE inside google's infrastructure. The fact that he could repeatedly find it should have paid out even more.

Agreed

So, why the hell does WHATWG want to treat \ as /?

That made me smile. A little persistence paid off 3x! And Google just paid.

Reply on news.ycombinator.com