[BreachExchange] Redis: Over 6,000 Installations Compromised

[Audrey McNeil]

https://www.riskbasedsecurity.com/2016/07/redis-over-6000-installations-compromised/

Recently we have seen an increased focus on Internet devices and services
that are being indexed and exposed by the search engine Shodan, but most of
these reports thus far have focused on the discovery of credentials or
confidential data.

One of our researchers started examining the tens of thousands of Redis
servers that have been indexed by Shodan.  Redis which stands for REmote
DIctionary Server is an open source project, first released in April 2009.
Redis has historically been ranked as the best NoSQL database and has been
previously sponsored by VMware and Pivotal Software making it quite
popular.  Redis functions as an in-memory data structure store which is
most often commonly used for a database cache or message broking between
applications and clients.

Armed with only a desktop viewer, we noticed that many of these Redis
servers indexed appeared to already have been compromised.  We discovered
that there was a common keyspace called “crackit” on a sampling of servers.
Upon further checking of the “crackit” keyspace, it appeared that it was
showing the same SSH key with an email pointing to ryan at exploit.im. The
discovery of this peaked our interest to say the least, as we have run
across that email address previously and we wanted to know more about what
was happening. Next, we started digging and discovered that the “crackit”
key dates back at least six months, with it also being discussed on forums
and in Git commits. This lead to the realization that the key name
“crackit” comes from one of the early Redis exploits released in mid 2015,
and a document outlining the issue has also been translated into Chinese
and spread across many Chinese based sites and forums.

It appears that some Redis users have started to notice and believe that
they have been hacked.  The reality is that they have unfortunately never
had proper security controls in place, as Redis describes in its
documentation. After reading the documentation it becomes clear, that Redis
is shipped for maximum performance and not with security in mind.  Meaning
that by default, Redis has no authentication or security mechanism enabled,
and any security mechanisms must be implemented by the end user.

In the article titled “A few things about Redis security”, the author
provides documentation on how this exploit is carried out and what can been
done to prevent it. The exploit allows an attacker to use the
unauthenticated server’s in-memory features to create an SSH key, add the
key, and store it in the server’s SSH authorized_keys file.  Ultimately
this allows the attacker to connect back to the server via SSH and gain
full access to the host.

After realizing that this issue was more widespread than we initially
thought, we decided to export all Shodan results for Redis servers and
conduct some non-intrusive research.  We checked for the first discovered
and common known keyname “crackit” as well as four other keys identified in
our initial research: “crackit_key”, “qwe”, “ck”, and “crack”. The
preliminary scanning showed that both the “crackit” key and the additional
four keys had minimal repeat results detected. After scanning and analyzing
30,239 Redis results that we had exported from Shodan, we were able to come
up with some reasonable statistics on who has been infected and by whom
purely using the meta data that Shodan provides as part of their exports.

Data Analysis

Compromises Detected: 6,338
Unique ASN: 838
Unique ISP: 1,024
Unique Hosts: 2,262
Unique Domains: 961
Unique Redis Versions: 106
Unique OS (Operating Systems): 5
Unique ORG: 1,121
Unique Country’s: 87
Unique Keys: 7
Unique Emails: 14
Unique SSH: 40

When we discovered that there were 106 different Redis versions
compromised, it was extremely eye opening for numerous reasons.  Given that
Redis 3.2.1 is the latest stable version, it is quite concerning when we
saw a Redis 1.2.0 version was the oldest compromised detected.  This means
that there are a lot of Redis installations that are not upgrading to the
most recent versions to fix any known security issues.

Redis VersionDetections
2.8.41,116
3.0.71,096
2.8.19339
2.8.17305
3.0.6274

Attribution

As mentioned previously, what caught our attention was that we originally
saw a single SSH key with an email pointing to ryan at exploit.im.  But after
the larger analysis, we detected 14 unique emails and 40 unique ssh-keys
combos.  While the email address detected doesn’t necessarily mean it is
the exact person behind the compromise, it does lead us to believe that
more than on individual or group are behind the infections.  Also, based on
the total number of compromised installations it becomes clear that some
emails and keys are being reused quite a bit.

When doing research such as this, some data that is returned can be a bit
messy and makes it a bit challenging to fully confirm exactly who is the
owner. With that said, we were able to determine that the most common email
that is being used was in fact the original address we found ryan at exploit.im
with 5,892 detections.  After that there was a significant drop off with
root at chickenmelone.chicken.com having 385 results followed
byroot at dedi10243.hostsailor.com with 211 results.

We then started to poke around to try to confirm some of the owners of the
discovered keys.  While we were unable to get anyone to go on the record,
it appears from our analysis that we have confirmation of two things, the
first being that this is not a new issue, and second, some servers are
sitting out there infected and are not being utilized for anything
malicious.

Lessons Learned

The key take away from this research for us has been that insecure default
installations continue to be a significant issue, even in 2016.  If your
organization doesn’t want to have your servers compromised then it is
critical to ensure that the correct measures are taken to properly
configure and harden the services and software that you deploy, even in
development environments.

Redis isn’t alone, but it is one of several packages that when installed
comes with no authentication enabled by default.  What is of serious
concern, is that this is well known security problem for a while now, and
while the developer community based around Redis is mostly aware of this
issue they have made no progress to implement better authentication
methods, access control lists (ACLs), as well as default settings making it
more secure out of box.

If you have a Redis installation here are some recommendations:

Check to see if you are currently infected

A quick way is to look for “crackit” or other known keys in your
installation

Make sure you are on the most recent version
Implement protected mode (available in version 3.2)
Learn how to secure your Redis installation
Ensure a security resource conducts an assessment of your installation

With the current state of Redis security, and these known compromised
systems,  there is a real possibility that these servers (and any new ones)
are currently being or in the near future could be used for malicious
reasons.  We sincerely hope that the Redis project will focus on improving
the default state of security of their product, as well as to implement
auto-update features for new versions.

We were unable to find security contact information for Redis to inform
them of our research surrounding the issue prior to release, but we are
planning to provide the link to this article once published on their
mailing list.  If there is anyone that is interested in conducting further
research on this topic, please feel free to contact us to discuss further.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160706/42a0d6dd/attachment.html>