The software supply chain 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.
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.
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’s pretty hard to prevent security flaws.
Perhaps nowhere is this more evident than in package managers. Recently the RubyGems package repository patched a critical vulnerability recently recorded as CVE-2022-29176. RubyGems.org is THE Ruby community’s gem hosting service, just like NPM is the official registry for the JavaScript world.
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’s even a risk of self-sabotage now.
Also read: How Hackers Compromise the Software Supply Chain
A Closer Look at the RubyGems Vulnerability
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.”
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.
A threat actor could replace the content of a legitimate gem with a script to steal credentials or a crypto miner, a critical vulnerability.
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 in CI and during deployment.”
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.
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.
Also read: SBOMs: Securing the Software Supply Chain
Platforms Are Prone to Attacks
Whether it’s RubyGem or NPM, or even pip for Python packages, 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.
The JFrog Security Research team recently detected a new NPM supply chain attack, similar to one previously reported on Azure. The hackers have used a dependency confusion attack with German industrial companies as targets: Bertelsmann, Bosch, Stihl and DB Schenker.
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’s an actual threat actor or a “very aggressive” pentester behind the attack.
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.
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.
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.
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 or backdoors to millions of installations.
Also read: Top Code Debugging and Code Security Tools
How to Protect Against Supply Chain Attacks
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:
- follow best practices for deployment and CI (e.g., recommendations of Bundler)
- run regular security checks and audits and never deploy something untested on live production
- register a public registry with the name of your private registry to prevent any typosquatting attacks
- use a stricter vendor policy (e.g., use the exact version number and not “*” or “^” to prevent any silent update during installations)
- if you are the owner or the maintainer of a package, enable multi-factor authentication
- never deploy configuration files or sourcemaps in production
- keep all dependencies updated
The last point seems a bit paradoxical, as hackers are trying to compromise update mechanisms to trick their victim into deploying malware. However, the threat landscape is growing too fast to neglect security patches. Outdated components are one of the very first elements hackers will check to see if they can exploit a known vulnerability.
The software supply chain is full of peril, and yet those external resources are important for speeding up development and standardizing practices. As a developer, you cannot control the code you don’t maintain – and most code in your project is not your code these days. The best answer is to be on top of your security practices.
