HTB: Devel

...

Intro:

A nice, straightforward box that taught me more about using compilation tools than actually hacking the box!

Recon:

Pulling a classic nmap -sT -sV -A -v <ip> Brings up an anon-enabled FTP server, and an open port 80.

Doing a quick check on the web server version shown by nmap (Microsoft IIS httpd 7.5) shows it's up to date and probably not vulnerable to exploits itself. We can open the page itself which contains a single image of a welcome sign, which when clicked brings us to the homepage for IIS, Microsoft's web server.

Checking out the FTP server shows us an interesting couple files: "iisstart.htm" and "welcome.png". The "welcome" picture hints to the website's homepage, and the .htm file confirms this. We currently have access to the webserver's root directory, which can be verified by uploading a text file and navigating to it in a browser: echo 'Hello, World!' > hello.txt; ftp <ip> <<< $(echo -e 'anonymous\n\nput hello.txt').

NETting a shell:

Since we are able to upload files, we can probably try uploading a reverse shell. But what language should our shell be written in? Well PHP doesn't work (because I've tested it), and by googling a bit because we aren't all web devs, we find we can run ASP code, as well as other languages such as C#. In an attempt to do everything as manually as possible, I see how hard it might be to write an ASP rshell manually. Nope. Next I try msfvenom to generate an rshell, but was unsuccessful in getting one to work. I would consistently get error 500 from the server, and to this day I'm not too sure why none of them worked.

The FTP root, cluttered by my tests and fails

Finally, I caved and stole an aspx reverse shell off github [1]. This worked like a charm though so I can't complain. Upload the shell via the FTP server and start a netcat listener: nc -lvp 3184. REMEMBER to edit the address and port in the aspx file. Unfortunately the reverse shell doesn't land us the user flag, so we need to do a little bit more...

Getting Usoot (User+Root):

Looking around, we can don't see too much. We can move to "C:\Users" and find a user "babis" who's home directory we don't have access to. This means we either need to find credentials somewhere, or we can go straight to system. There are two reasons we're doing the latter:

  1. A quick look around shows nothing of interest; No databases, secret special folders that might hide credentials, nothing.
  2. We hadn't come across anything hinting at the idea of stealing login details. This thought process is more geared towards the fact that this is a challenge and I'd advise against this because it'll build a bad habit of breaking the fourth wall O_o!

We can do a quick systeminfo to see what we're working with. We find the OS version is "6.1.7600 N/A Build 7600". A google search of the version alone brings us an exploit against the "MS11-046" bulletin [2]. It's a LPE, but the exploit is written in C (Boo hoo no Python!).

"systeminfo" showing us the OS name & version

There is no compiler on the target which means we need to compile it on our machine, which is a Linux box. How can we compile a Windows binary on a Linux box? MinGW-w64 that's how! It took me a decent amount of research to find this but here we go. Install mingw however you do on your system. Then compile it using: i686-w64-mingw32-gcc <exploit file> -o exploit.exe -l ws2_32. This is the command breakdown:

Final step is to upload the compiled exe (I just used the FTP server because it's already there) and execute it: exploit.exe. Now you won't see anything happen (it only prints when you exit the shell), but if you try "whoami" you'll see the beautiful "nt authority/system" popup on a new line. Go get those flags:

Showing off the exploit, as well as the output after exiting the shell

Understanding MS11-046:

Just so we aren't blindly using exploit, let's try to understand this, at least slightly.

This is an LPE exploit that abuses an issue in the Ancillary Function Driver "afd.sys". It's a kernel mode driver that is responsible for allowing proper functionality of the Winsock TCP/IP protocol [3]. The exploit works because the driver doesn't properly validate input passed from user mode, meaning a specifically-crafted input will allow us to up our privileges.

The way our exploit does this is by starting an arbitrary socket connection using Winsock, which will invoke "afd.sys".

Connecting to closed socket

Next it generates shellcode that will steal the AFD application's access token. The shellcode will then copy the token to our proces, effectively turning us into System.

Creating the shellcode

Finally, it sends the shellcode, upgrades us to System, then starts a shell as System [4].

Part of exploit execution. See [4] for detailed explanation




Resources:

ASPX Reverse Shell


afd.sys Exploit [EXTERNAL]


AFD Description [EXTERNAL]


NtQueryIntervalProfile() [EXTERNAL]




Last edit: 2021.08.25