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
Newest First  |  Oldest First  |  Threaded View
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.

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/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

FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setmac allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /gofrom/setwanType allows attackers to execute arbitrary code on the system via a crafted post request. This occurs when input vector controlled by malicious attack get copie...
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setVLAN allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setportList allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handlin...