4 ms·

GitLab scan finds 17,000 secrets in public repos, leading to $9000+ in bounties

30 points by adrianwaj 11mo ago

vatsachak 11mo ago
9000 in bounties for 17,000 secrets? You could make as much in a month creating those vulnerabilities
3eb7988a1663 11mo ago
The post keeps saying "verified secrets" - how are they verified? Did the author attempt to login to each service? Or does verified just means that it looks like a valid token?
- ctippett 11mo ago
  Tools like TruffleHog[1] will attempt to verify any credentials it finds by making some sort of authenticated request. [1] https://github.com/trufflesecurity/trufflehog#validation- https://github.com/trufflesecurity/trufflehog#validation-
jsiepkes 11mo ago
> Each Lambda invocation executed a simple TruffleHog scan command with concurrency set to 1000. This setup allowed me to complete the scan of 5,600,000 repositories in just over 24 hours. Gitlab must have been thrilled about a bot cloning 5.6 million repo's in 24 hours. That doesn't really sound responsible to me.
- treyd 11mo ago
  That's 64 clones per second. That's quite a lot but it seems like something that a forge operating at the scale of GitHub can handle, especially if they were --depth=1 (which might have missed some secrets if someone was lazy about clearing their git history).
  - nojs 11mo ago
    Gitlab*
  - digi59404 11mo ago
    Provided someone told GitLab Support. This was likely fine. GitLab can handle this much load. The platform as a whole has increased and improved over the years as new customers are added. Think about this… every CI/CD Job runs a clone. That’s a lot..
- 47282847 11mo ago
  If they don’t like, they will apply rate limiting? Assuming they were well behaved (user agent, IPs).
  - pcdevils 11mo ago
    Assuming bog standard lambda they'd have to rate limit a whole Aws region lambda range which would risk affecting legit usage. Bit of an arse way to behave against a service
- 3eb7988a1663 11mo ago
  I also thought the sleep(0.03) was cute. Some well deserved rest for the server to avoid hammering it.
iwontberude 11mo ago
Truffle Security treasury dollars: There are dozens of us! Dozens!
greatgib 11mo ago
"Google Cloud Platform (GCP) credentials were the most leaked secret type on GitLab repositories" Not surprising, Google SDK are sucking so much in term of authentication. It's never something simple like an API key, always a shitty iam like opaque function based on an opaque sdk needing to be installed that in the end requires a huge json. And most of the time, it is a pain in the ass to provide the token "as-is" in a buffer but the sdk expects that you give a file path to it. So, I easily guess that a lot of lazy devs will just store the credential json file in their project and consider it a job done.

30 points by adrianwaj 11mo ago

9000 in bounties for 17,000 secrets? You could make as much in a month creating those vulnerabilities

The post keeps saying "verified secrets" - how are they verified? Did the author attempt to login to each service? Or does verified just means that it looks like a valid token?

ctippett 11mo ago
Tools like TruffleHog[1] will attempt to verify any credentials it finds by making some sort of authenticated request. [1] https://github.com/trufflesecurity/trufflehog#validation- https://github.com/trufflesecurity/trufflehog#validation-

jsiepkes 11mo ago

> Each Lambda invocation executed a simple TruffleHog scan command with concurrency set to 1000. This setup allowed me to complete the scan of 5,600,000 repositories in just over 24 hours. Gitlab must have been thrilled about a bot cloning 5.6 million repo's in 24 hours. That doesn't really sound responsible to me.

treyd 11mo ago
That's 64 clones per second. That's quite a lot but it seems like something that a forge operating at the scale of GitHub can handle, especially if they were --depth=1 (which might have missed some secrets if someone was lazy about clearing their git history).
- nojs 11mo ago
  Gitlab*
- digi59404 11mo ago
  Provided someone told GitLab Support. This was likely fine. GitLab can handle this much load. The platform as a whole has increased and improved over the years as new customers are added. Think about this… every CI/CD Job runs a clone. That’s a lot..
47282847 11mo ago
If they don’t like, they will apply rate limiting? Assuming they were well behaved (user agent, IPs).
- pcdevils 11mo ago
  Assuming bog standard lambda they'd have to rate limit a whole Aws region lambda range which would risk affecting legit usage. Bit of an arse way to behave against a service
3eb7988a1663 11mo ago
I also thought the sleep(0.03) was cute. Some well deserved rest for the server to avoid hammering it.

iwontberude 11mo ago

Truffle Security treasury dollars: There are dozens of us! Dozens!

greatgib 11mo ago

"Google Cloud Platform (GCP) credentials were the most leaked secret type on GitLab repositories" Not surprising, Google SDK are sucking so much in term of authentication. It's never something simple like an API key, always a shitty iam like opaque function based on an opaque sdk needing to be installed that in the end requires a huge json. And most of the time, it is a pain in the ass to provide the token "as-is" in a buffer but the sdk expects that you give a file path to it. So, I easily guess that a lot of lazy devs will just store the credential json file in their project and consider it a job done.