Recently, there was an attack targeting 170k+ GitHub users in a very complex attack that leveraged a lot of different tricks in the book including stealing session cookies, account takeover, dependency confusion and dependency hijacking just to name a few. I think all of the NVD drama drowned this out, but it’s a pretty damning indicator of persistence to commit a software supply chain attack by adversaries which have planted this since *squints at watch* early February! Attackers are patient and can fool anyone, even maintainers who are the trusted guardians of a repository.
Today, we will discuss lessons learned from the attack and some easy things your teams can do to protect their organization.
1. Anyone can be a target. Yes, that means you: Again, we are really cautious about putting out any FUD, but when we find a package as widely used as Colorama, anyone can fall victim to an attack as widespread as this which impacted just your every day developers doing their own projects after logging off of the 9 to 5. It’s time to step it up. It’s time to step it up and gain visibility into your software supply chain (Cyber Kill Zone Tenet #1).
SSC Defense: Incorporate security tooling into your CLI. When you are pulling packages, validate your packages being pulled are coming from legitimate upstream sources. S/O to my good friends over at Phylum which provides a fine tool to help protect your source code via blocking malicious packages from being downloaded onto your machine: https://docs.phylum.io/
2. The Details Matter: The only difference between the legitimate website versus the poisoned domain was Python hosted versus PyPi hosted. Here is a screenshot from the CheckMarx blog, which you can find here.
This was made possible by attackers hijacking the accounts for certain maintainers on GitHub that maintain these OSS packages and then uploaded the malware using verified commits. Even if you had on protections against your repo to only allow verified commits, this commit would have appeared 100% legitimate unless you performed a diff on the code and could detect the malware injection in the commit.
SSC Defense: TLDR; don’t be this guy…
Use automated mechanisms to detect changes to code, alert on suspicious commits, and detect a diff in the code between commits that will help detect suspicious developer activity. Additionally, StackLok provides a free service in Trusty that can help you determine the trustworthiness of a specific package (I think that is where they got the name from, but Luke or Craig can correct me). To be fair, I’m not sure I 100% agree with this risk score, but nonetheless this is a very useful utility that is free for everyone. Yay!
(As a complete aside: that Colorama package is… sus. Do not pull that, I’m not liable. Seems like a pretty obvious typosquat)
3. Identify your blast radius: We saw that 170k developers were impacted by this breach. Keep in mind, that number is just developers that pulled that poisoned package. Not including the many others in the community that have been impacted.
SSC Defense: Be able to identify your blast radius in seconds. If you pulled a malicious package, included that poisoned package in shipped software, you need to be able to identify when/where you ingested that component at all times. You need to know your blast radius and be able to search all of your artifacts for that specific component. This is critical for any incident response team to help identify, contain, and triage these events for your organization.
Don’t get caught slipping.
A SPECIAL SHOUTOUT AND THANK YOU TO:
- Research teams at Phylum which produces incredible threat research for teams to leverage.
- Teams at CheckMarx who have continued to follow this attack which has a pretty long tail.
- StackLok for Trusty and having that available to the community to use.
What did I miss? If I did something, just let me know.
