Sysdig Threat Research Team has discovered PURPLEURCHIN, an elaborate crypto mining operation taking advantage of automated CI/CD services. Attackers have used millions of free compute cycles through services such as GitHub Actions, Heroku, and others, to run the operation.
What does this mean to the DevOps community?
A Basic Breakdown of the Attack
The attack was first identified when automated scanning identified some obscurely named images on DockerHub were being updated through automated patterns that did not match any kind of heuristic pattern. From there, it appears that free-tier GitHub accounts were being created and each account allows for 2000 minutes per month of free GitHub Actions runtime. Repositories were then created and a specially crafted github-actions.yaml workflow was created in those repositories. Containers were then started which kick off crypto mining operations. Ports are also opened up to serve as command and control for the distributed attack.
To get the full details of the attack, which are extremely fascinating, I would look into the article linked at the top of this post. There are a ton of depth and built-in workarounds to combat the systems of control that GitHub has in place to protect its infrastructure from attack.
What is the Threat of a Poorly Secured Code Repository?
Supply chain attacks have become commonplace in software development. Companies are constantly chasing CVEs from packages that are either not being well maintained by the community or are being maintained but companies are not allocating enough funding to keep their software in line with community updates.
The most pronounced threat in recent memory was Log4j remote code execution bug found in versions below 2.16. This allowed attackers to craft a simple attack that was able to quickly run arbitrary code that could have real consequences.
Companies all over the planet rushed to update their code bases. You can find massive Reddit threads that were discussing their companies' responses to the issue. I would imagine, even with all of the industry hype, this vulnerability still exists in the wild and is still being exploited.
How can something like this be avoided in the future? People familiar with DevOps automation will quickly reply by adding more automation to their environments and building systems. While I completely agree with this response, if automation is added irresponsibly the threat landscape you are looking at will broaden very quickly.
In high school, I was enrolled in vocational education where I learned how to build a shed. It was a pretty awesome experience and I learned a lot. The shop teacher in charge of running the class and keeping the students safe was generally opposed to using power tools to aid in our learning. When approached as to why his response was simply this; "power tools are just going to ensure that you kids screw something up faster than with hand tools".
When adding automation to an environment, especially in concert with code repositories and build systems, you are opening yourself up to a lot of risks that need to be mitigated. If your pipelines are fully automated from commit through production, then all it takes is one simple push before disaster strikes.
Tom Scott from "Things You Might Not Know" does a pretty good theoretical exercise about how quickly things can go wrong in a scenario like this. I have added the video below.
Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords
Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords
What Does PurpleUchin mean for DevOps and Automation?
PURPLEURCHIN appears to be a fairly sophisticated vehicle to utilize free computing resources to mine cryptocurrency. On its face, a group is just trying to make a buck.
On its face, it does not seem very threatening. This kind of attack really shows not only the creativity of attackers today, but it highlights how complex a company's technology stack has gotten, and how easy it is to hide inside of it.
Here are some questions that you can ask yourself to understand your level of visibility:
- Would you know if all of the code that made it into production on your next release was intentionally put there by good actors?
- Would you know if your servers are only running what you intended for them to be running?
- Could a sidecar process be spun up by a bad actor and would anybody notice?
- Does your automated testing stack take environmental considerations into account when passing a build?
- Do you know what versions of 3rd party dependencies are running in your environment?
- Would you know if a 3rd party dependency has been compromised?
- Could you quickly replace a compromised dependency to ensure business continuity?
- Do you know if your organization is utilizing GitHub Actions workflows that have been vetted by the security community?
Now, these questions may seem like a little bit of fear-mongering, and that is intentional. There are solutions for every single one of these already-solved problems on the market. In my experience, companies are not always going that extra mile to ensure that they are protected from threat actors.
The factors that compound all of this are speed and automation. I don't think anybody will dispute the argument that the technology space moves extremely quickly. On top of that, businesses must ship and release software at the pace of the market to remain competitive. Because of that speed, automation is generally employed as a stop-gap to maintain a consistent pace. Businesses have the possibility of leaving themselves exposed if those automated tools are not held to a higher standard than the software they are developing.
Conclusion
PURPLEURCHIN serves as another reminder about the time and attention we need to pay to our supply chain and automated tool stacks. While this particular attack does not constitute immediate concern for the technology community holistically like Log4J did, it serves as a great reminder that technology hygiene is as important as shipping valuable technology solutions to the market.
