GitHub Users Held to Ransom with Plaintext Pain

Published May 09, 2019
by Pieter Danhieux
cASE sTUDY

GitHub Users Held to Ransom with Plaintext Pain

Published May 09, 2019
by Pieter Danhieux
View Resource
View Resource
... a third party accessed your repository by using the correct username and password for one of the users with permission to access your repository. We believe that these credentials may have been leaked through another service, as other git hosting services are experiencing a similar attack.

As a user of a web-based service, it's never a great experience to receive an email like that about a potential breach of your personal data. Now, imagine that the data is a code repository representing your hard work, or even the trade secrets of your software. At least 392 (so far) GitHub, Bitbucket and GitLab users received that heart-stopping notification this week, and what's more - their code has been downloaded by the attackers, wiped from the repository and held to ransom. Once the affected users'files are all gone, just one text file remains containing this message:

Hacker asking for Bitcoin
Image credit: Bleeping Computer

Unlike most other newsworthy company breaches (and even previous attacks on GitHub) this one wasn't caused by a bug on their platform. Rather, account information was stored insecurely in plaintext and likely leaked from third-party repository management services. Developers were actively storing important password incorrectly, and often reusing the same credentials for multiple high-value accounts.

It would appear the scammers aren't the best and brightest of the programming world, as (at the time of writing) not a single user has paid the ransom to recover their code, and some clever security-minded folks have already found workarounds for affected users to recover deleted code.

Still, this does highlight issues we have known for a long time within the security industry: most developers are simply not sufficiently security-aware, and valuable data could be at risk at any time... even by those who aren't hacking geniuses.

Why is our password management still so poor?

Humans are of course flawed, and we tend to want to make life easier for ourselves. It's certainly much less of a hassle to reuse the same username and password over and over again, and remembering your first puppy's name is far easier than typing "Z7b3#!q0HwXxv29!'just to access your email. However, with so many large-scale cyberattacks taking place constantly, developers really should know better by now.

GitHub's own advice on the matter was straightforward, assessing that this ransom attack would not have taken place if two-factor authentication was in place and that secure password managers were in use. This is absolutely true, but as I keep saying - it is clear that the education must go further. All developers need to understand - at a fundamental level - why certain actions could leave their accounts vulnerable to attack.

Education: The magic pill?

Security-savvy coders understand that a simple security misconfiguration can have devastating consequences, and in the case of this GitHub attack, it seems misconfigured files were instrumental in allowing the attackers to successfully inject malicious skimmers to hunt down the keys to their castles.

Sensitive Data Exposure is also a critical vulnerability to overcome, still sitting at number three in the OWASP Top 10. Storing passwords in plaintext is clear evidence of many not understanding the dangers of doing so, and how easily systems can be breached through brute-force password attacks.

Understanding cryptography (and in particular, cryptographic storage) is an essential component to managing passwords in a code base using iron-clad security. Successfully salting and hashing any stored passwords, forcing their uniqueness, is going to make it far more difficult for situations like this ransom incident to take place.

It is important to understand that our collective attitudes towards security need to change, with more emphasis on adequate education for developers and taking the risk cyber threats seriously. We need to make learning about security a positive and rewarding experience, and I think that will be fundamental to an overall lift in standards for every developer self-assessing their work.

Want to try defeating the vulnerabilities you've read about here? You can play related challenges on Secure Code Warrior right now:

View Resource
View Resource

Author

Pieter Danhieux

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

GitHub Users Held to Ransom with Plaintext Pain

Published May 09, 2019
By Pieter Danhieux
... a third party accessed your repository by using the correct username and password for one of the users with permission to access your repository. We believe that these credentials may have been leaked through another service, as other git hosting services are experiencing a similar attack.

As a user of a web-based service, it's never a great experience to receive an email like that about a potential breach of your personal data. Now, imagine that the data is a code repository representing your hard work, or even the trade secrets of your software. At least 392 (so far) GitHub, Bitbucket and GitLab users received that heart-stopping notification this week, and what's more - their code has been downloaded by the attackers, wiped from the repository and held to ransom. Once the affected users'files are all gone, just one text file remains containing this message:

Hacker asking for Bitcoin
Image credit: Bleeping Computer

Unlike most other newsworthy company breaches (and even previous attacks on GitHub) this one wasn't caused by a bug on their platform. Rather, account information was stored insecurely in plaintext and likely leaked from third-party repository management services. Developers were actively storing important password incorrectly, and often reusing the same credentials for multiple high-value accounts.

It would appear the scammers aren't the best and brightest of the programming world, as (at the time of writing) not a single user has paid the ransom to recover their code, and some clever security-minded folks have already found workarounds for affected users to recover deleted code.

Still, this does highlight issues we have known for a long time within the security industry: most developers are simply not sufficiently security-aware, and valuable data could be at risk at any time... even by those who aren't hacking geniuses.

Why is our password management still so poor?

Humans are of course flawed, and we tend to want to make life easier for ourselves. It's certainly much less of a hassle to reuse the same username and password over and over again, and remembering your first puppy's name is far easier than typing "Z7b3#!q0HwXxv29!'just to access your email. However, with so many large-scale cyberattacks taking place constantly, developers really should know better by now.

GitHub's own advice on the matter was straightforward, assessing that this ransom attack would not have taken place if two-factor authentication was in place and that secure password managers were in use. This is absolutely true, but as I keep saying - it is clear that the education must go further. All developers need to understand - at a fundamental level - why certain actions could leave their accounts vulnerable to attack.

Education: The magic pill?

Security-savvy coders understand that a simple security misconfiguration can have devastating consequences, and in the case of this GitHub attack, it seems misconfigured files were instrumental in allowing the attackers to successfully inject malicious skimmers to hunt down the keys to their castles.

Sensitive Data Exposure is also a critical vulnerability to overcome, still sitting at number three in the OWASP Top 10. Storing passwords in plaintext is clear evidence of many not understanding the dangers of doing so, and how easily systems can be breached through brute-force password attacks.

Understanding cryptography (and in particular, cryptographic storage) is an essential component to managing passwords in a code base using iron-clad security. Successfully salting and hashing any stored passwords, forcing their uniqueness, is going to make it far more difficult for situations like this ransom incident to take place.

It is important to understand that our collective attitudes towards security need to change, with more emphasis on adequate education for developers and taking the risk cyber threats seriously. We need to make learning about security a positive and rewarding experience, and I think that will be fundamental to an overall lift in standards for every developer self-assessing their work.

Want to try defeating the vulnerabilities you've read about here? You can play related challenges on Secure Code Warrior right now:

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Submit
To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.