The strong_password RubyGems Supply Chain Attack

What happened

An attacker took over the gem owner's account and published version 0.0.7 with a hidden backdoor. The researcher who found it reports that the account was compromised through credential reuse across breached services and no two-factor authentication.

The new code was added at the end of lib/strong_password/strength_checker.rb. It started a background thread. The thread waited a random time, checked that the app ran in production, and then fetched code from a Pastebin post and ran it with eval. Errors were silently ignored. The code also sent the URL_HOST value to a remote domain. A second part added Rack middleware that decoded and ran Base64 commands sent in an HTTP cookie.

The researcher found the problem on 3 July 2019 by comparing the code on RubyGems.org with the GitHub repository. GitHub showed no recent change. The published gem had extra code at the end of the file. RubyGems.org yanked the release, locked the attacker's account, and restored McManus as owner. SecurityWeek reports 537 downloads of 0.0.7 before removal. Snyk also published an analysis.

Affected versions

• strong_password 0.0.7 (malicious, CVE-2019-13354)
• strong_password 0.0.6 (clean, a plain offline string-scoring library)

The advice from Rubysec was to downgrade to 0.0.6 at once.

Indicators of compromise

• Pastebin URL https://pastebin.com/raw/xa456PFt
• Domain smiley.zzz.com.ua
• A production check of the form Rails.env[0]=="p" in strength_checker.rb
• An HTTP cookie with an ___id parameter that carries Base64 text
• The gem uses the Faraday gem to talk to the remote server

How to check

List the installed version, then search the gem files for the Pastebin address. Neither command runs the gem.

gem list strong_password
bundle list | grep strong_password
grep -rn 'pastebin' "$(bundle exec gem contents strong_password | head -1 | xargs dirname)"

Also check Gemfile.lock for the version.

grep -n strong_password Gemfile.lock

What to do now

1. Pin strong_password to 0.0.6 or update to a fixed release, and run bundle update strong_password.
2. If a production app ran 0.0.7, treat the server as compromised because the code ran remote commands. Rotate secrets, keys, and database credentials.
3. Search outbound logs for pastebin.com and smiley.zzz.com.ua.
4. Turn on two-factor authentication for every RubyGems account you own. Use a different password for each service.
5. Compare gem contents on RubyGems.org with the source repository when you audit dependencies.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 12

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    lib/strong_password/strength_checker.rb
           It now downloads from the internet and reads saved passwords and access keys. It did not before.

Sources

1. withatwist.dev/strong-password-rubygem-hijacked.html
2. securityweek.com/malicious-code-planted-strongpassword-ruby-gem/