Blog

GitHub Users Held to Ransom with Plaintext Pain

Pieter Danhieux
Published May 09, 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:

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

The recent attack on GitHub repositories highlights a well-known issue within the security industry: most developers are simply not sufficiently security-aware, and valuable data could be at risk at any time.

Interested in more?

Chief Executive Officer, Chairman, and Co-Founder

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

Book a demo
Share on:
Author
Pieter Danhieux
Published May 09, 2019

Chief Executive Officer, Chairman, and Co-Founder

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.

Share on:
... 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

Fill out the form below to download the report

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.
... 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:

Access resource

Click on the link below and download the PDF of this resource.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

View reportBook a demo
Download PDF
View Resource
Share on:
Interested in more?

Share on:
Author
Pieter Danhieux
Published May 09, 2019

Chief Executive Officer, Chairman, and Co-Founder

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.

Share on:
... 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:

Table of contents

Download PDF
View Resource
Interested in more?

Chief Executive Officer, Chairman, and Co-Founder

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

Book a demoDownload
Share on:
Resource hub

Resources to get you started

More posts
Resource hub

Resources to get you started

More posts