Software Supply Chain: A Risky Time for Dependencies
The software supply chain is a critical element in the lifecycle of applications and websites. Interdependencies and common components in modern software development can increase the attack surface and sometimes allow hackers to bypass the robust security layers you have added to your infrastructure.
In fact, just one flaw in the code base may be enough to compromise the entire supply chain. The problem is that modern projects have tons of dependencies. This situation is known as “the hell of dependency” because your dependencies have their own dependencies and so on. Trying to track down all these dependencies can drive you crazy.
In addition, software development relies heavily on open source platforms and third-party vendors simply because it speeds up the process and provides developers with standard libraries. A wide range of people or organizations maintain the code, making it quite difficult to prevent security flaws.
These giant platforms host hundreds of thousands of packages, with millions of downloads, and are constantly under attack. Hackers try to hijack, confuse dependencies or typosquatting attacks regularly, and there is even a risk of self-sabotage now.
Read also: How hackers compromise the software supply chain
A closer look at the RubyGems vulnerability
Default CVE-2022-29176 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 is not authorized by RubyGems.org. to do so. “
There were other conditions, however, as the jewel, also known as the Ruby Package, “needed one or more scripts to create its name within 30 days OR no update for more than 100 days.” However, it could match many jewels on the platform.
A threat actor could replace the contents of a legitimate gem with a script to steal credentials or a cryptographic miner, a critical vulnerability.
RubyGems.org has not received any complaints from gem owners, so there is a good chance that the critical vulnerability has not yet been exploited. In any case, Bundler, the Ruby package manager, recommends using “Bundler in -Frozen or -Deployment in CI and during deployment”.
This best practice prevents your Ruby app from switching to a silent hijacked version, which is exactly what hackers want to achieve with this feat.
Users who need to audit their app to detect possible previous exploits can inspect the Gemfile.lock file and look for unwanted changes to the platform that have occurred in the gems while the version number has not changed.
Read also: SBOMs: securing the software supply chain
Platforms are prone to attacks
Whether it’s RubyGem or NPM, or even pip for Python packages, such large platforms are critical parts of the software supply chain. NPM regularly appears in the headlines of various campaigns that affect millions of projects and users.
JFrog’s security research team recently detected a new attack on NPM’s supply chain, similar to one previously reported to Azure. Hackers have used an attack of dependency confusion with German industrial companies as targets: Bertelsmann, Bosch, Stihl and DB Schenker.
Investigators said it was a “highly targeted” attack. Jfrog updated the post to say that they could not determine (at the time of writing) whether he was a real threat actor or a “very aggressive” pentester behind the attack.
There were several IoCs (compromise indicators), but hackers did not take the time to hide their target name in NPM and used a public obfuscator that can be easily detected and reversed, which seems quite unusual for to cybercriminals.
Dependency confusion involves using private package names to create public packages with a higher version number. When users run an installation or upgrade, the package manager gets confused and grabs what seems to be the most recent.
There are many opportunities for hackers who want to attack the supply chain. Addiction confusion or typosquatting are smart techniques, but not necessarily the easiest to achieve.
Stealing owner’s or maintenance credentials can be a more practical approach, as attackers can impersonate legitimate users to commit all forms of abuse, including the distribution of malware or backdoors to millions of people. facilities.
Read also: Main code security and code debugging tools
How To Protect Yourself From Supply Chain Attacks
Most of the time, the best thing you can do is mitigate a supply chain threat, but here are some simple steps you can take to reduce your risk:
- follow best practices for deployment and CI (e.g., Bundler recommendations)
- perform regular security checks and audits and never deploy anything untested in live production
- record a public record with the name of your private record to prevent any attack of immobilization
- Use a stricter vendor policy (e.g., use the exact version number and not “*” or “^” to avoid any silent updates during installations)
- if you are the owner or manager of a package, enable multifactor authentication
- never deploy configuration files or source maps in production
- keep all updated dependencies
The last point seems a bit paradoxical, as hackers try to compromise update mechanisms to trick their victim into implementing malware. However, the threat landscape is growing too fast to neglect security patches. Obsolete components are one of the first elements that hackers will check to see if they can exploit a known vulnerability.
The software supply chain is full of dangers, but these external resources are important to accelerate development and standardize practices. As a developer, you can’t control the code that you do not maintain, and most of the code in your project is not your current code. The best answer is to keep up to date with your security practices.
Read below: The Best Third Party Risk Management Tools (TPRMs) for 2022