preloader
blog-post

Supply Chain Attack Typology - How Bad Actors Corrupt and Exploit

Following is the second of three blogs about IT Supply Chain Security:

  1. The Software Supply Chain - A History of Security Failure
  2. Supply Chain Attack Typology - How Bad Actors Corrupt and Exploit
  3. How to Secure the Software Supply Chain - Best Practices

You can also view my presentation on these topics from CMS CISO Cybersecurity Forum 2021:

While there are myriad attack methods and plentiful attack surfaces, the following six methods are those pursued most frequently by bad actors in the wild, and comparably by cybersecurity researchers:

  • Submit bad code to the source repository
  • Compromise source control platform
  • Build with official process but from code not matching source control
  • Compromise build platform
  • Compromise Package Repo
  • Trick Consumer into using bad package

In the following sections, I provide examples of each.

Examples

The following examples, lettered A-H, correspond to the indicated areas in the accompanying lifecycle diagrams.

A. Submitting Bad Code - Linux Hypocrite Commits

Example: researchers at the University of Minnesota intentionally submitted bad code to introduce vulnerabilities into the Linux Kernel via patches on the kernel mailing list.

SLSA Attack Type A
Attack Type A

Mitigation: two person review caught most but not all of introduced vulnerabilities (cf. Linus Law “Many eyes make all bugs shallow”). The researchers from the University of Minnesota were also banned from further contribution and their past commits were removed from the kernel tree.

Lessons Taught: In an open source project community, trust but verify. Perhaps also keep your enemies close, but keep an eye on your friends, too.


B. Compromised Source Control - PHP GIT Server Attack

Example: the PHP project GIT server was compromised and injected with bad commits of code to insert a backdoor. The changes were tagged “Fix Typo” in an attempt to evade scrutiny.

SLSA Attack Type B
Attack Type B

Mitigation: The changes to the PHP project server were reversed and and the project server now enjoys better protection.

Lessons learned: Protect project hosting platforms, especially repositories, with automated measures. Don’t depend upon visual scrutiny of commits and comments.


C. Build with official process from code not matching SCM

Example: A backdoor was found in Webmin, a popular web-based server management tool. Attackers had modified Webmin build infrastructure to use malicious source files. The backdoor had apparently remained in place on publicly-available versions of Webmin for over a year.

SLSA Attack Type C
Attack Type C

Mitigation: Meta-data generated during the build process would have produced provenance info identifying the actual sources used, allowing code consumers to detect such tampering.

Lessons Taught: Malicious code is often hiding in plain sight.


D. Compromised Build Platform

Example: Attackers compromised the build platform for SolarWinds, an IT monitoring and management tool set, installing code that injected malicious behavior during each build. The same threat actors are now apparently striking at global supply chains.

SLSA Attack Type D
Attack Type D

Mitigation: The infamous SolarWinds attack could have been mitigated through environment attestation and better control of the build environment.

Lessons Taught: Build environments are not immune from compromise.


E. Use/Update of Bad Dependency

Example: Attackers were discovered to have added an innocuous dependency to the event-stream project and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (cf. attack F below - Bypass CI/CD).

SLSA Attack Type E
Attack Type E

Mitigation: The project maintainer should have built the dependency on local reviewed source code. Use of scanning tools and dependency risk analysis would also aid in mitigation.

Lessons Taught: Open source projects can have hundreds of (often nested) dependencies. Not all dependencies are to be trusted.


F. Bypass Continuous Integration / Continuous (CI/CD) Delivery

Example: Attackers used leaked credentials for DevOps code coverage tool CodeCov to upload a malicious artifact, which users download directly. This exploit potentially exposed hundreds of Codecov customers to compromise, both directly and as a springboard to further attacks.

SLSA Attack Type F
Attack Type F

Mitigation: Generate, sign, and distribute metadata during the build process.

Lessons Taught: Provenance is everything!


G. Compromise Package Repository

Example: Attacks on Package Mirrors by researchers targeted mirrors for popular package repositories, which could have been used to serve malicious packages.

SLSA Attack Type G
Attack Type G

Mitigation: Generate, sign, and distribute metadata during the build process.

Lessons Taught: Mirrors don’t always reflect true project code. Don’t trust - verify or use the original project site repositories.


H. Trick Consumers into Downloading/Using Bad Packages

Example: Browserify typosquatting - attacker uploaded a malicious package to a repository or app store with a similar or identical name as the original.

SLSA Attack Type H
Attack Type H

Mitigation: Inspect meta-data and chain of trust before allowing workload access to compute or network resources.

Lessons Taught: Don’t assume end-users will enforce policy, even obvious policy

Lessons for DevSecOps

The above examples have many and varied lessons to teach cybersecurity practitioners and DevSecOps teams:

Compliance != Security

Verification == Security

Verification > Monitoring

Verification is Required for Zero Trust

In the next blog in our series, we’ll look at how these truths apply to real-world implementation in a Zero Trust Architecture.

Related Articles

Contact Us For Early Access to the Platform

TestifySec Judge Provides Visibility into the Security of Your Inventory

Learn More