How Hackers Infiltrate Open Source Projects

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: