Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

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. That's 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 it's 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 don't 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. "It's a pretty well-known attack vector. And I would expect that it's probably happening more than we're aware of," says Chris Eng, chief research officer at Veracode.

Other experts agree. "It's not only heard of, it's happening all the time around us. We know of such actions from history and there's no reason to believe that it's 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 individual's 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 don't 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 there's no limit on how many layers deep the dependencies can go," says Yalon. "When you think you're building a project with one or two dependences, you could actually be using hundreds, and there's 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 didn't 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-pad's 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 it's] 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 it's a good project, meaning that there's 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 he's seen too many organizations that get excited about zero-day vulnerabilities and nation-state actors fail to keep up with "basic code hygiene." That's "the basic blocking and tackling like simply keeping your open source code up-to-date, and doing basic code scanning," he says.

It's all about trust: trust in the open source project and in the internal developer using the code, Yalon says. "A malicious open source packages isn't 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 what's going on."

Related Content:


Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
User Rank: Ninja
6/29/2019 | 12:18:50 AM
Guidelines to updating software
And upon left-pad's un-publishing, those thousands upon thousands of applications stopped working.

This statement is the reason why open-source projects are installed with some level of caution. There are a few steps we take before installing it on production systems:
  • Create a test environment where the code is installed on a VM or container (1 to 1 relatoinship with product)
  • We test the software update and patch to ensure the system comes up after a reboot
  • Implement a PIT (Point-in-Time) copy process to roleback the application
  • Install different versions on test environments to ensure the patch works (utilize VMware thinapp or other application virtualization tools)
  • Schedule a time and review app information on a regular basis
  • Test the application by using an automated process

User Rank: Ninja
6/30/2019 | 8:31:57 AM
Re: Guidelines to updating software
Very true Todd. And yet I know many app developers that openly admit to using open-source libraries to develop their code. Why recreate the wheel? The big problem there is that the libraries could be harboring malicious code and then you've given the threat actor inside access into your environment.
User Rank: Ninja
6/30/2019 | 8:47:07 AM
Re: Guidelines to updating software
Then there needs to be a filtering or application scrubbing mechanism that catches these items, in addition, just as the article states, there needs to be more eyes on this practice where the line of code goes through a check (similar to way AV functions where it looks for potential threats in the line of code).

Click on the link, this provides a list of tools, some are free to the public. One scrubbing center I can think of is Akamai, F5 and Radware.

Where Are the 'Great Exits' in the Data Security Market?
Dave Cole, Cofounder and CEO, Open Raven,  10/13/2020
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
US Counterintelligence Director & Fmr. Europol Leader Talk Election Security
Kelly Sheridan, Staff Editor, Dark Reading,  10/16/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-20
IBM Sterling B2B Integrator Standard Edition through and IBM Sterling File Gateway through are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially lea...
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 188517.
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link ...
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 188595.
PUBLISHED: 2020-10-20
IBM Spectrum Scale V4.2.0.0 through V4.2.3.23 and V5.0.0.0 through V5.0.5.2 as well as IBM Elastic Storage System 6.0.0 through could allow a local attacker to invoke a subset of ioctls on the device with invalid arguments that could crash the keneral and cause a denial of service. IBM X-For...