On March 8th, Imperva published a blog post about a new cryptojacking attack that incorporates Redis. From an engineering perspective, this attack isn’t so much a marvel as a complicated Rube Goldberg machine that happens to have Redis as one of the cogs. Good news though:
The Imperva blog post does a good job of explaining the exploit, so I won’t “reinvent the wheel” here, but I will briefly outline how Redis is involved:
Experienced Redis geeks are probably screaming right now. Let’s go over all the poor decisions related to Redis that need to be made to be vulnerable for this exploit:
In short, this attack targets those who manually altered settings to do dangerous things.
Redis Enterprise, on the other hand, is protected out-of-the-box against these types of attacks by providing a pure separation between the management / administrative plane and the data-path plane. For example, all CONFIG commands of the standard Redis API are disabled. Additionally, Redis Enterprise comes with a built-in multi-layer security control that includes an access control layer, authentication layer, authorization, forensics layer, encryption layer and available protection layer. A detailed description of all of these features can be found on the Redis Enterprise Security Technology page.
So, there you have it—a very ill-advised configuration is at the heart of this exploit. Don’t jump through hoops to make your open source Redis server less secure… or just use Redis Enterprise and you’re golden.
By continuing to use this site, you consent to our updated privacy agreement. You can change your cookie settings at any time but parts of our site will not function correctly without them.