Software Supply Chain Attack Types
A look at the CNCF Catalog of Software Supply Chain Compromises
We’ve discussed several times about the exponential growth of Software Supply Chain Attacks, using sources such as Sonatype. That said, what exactly is a software supply chain attack and what are some of the primary attack vectors?
In this article we will use the Cloud Native Computing Foundation (CNCF)’s Catalog of Software Supply Chain Compromises as a reference to discuss some of the primary attack types.
While software supply chain attacks may seem like a new phenomena with events such as SolarWinds and Log4j, they are far from new and the CNCF catalog has examples dating back to as the early 2000’s and even < 1984.
CNCF defines the types of supply chain compromises as follows:
Developer Tooling
Negligence
Publishing Infrastructure
Source Code
Trust and Signing
Malicious Maintainer
Attack Chaining
It is worth noting that several of the attack types map to existing frameworks such as MITRE’s ATT&CK which has sections dedicated to Supply Chain Compromise, including software dependencies, development tooling and software supply chain security itself.
Let’s discuss them each a bit below!
Developer Tooling
Developer tooling attacks are a compromise of the tools utilized to facilitate software development.
This may be the developers endpoint device, software development toolkits (SDK)’s, and toolchains. MITRE recommends utilizing integrity checking mechanisms such as hash validation and scanning downloads for malicious signatures. If a malicious actor can compromise dev tooling, they are able to introduce potentially malicious code from the onset of the SDLC and tarnish all subsequent application development activities and consumers.
There is also the need for robust endpoint security measures, especially in our modern paradigm of work from home and bring-your-own-device (BYOD). Developer tooling and endpoints can serve as a critical entry point for malicious actors looking to compromise the software supply chain.
Popular examples of Dev Tooling compromises include a 2021 incident impacting Homebrew or the 2022 PEAR PHP Package Manager Compromise.
CNCF list the specific mitigations as follows:
Mitigation - Use of trusted binary repositories. Verification of provenance (i.e. signatures) and/or integrity (i.e. checksums) of developer tooling downloads. Bootstrapping development toolchain from a minimal, trusted and auditable seed (ideally source code).
Negligence
Negligence is a failure to adhere to best practices, which is common, given there are so many application security and secure software development best practices to be cognizant of and we live in an increasingly complex digital ecosystem.
Something as simple as neglecting to verify the dependency name can have a major impact on an organization. Malicious actors have increasingly been utilizing an attack method known as “Typo Squatting,” which takes advantage of lack of attention to detail of dependency names. Attackers typically will target a popular framework or library, add their malicious code under a similar name as the original library and then wait for unsuspecting victims to download and utilize it in their applications.
Popular Negligence examples include 2019 PyPI typosquatting or the 2021 incident impacting klow/klown/okhsa.
The mitigations here are fairly simple, but not easy. There are many best practices and developers and engineers are incentivized not based upon adherence to security best practices, but often based on factors such as feature and product development and the release of new code.
Publishing Infrastructure
Publishing infrastructure has become increasingly critical as organizations now commonly utilize Continuous Integration/Continuous Delivery (CI/CD) pipelines and platforms to deliver software artifacts. One mitigation technique includes code signing, which helps ensure the integrity of the published code.
However, as we will seen in cases such as SolarWinds, a compromise of the CI/CD infrastructure itself can allow malicious actors to legitimately sign software artifacts which presents them as trusted to downstream consumers. This attack method can be devastating and nefarious and it emphasizes why the publishing infrastructure must be secured like production environments are and aligns with emerging frameworks such as SLSA which we will touch on in upcoming chapters.
Some resources to consider here include the OWASP CI/CD Top 10 Security Risks.
Popular examples that utilized the Publishing Infrastructure include none other than SUNBURST/SUNSPOT/Solarigate in 2020 and malicious containers on Docker Hub in 2022.
CNCF Mitigations include:
Mitigation - This kind of compromise can be deterred or defeated by implementing code-signing. Code-signing requires attackers to perform multiple operations to be successful, making the level of effort higher.
Source Code
Source code attacks involve the compromise of a source code repository either directly from a developer or through the compromise of a developer's credentials. The 2022 Verizon Data Breach Investigation Report (DBIR) found that credential compromise was involved in over 80% of data breaches. This includes situations impacting source code or source code repositories. Malicious actors targeting source code and repositories will often try and introduce vulnerabilities or back doors into the source in order to later exploit them or impact downstream consumers.
Source code attack examples include the infamous remote code injection of Log4j as well as Codecov.
Trust & Signing
Integrity is critical to trust in the software supply chain. This is typically facilitated by activities such as digital signing and attestations. Signing code gives downstream consumers a level of assurance regarding the provenance of code and its integrity. That said, compromising signing can and has been done to enact software supply chain attacks.
Therefore, fundamental security concepts such as defense-in-depth remain key. Defense-in-Depth is a longstanding cybersecurity practice of utilizing multi-layered defenses so that no single vulnerability or weakness leads to an entire system or organizational compromise. Malicious actors need to exploit several layers of defenses and security measures to achieve their objectives, rather than a single vulnerability or weakness.
In the example above, only using digital signing is insufficient and can be exploited. This is among the attack types listed in the CNCF index and cited by MITRE in their supply chain compromise section of the ATT&CK framework. Potential threats include activities such as theft or private keys, misplaced trust, abusing certificate issuance among others, as cited by NIST in their “Security Considerations for Code Signing” whitepaper. Mitigation techniques involve activities such as establishing trusted users, separation of roles, strong cryptography and protecting signing keys and associated systems.
Popular attacks that compromised trust and signing include the ROS build farm compromise.
CNCF Mitigations include:
Mitigation - Follow best practices regarding code signing key protection. A more in depth explanation can be found from NIST
Malicious Maintainer
Given the complexity of the software supply chain and the often-voluntary nature of maintainer activity, not all threats originate from outside of a project either. The malicious maintainer attack vector is among the threats listed in the CNCF index and it involves a maintainer, or someone posing as one, deliberately injecting malicious software or vulnerabilities into the supply chain or source code. This can occur due to a maintainer deciding to act maliciously, or their account or credentials being compromised by an external entity. Motivations for these sorts of attacks range from hacktivists to those posing as involved maintainers, only to abuse their permissions and access to nefarious purposes.
Malicious maintainer examples include incidents such as the npm library “node-ipc” or npm Libraries ‘colors’ and ‘faker’, both of which were done in protest by their maintainers.
Attack Chaining
Lastly, attacks and vulnerabilities don’t only occur in isolation. Malicious actors may chain together several vulnerabilities and attack vectors to carry out their activities and desired intent.
Looking at some of the attack types mentioned above, a hypothetical scenario could involve a malicious actor posing as an interested contributor or maintainer only to abuse their access, insert malicious code, abuse signing and so on. Stringing together several attack vectors can have a devastating impact when done correctly. It can also be necessary, depending on the security posture of the target.
My friend and Resilient Cyber podcast co-host Dr. Nikki Robinson has published studies on Vulnerability Chaining.
The reality is that vulnerabilities don’t exist in isolation, they can, and are, often chained together by malicious attackers to facilitate their objectives. This is why organizations need to have a a comprehensive approach to vulnerability management that takes their entire portfolio and environment into consideration.
Moving Forward
While this of course isn’t an entirely exhaustive list of potential software supply chain attack types and vectors, the CNCF Catalog does provide a fundamental understanding of the relevant attack types as well as examples of incidents over the years. As malicious actors continue to realize the value of “posioning the well” and compromising a single entity, project or component and have a cascading downstream impact across the software supply chain ecosystem, innovative and novel attack types will continue to evolve.