Sonatype Selected by Equifax to Support OS Governance Press Release

blog-logo Sonatype Blog

Nexus Intelligence Insights: CVE-2019-13354: 'strong_password' embedded malicious code, RubyGems

July 10, 2019 By Elisa Velarde

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
Minified snippet 2019_13354
  • 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.
“The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019,” -  Brian McManus, the project maintainer.

From Tute Costa’s blog:

Malicious code snippet in the gem:

Malicious code snippet 1 2019_13354

Minified version (show again for reference):

Minified snippet 2019_13354

Malicious payload within the linked pastebin file that the component would eventually fetch:

Malicious code payload snippet 2 2019_13354

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.

 

Tags: vulnerabilities, Ruby Gems language, featured, Nexus Intelligence Insights, embedded malicious code, cve-2019-13354

Written by Elisa Velarde

Elisa is a Senior Product Marketing Manager at Sonatype. She brings over 10 years of experience in sourcing, mentoring, and leading Marketing or full Agile product teams while maintaining a collaborative, cross-departmental approach to support company goals.