$ nmap -p- --min-rate 3000 -Pn 192.168.208.166
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 15:23 +08
Nmap scan report for 192.168.208.166
Host is up (0.17s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
6379/tcp open redis
Redis is enabled on this, which is probably vulnerable somehow. I did a detailed scan too:
$ nmap -p 80,6379 -sC -sV --min-rate 3000 192.168.208.166
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 15:24 +08
Nmap scan report for 192.168.208.166
Host is up (0.18s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-title: Readys – Just another WordPress site
|_http-server-header: Apache/2.4.38 (Debian)
|_http-generator: WordPress 5.7.2
6379/tcp open redis Redis key-value store
Wordpress was running on the site, so let's scan that first.
Redis Creds Block
The Redis instance needed credentials to enumerate:
$ redis-cli -h 192.168.208.166
192.168.208.166:6379> INFO
NOAUTH Authentication required.
Wordpress LFI -> Redis Creds
I used wpscan on the website and found a vulnerable plugin.
So we have an LFI, and the only other exploitable thing is the Redis instance. I tried to find credentials for it using this LFI, and found it within /etc/redis/redis.conf:
Searching for the AUTH string allowed me to find the password:
We can then enumerate the database:
Redis RCE
The Redis instance is vulnerable to RCE through the module loading exploit with Redis Rogue Server:
We can easily get a reverse shell using this RCE exploit:
Privilege Escalation
Redis -> Alice
This user had extremely limited privileges over the file system. There was a user present, but I cold not even read the /home directory. There wasn't much else we could do besides try to execute PHP reverse shells using the LFI we had.
I wrote a PHP reverse shell to the /opt/redis-cli directory. Then, using our LFI, we can execute it:
