Following our previous blog post, we began examining our own database to evaluate the effectiveness of detection engine against real-world targets.
While reviewing our internal reports, we discovered that a personal access token related to a public GitLab service was leaking in a JavaScript file, along with private key. As experienced bug bounty hunters, we know that such findings are generally worth investigating if we can demonstrate their actual impact. Most programs won't accept raw findings without evidence of potential exploitation, or they may lower the severity of the issue. Therefore, it is crucial to understand how these pieces of information could be used and highlight a security issue for the customers.
I started to check the GitLab personal access token with the following API request to verify the token's validity:
GET /api/v4/projects/ HTTP/1.1
Host: gitlab
User-Agent: Mozilla
Private-Token: <The private token we discovered>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Priority: u=1The target GitLab instance returned all the projects the users had access to. This was a promising first step!
Next, we focused on the private key, which appeared to be tied to a Google Cloud Platform (GCP) service account. From my experience, this meant I should be able to authenticate against GCP services and access the services associated with this service account. Here's what I did:
I saved the embedded JSON in a file named credentials.json and used the Google Cloud CLI:
# gcloud auth activate-service-account --key-file credentials.jsonOnce the service account credentials were validated, I issued some commands to verify their functionality and access to sensitive information:
# gcloud projects listThis command provided a list of projects, including one related to the customer's production environment. I then set the current project on the CLI to this production project:
# gcloud config set project PRODUCTION_PROJECTFinally, it was possible to list all the jobs and, if I wanted to, perform any update operations on them. To summarize, it was possible to fully compromise the GCP environment of this customer!
As usual, I reported this vulnerability on YesWeHack, and within less than four hours, the report was triaged, acknowledged by the customer, and awarded the maximum bounty given its severity. Kudos to their team!
This real-life example is a great testimonial of how leveraging SecretsBuster can help you identify sensitive data leaks and mitigate them before malicious exploitation occurs.