Skip to main content
banner image
venafi logo

Insecure Key Collection on GitHub Is a Dream Come True for Cyber Attackers

Insecure Key Collection on GitHub Is a Dream Come True for Cyber Attackers

GitHub, source code repository, data leak
March 27, 2019 | Guest Blogger: Kim Crawley

GitHub is one of the most popular source code repositories in the world, if not number one. The convenience that the service offers developers has been incredibly useful to possibly millions of people worldwide. In fact, I’m willing to bet that many applications wouldn’t have been developed as effectively if it weren’t for GitHub.

When it comes to cloud security, or security on any third-party networks, the responsibility for protecting infrastructure belongs to the owner of the infrastructure. For example, it’s Amazon’s responsibility to make sure that unauthorized people can’t physically breach any of their datacenters which host AWS. But the security of a developer’s third-party hosted content is the responsibility of the developer. And a study conducted by North Carolina State University has revealed that a huge number of developers that use GitHub don’t secure their various API and cryptographic keys.

From NCSU’s report paper:

“GitHub has become the most popular platform for collaboratively editing software, yet this collaboration often conflicts with the need for software to use secret information. This conflict creates the potential for public secret leakage. In this paper, we characterize the prevalence of such leakage. By leveraging two complementary detection approaches, we discover hundreds of thousands of API and cryptographic keys leaked at a rate of thousands per day. This work not only demonstrates the scale of this problem, but also highlights the potential causes of leakage and discusses the effectiveness of existing mitigations. In so doing, we show that secret leakage via public repositories places developers at risk.”

Imagine a 50-story commercial tower where tenants tend to stash their physical keys in random spots all over a publicly accessible lobby. Someone up to no good could easily find the keys and sneak into the offices of insurance companies or dental practices in the evening and destroy those businesses if they wanted to. If the night time cleaning crew has high turnover, who would even notice before it’s too late? That’s the sort of mistake that many GitHub users are making, constantly and every day.

NCSU researchers scanned nearly 13% of GitHub’s public repositories over a timespan of about six months. As per the paper: “We find that not only is secret leakage pervasive – affecting over 100,000 repositories – but that thousands of new, unique secrets are leaked every day.” Ouch. The insecure keys range from API tokens to SSH keys to TLS certificates and more.

Here are some more gruesome details.

The researchers found a user who appeared to be exploiting YouTube in a way that could involve copyright infringement. “We found a total of 564 Google API keys in these repositories, along with indications that they were being used to bypass rate limits. Because the number of keys is so high, we suspect (but cannot confirm) that these keys may have been obtained fraudulently. We could not locate the keys elsewhere in our limited view of GitHub, but it is possible that the keys came from elsewhere on GitHub.” That not only puts developers who use YouTube APIs legitimately at risk, but possibly also Google as a whole.

A major website that’s used by millions of American college applicants that the researchers won’t name was amongst the many web services with highly vulnerable keys on GitHub. Another web service with vulnerable keys on GitHub was the website of a western European government agency. That entails AWS credentials, and puts a lot of very sensitive public sector data at serious risk! “In that case, we were able to verify the validity of the account, and even the specific developer who committed the secrets. This developer claims in their online presence to have nearly 10 years of development experience. These examples anecdotally support our findings that developer inexperience is not a strong predictor of leaks.”

That’s one of the things that I personally found the most worrisome. These parties who are leaving their keys easy for cyber attackers to grab aren’t typically kids who are just starting to dip their toes into serious application development. These mistakes are being made more often by seasoned developers who are working for corporations and major government agencies. They are supposed to know better.

What could GitHub users do to better protect their keys? GitHub has tools that many people aren’t using, and at their peril. “The .gitignore file is intended to allow developers to specify certain files that should not be committed, and it can be used (among other things) to prevent files containing secrets from being leaked. While this is a good strategy, many developers do not use this option and some do not fully understand it. To better investigate its usage, we used the Search API to collect .gitignore files over a 3-week period in the same manner as our normal collection process. Our assumption had been that these files would not contain secrets as they should only contain path references to files. Yet, we identified 58 additional secrets from this process. While this is a small number compared to the full dataset, this finding indicates that some developers commit secrets out of fundamental misunderstandings of features like .gitignore.”

Cloud services like AWS, Microsoft Azure, Google Cloud Platform, and GitHub offer users many tools and features that can be used to help keep applications secure. And sadly, even experienced professionals aren’t using them. Remember, the security of applications in the cloud is the responsibility of developers.

But if developers are operating within your DevOps environments, you may have to take a more active role in enforcing best practices for security. Automating machine identity protection with your DevOps lifecycle will help eliminate many of the human errors that result in exposure like those we’ve seen on GitHub.

Could GitHub do a better job of teaching users how to use features such as .gitignore properly?

Related posts

Like this blog? We think you will love this.
old ciphertext mechanism on a desk with an hourglass
Featured Blog

Traditional Cryptographic Attacks: What History Can Teach Us

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley

Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat