GitHub Users Held to Ransom with Plaintext Pain9th May 2019
... 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:
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: