{"id":21929,"date":"2022-05-17T14:45:03","date_gmt":"2022-05-17T14:45:03","guid":{"rendered":"https:\/\/www.esecurityplanet.com\/?p=21929"},"modified":"2022-05-17T15:30:31","modified_gmt":"2022-05-17T15:30:31","slug":"software-supply-chain-a-risky-time-for-dependencies","status":"publish","type":"post","link":"https:\/\/www.esecurityplanet.com\/applications\/software-supply-chain-a-risky-time-for-dependencies\/","title":{"rendered":"Software Supply Chain: A Risky Time for Dependencies"},"content":{"rendered":"\r\n

The software supply chain<\/a> is a critical element in the lifecycle of applications and websites. The interdependencies and components common in modern software development can increase the attack surface and sometimes allow hackers to bypass robust security layers you’ve added to your infrastructure.<\/p>\r\n\r\n\r\n\r\n

Indeed, only one flaw in the code base can be enough to compromise the entire supply chain. The problem is modern projects have tons of dependencies. This situation is known as “dependency hell,” as your dependencies have their own dependencies, and so on. Trying to trace all those dependencies could drive you crazy.<\/p>\r\n\r\n\r\n\r\n

In addition, software development heavily relies on open-source platforms and third-party vendors simply because it speeds up the process and gives developers standard libraries. A wide range of people or organizations maintain the code, so it\u2019s pretty hard to prevent security flaws.<\/p>\r\n\r\n\r\n\r\n

Perhaps nowhere is this more evident than in package managers. Recently the RubyGems package repository patched a critical vulnerability<\/a> recently recorded as CVE-2022-29176<\/a>. RubyGems.org is THE Ruby community\u2019s gem hosting service, just like NPM is the official registry for the JavaScript world.<\/p>\r\n\r\n\r\n\r\n

These giant platforms host hundreds of thousands of packages, with millions of downloads, and are constantly under attack. Hackers try hijacking, dependency confusion or typosquatting attacks regularly, and there\u2019s even a risk of self-sabotage<\/a> now.<\/p>\r\n\r\n\r\n\r\n

Also read: How Hackers Compromise the Software Supply Chain<\/a><\/p>\r\n\r\n\r\n\r\n

A Closer Look at the RubyGems Vulnerability<\/strong><\/h2>\r\n\r\n\r\n\r\n

The CVE-2022-29176 flaw was found on RubyGems.org, the package registry for the entire Ruby programming language community, and allowed “any user to remove and replace certain gems even if that user was not authorized to do so.”<\/p>\r\n\r\n\r\n\r\n

There were other conditions, though, as the gem, a.k.a. the Ruby package, “needed one or more dashes in its name creation within 30 days OR no updates for over 100 days.” However, it could match lots of gems on the platform.<\/p>\r\n\r\n\r\n\r\n

A threat actor could replace the content of a legitimate gem with a script to steal credentials or a crypto miner, a critical vulnerability.<\/p>\r\n\r\n\r\n\r\n

RubyGems.org did not receive complaints from gem owners, so there’s a good chance the critical vulnerability has not yet been exploited. In any case, Bundler, the package manager for Ruby, recommends using “Bundler in --frozen or --deployment<\/code> in CI and during deployment.”<\/p>\r\n\r\n\r\n\r\n

This best practice prevents your Ruby app from switching to a hijacked version silently, which is precisely what hackers want to achieve with such an exploit.<\/p>\r\n\r\n\r\n\r\n

Users who need to audit their app for any past exploits can inspect the Gemfile.lock file and look for unwanted platform changes that occurred in gems while the version number did not change.<\/p>\r\n\r\n\r\n\r\n

Also read: SBOMs: Securing the Software Supply Chain<\/a><\/p>\r\n\r\n\r\n\r\n

Platforms Are Prone to Attacks<\/strong><\/h2>\r\n\r\n\r\n\r\n

Whether it\u2019s RubyGem or NPM, or even pip for Python packages<\/a>, such big platforms are critical parts of the software supply chain. NPM is regularly in the headlines for various campaigns that affect millions of projects and users.<\/p>\r\n\r\n\r\n\r\n

The JFrog Security Research team recently detected<\/a> a new NPM supply chain attack, similar to one previously reported on Azure<\/a>. The hackers have used a dependency confusion attack with German industrial companies as targets: Bertelsmann, Bosch, Stihl and DB Schenker.<\/p>\r\n\r\n\r\n\r\n

The researchers said this was a “very targeted” attack. Jfrog updated the post to say they could not determine (at the time of writing) whether it\u2019s an actual threat actor or a “very aggressive” pentester<\/a> behind the attack.<\/p>\r\n\r\n\r\n\r\n

There were various IoCs (indicators of compromise), but the hackers did not take the time to hide the name of their target on NPM and they used a public obfuscator that can be easily detected and reversed, which looks pretty unusual for cybercriminals.
<\/p>\r\n\r\n\r\n\r\n

The dependency confusion consists of using the names of private packages to create public packages with a higher version number. When the users run an install or an update, the package manager gets confused and grabs what appears to be the most recent one.<\/p>\r\n\r\n\r\n\r\n

There are plenty of opportunities for hackers who want to attack the supply chain. Dependency confusion or typosquatting are clever techniques, but not necessarily the easiest to achieve.<\/p>\r\n\r\n\r\n\r\n

Stealing owners or maintainers’ credentials can be a more practical approach, as attackers can impersonate legitimate users to perform all kinds of abuses, including distributing malware<\/a> or backdoors to millions of installations.<\/p>\r\n\r\n\r\n\r\n

Also read: Top Code Debugging and Code Security Tools<\/a><\/p>\r\n\r\n\r\n\r\n

How to Protect Against Supply Chain Attacks<\/strong><\/h2>\r\n\r\n\r\n\r\n

Most of the time, the best you can do is mitigate a supply chain threat, but there are simple actions you can take to reduce your risks:<\/p>\r\n\r\n\r\n\r\n