Published on
As the complexity of applications increases, so does your reliance on open source and third-party software libraries. With the compounded usage of open source, an expansion of the attack surface is underway. The increased threat is evident in recent high-profile attacks targeting the software supply chain. These types of attacks threaten organizations indirectly by targeting third-party vendors that provide you with software. Can you vouch for the security state of every library in your Rails applications?
Public repositories like npm (Node.js), RubyGems, and PyPI (Python), have shortened your software delivery times and reduced the workload of your teams. Using third-party packages in your projects minimizes the amount of code you must create. The less code you write, the faster you can get your product to the customer. The challenge is that as you use more third-party and open-source, your applications have an increase in security risk.
Open-source software and third-party packages exist in all modern applications. The 2020 State of the Software Supply Chain by Sonatype stated that there are 373,000 downloads of open-source software components per Enterprise every year. That same report estimated that one in ten elements downloaded has known vulnerabilities.
Where is the kink in the chain?
At Security Journey, we describe three types of Software Supply Chain attacks: infiltrated repository, primed repository, and source swap.
An infiltrated repository is when an attacker presents as a maintainer or contributor to an open-source project to gain commit credentials to overtake a repo. An alternate scenario is that an attacker steals commit credentials directly from the package maintainers. Once the attacker has the credentials, the attacker publishes an updated version of the package, including malicious code.
A primed repository is when a convenience package exists for the sole purpose of being snuck into code bases. Often this package contains functionality that is basic and adds malicious functionality after the library gains popularity. This attack takes advantage of developers who are overusing third-party software to reduce development time and not truly measuring the usefulness of the packages they add.
A source swap attack attempts to trick a developer into including a malicious package that appears to be a similar legitimate package. Attackers use typosquatting or machine-in-the-middle approach to execute this type of attack. With typosquatting, the attacker names the malicious package similarly to a legitimate package hoping that a developer will make a typing error when installing the gem. Taking advantage of typing errors is not a new concept for nefarious actors. For years, attackers have used similarly named domain addresses to steal sensitive data from unsuspecting users. This type of attack against the software supply chain has seen a steady rise in recent years because of its effectiveness and because it requires minimal effort to deploy.
Beware: Malicious Ruby Gems & Typosquatting
For Ruby, there have been multiple high-profile attacks that use one of the three techniques. In December 2020, RubyGems removed two gems: pretty_color and ruby-bitcoin. Researchers found malicious code in each. The gems had malware that executes on Windows and watches the clipboard for a Bitcoin wallet address, then replaces it with the attacker's wallet address to redirect funds to the attacker. In this example, the attacker used typosquatting to conduct a source swap attack.
These attacks replay attempts similar to the seven-hundred malicious gems discovered by ReversingLabs uploaded to RubyGems from February 16th to 25th, 2020. Of the 700 evil gems found, one stood out in its success by getting users to download the malicious package 2,100 times using the typosquatting approach. Many developers downloaded the Gem named "atlas-client." The total number of downloads represents thirty percent of the legitimate Gem downloads of "atlas_client."
Battling Ruby on Rails Supply Chain Attacks
Mitigating the risk of software supply chain attacks is a challenging task. In modern software development, it is impossible to remove dependence on third-party software. However, there are several steps you can take to reduce your risk.
At Security Journey, we recommend that you vet and curate your gems, audit your gems, use software composition analysis (SCA) tools, and integrate security checks into your CI pipeline.
1. Vet and curate your gems.
When vetting the gems to include in your Rails project, you need to ask yourself a few questions. The first is, do you really need the Gem, or can you quickly write the added functionality yourself? If you decide the Gem is necessary, ensure that the package is well documented and contains good codebase comments. The second question you should ask is the Gem well maintained? When was the last commit? Stale packages are ripe for attackers to target for malicious purposes.
2. Audit your gems.
The ruby-advisory-db maintains a database of vulnerable Ruby Gems. `bundler-audit` is a utility that looks at the application's Gemfile.lock and the ruby-advisory-db to see if you are using a vulnerable version of a Gem. You should integrate this into your CI pipeline to automate the task instead of running it manually.
As our programs change over time, we get stagnant Gems in our projects that we no longer need. It takes an exceptionally long time to go through all packages to remove the useless ones manually. Lucky for us, we can run the command "bundle clean --force" that will remove any unused libraries from the project.
3. Use SCA tools for Ruby pipelines.
Include software composition analysis tools to check for vulnerabilities and break the build if we have a known vulnerability. These tools must integrate them into your CI pipeline. Two top-rated tools to conduct SCA for Ruby applications are Synk and Sonatype's Chelsea. Synk and Chelsea will check for vulnerabilities in your third-party packages. Automate security whenever possible. These scans should be a step in your CI pipeline that runs every time you push code.
There are benefits to using third-party gems in our Rails projects. However, knowing that attackers will target our applications using techniques like an infiltrated repository, primed repository, and source swap, we must be vigilant to include only useful, safe, and needed gems in our projects. Vet and curate your gems, audit your gems, use software composition analysis (SCA) tools, and integrate security checks into your CI pipeline to prevent attackers from taking advantage of your software supply chain to infiltrate your projects.
