2022 in Review: 4 Lessons We’ve Learned from 2022’s Largest GitHub Breaches

2022 revealed that security challenges remain for organizations leveraging GitHub. Between supply chain attacks, API key leaks, and other security risks, there are plenty of lessons and takeaways from this year’s GitHub-related headlines. In this post, we’ve rounded up and categorized the year’s largest GitHub stories. Read on to learn more about the types of security risks occurring in GitHub and the lessons you’ll want to take with you into 2023 and beyond.

Lesson 1: GitHub supply chain attacks stole this year’s headlines - monitor your dependencies

This year, the GitHub ecosystem was impacted by a wide variety of distinct supply chain attacks. While the growth of supply chain attacks may initially come as a surprise, data from 2022’s State of the Octoverse may help shed light on this development. A staggering 90% of companies using GitHub rely on open source contributions. While open source is not inherently insecure, the increasing number of dependencies being leveraged by organizations does pose security challenges. As we covered in our recent cryptojacking post, threat actors are aggressively targeting open source registries to integrate malware into critical infrastructure. This year’s top GitHub supply chain attack stories include:

• Malware propagates through typosquatting, vulnerabilities, and general deception Threat actors have gotten clever in how they infiltrate the open source ecosystem. Campaigns like WASP, CuteBoi, and others have revealed just how persistent malware is in the open source ecosystem. Tactics like malicious forks of legitimate repositories have tricked developers into downloading compromised packages. Security researchers have also identified vulnerabilities, like one reported on by Legit Security in September, that would allow for malicious code injection by forking and merging open source repositories that contain a specific configuration file.

• Heroku/Travis CI OAuth token stolen. We first covered the Heroku OAuth token hijacking hack in May, when one of our customers reported they used Nightfall to confirm that they’d minimized their exposure to the incident. Threat actors illicitly acquired OAuth tokens issued to Heroku and Travis CI and then used these to access repositories that’d authenticated these apps, including GitHub’s npm infrastructure. Heroku itself had its customer passwords stolen in the hack. This incident had additional downstream effects in that nearly 100,000 npm user credentials were stolen, which is eye-opening in light of the increased npm malware campaigns over the past year.

• Travis CI API leaks logs. Travis CI was impacted by two incidents this year, the aforementioned OAuth token theft, as well as a leak of credentials in logs via the Travis CI API. With Travis CI being one of the largest open source continuous integration services on GitHub, this has undoubtedly had a security impact on a number of organizations.

• GitHub fixes repojacking vulnerability (although risk remains). In a piece of good news, last month, GitHub officially patched a critical vulnerability that would have allowed threat actors to take control of GitHub repositories and serve their own code. Dubbed “repojacking,” attacks exploiting this flaw could have targeted any renamed user accounts on GitHub. Charkmarx, which discovered the flaw, said that over 10,000 packages on the Go, Swift, and Packagist package managers were susceptible to attack. Apparently, even with the recent patch, some repositories may still be vulnerable. In response, Checkmarx has created an open source tool to identify these repos. GitHub itself is also investing in tools to help security researchers securely and quickly report vulnerabilities which will hopefully help prevent similar vulnerabilities from being used.

The big takeaway here is ultimately whenever including open source dependencies in a project, verify the source and regularly review code for vulnerabilities. Additionally, keep your ear to the ground regarding vulnerabilities in open source projects so that you can ensure your environments and applications remain secure.

Lesson 2: Public-facing codebases continue to provide persistent access to customer data - scan for secrets in code

In addition to supply chain attacks, organizations face more traditional risks on GitHub. Developers continue to leave sensitive data in code, like secrets and API keys, which can lead to customer data exposure through privilege escalation into systems outside of GitHub. This is an issue we’ve highlighted over the last few years. This year’s incidents include:

• AstraZeneca exposes PHI. We reported on the AstraZeneca breach last month, which entailed sensitive patient PHI being leaked through server credentials in a GitHub repo. These credentials granted access to a test Salesforce cloud environment.

• Toyota exposes PII. In October, it was revealed that Toyota had potentially exposed customer data for nearly five years when a piece of the company’s T-connect site source code had been mistakenly published on GitHub. The code contained an access key to a data server containing customer email addresses.

These two stories teach us just how common incidental exposure of data through GitHub remains, especially for large organizations. You’ll need to teach developers to not hardcode secrets and then continuously scan your environments for secrets to ensure this best practice is being followed. Watch the following video clip to learn about the eight best practices you need to bake into your engineering org to fully mitigate this risk.

[youtube:SmQwiKZG6A0]

Lesson 3: Employees & contractors can introduce risk of sensitive data exposure

Employees and contractors who don’t follow best practices can introduce risk via their accounts or their actions. The three following stories highlight this risk:

• Dropbox experiences repo intrusion through CircleCI phishing campaign. Last month a threat actor accessed and copied 130 private Dropbox GitHub repos. They entered Dropbox’s environment through a phishing email scam posing as CircleCI that captured an employee’s GitHub account credentials. Code accessed by this threat actor contained API keys used by Dropbox developers as well as employee and vendor names, modified third-party libraries, internal prototypes, security team tools, and configuration files. Dropbox says that no code for code apps and infrastructure or customer data was exposed.

• Veteran Affairs experiences potential breach through source code. In September, the Department of Veteran Affairs began an investigation into a potential breach when it was discovered a federal contractor published source code containing hard-coded credentials to GitHub. It’s not known what systems these credentials were connected to, but the credentials remained available from July 5 to September 9th of this year.

• An ex-employee of Adafruit leaked customer data from their personal repo. Adafruit, a provider of electronic components for open-source, DIY hardware projects, announced earlier this year that a public repo compromised some user data. The repo, owned by a former employee who’d apparently used real customer information for training and data analysis operations, contained some Adafruit usernames, email addresses, mailing/shipping addresses, and order details.

Like the other stories in this article, these three hammer in the need for “zero trust” repository security through continuous scanning of secrets and PII in GitHub in order to remove this sensitive content. This is because the number of ways in which your repositories’ contents can be made public keeps increasing, be it through vulnerabilities, human error, or a sophisticated threat actor. Additionally, you should ensure that you’re monitoring employee permissions to guarantee that any account only has access to the repositories that they strictly need in their role.

Lesson 4: GitHub breaches pose serious corporate (and personal) liability

The last two stories we’ll be covering concern legal rulings regarding breaches that occurred before this year:

• Former Uber CISO held personally liable for obstructing breach investigation. In October, we saw a federal jury convict Joseph Sullivan, the former CISO of Uber with obstruction of proceedings of the FTC as a result of Uber’s attempted cover-up of its 2016 breach.

• Drizly hit with settlement; CEO individually liable for key violations Similarly, the FTC in its proposed settlement with Drizly (an alcohol delivery service sold to Uber last year) has not only taken action against the company but has personally named the CEO in key violations. The company has been forced to settle over two distinct security incidents involving AWS credentials exposed through GitHub (one of which compromised the company’s entire customer database and exposed it to the dark web). The settlement not only requires Drizly to rectify its security processes but CEO Cory Rellas is personally required to ensure he implements a data security program at any future company where he will be the majority owner for the next 10 years.

The takeaway from these two stories is pretty straightforward. The stakes for GitHub security incidents couldn’t be higher, with the federal government taking the question of who is liable for such incidents very seriously.

The key takeaway

This year has highlighted the importance of practicing good security fundamentals when using cloud services like GitHub. These include things like embracing the practice of continuously scanning and removing secrets from your repositories. To learn more about this, check out our GitHub DLP remediation guide or reach out to us to learn more about Nightfall for GitHub, a tool that dozens of organizations like Bluecore and Klaviyo rely on to ensure their GitHub organizations don’t leak secrets, PII, and other business-critical data.