Thinking Like a Hacker: Stealing Secrets with a Malicious GitHub Action

Last time, a cryptocurrency scammer scanned Android APKs on the Internet Archive and found thousands of leaked Twitter API keys. After that, the scammer invested money into an altcoin and used the leaked API keys to promote the altcoin with hijacked Twitter accounts. The story ended with a classic pump-and-dump that made the crypto scammer millions of dollars at the expense of duped investors.

In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.

GitHub Actions Marketplace

In this scenario, we start out with a full-stack developer at Poor Corp who is trying to get started with automatic builds and deployments using GitHub Actions. Poor Corp has a Jenkins instance that they have used in the past for automating internal jobs, so the developer decides to try using that as part of the CI/CD pipeline. They do a search for “Jenkins” in the GitHub Marketplace to get started, but there don’t seem to be any official-looking actions or apps. The developer browses through a few of the available actions provided by other developers on GitHub and chooses the first one with a helpful README. Little does our developer know; he has just fallen for a trap.

Recently, a malicious hacker has been cloning various GitHub actions in the Marketplace. However, these clones have some additional code in them. The actions work as expected, but in each one, the hacker has added code that steals secrets passed into the action through arguments and environment variables. After publishing the cloned actions in the Marketplace, the hacker sits and waits for someone like Poor Corp’s developer to use one.

Stolen cloud credentials

Poor Corp’s developer spends the next few weeks testing out builds and deployments with Jenkins, and eventually gets to a point where they are deploying production code automatically with GitHub Actions! Everything is going well, and the developer is excited to convert other projects to this new way of deploying code. And then, at the end of the month, the developer’s department gets the bill from their cloud provider. The bill for the month is as big as the department’s budget for a year.

Panic sets in, and Poor Corp’s developers start investigating the cause of the massive cloud bill. They quickly discover a lot of high-resource virtual machines deployed in their cloud account that they didn’t provision. Upon further inspection, each one is running a cryptocurrency miner.

Investigations continue, and Poor Corp eventually learns that the Jenkins action their developer used was actually a malicious clone from the hacker we mentioned earlier. As soon as the developer started using Poor Corp’s cloud provider credentials to deploy code, the malicious action sent the credentials off to the hacker. With the credentials in hand, the hacker deployed cryptocurrency miners on new servers funded by Poor Corp’s cloud account.

In the end, Poor Corp worked with their cloud provider to dispute the fees for the resources they didn’t authorize. They were lucky, and the charges for the hacker’s crypto miners were waived. As for the hacker, though, there wasn’t enough evidence to identify and charge the individual behind the attack. The hacker kept the cryptocurrency that they profited from the mining, and they set up more malicious actions to find their next victim.

Lessons learned

The cloud is built for easy scaling, and while that has big advantages for organizations, it can also present big risks. All it takes is a few API calls to deploy massive servers. As we saw in this story, misconfigurations or hijacked accounts can quickly leave organizations with a massive bill for consuming resources that they otherwise wouldn’t have access to.

To protect yourself or your organization from unforeseen costs, you need to make sure that you have billing alerts set up. All major cloud providers have some sort of mechanism for this, and it can save you in a situation like the one we just covered. Had Poor Corp set up their own billing alerts, they would have been alerted to the rogue cloud servers well before their monthly cloud bill came.

The other big takeaway from this story is to do your due diligence when selecting third-party GitHub actions to use in your workflows. Anyone can publish an action on the GitHub Marketplace, and even though the source code is available, most people don’t read the code for the actions that they use. Just like Poor Corp’s developer, they just want to find something that works and is easy to set up quickly.

It's not that often that you use new actions in your workflows. Whenever you decide to use a new third-party action, just take the time to skim through the code and make sure there’s no suspicious code that stands out or was recently added. Additionally, a good indicator that an action is trustworthy is if it has a lot of stars and contributors.

At the end of the day, actions on the GitHub Marketplace are just code that someone else wrote that will run in your environment. All developers want to get things done as quickly as possible, but you should never blindly trust third-party code to speed up development.