How attackers leverage example apps/reproduction scripts to attack OSS maintainers
A possible method of attacking your code base is a bit of social engineering that involves using open source to report potential bugs in software that provides reproduction applications. These applications can include malicious code that can compromise your software and applications. In the blog post, we’ll briefly look at why and how they operate, and how to mitigate this practice.
Why are open source software maintainers increasingly at risk from attackers?
In terms of security, open source software is, arguably, the victim of its own success. Its use is becoming almost ubiquitous, with around 80 percent of all code bases containing open source coding. So, naturally, it’s a big target for attackers. It’s also a rich source of vulnerabilities. When you consider that the more software that’s developed, the more upgrades and uses come into being, which means there’s layer upon layer of open source code. Every component, and every interaction between components, can be compromised if they’re not properly protected.
This situation has come about quite organically, as the use of open source has increased. I have spoken with some popular open source maintainers and what’s clear from these conversations is that, as a result of this type of growth, there is no culture or a good set of rules that has been established to handle issues with reproduction scripts or reproduction codes for open source. Consequently, they can remain vulnerable, and it can be easy for malicious actors to exploit them.
Why are example apps/reproduction scripts such a serious threat to open source security?
When you decide to open an issue in many of the popular open sources, you need to describe your problem, establish what you would like to achieve, and ensure that you have a reproduction repository. If the problem is small, it’s usually a couple of lines of code, but sometimes with complex open source, people are asked to create reproduction example applications, and it’s very easy to put malicious code there.
If you have your own example apps and you rely on them, that’s easier to handle, because you can ask people to create a pull request and you see all of the changes that are made to your code. However, if someone creates their own example app, claiming that they can narrow down a particular problem with their specific version, most people aren’t going to check all of the code, with all the dependencies and components therein. They may look into the app, but you can hide the malicious code in one of the dependencies and not many people will check it. What many maintainers do is clone the repository and try to run a reproduction case. Then they could be compromised.
So, example apps and reproduction scripts pose a threat because they may target open source maintainers, people that have access to really popular projects. If you have access to projects that, say, 50,000 other projects rely on, and you get compromised, maybe even without knowing it, then the whole community is at risk.
What are the best ways for detecting and mitigating these example Apps and reproduction scripts?
The primary solution here is to provide example applications using your open source and create policies whereby anyone reporting a bug needs to provide the full reproduction as an inline script that you can read, or as a pull request to your example applications. Doing so allows you to see all of the changes and figure out the problem. For example, if you’re reporting a UI issue, why are you adding dependencies to packages?
In your open source projects, Mend should detect if a malicious dependency is being injected, but even if the malicious code is being injected into the example app, you will see it in a pull request. When you get a pull request to your example ap,p it’s never going to be merged. At least you can define it and see it. The biggest risk for open source developers and maintainers is to rely on reproduction bug reports and feature requests that demo themselves from external example apps. Either you need to read every line of these apps, or you blindly trust them.
How can Mend help you identify and fix such threats?
You can use Mend software as a part of your example applications. If you use our plugins for Mend Supply Chain Defender include our unified agent scanning in the CI/CD, when someone creates an app based on an example app that you own, and creates a pull request, we should be able to pick that up and perform at least part of the assessment.
The Xanitizer element of our tool should be able to find a semi-malicious code being inserted into the code base. Mend Supply Chain Defender focuses on the open source supply chain components. The primary consideration is to never run any code that would claim there is a bug or a component that doesn’t come from your example applications. For further information about how to defend your software supply chain with Mend, click here.
