Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

An internal GCP project called cxl-services is used for internal requests within some other service. The author does not give a description of what it does at all.

The application has an allowlist for the domains that can be called internally using this service. When validating the URL, the parser falls for the '\@' trick, which even the original RFC gets wrong.

The issue is that https://[your_domain]\@jobs.googleapis.com thinks the authority is jobs.googleapis.com but the library making the request makes the request to [your_domain] with a path of /@jobs.googleapis.com. Hence, the verification differing from the usage causes the vulnerability.

Why does this SSRF cause a problem? Most of the time, the attacker gets access to an internal network. In this case, an authorization token for App Engine is in the request, which is now leaked to us.

With the access token in hand, the author wanted to demonstrate impact without jeopardizing the company. They found a few other projects that the authorization token had access to (docai-demo, p-jobs, garage-stating, etc.). They took rigorous notes on the requests they made, in order to help Google with incident response.

The patch for the bug was pretty terrible: block all usage of '\@' next to each other. So, adding anything between these (such the URL https://[your_domain]\_@jobs.googleapis.com) still caused the SSRF. After fixing this, they found ANOTHER issue. There are still old vulnerable versions of the AppEngine app running, which needed to be patched.

Overall, interesting bug and a trick that I did not know about! Verification corresponding to actual usage is hard to do properly. Additionally, lots of bugs are not fixed properly the first time!