What the History of Software Supply Chain Attacks Says About Today’s Risk
Despite attracting major media attention in the wake of the recent SolarWinds breach, software supply chain attacks are not a new concept. In this post, we take a look at the last forty years and examine how software supply chain attacks became such a big issue.
Historically, software security has struggled to keep up with pace of evolving technology. Attackers are often one step ahead, seeking new ways to gain access to sensitive systems.
As recent attacks have shown, soft targets in the software supply chain are now the path of least resistance for attackers. Organizations need to keep pace with modern security approaches that meet the risk and scope of today’s issues.
Tracing the Origins
One of the earliest references to subverting the software supply chain was in the 1984 paper, "Reflections on Trusting Trust," by Unix co-creator, Ken Thompson. In this paper, Thompson presents the idea that compilers, which take developers’ source code to produce executable binaries files, can be subverted to add backdoors or malicious logic. The result is that there are no detectable issues within the source code, but the actual software that is produced, distributed, and executed would contain malicious logic. At the time, the fields of program analysis and software surety, which encompass software reverse engineering, source code analysis and beyond, were in their infancies.
During the late 1980s and early 1990s, the use cases, hardware, and software stacks of computers were very different than today. As systems started to become more connected, security took a backseat to functionality. Systems as a whole were much more trusting. Businesses and consumers relied more heavily on interconnected computer systems before the most basic security features had fully evolved.
At this point, security products were early in their evolution and relatively unsophisticated. They largely relied on a database of naively developed "signatures" to find malicious software. Much of the software running on important systems did not have secure design. Many systems were developed using low level languages and were error-prone. As a result, there were a number of paths into relatively unguarded computer systems, many of which required surprisingly little effort to access.
In the mid-90's, "Smashing the Stack for Fun and Profit," became an influential paper within the information security sphere and led to the education of an entire generation of security professionals in exploitation.
Security features built into systems in the 1990s were rudimentary. Once an attacker compromised a system through a poorly-developed protocol, exploitation or security misconfiguration, there was little to prevent the attacker from wreaking havoc. Most organizations placed comparatively little value or had little knowledge about the extent of damage that could happen if a compromise occurred.
Fast forward to the present, modern devices are now massively interconnected in a constant fashion. This contrasts with many older systems which were often connected to larger networks in an ad-hoc way via dial-up modems. The security landscape has also changed an enormous amount. Gone are the days when a rogue hacker could simply apply techniques from "Smashing the Stack for Fun and Profit" with a small amount of reverse engineering and break into modern systems. Today’s attackers often use multiple different vulnerabilities and must exploit them in order to bypass security controls before they can actually achieve control.
Shifting the Course
As computer systems and security controls have become more complex, attackers face substantial lead time and potentially millions of dollars in upfront investment. As a result, attackers search for softer targets. By going after unpatched, critical vulnerabilities, as seen in the Equifax breach, and targeting humans, as observed with the increase in spear phishing campaigns, attackers often focus on the weakest parts of the software supply chain.
To respond to increased threats, there has been a broad shift towards managing and cataloguing known vulnerabilities in the libraries that developers use and efforts to strengthen company policies. In addition, companies are using tools like web application firewalls and taking a more serious approach to conventional vulnerability scanning. These tactics have helped to mitigate bugs in custom code and third party libraries.
As with the previous generation of security solutions, attackers are always seeking new ways to gain access to sensitive systems. The "path of least resistance" is again shifting… but to where?
Today's Attacks
The software supply chain itself has become the path of least resistance for attackers. The number of software supply chain attacks has risen in recent years, with the SolarWinds attack being the most recent and widely publicized.
While the shape and vector of many software supply chain attacks have differed, all of the attacks essentially targeted the same, relatively small and undefended space: software developers, build systems, tooling, and third-party dependencies. Looking back to May 2020, the Octopus Scanner Malware was a harbinger of events to come. The Octopus Scanner Malware did something remarkably similar to the malware employed in the SolarWinds breach. It infected all software builds using a specific set of software development tools with malicious logic. This malicious open source project was identified and subsequently taken down by GitHub.
Similar targeted attacks have also been documented in the last few years. Malicious JavaScript packages have targeted cryptocurrency systems, and attackers have installed backdoors in other third party tools such as the system administration tool CCleaner. Other emerging issues that don't bucket well into the traditional definitions of software supply chain issue terminology include systemic, package manager related issues, such as repo jacking and dependency confusion.
Moving the Goal Posts
There have been some rebuttals to the earlier literature on software supply chain issues, such as David A. Wheeler’s 2009 PhD Dissertation. However, many of these approaches would be difficult to implement in modern build systems. Attacks through 3rd party packages, open source dependencies, and code injection, as observed with Octopus Scanner and the SolarWinds malware, would have gone undetected.
To make matters worse, this is only the tip of the iceberg. Open source software was once somewhat niche and could be managed with relative ease. In modern development environments, this is no longer the case.
What This Means
While the concept of software supply chain security is not a new problem, the old processes of management and mitigation cannot keep pace in modern environments. Simply looking at a "bill of materials" or a list of known vulnerabilities is no longer sufficient. The amount of software that needs to be managed has grown too large to undergo effective audits. Looking for known vulnerabilities also creates an incomplete view of the risk that software dependencies pose to an organization. Vulnerabilities alone ignore actual attacks and other issues that have risen in the open source ecosystem in recent years.
Examining vulnerabilities maintained in public data feeds miss a large swath of real issues. The list of reported vulnerabilities for the entire NPM repository, the epicenter of JavaScript’s ecosystem, including all versions of all packages, is miniscule relative to the amount of published software. The reported vulnerabilities were a scant 1,500 entries or so at the time of writing. This means that the number of reported vulnerabilities in publicly accessible databases across the board comprises <0.1% of the number of published packages in the ecosystem, which was around 1.5M published packages at time of writing. It is unlikely that the JavaScript developer user base is significantly more security conscious than contributors to other ecosystems. As such, we are likely missing a substantial number of issues that are not catalogued in public data feeds.
For most organizations, comprehensive approaches that actually secure the software supply chain are lacking. Massive changes in the open source ecosystem have left organizations struggling to keep up. Many organizations still use legacy processes that work to a point but profoundly miss the scope of risk present in today’s software supply chain.
Image credit: photo by Jason Leung
