In November of 2018, an event-stream, flatmap-stream hack involving a clever combination of social engineering and minified code, allowed a hacker to steal cryptocurrency. In April of this year, a bootstrap-sass vulnerability was discovered when a developer using that very popular component, had a build fail. After doing some investigation, the developer uncovered a stealthily executed attack at the source - “someone” had removed a version of the library, Bootstrap-Sass v3.2.0.2 and immediately released a new version, moments later, v3.2.0.3.
Flash forward to today and we have another attack on RubyGems at the source, CVE-2019-13354. This attack involves remote code execution in applications using or bundling the `strong_password` component, specifically its version 0.0.7. While this may seem like another mundane vulnerability that needs to be addressed, the story behind how this issue surfaced shines a light on a trend Sonatype has been following for years - attacks are not only getting more sophisticated, they are originating at the source in the software supply chain where it’s much more difficult to detect malicious activity.
Name of Vuln/Sonatype ID: CVE-2019-13354
Type of Vulnerability: Embedded malicious code
Components Affected: Version 0.0.7 'strong_password' ruby gems
Vulnerability Description:
Version 0.0.7 of the `strong_password` gem contains malicious code. The `strength_checker.rb` script fetches and evaluates a code payload from a remote server. At the time of this report, the fetched payload runs a backdoor in production code that evaluates the contents of a crafted cookie matching the regex `/___id=(.+);/`. Since the contents of the cookie payload are subject to change, a malicious actor can run arbitrary code on a system using `strong_password`.
Overview of the Attack:
Before we get to the attack mechanics of the compromise, it’s important to point out that a developer discovered this breach while cleaning up code dependencies in his code base. Knowing precisely where he needed to look and which components needed attention is a best case scenario. In many cases, development and security teams aren’t 100% sure what’s in their code bases at the outset of this sort of dependency grooming. This makes vulnerable component discovery more complex and the potential for ongoing compromise a harsh reality. Knowing what actually exists in a code base versus relying on what’s simply declared is critical.
Unlike the flatmap, event-stream hack mentioned above where the bad actor leveraged the good nature of the open source community to gain commit rights to a component, the hacker in this scenario compromised 'strong_password' and its dependencies and locked out the gem maintainer. The boldness of bad actors is escalating.
The Attack Mechanics:
- As noted in his blog post, Tute Costa while updating gems for his Rails app (about 25 of them) noticed something suspicious in the CHANGELOG.MD file related to strong_password
- He realized no changelog file existed for version 0.0.7 (Changelog or release notes typically list the new features and bug fixes that were introduced in the latest version of a software release)
- 0.0.7 seemed as if it had been newly released but there was no documentation indicating what had changed
- The GitHub repository for the project did not show any major changes for the prior six months. The new version only appeared on RubyGems
- Costa decided to investigate what had changed, only to discover a minified variant of the following snippet appended at the end of the file: lib/strong_password/strength_checker.rb
- Upon noticing the latest gem was published from an “almost empty” account, Costa further followed up with the maintainer of the official repository to clear up the cause for this discrepancy.
- The maintainer’s response confirmed that there had been unauthorized access, and the malicious version 0.0.7 had been published in an unauthorized manner.
From Tute Costa’s blog:
Malicious code snippet in the gem:
Minified version (show again for reference):
Malicious payload within the linked pastebin file that the component would eventually fetch:
Remediation Recommendation:
Because this package is inherently malicious, we recommend removing it completely. Any hosts that downloaded and ran this package should be considered compromised and be remediated as appropriate.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2019-13354 within hours of the discovery. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.
