Between April and May of 2013, I presented at SOURCE Boston and THOTCON and blogged about some of my research involving the exploitation of continuous integration/delivery (CI/CD) services using malicious unit-tests as a remote code execution (RCE) attack vector.

During that time, I explored a number of fun post-exploitation scenarios that an attacker could use if they had successfully exploited the CI/CD infrastructure or build chain. This included attacking the build target directly, pivoting to adjacent systems, and abusing trust relationships that are imparted on these systems by their owners.

In this blog post, I want to briefly explore RubyGems API keys, which I only lightly touched on in my previous research.

What Are RubyGems API Keys?

As I discussed in a more recent blog post on signed RubyGems, a Ruby gem is a simple container for code and other relevant bits that can be portably installed by end-users with a single command, like “gem install gem_name”.

What makes this possible is a centralized repository maintained by RubyGems.org at no cost to gem authors. In order for gem authors to push up new versions of their gems, they need to first authenticate with the RubyGems system with their username and password and a RubyGems API token is then automatically persisted on the developer’s workstation or CI/CD system.

Once a given system has the RubyGems API key stored locally, a username and password is no longer required to push new gem versions. When a new Ruby gem needs to be published, the command of “gem push gem_name.gem” is used, and the system references the locally stored API key to authenticate the publish request.

Why Are RubyGems API Keys “Risky”?

When RubyGems API keys are stored on the system, in the above mentioned process, they are stored in the current users home directory in ~/.gem/credentials.

A typical credentials file would look something like this:

$ cat ~/.gem/credentials
---
:rubygems_api_key: 948979d097a4b11d029bf53f6d371829

There are concerns with this approach, in that the key is not encrypted or protected in any way, which could allow an attacker to quickly gather the key and use it to publish potentially malicious gems on the developer’s behalf. This means an unsuspecting user trying to install the real gem (from RubyGems.org) could end up installing an attacker-controlled gem yielding additional RCE scenarios. Ouch!

A New Metasploit Post Exploitation Module

Today, I’d like to announce a new Metasploit module (“Multi Gather RubyGems API Key”) that I’ve written to make the process of stealing these keys that much easier.

Why would I do such a thing? Well, it’s because I would like to see the security of these API keys improve, and one of the ways we can influence change is by making it easier for security consultants and penetration testers to demonstrate this risk to our customers when build/developer systems are compromised during security assessments.

A prerequisite for using this new Metasploit module is having an existing Metasploit session on a target (the initial attack vector to get the session is irrelevant). Once you set the session id, the post module can extract RubyGems API keys from all users on the system, like so:

This module is currently available in the master branch of the Metasploit Framework GitHub repository here and was included in last Friday’s Metasploit release.

Lastly, I’d like to sincerely thank @_sinner for his timely and thorough review during the development of this post module.

UPDATE – 02/06/2015

For those of you who have contacted me privately thinking I revealed my RubyGems API key, thank you for your concern.

I submit this for your consideration.

$ echo "SpidersAreFun" | md5
948979d097a4b11d029bf53f6d371829

Have a great day!