Misconfigured Redis

One of the category of VMs available on Bitnami was tagged as #database. I decided to check Redis this time. My goal was to install it on clean Ubuntu 18 server and configure as 'vulnerable'. Let's say it will be our small 'vulnerable Redis Lab' ;) Here we go...

TL;DR - what'll you need:

* Redis - I used this one
* Ubuntu - I used "ubuntu-18.04.1-live-server-amd64.iso"

(*More details about 'attacks' described below you will find on 'reference' section.)

 

After you will install Redis-stable you'll also need to enable remote console (just in case you would like to leave your box more vulnerable to remote attacks ;] and we like to do that in our scenario).

Few ways to do that is to find redis.conf and:

- go to line 69: and add a comment (#) to "bind 0.0.0.0". Then restart redis.

- find "protected-mode" in config file and set it to 'no'. (Then restart redis.)

- change "requirepass" value to "". ("empty" value)

- restart redis-server with --protected-mode no.

It should be ready for remote connection.

Good. Checking connection - after this article:

So far so good. We can connect to remote Redis and grab some info.

Next I was reading about some attacks related to vulnerable Redis configuration (see; Reference section below). One of them was described here. I was wondering if I can achieve similar results on my 'configuration'/'lab'. 

So I started from nmap and scan to get remote ports:

We have SSH, WWW and Redis. With our configuration it shoud be good enough to 'root the box':

As you can see the trick was also described in 'Network Security Assessment: Know Your Network' book:

Checking:

I deleted $HOME/.ssh on attacker's VM to generate new key:

Key file copied to $HOME:

Now we will "delete all the keys of all the existing databases":

 Checking keys:

 Checking:

...and we forgot about...

Ekhm... ;] Again:

Looks like this is a good reason to protect your Redis server(s). ;)

Cool. But as we already know on our target-Redis-machine we found also WWW server.

According to the possibility of reading/writing files I was wondering what about www-related attacks (like dropping webshell, etc...).

So, here we go again:

Scenario-lab: Ubuntu 18 with Apache2 and PHP7.2:

root@redis:~# php7.2 -v
PHP 7.2.10-0ubuntu0.18.04.1 (cli) (built: Sep 13 2018 13:45:02) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.10-0ubuntu0.18.04.1, Copyright (c) 1999-2018, by Zend Technologies
root@redis:~# ps aux | grep redis

Ok, now: as you can see I tried to place php-webshell inside 'ssh' string:

Parser didn't liked it.  I also tried reverse-shell from PentestMonkey but after uploading it via Redis there was too much noise to get connection back. So I decide to use phpshell based on fsockopen(). And now we are here:

Preparing backdoored file:

I added few newlines to avoid noise-in-the-file situation (from example before with sshkeys):

So now:

With netcat listening on port 4444/tcp on local Kali machine I decided to check our uploaded (misha.php) file via browser:

As you can see netcat was able to grab the connection from remote host so I think that shoudl be the end.

Remember to configure Redis securely. Multiple details about it you can find on Redis official webpage: here or here.


References:

When I was reading about this misconfiguration bug I found a lot of useful informations on resources mentioned here: 1, 2, 3, 4, 5.

If you would like to share some other interesting cases related to Redis security feel free to leave a comment or drop me and email/msg.

Cheers