Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Anatomy of the RubyGems 'REST-Client' Hack, and Getting Creative About Open-Source Security

DZone 's Guide to

Anatomy of the RubyGems 'REST-Client' Hack, and Getting Creative About Open-Source Security

We need new open-source security software to stay ahead of the bad actors.

· Open Source Zone ·
Free Resource

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 far as hacks go, it 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:

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 our company, 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.

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 continues 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. 

Topics:
os ,rubygems ,open-source security ,oss ,security ,strong password ,bad actor ,hack

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}