Code Signing

Prevent supply chain attacks using Encryption Consulting’s Build Verifier

Prevent supply chain attacks using Encryption Consulting’s Build Verifier

Reading Time : 5 minutes

Code signing is a crucial mechanism to establish authenticity and trust, ensuring that software is not compromised during distribution. In today’s interconnected world, where software forms its foundation, the security of the software supply chain has never been more critical. Recent events, exemplified by the SolarWinds attack, have highlighted the vulnerabilities that can be exploited within this supply chain, and they serve as a stark reminder of the importance of safeguarding code signing practices. This blog delves into the intricacies of such attacks, shedding light on their execution, and explores proactive security approaches to fortify the software supply chain.

What is the SolarWinds attack?

The SolarWinds attack was a massive supply chain attack that targeted the SolarWinds Orion platform, a widely used software by major enterprises and government agencies for managing infrastructure. By compromising SolarWinds during the software development phase, the attackers gained access to the networks of the platform’s customers, which were their ultimate targets.

In a supply chain attack, the malicious code is injected into the product during its creation or manufacturing process, allowing hackers to exploit the end users once they receive the infected product. In this case, the attackers infiltrated the software updates with malicious code before the updates were distributed to clients as part of routine maintenance.

The advantage of this attack strategy is that it creates a hidden backdoor into the network of every end user using the compromised product. With the SolarWinds Orion platform, the attackers had an even more powerful entry point because it spans across the user’s networks, granting significant control.

Once inside, the hackers could deploy additional malware to expand their capabilities, escalate the attack, and maintain their presence undetected. This attack had a far-reaching impact, affecting numerous organizations that relied on SolarWinds Orion for their operations and putting sensitive data at risk.

How was the SolarWinds attack carried out?

The SolarWinds attack began with the insertion of malicious code into software updates on February 20, 2020. By March 26, 2020, compromised updates were distributed to SolarWinds’ customers, installing the Sunburst backdoor on their networks. The attackers gained direct access through this backdoor. SolarWinds used code signing, but the attackers inserted the malicious code during development, bypassing code signing. Sunburst communicated with the attackers’ servers disguised as legitimate traffic. The attackers then deployed Teardrop and Raindrop malware to escalate the attack on selected victims. The attack had a significant impact on organizations relying on SolarWinds Orion.

Let’s discuss each of these components step by step:

  1. Sunspot Malware

    Sunspot, deployed in September 2019, was the initial malware used in the SolarWinds attack. Its sole purpose was to covertly insert a malicious backdoor into SolarWinds’ Orion source code, operating stealthily on the build server. Once it detected Orion build commands, Sunspot quietly replaced the legitimate code with the compromised version.

  2. Sunburst Backdoor Malware

    Sunburst, the primary backdoor malware, resided in the DLL file “SolarWinds.Orion.Core.BusinessLayer.dll.” Its function was to establish communication with the attackers’ servers via HTTP. It was concealed within a trojanized version of a Windows Installer Patch file, coexisting with legitimate update files. Sunburst hibernated for two weeks post-installation to avoid detection, then activated to communicate with the attackers’ domain. It disguised its communication as SolarWinds API traffic, recording sensitive victim network data.

  3. The Solorigate DLL File

    The attackers embedded Sunburst’s code within a DLL file, naming it “OrionImprovementBusinessLayer” to blend in. This class contained the full backdoor functionality, designed to be lightweight and inconspicuous. It was positioned within the method “RefreshInternal” to ensure regular invocation without disrupting normal operations.

  4. Teardrop & Raindrop

    Following the initial reconnaissance with Sunburst, the attackers deployed additional malware, Teardrop, and Raindrop, targeting specific victims deemed suitable for escalation.

The SolarWinds attackers executed a meticulous plan to compromise the build server before the code signing stage and inject the malicious code. Their infiltration of the build server granted them a strategic foothold to manipulate the software update procedure, guaranteeing the introduction of malicious code before the critical code signing step. This enabled the attackers to remain undetected, as the compromised code bore the signature of a valid SolarWinds certificate, creating a deceptive facade of authenticity.

What are the methods to execute such an attack successfully?

Let’s understand various strategies that can be employed to pull off similar attacks and compromise the software supply chain.

  1. Gaining unauthorized access to code signing keys

    This tactic involves acquiring the cryptographic keys used to sign software code. These keys assure users that the downloaded software has not been tampered with. Stealing these keys allows attackers to sign their malicious code, making it appear genuine and trustworthy to users and security checks.

  2. Breaching the build server, as observed in the SolarWinds incident

    The build server was a critical target in the SolarWinds attack. Attackers infiltrated this server, responsible for compiling and packaging software updates. By compromising the build server, they gained control over the software update process, allowing them to inject malicious code before the code signing stage. This manipulation helped them to distribute malicious updates to unsuspecting users.

  3. Injecting malware directly into the source code repository(Difficult since it leaves permanent marks)

    Injecting malware directly into a source code repository is challenging because it often leaves detectable traces. This repository is where developers store and manage the source code of software projects. Any unauthorized changes, including malware insertion, can potentially be identified and traced back to the attacker. As a result, this method is riskier and more likely to be detected.

  4. Targeting the developer’s workstation for compromise

    Another approach is to compromise a developer’s workstation. Developers use these machines to write, test, and develop code. If an attacker gains access to a developer’s workstation, they can manipulate the code before it is committed to the repository. This tactic can be difficult to detect unless robust endpoint security measures exist.

Strategies to safeguard against such attacks

The following approaches can be followed to prevent similar attacks:

  1. Hash Validation

    The method of hash validation is a pivotal defense against supply chain attacks like the SolarWinds breach. It serves as a stringent gatekeeper in the software development process, ensuring that the code to be signed matches the one securely stored in the source code repository. This security measure involves the build server generating a code hash, which is then scrutinized by the signing server.

    The signing server independently verifies the code’s integrity by initiating a deterministic build within the source code repository and comparing hashes. Only when these hashes match does the signing server authorize code signing, providing a robust layer of security that safeguards against unauthorized code alterations.

  2. Build Verifier

    An additional preventive measure against such attacks involves a rigorous hash validation system seamlessly integrated into the software development pipeline. The process begins with calculating file hashes whenever code is checked into a specific release branch, with these hashes securely stored in an encrypted file using Encryption Consulting’s CodeSign Secure. Subsequently, when the build server initiates a build from the designated branch, it retrieves the code and computes hash values for all files, storing them in a text file. A Build Verifier module then compares these hash values against those securely encrypted within the repository.

    The build proceeds successfully if a match is found for all hash values. However, any hash-value disparities prompt the Build Verifier to mark the build as a failure, immediately halting the process and triggering notifications via the CI/CD pipeline. This robust approach ensures rigorous code integrity verification at multiple stages, significantly bolstering the security of the software supply chain.

How can Encryption Consulting’s Build Verifier prevent this?

Encryption Consulting’s Build Verifier plays a pivotal role in ensuring the integrity of the build process. It would promptly identify this alteration and categorize the particular build as a FAILURE. Subsequently, notifications would be generated and dispatched to the relevant parties to initiate immediate corrective measures. This capability underscores the effectiveness of Encryption Consulting’s Build Verifier in upholding the security and reliability of the software development pipeline.

While the conventional method of hash validation is undoubtedly a valuable defense mechanism against supply chain attacks, Encryption Consulting’s Build Verifier takes software security to a more comprehensive level. Both approaches share the core principle of ensuring code integrity by matching hashes. However, the key distinction lies in the scope of their vigilance. The conventional approach primarily focuses on the code, verifying that it aligns with the repository’s version.

Encryption Consulting’s Build Verifier offers a more encompassing defense strategy. It scrutinizes the code and extends its watchful eye to crucial configuration files and dependencies. This broader scope enables it to detect subtle changes that might go unnoticed by the traditional hash validation approach.

Conclusion

In light of the SolarWinds attack, which exposed vulnerabilities in the software supply chain, it’s crucial to explore proactive security measures. Attackers execute such breaches by meticulously compromising build servers before the code signing process, introducing malicious code into software updates, and evading detection through valid signatures.

In summary, safeguarding the software supply chain requires innovative approaches like Encryption Consulting’s Build Verifier, securing trust and confidence in the digital world. As cyber threats evolve, staying one step ahead remains imperative, and Build Verifier stands as a testament to proactive security in a complex cybersecurity landscape.

Free Downloads

Datasheet of Code Signing Solution

Code signing is a process to confirm the authenticity and originality of digital information such as a piece of software code.

Download
secure and flexible code signing solution

About the Author

Yathaarth Swaroop is a Consultant at Encryption Consulting, working with PKIs, HSMs and working as a consultant with high-profile clients.

Explore the full range of services offered by Encryption Consulting.

Feel free to schedule a demo to gain a comprehensive understanding of all the services Encryption Consulting provides.

Request a demo