Supply Chain Attacks: Case Studies

Let’s take a look at a few case studies on the different Supply Chain Attacks.

Published in

Pentester Academy Blog

5 min readApr 6, 2022

Introduction

I’ve have already covered a lot of ground in my previous post dedicated to Supply Chain Attacks, where I’ve discussed about what Supply Chains are, the attack surface, how these attacks happen, and how to prevent these or how to do your best to prevent them, because at the very least, these attacks can be quite hard to detect because they don’t entirely happen because of your fault but it’s a shared responsibility and thus any hardware, software or service you depend on can actually get you compromised. And not only these components but also the people involved. If they don’t take the security measures for each and everything they do, that negligence can bite you (as a customer) back.

In this post, we will cover some of the Supply Chain Attacks that happened in the past. This is definitely not an exhaustive list because that would be like a 50–100 page book or maybe more. But instead, I am more focused on telling you about some of the issues from the recent past, so you can see how these issues happened and what the probable fix was.

So let’s check them out…

Case Studies

The researcher going by the alias RyotaK had found a series of Supply Chain issues in Homebrew Cask, cdnjs, PyPI and npm packages. As you can already imagine, these are some of the services that you use directly or indirectly, thus the effect of the vulnerability is much more pronounced!

We will be covering aforementioned 4 issues first and the last case study focuses on SolarWinds (cherry on top!).

#1: Remote code execution in Homebrew by compromising the official Cask repository

Reference: https://blog.ryotak.me/post/homebrew-security-incident-en/

This issue boiled down to the vulnerability in the git-diff gem used by one of the Github Actions review-cask-pr.yml. This gem had a vulnerability which when chained with the issue in the workflow allowed an attacker to perform (ruby) code injection.

And all this happened via a pull request!

#2: Remote code execution in cdnjs of Cloudflare

Reference: https://blog.ryotak.me/post/cdnjs-remote-code-execution-en/

This issue boils down to the unsafe zip archive extraction resulting in arbitrary file overwrite and arbitrary file read (via symlinks).

Note: Zip files are quite interesting for attackers. I will cover the different attacks possible via unsafe file extraction in a separate post.

Again this issue could be triggered via a pull request and the impact is that a malicious actor could, as the researcher says (paraphrasing it):

tamper with the core part of cdnjs, such as the origin data of cdnjs, the KV cache, and even the cdnjs website.

#3: Potential remote code execution in PyPI

Reference: https://blog.ryotak.me/post/pypi-potential-remote-code-execution-en/

Due to a vulnerability in the Github Actions of the PyPI repository, a well crafted malicious pull request would result in arbitrary code execution and leak the Github Access Token (with write access to the repository). Thus, an attacker could deploy modified code on the main pypi.org website.

#4: Tampering with arbitrary packages in @types scope of npm

Reference: https://blog.ryotak.me/post/definitelytyped-tamper-with-arbitrary-packages-en/

Again a vulnerability where a pull request resulted in package-based permissions management bypass, resulting in tampering of arbitrary packages in the @types scope of npm.

As you can see a pattern in all of the above issues: all of them resulted in the compromise of the package or library repositories and had a great impact on a lot of consumers due to them relying on these packages and libraries. All of them resulted either due to vulnerable coding practices, either in the code owned by the organization or by a dependency being used.

The last case study would be SolarWinds. I won’t go too much into it because there’s already a large number of good videos and resources out there, so it doesn’t make much sense to repeat things out.

#5: SolarWinds Hack

This happened last year, when a lot of companies (many among the Fortune 500 and otherwise) including Cisco, Microsoft, Intel, DoD (and many other US gov agencies), FireEye, and many many more were compromised due to a malicious build of SolarWinds Orion tool. The attackers targeted the build process and replaced a DLL named BusinessLayer.dll.

It was FireEye who helped to uncover this hack, otherwise it might have gone unnoticed for much longer. It all happened when one of FireEye’s employees got a request to reset MFA they did not initiate, which raised an alert and thus the investigation began into this issue. It took a lot of time (and a deep dive into assembly code by the researchers from FireEye) to finally uncover the issue with the SolarWinds Orion tool.

The crazy part is that this attack went unnoticed for more than a year.

Since this tool was used for configuration management of firewalls, switches and other devices, it had the credentials for those devices too.

Using the compromised software an attacker could find their way into your organization’s network and have access to the devices being managed by the tool.

This was by-far the largest software supply chain attack that had been witnessed and it was quite strategic as well, if you dig into the details of it.

Check out these videos to get some insights into the attacks:

You can always Google and find more articles and videos covering this attack.

Closing Thoughts

Supply Chain Attacks are quite hard to detect and sometimes the causes are not so sophisticated (like minor coding issues in the dependency), but when they get chained with other issues they can result in exploitable bugs.

It’s always good to have code auditing in your workflow, because your organization can get it wrong, which can be a big issue. What you can do is analyze all the components you rely on and make sure that they are always up-to-date and battle tested.

For more detailed prevention advice you can always check out my previous post where I go into much more depth about the subject.

So I hope all this was quite interesting for you and helped you learn something amazing today.

If you wish to try these issues live, we have a lot of labs covering malicious package repositories: both Git, PyPI and APT. We even have some more labs to show you how to exfiltrate the code repositories (to possibly find weaknesses and secrets within them) for SVN and Git. So give them a try and become a better defender.

See you next time. Happy learning!