Kieran Miller | Chief Architect, Garantir
Cyber criminals employ a number of different tactics to gain access to enterprise networks and data. One such tactic is to inject malware into a software product the enterprise uses, then use that malware to compromise the devices on which the software is used. This is an example of a supply chain attack.
In order to secure the software supply chain, it’s important to understand where the potential vulnerabilities lay. This post will analyze the four most common attack vectors used to inject malicious code into legitimate software or firmware.
Overview Of A Typical Build Process
Before we get to the attack vectors, it’s important to cover some basics about the software build process. While build processes will vary slightly from one organization to the next, they typically follow the same general structure.
First, a developer commits code changes to the source code repository. This triggers what’s referred to as a “build”. The build server retrieves the source code for that project and starts the build process.
With the source code downloaded, the build server will typically run some tests on it such as static analysis and style checks before compiling (or “building”) the code into binary format. Once built, the code is signed and then further tests (such as unit and integration tests and fuzzing) are executed.
As this process involves a number of steps, attackers have multiple options at their disposal when attempting to inject malware. Let’s take a look at the four most common attack vectors.
Attack Vector #1: Code Signing Keys
If the malware isn’t signed by the enterprise’s production code signing key, it will not be able to achieve much. Thus, the first attack vector is the code signing keys. If these keys are simply stored in software on end-point devices or build servers, it’s relatively easy for attackers to steal the keys. Once the keys have been compromised, attackers can inject and sign malicious code as they please.
Attack Vector #2: Build Servers
A second attack vector is the build server itself. If attackers compromise the build server, they can potentially inject malware without detection, as many build processes assume that the code in the source code repository is an exact match of the code being compiled and signed by the build server. Thus, the build server has practically free reign to sign what it pleases.
Attack Vector #3: Source Code Repository
A more difficult target to compromise (undetected) is the source code repository. If cyber criminals gain access to the repository, they can submit code changes as if they were an authorized developer. This presents an opportunity to add malicious code to the core of the product.
Attack Vector #4: Insider Threats
The fourth attack vector for a malware injection is an insider threat. In this case, the attacker may be receiving assistance from one or more authorized enterprise employees or, worse, the authorized employee is actually the attacker.
Constraints
While some of these attack vectors on their own may seem manageable, the reality is that security is not performed in a vacuum. Protecting against these attacks must not hinder business processes or exclude the use of industry-standard tools. Any solution to these problems must:
- Integrate with existing software development tools, such as source code repositories and IDEs;
- Integrate with existing build tools, such as compilers and code signing utilities;
- Function without slowing down the CI/CD pipeline; and,
- Function without requiring massive overhead to maintain.
Securing the Software Supply Chain
To learn more about preventing malware injections and securing the software you produce, join the Thales and Garantir webinar, Securing the Software Supply Chain, on Tuesday, February 16 at 11:00 am EST.