<div dir="ltr"><a href="https://www.riskbasedsecurity.com/2016/07/redis-over-6000-installations-compromised/" target="_blank">https://www.riskbasedsecurity.com/2016/07/redis-over-6000-installations-compromised/</a><br><br>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.<br><br>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.<br><br>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 <a href="mailto:ryan@exploit.im" target="_blank">ryan@exploit.im</a>. 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.<br><br>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.<br><br>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.<br><br>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.<br><br>Data Analysis<br><br>Compromises Detected: 6,338<br>Unique ASN: 838<br>Unique ISP: 1,024<br>Unique Hosts: 2,262<br>Unique Domains: 961<br>Unique Redis Versions: 106<br>Unique OS (Operating Systems): 5<br>Unique ORG: 1,121<br>Unique Country’s: 87<br>Unique Keys: 7<br>Unique Emails: 14<br>Unique SSH: 40<br><br>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.<br><br>Redis VersionDetections<br>2.8.41,116<br>3.0.71,096<br>2.8.19339<br>2.8.17305<br>3.0.6274<br><br>Attribution<br><br>As mentioned previously, what caught our attention was that we originally saw a single SSH key with an email pointing to <a href="mailto:ryan@exploit.im" target="_blank">ryan@exploit.im</a>.  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.<br><br>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 <a href="mailto:ryan@exploit.im" target="_blank">ryan@exploit.im</a> with 5,892 detections.  After that there was a significant drop off with <a href="mailto:root@chickenmelone.chicken.com" target="_blank">root@chickenmelone.chicken.com</a> having 385 results followed <a href="mailto:byroot@dedi10243.hostsailor.com" target="_blank">byroot@dedi10243.hostsailor.com</a> with 211 results.<br><br>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.<br><br>Lessons Learned<br><br>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.<br><br>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.<br><br>If you have a Redis installation here are some recommendations:<br><br>Check to see if you are currently infected<br><br>A quick way is to look for “crackit” or other known keys in your installation<br><br>Make sure you are on the most recent version<br>Implement protected mode (available in version 3.2)<br>Learn how to secure your Redis installation<br>Ensure a security resource conducts an assessment of your installation<br><br>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.<br><br>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.<br></div>