GitHub — a Dangerous Platform if your house isn’t in order

Photo by Jefferson Santos on Unsplash

Every year hacker summer camp (aka Defcon, Blackhat, BSides) arrives in a flurry of anticipation, presentations, and great ideas that often take reflection to determine how best to implement in our daily lives. Each year in addition to new skills and information, we look for themes that may come to dominate the security world over the coming years. This year I attended FOUR BSides talks(1) and a repeat at DefCon(2) on abusing GitHub — indicating that GitHub may be looming as a larger target than many other platforms. Last November DropBox had 130 repos compromised, and in January GitHub itself reported that hackers stole some code-signing certs. Several years ago, exposed and vulnerable S3 buckets was a similar theme — replete with many large newsworthy breaches.

GitHub launched in 2008 and has grown from 6,000 users and 2,500 repositories in 2008 to around 100 million users and 370+ million repositories (more than tripling since Microsoft purchased it in 2018). There are now ~1 billion public commits. And five years after the official platform launch, GitHub search (github-dork.py) came along and enabled a simple way to identify secrets. Though hard to believe it took 10 years for the spotlight to shine on this issue (and there have been many other talks on the subject), 2023 brought a confluence of them together (as well as a strong presence from GitGuardian). The scariest statistic discussed by GitGuardian was their discovery of 10M secrets in one year, 4% of which were private repo keys stored in a public repo.

All of the presenters discussed finding hard coded secrets in public GitHub repos (Mackenzie actually did so live in front of the audience). Additionally, once attackers have breached a perimeter, ‘private’ repos are no longer private. There were many reminders that no matter how buried your secrets are, if they are available, a determined adversary can find them. GitHub has documentation readily available on how to avoid many of these attack vectors (https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions) but security teams need to work to implement them.

Attack vectors discussed included:

• Exploiting Github Actions — sneaking code into the pipeline via 3rd party apps, free jacking, malicious forking, etc.)
• Finding Insecurities in Action Pinning — good intentions can still lead to token creating and malware introduction
• Dorking for secrets — GitGuardian says there are far too many still being hardcoded and available in plain sight
• Decompiling Mobile Apps — applications with .apk and .ipa extensions are effectively zip files, often with plain text credentials that can be unpacked and searched
• Monitoring code leaks to harvest secrets
• And RepoJacking hit the news a month before DefCon — accessing old repos through old/retired usernames and transferring ownership

The silver-lining in most of these talks is that if an organization is willing to suffer through the administrative load, all these issues are solvable and preventable. The bad news is that most of the problems come from process and user behavior failures, not from technology failures — but they are often more painful to fix.

Countermeasures discussed included:

• Assuming your source code is public (even if it is in a private repo). If your policies and procedures treat private repos as public, and thus you scan them regularly, developers will stop storing plaintext secrets.
• Ensuring key rotation policies are in place and audited (so you know exactly what each key is for). Develop a secrets management approach so that keys are rotated regularly (without the need for sharing new passwords, updating code, or reconfiguring anything).
• Differentiating between secrets (passwords, keys, etc.) and identifiers (IP addresses, DNS names, users). There are reasonable justifications for hard-coded identifiers. If the repos are compromised, there are still multiple steps before access could be obtained.
• Using automated detection like ggshield, whispers, etc. (attackers do this already: gitleaks, troublehog). These services can automatically identify and detect sensitive information and alert you to its presence.
• Using HoneyTokens to identify if/when you are being breached. Develop trackable and traceable records to provide early warning signs to otherwise undetected breaches by creating fictitious records/tokens.
• Using Infrastructure as Code and Scanning to replicate code and identify misconfigurations can help serve as an early warning system
• Using a vault (e.g. Hashicorp vault or Azure key vault) to securely store and tightly control access to API keys, certificates, passwords, tokens and other secrets.
• Monitoring Github events and setting alerts for when a private repository is made public and immediately rotating any secrets contained therein.

A few that weren’t discussed that we’d add to this list include:

• Providing privileged access management (following least privilege). This approach minimizes the access that a secret could provide an attacker even when discovered.
• Encrypting data using a key management service. If keys are properly managed then they can be rotated when mistakenly published while data remains safely encrypted.

Secrets are everywhere. GitHub is a (large) potential aggregation point for secrets, but it is securable using the same approaches organizations should have in place for all secret management. Defense in depth requires people, process and technology to work together at mitigating the vulnerability presented. The administrative processes of ensuring appropriate access, controls, data, etc. are often burdensome but absolutely necessary. And as we’ve been counseling for years, developer teams need to work ever closer with security teams (e.g. devsecops).

Footnotes:
(1) Actions have Consequences: The Overlooked Security Risks in 3rd party GitHub Action, Yaron Avital

The Attackers Guide to Exploiting Secrets in the Universe, Mackenzie Jackson (also 2022 talk Exposed secrets — How public git repositories and docker images expose millions of secrets like API keys and security certificates every year)

The GitHub Actions Worm: Compromising GitHub repositories through the Actions dependency tree, Asaf Greenholts

The Dark Playground of CI/CD: Attack Delivery by GitHub Actions, Yusuke Kubo, Kiyohito Yamamoto

(2) The GitHub Actions Worm, Asaf Greenholts