Hot Topics

Home » Cybersecurity » SBN News » RubyGems strong_password v0.0.7 hijacked; infected thread and attacker account isolated for now

RubyGems strong_password v0.0.7 hijacked; infected thread and attacker account isolated for now

by Vincy Davis on July 8, 2019

Last week, a developer Tute Costa notified Ruby users that the strong_password v0.0.7 rubygem has been hijacked. The malicious actor published v0.0.7 containing the malicious code, which enabled the attacker to execute remote code in production. As of now, the thread has been tweaked and the attacker’s RubyGems account has been locked.

A strong_password is an entropy-based password strength used for checking Ruby and ActiveModel.

How was the strong_password v0.0.7 hijack identified?

While linking line by line to each library’s changeset, Costa noticed that the strong_password has changed from 0.0.6 to 0.0.7. Although the last changes in any branch in GitHub was from 6 months ago, Costa recalled that everything was up to date. Costa then downloaded the gem from RubyGems and compared its contents with its latest copy in GitHub. He found that at the end of the lib/strong_password/strength_checker.rb version 0.0.7 there was the following message:

Image Source: With a Twist Dev

Costa found that a malicious actor has used an empty account, with a different name than the maintainer’s. The malicious actor has published the gem, after receiving access to the particular gem. Later, Costa forwarded this thread to the strong_password maintainer’s email in GitHub.

Sponsorships Available

Brian McManus, the strong_password maintainer replied, “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.”

How does the malicious code work?

If the malicious code didn’t run before checking for the existence of the Z1 dummy constant, it injects a middleware that eval’s cookies named with an ___id suffix, only in production.
It is surrounded by the empty exception handler _! function that’s defined in the hijacked gem.
This opens the door to the attacker to silently execute remote codes in production.
The malicious code also sends a request to a controlled domain with an HTTP header informing the infected host URLs.

What is the current status of strong_password v0.0.7?

Rafael França, the Ruby on Rails’ security coordinator has added [email protected] to the thread. Later André Arko, the founder of Ruby Together, tweaked the thread and locked the RubyGems account. McManus was later added back to the gem.

Costa also notified users that he asked for a CVE identifier (Common Vulnerabilities and Exposures) to [email protected] and received CVE-2019-13354. He used this CVE “to announce the potential issue in production installations to the rubysec/ruby-advisory-db project and the ruby-security-ann Google Group.”

The community has been praising Tute Costa for his efforts in finding out about the hijack.

“strong_password v0.0.7 rubygem hijacked”.. this person did due diligence like one should. But I’d say that this still exposes problems in the way the ruby gem security ecosystem works.https://t.co/bKvdfhimzl pic.twitter.com/AzJxFYXP70
— mjosdwez (@mjos_crypto) July 8, 2019

A user on Hacker News states that “In light of vulnerabilities like these, I’m glad there are developers that spend time to make their apps more secure. Thus, making us all aware that issues like these are out there. Security is almost always just put off in exchange for features and security is most of the time taken for granted. It’s about time that we start taking it seriously. Kudos to you!”

Many users are also skeptical about RubyGem’s security vulnerabilities.

A user on Hacker News says, “There’s still a lot to learn about this incident, but most likely the RubyGems account was compromised, allowing the attacker to upload whatever they wanted. Signed releases with a web of trust would be ideal, but I doubt we’ll ever see that world. A simple and pragmatic solution would be to have the next version of bundler support the ability to only install packages published with 2 factor enabled, then the next major rails version default it to on, with plenty of advanced warning in 6.x/bundler. This still has plenty of gaps, such as an attacker being able to take over even with 2 factor, and then re-enabling it with their own keys, or RubyGems.org itself being compromised. It still represents a major upgrade in security for the entire Ruby ecosystem without causing much pain to authors and users.”

Another comment reads, “Rubygem should contract an external auditor (security firm), this could go way deeper. Until they perform a thorough audit I will personally stay away from this project.”