HTB Starting Point: Oopsie

This week, we are moving forward from the last box and learn some new techniques.

After ensuring we have the VPN turned on with a solid connection, we start off with a quick nmap scan to get started. Of course I start with putting the IP address of Oopsie in a variable, but here is the quick scan:

This was enough for us to start an investigation. While I investigate these, I’ll let the full nmap run in the background to get the full picture: nmap -p 0–65535 -sC -sV -oN Oopsie.nmap $IP. Assuming that we don’t have access to ssh, I’ll start with port 80. A quick set of curl commands can give us what we are working with:

So we are using Apache. Quick look in searchsploit doesn’t give away any big exploits for this version, so on to the webpage. Looks like there is an “admin@megacorp.com” in there. This page has quite a bit of content, so let’s start with filtering out the links to webpages and scripts. We can do this with curl $IP | grep -E — colour ‘href|script’ which gives us a few options. Looking at this list, we have a theme, css, js, and cdn-cgi directories. Additionally, it says that there is a login area. Sounds juicy, let’s go give it a shot. Starting with curl $IP/cdn-cgi/login/ gives the source code. Looking through here, we can pull out some important things. Now we know that login gives a POST call to index.php with username and password as data. We have a few options here on where we can move forward. I’ll check to see if this page is vulnerable to sql injection. Easy way is to try sqlmap $IP/cdn-cgi/login/ — data username=user:password=pass to see if it can identify anything. It comes back with nothing injectable. We have an option of brute-forcing, but there is not much value in learning that way. In the webpage it indicated admin@megacorp.com and on the previous box we had admin’s password. Let’s try it.

And that worked! Password reuse wins again. Okay, Lets enumerate further. Clicking through the links at the top, the “Uploads” page says “This action requires super admin.” Guess being admin isn’t good enough, so looking around we see that each page has some get parameters that control content on the page. Open up the “Web Developer” tools on your browser and you can see the “Storage.”

So I am user 34322 as indicated in my cookie, but I am id of 1 in the bar. If I change it to a ‘2’, then I get nothing on the screen. Looks like I can manipulate it. With this, I’ll jump to the command-line and use wfuzz! I’ll start with this to verify it works: wfuzz -c -z range,0–2 — hh 3595 -b role=admin -b user=34322 -u “http://10.10.10.28/cdn-cgi/login/admin.php?id=FUZZ&content=accounts" and it works! When I ran the code, I saw that a page with no table gives me a header length of 3595. So I added that to my above command so I won’t see that output in the table. So I’ll expand out an make the range go from 0–100. That finds some results:

So we manually go back to the page and try these 4 payloads (‘1’ doesn’t count) and we see that ‘30’ is the superadmin. I’ll steal his email address and put it in my notes and now we have the Access Id. Looking at the cookie, let’s see if we can just change the value of the user to the new AccessId. Refresh the page and it takes it. Navigating to the uploads page, there is now a spot to upload a file. We are on a php page, so let’s try to upload a php shell and see where that takes us.

So that was a success, but now where did it go? We never did any directory busting in this process, so we now have to go find out where these uploads go. I’ll do a few tries and see if we can guess. Navigate to $IP/upload and it gives us a 404. Try $IP/uploads and it gives a 301, yea! Fire up a listener and then curl $IP/uploads/revshell.php and we have a shell! However, it immediately tells me that it isn’t a tty shell, so let’s get there.

We now have a tty shell and let’s start looking around. In a web user directory, I normally want to look for configurations or stored passwords. Drilling down into the html directory, there are a few php files. There is a database connection that has hard-coded passwords. Let me copy those out and let’s dig into the database. Connecting to mysql with these creds, there wasn’t anything in the database that was interesting. I have creds for mysql for robert, does that work elsewhere? Let’s try su robert and see if it works…it does. Password reuse hits again (I see a theme here). Now that we are robert, again, look around the home directory and see what we got. After looking through these files, we don’t find anything juicy so I’ll turn to linpeas. Running linpeas gave me the following things that looked abnormal to check first:

So I’ll investigate these before I go try kernel or process faults. I’ll start with /usr/bin/gettext.sh. I start with file, then inspect that file. Nothing good. Next is /usr/bin/bugtracker. I start with file, and it is an executable. So I’ll look at the libraries using ldd but there is nothing exploitable there since I cant hijack those paths. I run strings to see if I can get an idea of what the program has hard-coded. I then run ltrace to see exactly what the calls do.

Looking at the output, it looks like a system command is calling the cat command and looking at the setguid line, it is setting the UID as 0 which is root. Why is that? Oh, do an ls -al and the stickybit is set. So let’s hijack the environmental path and make it execute the cat command of our choice. Maybe something easy?

So we put something simple in the cat command, updated it to executable, then updated the linux PATH. Then running the executable, we get dumped in to a bash shell as root! I don’t want to lose this and need a backdoor, so I’ll create a basic ssh key (ssh-keygen) and upload it to the authorized_keys file for root. Now I can get in as root anytime. Now time to pillage, so I pull the shadow file for passwords and look around for credentials. There is a file inside of the .config that has some additional credentials. Based on the last box, I’ll add all these I found to my crendential file because password reuse may be a theme here!