Postman

High-level Summary:

The host is a Linux machine running a web server on port 80. There is a Webmin portal on port 10000 that is vulnerable to credential-reuse and a Redis database on port 6379 that does not require authentication. SSH is also running on port 22/tcp which is used for the initial foothold.

I was able to gain access by generating my own public-private key pair and uploading the public RSA key to Redis. Once uploaded this provided me with the ability to enumerate the local file system leading me to a user’s backup private key. I was able to crack this private key and use the password for lateral movement on the Webmin portal. This gave me access to use an exploit to compromise the server running as root.

Information Gathering:

I ran several tools to gather information. Many of them provided information but ultimately sent me down a couple of rabbit holes. The most important scan that provided me with the best information was running my go-to Nmap scan.

Open ports 22/tcp, 80/tcp, 6379/tcp, 10000/tcp

Initial Foothold:

The Redis service running on 10000/tcp is write-able and does not require authentication. I also found an article written by the Redis author stating that the service is both exploitable and vulnerable if outside facing. https://packetstormsecurity.com/files/134200/Redis-Remote-Command-Execution.html

Next step was to download Redis-Cli: $ Sudo apt install redis-cli

After connecting to the Redis service, I was able to view the following directory without any authentication.

Directory /var/lib/redis/.ssh exists

Following the articles directions, I generated my own RSA key-pair. The public key is also given a padding and the beginning and end using \n\n. This padding eliminates simple patterns which prevents Redis from compressing the file and ultimately tricks the SSH service into parsing a corrupted file.

A passphrase was not used when creating the RSA key-pair.

Creating the padding, notice the blank spaces before and after the public key.

Now that the RSA public-private key-pair has been generated. It was time to write my public key into the Redis memory. Notice the first error, it is unclear why this propagated. However, I felt it was worth noting that by pressing Enter a second time it managed to successfully write the data anyways.

Created a database key called crackit and set its value to our public key. Then, saved the key to the Redis users authorized_keys .ssh directory.

It is now time to use the previously created RSA private key that is paired to our public key that was just uploaded to the Redis .ssh directory.

SSH terminal connected successfully.

Once connected via SSH I began digging around the directories, a lot of directories. I didn’t find anything interesting expect for what was initially in the root folder when I first connected, a file called .bash_history. By viewing this file, I was able to see the most recent commands that the administrator had previously ran on this machine.

Here is the content of the file

I knew that I could potentially copy the backup of the private key to my system and SSH into the server as the user Matt, if this is indeed his private key. To find where the key was sitting, I used the “locate” Linux cmd.

Used the less cmd to print the private key to my screen. Highlight, copy, open text editor on my laptop and paste.

I then attempted to SSH using the boosted key, unfortunately I was asked to enter a password. In order to crack this password I used JohnTheRipper. In order for this to work the RSA private key had to be converted into a format that it understands.

Converting the RSA key using ssh2john.py

I then copied the text from above and pasted it into a new text document naming it johnkey. This file was then cracked with JohnTheRiper.

Password for the RSA private key is computer2008.

Now that I have a password, I made another attempted to connect via SSH, which failed. It was at this point I began to understand that this private key is more than likely a backup of a preexisting key and does not pair to the currently used public key that Matt is using. However, that does not rule out that we can’t use this password somewhere else. First stop, Webmin running on port 10000/tcp.

Login attempt to Webmin using password computer2008.

Matt likes to reuse passwords, here’s the admin dashboard of Webmin.

After snooping around there wasn’t much going on in this dashboard except for one flaw. Matt is a very lazy guy. Not only does he like to reuse passwords, he also hasn’t updated this server as the bottom right corner of the dashboard displays 60 package updates, of which 32 of them are security patches.

I decided to launch Metasploit and perform a quick search for any tools related to Webmin. I found an exploit that can perform remote code execution. I decided to put the exploit to the test using the username Matt and his password computer2008.

Webmin_packageup_rce settings used for exploitation.
PWNed, vulnerability

Now that I was connected to the Webmin service, I was able to pop a remote shell on session 1 as shown in the last line of the above screenshot.

A quick whoami determines that I have root access.