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!

The author had automated fuzzing tools setup on cloudcrmipfrontend-pa.googleapis.com. This was responding to 200 for some suspicious endpoints, many of which were public debugging endpoints. Notably, /v1/integrationPlatform:getProtoDefinition was logging internal source code protobuf information. Not a major vulnerability by itself, but useful for hunting on Google-based products.

They seemed to really like working with protobuf. In the past, they created the tool req2proto. He joked with his friends that this is just req2proto as a service. From there, they decided to probe for more debugging endpoints. ListQuotaQueueResponse contained internal workflow execution queue information from things such as Salesforce. This was immediately worked as a P0 finding and triaged. But, can we do more?

The API seemed to be related to Google Cloud's Application Integration feature. This allows users to define a workflow with a configuration on when to trigger and what to do once triggered. While reading documentation, they found a task called GenericStubbyTypedTask. Why does this matter? Google production follows a security model where each task service has its own identity. When a request is made to *.googleapis.com, Stubby calls the backend and carries out the action as the end-user with THIS security ticket. If this contains the ability to make arbitrary queries with Stubby, this has the flavor of a confused deputy issue.

Every Stubby service has a defined RpcSecurityPolicy. Each mapping block lists a set of RPC methods, the callers who can invoke them, and the credential type under which they can be invoked (anon, user, etc.). With a confused deputy issue that allows arbitrary calls with Stubby, you're limited to the policy's permissions.

When making API calls, they initially received a 400 error due to bad arguments. If you're on the Google intranet, a full stack trace is provided instead of generic errors. After some time testing different fields, they realized they were missing a client_id. They needed to create a workflow before they could do this, which led the author to hit a wall. They posted on Discord that they had the original vulnerability, prompting another person to say they were working on the same thing. Naturally, a team had been born!

The initial set of fixes only fixed one of the callable namespaces. Notably, /v1/integrationPlatform:getProtoDefinition was blocked but /v1/integrationPlatform/workflowsupport:getProtoDefinition was NOT blocked. createDraftWorkflow disabled but didn't have a counterpart. Although they kept getting access denied, it was inconsistent. The patch hadn't landed on all servers before load balancers yet!

Because of the simaliarities to Application Integration Google Cloud service, they decided to reverse engineer the JavaScript for help; luckily for them, this gave them more information about the required fields to use. The ACL issue that originally blocked publishing... the partner in crime figured out that updating the ACL for IP_EVENTBUS_WORKFLOWS with a separate endpoint. So, they could create a workflow with GenericStubbyTypedTaskV2 to create an arbitrary Stubby query. They got RCE through this and were rewarded $60K for the bug.

Three months later, they found several IDOR's in Application Integration's public API. Just set a victim's resource and modify it. Since the UUID's were very long, they needed a way to leak them though. By dropping fields 2 and 6 from the protobuf request, the response would come back with test cases for every GCP project. Eventually, they were able to use a Google-owned workflow through the IDOR to get RCE via snubby once again.

I was amazed by the authors internal understanding of Google and their ability to debug internal functionality super well. The post has an awesome bug, with great impact and explanations.