It all started with the SolarWinds breach
The recent SolarWinds breach compromised around 18,000 of SolarWinds’ 33,000 customers, including multiple U.S. military and federal agencies. The attackers first compromised the SolarWinds’ systems, enabling them to modify parts of the SolarWinds code.
The attackers then added a few lines of code to a standard software plug-in for an upcoming SolarWinds software update. The plug-in, which would normally provide background software and executables, was turned into a trojan virus that went on to infect thousands of networks.
The trojanized component was digitally signed with a SolarWinds certificate but contained a backdoor that communicated with third-party servers controlled by the attackers. Once online and communicating, this gave attackers unrestricted access to the target’s systems and networks.
In a blog post, Microsoft’s Threat Intelligence Center explained, “[w]ith a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions.”
The SolarWinds breach: a Software Supply Chain Attack
This type of attack is referred to as a Software Supply Chain attack because it did not directly attack a target, but rather component software “suppliers” that were upstream from the target. This can be analogously understood in a scenario where a processed food product could become contaminated by any number of supplier ingredients.
In the case of food products, the FDA provides certification, best practices and inspection to minimize these outbreaks. Unfortunately, an equivalent institution doesn’t exist for software. Software Supply Chain Attacks are not always well understood and are poorly managed by community or government action.
The SolarWinds breach has brought the topic of Supply Chain Attacks into the mainstream. This has caught the attention of everyone from corporate boardrooms to the White House. The Biden Administration is in the process of overhauling cybersecurity regulations for critical industries and has asked the National Telecommunications and Information Administration (NTIA) to weigh in.
Understanding Software Supply Chain Attacks: the SBOM
The White House instructed NTIA in Executive Order to “publish the minimum elements of SBOM” within 60 days. A Software Bill of Materials or SBOM (Pronounced “S” “Bomb”) is a standardized way to communicate what is in software. This is an initial step towards defining the surface area exposed to attacks.
In our food processing analogy, this could be thought of as an ingredient label requirement. In July 2021, NIST is expected to publish industry standards for how software firms are to publish and use SBOMs.
The SBOM framework has been slowly gaining prominence as a likely solution to Supply Chain Attacks. By clearly identifying software dependencies in an SBOM, downstream vendors are able to catalog potential risks and establish procedures for changes in those dependencies.
For instance, a modern application may draw from Open Source, 3rd Party Licensed and proprietary code and libraries. Typically these dependencies are hidden from end users – and sometimes are even hidden from sophisticated technical teams such as in SolarWinds. An SBOM has the potential to educate these teams and provide necessary structure to explicitly monitor and maintain their software dependencies.
Allan Friedman was an early champion of the idea and now works as the Director of Cybersecurity Initiatives at NTIA. According to the NTIA, an SBOM is a nested inventory or list of ingredients that make up software components. An SBOM is a directed acyclic graph of software components and information about those components, and supply chain relationships between them.
The arrival of the SBOM as a recognized and established solution is a transformative shift in the world of software supply chains. The industry has been waiting for a uniform standard for communicating software dependencies. Although it took a global highly-sophisticated supply chain attack to get here, the SBOM is something that has been missing for a while.
Not only will the SBOM help with software supply chain questions, it will also help solve another equally dangerous attack vector - the package confusion attack.
Package Confusion Attacks
Package confusion attacks deliberately leverage the trust permissions between a package manager and public repositories. Many package managers (npm, RubyGems and PIP) will automatically pull new package versions from public repositories.
Package managers are services which fetch and install software packages to computers. Typically, a package manager will fetch packages from package repositories. Package repositories store and service software packages. Package repositories are optimized for ease and speed, with focus on hosting all applicable updated packages, and they have very little focus on security and authenticity.
Package repositories and their distribution via typical package managers is a structure and workflow built on a trust relationship. This inherent trust relationship is ripe for abuse.
Let’s look at a simple example of what we call a Package Confusion attack. Say an attacker wants to get access to Company X. With a little knowledge of how Company X names their internal company packages, an attacker can replicate those package names on a public repository. For example, if a package is called “abc_3.0”, an attacker could make a package on a public repository called “abc3.0”. The attacker knows that most developers have left the settings for fetching packages set to default, which prioritizes public repositories over private ones. If a developer types in “abc …” the public (and faulty) package could get chosen by the default settings of the system.
The faulty packages on the public repository become bait, and the attacker waits. When someone’s computer grabs the decoy package, then the code the attacker put into the package springs into action.
In a recent demonstration, a security researcher named Alex Birsan used this dependency to lure 35 large tech companies into downloading the wrong package. This attack vector, similar to a Supply Chain Attack, highlights a flaw in the trust-based software dependency model which is at play in so many software supply chains.
What is the solution?
The solution to both supply chain attacks and package confusion attacks is the same. First, the industry needs an accepted way to know what is supposed to be in a specific software package. Second, the industry needs a way to reliably audit that package, and verify that its contents match the specifications.
Due to the White House’s initiative, the SBOM has answered the first challenge by creating a uniform way for software manufacturing, QA teams, security researchers, and developers to communicate the contents of a software package.
As for the second challenge, packagecloud can audit and verify a package’s contents against the SBOM.
Packagecloud: a platform for auditing package dependencies
Packagecloud is building the industry’s first platform to audit packages against the SBOM framework. This platform will audit software packages for their content and compare them to the applicable SBOMs.
Packagecloud.io was an early pioneer in building solutions for package management and dependency. Built in 2015, packagecloud is built to automatically parse a package’s metadata and manifest, update the indexes, and sign it with a GPG key unique to every repository.
We built packagecloud to create a seamless and easy package manager solution that automates and abstracts away the tedious work for DevOps. Our expertise in understanding software dependencies and the risk involved enables us to assist companies with untangling the web of dependencies in their own software or the software on their network. Up until now, this has been a desirable, but not necessary function for software business. This is changing.
The ability to leverage SBOMs will soon be a requirement for any provider of software to the Federal Government. Following the minimum requirements of SBOMs, NIST is expected to release guidelines for how companies must employ automated tools to maintain trusted source code supply chains, regularly check for known and potential vulnerabilities, and remediate them.
Packagecloud has assembled an all-star team to solve the package dependency problem. Leaning on the success of our existing solution, we are building the next-generation package management solution for auditing packages against SBOMs.
Are you interested in partnering with us? Want to find out more? Book a call!
