New Application Security Toolkit Discovers Dependency Confusion Attacks

Confusing dependencies is a pesky software development problem, as malicious actors use various tricks to trick developers and integrators into embedding malware components into their codebase. Instead of getting the functionality they want in the app, developers end up with an app that behaves differently than expected or one with a backdoor that can be exploited by unauthorized parties.

Apiiro has released the Dependency Combobulator, an open source Python-based toolkit that offers organizations a way to protect themselves against this type of supply chain attack. Dependency Combobulator works with npm (Javascript packages) and maven (Java packages) package management out of the box, but it can also be extended to use other package management systems, according to the company.

Earlier this year, a security researcher Alex Birsan illustrated how easy it was to upload code components to public package managers and code repositories and get developers to upload them. Birsan was able to exfiltrate data from companies such as Tesla, Apple and Microsoft as part of this research. A month later, PyPI, or Python Package Index, removed 3,653 malicious packages – including an unauthorized version of CuPy, a library for Nvidia’s CUDA parallel computing platform – using the same attack method.

The process of exploiting a dependency confusion attack (or package name substitution attack) is fairly straightforward, as it begins with the malicious actor uploading to a public repository a code package with the same name as a private internal package. The actor could discover the names of these private packages by browsing the configuration files in publicly accessible projects. If a developer updates all of a project’s dependencies and checks out both private and public repositories, the default build process retrieves the malicious package from the public repository instead of the private internal package. By the time the developer realized that the wrong package had been extracted, the malicious code had already been executed in the code and compromised the project. And if the build was done as part of an automated process, as would happen in a continuous integration / continuous delivery (CI / CD) environment, this particular substitution could go unnoticed for some time.

Detect dependency confusion

Application security teams will most likely implement the Dependency Combobulator at the CI level, says Moshe Zioni, vice president of security research at Apiiro. For example, if the team uses Jenkins for their CI process, the toolkit can be used as part of the build process. Another place to use the toolkit would be during code validations and push requests, where every change in dependency imports will be sent to the Dependency Combobulator for inspection and decision making.

“It can potentially be interconnected via a plugin, but it’s a more complicated way that isn’t easily supported out of the box and will require additional development work,” Zioni explains.

There are many other tools that work similarly to Dependency Combobulator. Snyk offers snync, an open source tool for detecting potential cases of dependency confusion in the code repository. Sonatype offers developers a GitHub dependency / namespace confusion check script
which checks if a project has artifacts with the same name between repositories, and to determine if the developer has been affected by a dependency confusion attack in the past. Sonatype’s Nexus firewall can quarantine suspicious or malicious open source components even before they enter the organization’s repository. There are private registries (Verdaccio sets up npm private registries) and dedicated package management systems (such as Cloudsmith) that organizations can use to prevent this type of attack.

Minimize the risks

There are ways for organizations to minimize this type of risk to the software supply chain. GitHub, which owns npm and manages the public npm registry, recommends the following to deal with dependency confusion: use of scopes for internal packages to be explicit where the packages are; place an .npmrc file at the root of the project to explicitly define the intended registry; be careful when using proxies; and respond quickly when something fails during the build process.

Another thing organizations can do is preventively name their own private dependency names. By claiming names used for private dependencies, including namespaces and scopes, on public repositories, the organization ensures that adversaries cannot use them for their own purposes.

“We were eager to respond by creating a toolkit that could mitigate similar threats and be flexible and scalable enough to combat future waves of confusion-dependency attacks,” Zioni says. “Addressing this attack vector is essential for organizations to be successful in securing their software supply chains. “

Source link

Comments are closed.