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

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
tdsan
50%
50%
tdsan,
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

Todd
RyanSepe
50%
50%
RyanSepe,
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.
tdsan
50%
50%
tdsan,
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).
https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools

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.

Todd
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
New FISMA Report Shows Progress, Gaps in Federal Cybersecurity
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-18573
PUBLISHED: 2019-08-22
osCommerce 2.3.4.1 has an incomplete '.htaccess' for blacklist filtering in the "product" page. Remote authenticated administrators can upload new '.htaccess' files (e.g., omitting .php) and subsequently achieve arbitrary PHP code execution via a /catalog/admin/categories.php?cPath=&ac...
CVE-2019-11013
PUBLISHED: 2019-08-22
Nimble Streamer 3.0.2-2 through 3.5.4-9 has a ../ directory traversal vulnerability. Successful exploitation could allow an attacker to traverse the file system to access files or directories that are outside of the restricted directory on the remote server.
CVE-2019-11029
PUBLISHED: 2019-08-22
Mirasys VMS before V7.6.1 and 8.x before V8.3.2 mishandles the Download() method of AutoUpdateService in SMServer.exe, leading to Directory Traversal. An attacker could use ..\ with this method to iterate over lists of interesting system files and download them without previous authentication. This ...
CVE-2019-11030
PUBLISHED: 2019-08-22
Mirasys VMS before V7.6.1 and 8.x before V8.3.2 mishandles the Mirasys.Common.Utils.Security.DataCrypt method in Common.dll in AuditTrailService in SMServer.exe. This method triggers insecure deserialization within the .NET garbage collector, in which a gadget (contained in a serialized object) may ...
CVE-2019-11031
PUBLISHED: 2019-08-22
Mirasys VMS before V7.6.1 and 8.x before V8.3.2 mishandles the auto-update feature of IDVRUpdateService2 in DVRServer.exe. An attacker can upload files with a Setup-Files action, and then execute these files with SYSTEM privileges.