# Detect and prevent the SolarWinds build-time code injection attack

**[blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack](https://blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack)**

February 17, 2021

[Go back](https://apiiro.com/blog/)

February 17 2021 | 3 min read

Technical | February 17 2021 | 3 min read

We have developed a patent-pending technology to detect and prevent SolarWinds-style
attacks before shipping binaries to production, in both on-prem and cloud environments.

In order to understand how this new capability works technically, let’s briefly examine how
the attack was executed and why it went unnoticed for so long.

## THE MOTIVATION


-----

In late 2020, a complex supply chain attack against SolarWinds made headlines globally.
Malicious code that implemented a back door was injected into the source code during the
build process, exposing every SolarWinds customer to a significant threat. Although supply
chain attacks are a known concept, this is the first disclosed detection of one at such
complexity and vast scale.

Internal and external investigations of the scenario discovered that malware was running on
the SolarWinds Orion IT management build environment and waiting for msbuild.exe (the C#
compiler) to run. When a build process started, the malware verified that the build target was
_SolarWinds.Orion.Core.BusinessLayer.dll. If so, it immediately replaced the staged C# files_
with a version containing the back door’s code before compilation, resulting in malicious
code inside. This dll was later digitally-signed, which resulted in the file avoiding significant
_scrutiny._

Once the build environment is penetrated, there are countless methods to influence the
resulting product. While the pipeline’s input is readable (and testable) code, its output is
**a digitally-signed binary. Comparing them in order to identify a build-level attack**
**wasn’t possible … until now.**

## THE CHALLENGE

Taking binary code and restoring it to its original source code is a practically impossible task.
Compilation is a complex, non-reversible action. A compiled binary is packed with
information, optimizations, and metadata that are continuously changing. Even if you take
the same source code and compile it again a minute later, the binaries won’t be identical.

In addition to the non-readable binary challenge, the variety of CI/CD tools and
approaches is extremely broad. These tools are used differently by every team (where each
approach handles dependencies, common code, and additional resources in a unique way).
Add to this the fact that the CI/CD pipeline is designed to be invisible to its users and is
almost never inspected and you get a huge DevSecOps blind spot

**We think about this from a totally different perspective**

## THE SOLUTION

With a deep understanding of the source code, it is possible to determine whether or not it
matches the relevant binary file (based on patent-pending technology). By the time the build
process starts, Apiiro will have already learned the source code and developer experience
using its risk-based AI engine. Once the Apiiro platform knows all the code components,
security controls, logical flows, data types, and their relations, the next phase is to analyze
the binary.


-----

Let s take a .NET binary, for example. The Apiiro platform will parse and perform the
following actions on the executable files:

Learn all possible logic flows and symbols
Clean out all auto-generated compiler logic
Adjust expected differences between runtime versions
And more…

With the normalized entity relations from the binary, Apiiro runs graph comparison algorithms
against the same data it learned from the source code.

Apiiro’s algorithm is also aware of all possible legitimate code changes during compilation
(AOP frameworks, optimizations, etc.) and is able to distinguish only inserted malicious
**functionality, be it a small configuration change or full back door code.**

To protect your organization from the next supply-chain attack, do not allow your vendors to
deploy or upgrade their products without:

Performing the above comparison for every compiled binary to detect source code
manipulation
Validate included dependencies, external (using a digital signature) and internal (using
contextual knowledge of all the organization’s repositories)
Compare additional resource files, if present, to their counterparts from the source
commit, taking into account potential build-time templating processes

These steps will be done simply by uploading the built binaries to the Apiiro platform using a
dedicated API that can easily be integrated into every CI/CD pipeline and read-only access
to the source control manager.

**When Apiiro performs this process at the end of every build, you get end-to-end**
**validation that no unwanted code is injected into your product before shipping to**
**customers**

Ariel Levy

Senior Software Engineer


-----