Three New Supply Chain Attack Methods You Should Be Aware Of

Another day, another supply chain attack. No sooner did we recover from the SolarWinds breach, than we found ourselves reeling from a new ClickStudio attack. That’s why we’ve decided to launch this new series, fondly named The Source, to provide you with the latest news and updates on supply chain security. 

On this installment of ‘The Source’, get to know the red hot supply chain attack methods du jour. 

1. The Imposter Library Method

When Mend Supply Chain Defender first detected the “ddtracer” library, we realized it was an elaborate build-up for a future attack. Here’s what happened. A month and a half ago a malicious actor started building up a library called ddtracer. ddtrace is a library owned by the cloud monitoring company DataDog. There would not be anything weird about it — people often give packages similar names– if it wasn’t for a few facts:

• The attacker used DataDogs codebase to mimic DataDog and make their library work like the DataDog one — probably to gain a user-base.
• The attacker used the “github stars” reference of DataDog as well as all the metadata in order to confuse users.
• The attacker’s profile on RubyGems was designed to look like DataDog’s.
• There was nothing malicious in the code at that time, but all of the above was really suspicious. 

We chose to name it the ‘Imposter Library’ method because the aim is to trick users into thinking they’re using the real library since its name is believable (unlike a typo like “ddtarcer”), and it indeed initially uses the real source code.

While the Imposter Library attack method can be considered a distant relative of typosquatting, its aim is different. The goal of this attack is to impersonate popular libraries harmlessly, keeping the chance of suspicion and detection lower.  When there are enough users to make it worthwhile, malicious code is added, which increases the chance of being detected, so it may not last long after that. Of course, we aim to catch these in the initial harmless stage and block them.

2. The Brandjacking Method

Brandjacking is similar in nature to the Imposter Library MO, but throwing a wider net. The idea is to leverage inconsistent naming – particularly by big brands with many packages – and user assumptions about naming conventions.

For example: https://github.com/googleapis/google-api-ruby-client  — when developers see “google-api-ruby-client” on Github, they go with the assumption that the package name in NPM or RubyGems will also be “google-api-ruby-client”. But quite often it is not. Just to make that point, we registered the “google-api-ruby-client” name on RubyGems, along with a few other ones. Thanks to this and a couple of other packages like that, I was able to gain access – purely for security research purposes – to 648 unique (mostly development) machines with the full permission scope to execute. 

This is potentially a huge risk for organizations, as I could send myself codebase, AWS credentials, and much more.

3. The Security Research Smokescreen Method 

Anyone that’s been connected to the internet over the past two months is already familiar with the Dependency Confusion attack. An important point to note is that some registries like Rubygems allow gems for security research purposes as long as they don’t do anything malicious. So when we detected, blocked, and reported the Dependency Confusion gems months before the research went public, they were allowed to remain on the registry.

This generous policy towards security research meant that there were many copycat attempts after Dependency Confusion was publicized — which we detected and blocked — but following that we observed a new form of attack. Malicious actors attempted to publicize malicious gems which allowed for Remote Code Execution (RCE) while pretending to be allowable copycat security research.

Two weeks ago, Mend Supply Chain Defender discovered 61 packages that were uploaded to RubyGems that claimed to be designed for security research. 

As it turns out, those 61 packages had an RCE in them. How does remote code execution benefit security research, you might ask. Well, it doesn’t. If fact, its presence suggests that those were not packages built to “harvest” some non-sensitive information, but rather to gain full access into machines in real time.

When we at Mend alerted rubygems.org of the malicious packages, they immediately yanked them out of their registry. 

We’ve named this the Security Research Smokescreen attack because it’s a malicious attack trying to use security research as a smokescreen to bypass filters and detection.

Supply Chain Defender for Software Supply Chain Threats

There you have it folks, the latest supply chain security updates to help you ensure that you keep your code free of malicious threats to software packages. 

As package managers have become an attractive target for malicious players, and manually reviewing every package update requires more hours in the day, it’s important to stay informed and leverage automated tools to make sure any threats are blocked before they become a real problem for you, your organization, or your users. 

Join us next time for more supply chain security news and updates!