How Hackers Infiltrate Open Source Projects

The dependency trees of modern software-development make smaller open-source projects vulnerable to hackers sabotaging code.

The open source software that the vast majority of organizations include in their critical applications is vulnerable to exploitation from threat actors taking part in its creation. Thats the message from security professionals who point to the nature of open source projects and the ubiquity of the code as a real threat to enterprises.
Once insinuated into an open source project, criminals have a wide range of options, but within a narrow window: Whether its a backdoor keylogger, or Trojan of some sort, it needs to net them something valuable quickly, or they need to do it in a really slick way so they dont get found out for a while, says Brad Causey, owner of Zero Day Consulting.
The combination of flexibility and availability makes open source project hacking an opportunity that criminals are willing to sieze. Its a pretty well-known attack vector. And I would expect that its probably happening more than were aware of, says Chris Eng, chief research officer at Veracode.
Other experts agree. Its not only heard of, its happening all the time around us. We know of such actions from history and theres no reason to believe that its not still going on, says Erez Yalon, head of security research for Checkmarx.
In almost all open source projects, contributors must have their work vetted by other members before the code is accepted as part of the project. The level of review varies with the individuals reputation — as they become more trusted, fewer layers of review may be required. Especially in the larger, more well-known open source projects such as major Linux distributions, the procedures are well-defined and the labor pool large enough to enforce those procedures on a consistent basis.
The smaller projects dont have those resources to provide the level of security that the larger project have, says Causey. So you see those projects getting compromised more often.
Small Project, Big Impact
Experts point to very small open-source projects as the primary target for malicious actors looking to insert malicious code.
A very small package can be a dependency of larger packages, and theres no limit on how many layers deep the dependencies can go, says Yalon. When you think youre building a project with one or two dependences, you could actually be using hundreds, and theres no way of really checking all of them.
An open source project published and maintained by a single individual,
Event-stream
, was taken over by a malicious actor who managed to insert attack code into the code library distributed through NPM, a popular package manager for Javascript developers.
Event-stream was a project run by a developer who didnt have enough time to maintain it, explains Yalon. A malicious user convinced him that he could take over the project.
After taking over the project, the code was maintained as usual — for a time. Then, the malicious owner changed a package that event-stream itself depended on, inserting code that was able to hijack certain Bitcoin wallets.
How big was the reach of this attack? The project code is downloaded almost 1.5 million times each week, and it used in more than 1,600 other packages that are, themselves, downloaded millions of times.
Another non-malicious incident exemplifies how profound the impact of a small package can be: On March 23, 2016, a developer named Azer Koçulu removed 250 modules he had written and distributed through NPM. One of those modules was a very small piece of code (11 lines) that added spaces to the left side of a string of text to make it fit into a variable definition.
left-pad
was, as it turns out, part of the code collection (known as dependencies in development-speak) used in thousands upon thousands of enterprise and commercial programs around the world, including those built with Javascript development mainstays
Babel
and
Node
.
And upon left-pads un-publishing, those thousands upon thousands of applications stopped working. While it was easy for developers to re-create the functionality, the short-term impact of this simple act was huge.
(Nearly) Universal Threat
I do think [that its] important to just underscore how prevalent open source is, notes Eng. Gartner data shows that 95% of enterprises use open source code in their internal projects, he says.
Given the time pressures inherent in agile and devops methodologies, the one certain defense — the internal development team writing its own functions and libraries — is not likely to be adopted, Eng says.
So what is a dev group to do to increase code security?
Step number one is to be selective about what libraries and what open source projects you choose to roll into your technology stack, says Causey, adding that some projects have much better track records than others.
Next, he says, be sure that the project for the code used is an active project, with regular updates. Look into the history of the activity of the project to make sure its a good project, meaning that theres a lot of active folks out there, he explains. This makes it far more likely that any vulnerabilities will be quickly patched.
And once the patches are written, they have to be applied, says Eng. He says that hes seen too many organizations that get excited about zero-day vulnerabilities and nation-state actors fail to keep up with basic code hygiene. Thats the basic blocking and tackling like simply keeping your open source code up-to-date, and doing basic code scanning, he says.
Its all about trust: trust in the open source project and in the internal developer using the code, Yalon says. A malicious open source packages isnt a problem if no one uses it, he says. There should be rules inside every it organization for who can upgrade or change software packages. Someone should take a look to see whats going on.
Related Content:
Can Your Patching Strategy Keep Up with the Demands of Open Source?
Cattle, Not Pets & the Rise of Security-as-Code
How Open Testing Standards Can Improve Security
War on Zero-Days: 4 Lessons from Recent Google & Microsoft Vulns
How the Best DevSecOps Teams Make Risk Visible to Developers

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
How Hackers Infiltrate Open Source Projects