Snippet: Malware in open-source code can create security vulnerabilities, and validating controls can help mitigate risk.
Over the last year, threat actors have focused increasingly on attacking critical supply chain members. Malicious actors seeking to disrupt digital or physical supply chains manage to find organizations that sit at the epicenter of an industry. While social engineering and phishing are primary attack vectors, threat actors increasingly deploy sophisticated attacks. Organizations need to understand the risk that malicious code inserted into open-source code libraries poses and ensure that their security teams can validate processes and technologies.
Threat actors focus on supply chain attacks because they come with a high return on investment. Infiltrating a product or service that many companies use gives the threat actors the ability to infiltrate the customers as well.
While politics guide some nation-state actors, most cybercriminals attack organizations for financial reasons. From a nation-state perspective, critical supply chain vendors act as a springboard to more valuable digital assets, depending on their customer base. From a financial perspective, these types of organizations offer a low-cost, high rate of return by deploying ransomware or malware to one organization and spreading across the customer-base.
For example, one recent incident that used major cybersecurity organizations as a gateway impacted nine US agencies and 100 private companies. As part of another recent attack, cybercriminals deployed ransomware to approximately 60 MSPs and up to 1,500 direct commercial customers.
If threat actors can successfully deploy an attack against one of these vendors, they can cause a larger ripple across multiple industry verticals.
Open-source libraries offer threat actors an even larger return on investment. Built on a foundation of community involvement, the repositories often invite users to add updates and features. Moreover, small and large organizations leverage code blocks as part of their development processes. In their research paper, “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks,” the authors note that malicious actors can insert the malicious code in two ways, by submitting a new package or inserting code into an existing package.
Typosquatting is one of the more common ways that threat actors infiltrate software during the development process. With typosquatting, malicious actors can also use traditional social engineering attack types to trick developers into using corrupted code repositories. For example the Cybersecurity Infrastructure Security Agency (CISA) notes that threat actors used typosquatting to draw developers into repositories that looked similar to the popular “django” Python library. The malicious libraries contained the same code and functionalities, but they also incorporated a functionality that obtained boot persistence and opened a reverse shell on remote workstations.
Weak credentials are another primary weakness in open source projects. Threat actors can also leverage project credentials to insert malicious code into libraries. In this case, they may use social engineering to steal credentials or locate weak credentials ripe for compromise. Either way, they obtain maintainer status which allows them to commit malicious code to the code base without going through the approval process.
Threat actors can act like legitimate users, assuming a role that appears to fix a bug or introduce a useful feature. If approved, the pull request merges into the main code. Malicious code delivered via pull request requires a project maintainer to approve the code prior to merge.
Inserting malicious code into open-source libraries causes a ripple effect throughout the software supply chain. Every other project that uses code containing the malicious package suffers from the vulnerability created by the threat actors via the dependencies.
Since developers across the product spectrum use open-source code, from small developers to large proprietary software companies.
Problematically, developers and organizations struggle to detect the malicious code. In “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks,” the authors note that, on average, malicious packages were available for 209 days. Additionally, 56% of them started their routines on installation.
Depending on what software used the compromised code blocks becomes a security weakness for organizations using the software.
Recognizing the problem, the recent Executive Order on Improving the Nation’s Cybersecurity (“Executive Order”) incorporated a requirement that software companies provide purchasers an SBOM. According the the definition of SBOM:
Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product.
The underlying goal of the SBOM is to give companies a way to buld trust in vendors and their coding practices. Ultimately, the information should enable purchasers to be aware of the open source libraries used in their vulnerability monitoring processes. For example, the Executive Order continues:
Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.
By using an SBOM as part of vulnerability management, companies can review whether their purchased software contains at-risk code. The goal is to empower organizations by providing them visibility. If they know that a code repository with a built-in vulnerability exists, they do not need to rely on a vendor to secure the software.
Despite the SBOM requirement, many software purchasers may not be able to appropriately track all code back to its repository, more specifically the at-risk version of the repository. While repositories are often updated regularly, organizations may not be updating their software in parallel. This means that the version of a software using maliciously inserted code may not be the one they use, or they may not realize that an update fixes a vulnerability.
As new tactics, techniques, and procedures (TTPs) are found, organizations need a way to rapidly validate their controls. SBOMs offer a layer of visibility, but they may not fully protect an organization from risk.
With Attack, Detect, and Respond (ADR) solutions, organizations can emulate specific TTPs related to new vulnerabilities discovered. Unlike simulations that can only run provided TTPs, ADR enables organizations to create their own attack paths. By using emulation, they can follow the same sequence of events that threat actors would use to exploit a vulnerability. This enables them to do real-time control validation, enabling them to better protect sensitive data.
With SCYTHE’s ADR emulation platform, organizations can stand up a campaign in minutes, aligning it with real-world TTPs. This capability enables them to gain visibility into whether their systems incorporate any potentially at-risk open source code known to be used by threat actors.
Additionally, as organizations mature their security posture, they can use SCYTHE to review their controls. Even without knowing that a code repository has malicious code injected into it, they can review their software and systems regularly. By working together, Blue and Red Teams can more effectively mitigate known and unknown risks, giving them more confidence in their technologies and processes.