Anatomy of the RubyGems ‘rest-client’ Hack, and Getting Creative About Open Source Security

Over the last several years, we’ve been raising awareness of breaches to popular open source software components and the worrying trend that they are more frequently being attacked at the source - bad actors are growing bolder and the velocity of attacks increasing. Last month, the RubyGems strong_password component was breached. The attack involved remote code execution in applications using or bundling `strong_password`. Any developer downloading this component, also downloaded the malicious code. This latest RubyGems compromise is another attack on open source, at the source and as hacks go is about as bad as it gets in terms of the mechanics. Compromising the code source allows hackers to get creative about how they leverage open source libraries for nefarious purposes and do it with unprecedented speed. 

The story of this new hack begins with a topic that’s just about as old as technology time, password hygiene. In the case of ‘rest-client’, the project maintainer was still using a password that had been leaked in an earlier breach. Not having logged on to the project in years, changing his gem password wasn’t exactly top of mind. It’s an oversight that could happen to any of us. We’re human after all. The sequence of events that happened after the maintainer’s password was hijacked, make that oversight unpleasant for many developers. 

From Github, regarding CVE-2019-15224:

• On August 14, attackers published a series of rest-client versions from 1.6.10 to 1.6.13 using the credentials of a rest-client maintainer whose RubyGems.org account was compromised. The affected versions were downloaded a small number of times (~1000).
• On August 19, @juskoljo observed the malicious gem version and created this issue. Later that day, the RubyGems security team yanked the offending gem version and locked the affected maintainer's account. Several other gems were similarly affected.

Here is a summary of the exploit described by @JanDintel on the Github thread:

• It sent the URL of the infected host to the attacker.

• It sent the environment variables of the infected host to the attacker. Depending on your set-up this can include credentials of services that you use (e.g. database, payment service provider).

• It was allowed to eval Ruby code on the infected host. Attacker needed to send a signed (using the attacker’s own key) cookie with the Ruby code to run.

• It overloaded the #authenticate method on the Identity class. Every time the method gets called it will send the email/password to the attacker. However, I'm unsure which libraries use the Identity class though, maybe someone else knows?

So... it potentially compromised your user's passwords, or system account passwords used between microservices.

This is an ugly one. Fortunately, RubyGems yanked the gem, locked the account and published a new component version to supersede the compromised one on August 19. Also, fortunately, not a huge number of downloads were made ….. this time. 

In fact, maintainers of the RubyGems package repository have subsequently yanked 18 more malicious versions of 11 Ruby libraries that contain a backdoor exploit that uses hidden code to mine cryptocurrency in other people’s projects.

At Sonatype, we notified impacted customers within hours of the entire ruby breach and provided custom, curated remediation guidance. With more granular data, they were able to quickly identify whether this specific component was in their code and posed a risk to their projects. Precise, accurate data makes it much easier to identify and contain an exploit, and Sonatype has been helping customers do exactly that for more than 10 years. 

However, binary “fingerprinted” data aside, the increasing frequency of these types of attacks does beg the question, should we be entertaining the notion of attempting to identify a potential compromise before there’s a hack? Would it have been possible to analyze a set of attributes and determine if ‘rest-client’ was vulnerable to an exploit? As the frequency of attacks at the source continue to escalate, the open source community and the open source software partners who support them, will need to get more creative than the bad actors. We’ll need new technology to keep ahead of the threat. Can it be done? Stay tuned.