Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

#Infosec17 Dangers and Dependencies of Open Source Modules Detailed

Open source modules can contain major security problems, and are often relied upon by thousands of dependents.

Speaking on the subject ‘Node.js – Could a few lines of code “F” it all up’ in the Infosecurity Europe Tech Talks, Amit Ashbel, director of product marketing and cybersecurity evangelist at Checkmarx admitted that the answer is ‘yes’, and he described occasions where significant damage has been caused.

Saying that anything between 65-90% of organizations used open source code in their applications, Ashbel said it is ‘code like any other code and the fact that no-one wrote it in an hour doesn’t mean it is magic’. He encouraged analysis of open source code and modules at least.

He showed several instances where open source code-driven modules can cause damage, and pointed at the instance of Azer Koculu who shared code on NPM and Github and after a disagreement on naming, he removed the ‘Kik’ module from ‘Leftpad’, causing all sorts of problems.

“It was used by 40 NPM modules, and used by means that other modules depend on it,” he said. “We mapped it and found 450 modules, and the dependency was amazing. This triggered a discussion on what is going on, can an author unpublish work and can someone take over the modules?”

He highlighted three problems: that dependencies are not locked to any version by default; that persistent authentication is a problem if your computer is infected or if anyone is infected near you; and that everything is stored on a central location.

Ashbal said that one Active Directory module he found was in 19 different repositories, and if this were to be pulled it would have the potential to put the Active Directory repository.

Loadash has 30 million downloads a month and 90,000 dependents, so how can it cause damage? You can create a useful module and have people adopt and use it, and later there is no way to control it and automatically install it, and you can push whatever you want into the module.”

A common attack was by making a spelling mistake, as this can allow you to take over a legitimate account based on the module identity name. “The developers are here to develop and don’t always consider security,” he said.

In an experiment to see how vulnerable modules are, Checkmarx took packages from NPM, and analyzed the code. In one instance, which had a denial of service loop, the module had 300,000 downloads a month and 370 dependents, Ashbel said the developer did not believe the problem until an 86kb payload server crashed. Ashbel sent over the proof of concept, and he acted to fix the code.

“Among the NPM packages we found stored XSS attacks, command injection and others, so make sure you analyze open source,” he said. “NPM allows you to inspect so check on install slips, and you can also lock down dependencies. When necessary write your own code, and take extra care of dependencies. You can also run you own local repository, and check and validate it and make sure it doesn’t allow install from a domain registry.”

What’s Hot on Infosecurity Magazine?