Supply Chain Attack Typology - How Bad Actors Corrupt and Exploit
Author: Cole Kennedy
Following is the second of three blogs about IT Supply Chain Security:
- The Software Supply Chain - A History of Security Failure
- Supply Chain Attack Typology - How Bad Actors Corrupt and Exploit
- 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.
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.
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.
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.
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).
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.
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.
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.
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.