Over the last week, troubling new reports have arisen about state-sponsored threat actors leveraging modified open source applications to compromise employees' machines at technology companies, governments, and non-profit organizations. Microsoft, Mandiant, and Ars Technica all covered the technicalities of the attack type, where bad actors pose as recruiters who target specific individuals as their victims.
These victims are led to believe to be undertaking a technical assessment for recruitment. They are asked to use a specific bundle of tools, which are modified versions of popular open source tools such as PuTTy or RealVNC. When the unsuspecting target executes any of these tools, they load the system with services that can be used to load further malware. The threat actor gets into the victim's workstation and is able to infiltrate data or further explore the victim's network for secondary targets.
This strategy has been extremely successful for the threat actors. Combining elements of targeted attack with our implicit trust in known good open source tools and trust in that the process seems legitimate and does not deviate from how we'd usually expect things to work.
This subversion of an existing "institutional" structure is not unique to targeted attacks but a broader phenomenon affecting the entire open source world. We here at Sonatype have observed a similar pattern of malicious activity throughout the years affecting open source packages - essentially building blocks of software - that has the same Modus Operandi, to leverage the implicit trust held in open source packages by developers, and to use this as a vehicle of compromise.
Examples of such attacks are numerous - from actors taking over legitimate open source packages and using them to redistribute their malware. Recent examples include the takeovers of the Coa and Rc packages as well as ua-parser-js. In both cases, the bad actors used the existing wide distribution of these packages as vectors to spread their own malware. Though the length of the campaign was short and discovered quickly by the community, the damage was already done for the victims.
Although the above examples may seem like isolated incidents, they are not. We reported an annual increase of similar software supply chain attacks, up over 730% on an average annualized basis in the last 3 years. This is astonishing growth and possibly places this vector as the fastest growing method of malware distribution.
Why is open source being weaponized?
There are several reasons why such attacks are growing in volume. Firstly, programming infrastructure has always been informal, growing organically from passionate engineers sharing their work openly through the internet. Over time, these informal structures have grown into the backbone infrastructure of the software industry. Many of the major open source supply chain sources such as PyPI, Maven Central, or npmjs were all started by enthusiasts for enthusiasts.
Even open source software itself was founded by enterprising enthusiasts sharing their work. 90% of the world’s servers run Linux, and utilities like curl, wget, ssh and others are an inseparable part of DevOps infrastructure. The reason for this market share domination? To put it simply - the open source alternatives are as good or better than any commercially available tools for a similar task, are often specialized to handle just the thing they claim to do, and most importantly are easy to acquire. It's no leap of faith to say this openness and low barrier of acquisition is what makes open source software so successful.
However, it's precisely this enthusiasm and perceived high quality that has led to a lot of trust being placed on systems. We as people place a large amount of trust and reverence on things perceived to be professionally on top of their game which can lead to overriding our better judgements. For example, seeing a familiar name on an executable may shortcut our usual cautiousness in executing software from the internet. The case of the weaponized PuTTy application reported last week is no different from a spearfishing attack targeting an executive using a word document with a poisoned macro.
The difference with open source software is the list of potential victims is exponentially larger. By some estimates there are now nearly 30 million professional developers in the world, with the largest companies employing thousands at a time. If we add data scientists, amateur programmers, and people leveraging coding skills in their everyday professional lives, the number grows much larger still. Adding to this information overload is all the new releases of packages being distributed every makes it a very hard task to control with awareness training alone.
Combining these elements has made the open source community, and its supply chains, attractive targets.
We see that the current methods of educating developers and users are not enough. To this day, the world's most publicized security vulnerability, log4shell, has millions of downloads. In fact, at the time of writing, over 30% of all download figures of Log4j2 were old, unpatched versions.
What can be done?
The first thing to recognize is that nearly all of the security risk that is realized lies squarely on the shoulders of adopters of open source. Nearly all open source licenses contain the following condition from the Apache License Version 2.0 stating there is no warranty or guarantee of software functionality. Let me be clear - this is not to say we should STOP adopting open source by any means, merely to illustrate that the burden of responsibility is explicitly stated in licensing.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
The purpose of this stanza is to educate adopters of the open source product containing it, that they carry all the risk of adopting it. Yet, for all the legal posturing this is not how many developers actually behave. Most rely on a mix of intuition, skin-deep research, and sometimes tooling that may or may not reveal some security vulnerabilities.
In many organizations, this very important part of their innovation and operational technology stack is left entirely informal and unmanaged. Given the rise in attack scenarios, this has to change.
There are certainly things upstream open source distributors can do to mitigate the issue. For example, Sonatype has disclosed and taken down nearly 20,000 malicious packages in the last year. Many open source registries are enacting policies to restrict, scan and curb distribution of malicious or vulnerable content and encourage projects to generate a software bill of materials file to communicate what external code they are relying on.
However, this will not replace the need for organizations to manage their own software supply chains or for end users to take more responsibility for what they acquire and where. To effectively manage such a complicated system takes several steps. It requires an understanding of what is being downloaded, where it is being used, and the ability to certify your knowledge of known risks.
An example of a good maturity framework can be found in the recent CISA Secure software supply chain guidelines document we covered last week.
Diagram shared via Securing the Software Supply Chain: Recommended Practices Guide for Developers
Another framework that can be followed is the SLSA.dev model produced by the OpenSSF project, a cross-industry action group that operates with the Linux Foundation. SLSA sets maturity levels that can indicate your organization's readiness to react to risks arising from external code.
In practice, these models may seem hard to implement - and that is because this problem is so much bigger than just developers making poor decisions - it is a fundamental shift in thinking about how to leverage external suppliers.
We here at Sonatype continue to advocate for processes and tooling that not only prevent developers from making bad decisions but rather give them the automation to guard them against outright malicious attacks as well as protect them from making uniform choices about open source. For example, the easiest way to avoid being compromised by known malicious code or by inadvertently adopting code with a security vulnerability is not to have it at all. Using automated tooling that provides visibility and enforcement is a strong companion in footing in a new culture that supports the transformation.
The Sonatype Platform has helped thousands of organizations across the globe reduce the risk they have from the supply chain. From firewalling malicious code entering to automatically informing developers of better versions to use and finally producing software bills of materials to communicate this compliance, our decade-long experience of effective open source adoption continues to help drive and inform the best practices of open source usage.
If you want to find out more about how you can develop and protect your supply chains, take a look at our free Sonatype Vulnerability Scanner.
If you are curious about the research we produce in the field of software supply chain, join our mailing list. We're excited to release the 8th annual State of the Supply Chain Report later this month.
