Hackers continuously steal secrets from GitHub repositories

Having a little time in front of him in full confinement linked to the health situation, a security researcher took the opportunity to try an experiment. Craig Hays thus got it into his head to disclose a username and password (SSH) in a Github repository and see if an attacker could find it. Initially, he thought he would have to wait a few days, maybe a week, before anyone noticed. But the reality turned out to be more brutal: the first unauthorized connection thus occurred within 34 minutes. “The biggest eye-opener for me was how quickly this repository was leveraged,” Craig Hayes told our CSO colleague. In the first 24 hours, six different IP addresses connected to its honeypot a total of nine times. One attacker tried to install a botnet client, another tried to use the server to launch a denial of service attack. The researcher also realized that one person wanted to steal sensitive information from the server while another started poking around.

This experience showed Craig Hayes that threat actors constantly scan GitHub and other public code repositories for sensitive data left behind by developers. The volume of secrets, including usernames, passwords, Google keys, developer tools, or private keys, continues to grow as companies move from on-premises applications to the cloud and more developers work from home. This year alone, the increase in exposed secrets compared to the previous year should be at least 20%, according to Eric Fourrier, co-founder of the French security start-up GitGuardian, which analyzes public repositories to identify data that attackers could take advantage of.

How Hackers Find GitHub Secrets

Hackers know that GitHub is a great place to find sensitive information. Organizations such as the United Nations, Equifax, Codecov, Starbucks and Uber have also paid the price. Some companies might claim they’re safe because they don’t work with open source code, but the truth is more nuanced because developers often use their personal repository for professional projects. According to the State of Secrets Sprawl report on GitHub, 85% of leaks occur on developers’ personal repositories and only 15% on organization-owned repositories. It contains shell command histories, environment files, and copyrighted content. Sometimes they make mistakes because they’re trying to streamline their processes. For example, they can include, for debugging purposes, their credentials when they write code. They may also forget to delete it. Even if there is a problem with a later deletion commit or an action to clear secrets, this private information is often still accessible in the Git history.

“I find a lot of passwords in older versions of files that have been replaced by newer, cleaner versions without the passwords,” says Craig Hays. “The Git commit history remembers everything unless you deliberately and explicitly delete it.” Junior and senior developers can make mistakes. “Even if you’re a great developer and you’re educated on the problem, at some point when you’re coding late at night, you can make a mistake and things happen,” continues Eric Fourrier. “Leaking secrets is human error.”

While any developer is prone to error, those just entering the job market usually spill the most secrets. Many years ago, as a software engineering student, Crina Catalina Bucur created an AWS account for development purposes and received a bill for $2,000… when she was not supposed to pay more than $2,000. penny for this service. “My project was an aggregated file management platform for about 10 cloud storage services, including Amazon’s S3,” she said. “This was before GitHub offered free private repositories, so my AWS access key and corresponding secret key was published along with the code in my public repository. I didn’t think then that I should have paid more attention to it. A few days later, she started receiving emails from AWS warning her that her account was compromised, but she didn’t read them carefully until she received the bill. Luckily for her, AWS support removed the additional charge. Errors in Crina Catalina have been exploited by hackers, including hard-coding keys for convenience and posting them to a public code repository.

Additional resources to exploit errors

Today, hackers who want to find errors like these need few resources, says Craig Hays. A bug hunter to earn bounties in his free time, he often relies on open source information (OSINT) that anyone can find on the Web if they know how to search a little. “My preferred method is to search manually using the standard Github.com interface,” he said. “I use search operators to narrow down to particular file types, keywords, users, and organizations, based on the companies I’m targeting.”

Some tools can make the process faster and more efficient. “Attackers run automated bots that scavenge GitHub content and extract sensitive information,” says Gabriel Cirlig, security researcher at Human. These bots can run all the time, which means hackers can spot errors in seconds or minutes. Once a secret is found, attackers can easily exploit it. “For example, if you find an AWS key, you have access to the company’s entire cloud infrastructure,” explains Eric Fourrier. “It’s very simple to target developers working for a specific company and try to look at some of the company’s assets. Depending on the nature of the secrets, hackers can do many things, including launching supply chain attacks and compromising the security of a company’s customers.

How companies can protect secrets from GitHub leaks

As the volume of secrets grows, companies need to better detect them before it’s too late. GitHub has its own “secret analysis partner program”, which finds text strings that look like passwords, SSH keys, or API tokens. GitHub has partnered with over 40 cloud service providers to automatically patch API keys exposed in public repositories. “We are continually looking to put a stop to these issues to better protect the ecosystem,” a GitHub spokesperson told CSO. “We currently revoke over 100 exposed GitHub API keys every day, often safely introducing new developers to the importance of credential security. »

Craig Hays said the “secret scanning partner program” is a step in the right direction because it makes it harder for attackers to find valid credentials. But the initiative isn’t perfect: “It still leaves a void when people accidentally check their own SSH keys, passwords, tokens or anything else sensitive,” he says. “It’s much harder to detect and manage because there are no partner credential providers to ask questions like ‘Is this real?’ Do you want to revoke it? Should any of us let the owner know? “. He also advises developers to be mindful of how they write and deploy their code.

“One of the first things to do is add the correct settings to a .gitignore file,” he said. “This file tells Git and therefore GitHub.com which files should not be tracked and downloaded from the Internet.” Some security start-ups are also trying to offer a solution. This is the case of GittyLeaks, SecretOps, gitLeaks and GitGuardian with some additional layers of protection for professional and independent users. Some detect leaked secrets in seconds, allowing developers and businesses to take immediate action. “We scan all your code on your software through the development cycle, the Docker container, different types of data,” says Fourrier. “We find the secrets and try to revoke them.” Ideally, however, the best strategy is not to divulge secrets at all – or as little as possible – and for this awareness certainly has a role to play in achieving this. “Training developers to write secure code and proactively stop bots is always better than risking too much disclosure,” says Cirlig.