[Penetration Testing] WebDAV IIS 6.0 / TCP/IP IOCTL Privesc

TRY HARDER: A Blog About Discovery

Author: Brennan Turner @BLTSEC
Foothold: Buffer Overflow in WebDAV service IIS 6.0 (CVE-2017-7269)
Escalation: NULL pointer dereference Privilege Escalation via tcpip.sys (CVE-2014-4076)

Mission: Investigate the system with an ip address of and determine if any vulnerabilities exist. If vulnerabilities do exist determine if they can be exploited. Finally help mitigate risk by suggesting security controls to implement.

Disclaimer: This is a test system and some of the below methods shouldn’t be done in a production environment. Use these techniques responsibly and ethically and always test every flag, switch, command, and exploit in your own test environment prior to running in a customer’s environment.

Enumerate: I began by running the following command “nmap -v -sV -O -F –version-light -oA /home/dfadmin/grandpa/gramps” This command gave verbose output, gathered versions and details of the ports and their associated services, tried to determine the target’s operating system and finally ran a scan that targeted fewer ports than normal.

The scan resulted in port 80 possibly running Microsoft IIS 6.0. Now let’s start Nikto and look for vulnerabilities to research and test.

It was apparent by the scan that the WebDAV and HTTP methods needed to be investigated. I ran the nmap script http-webdav-scan.nse which verifies that WebDAV is running, checks it’s methods, and in addition checked the HTTP methods available.

So far we have gathered details about the os and service running on the target. We know that the operating system is most likely an early WIndows server most likely Windows 2003 based on the IIS 6.0 service running on the machine and we know WebDAV methods are available to enumerate as well as HTTP headers. Another option to verify that WebDAV is running on the target is by using the WebDAV PROPFIND method with netcat or telnet.

The WebDAV method PROPFIND is used to retrieve XML stored properties from a resource. It can also be overloaded to allow one to retrieve the directory hierarchy of a remote system. We can also check a server by testing the extensions that WebDAV uses and checking the response; this tells us if it’s running or not. The response above indicates the WebDAV is enabled, notice the 411 Length Required response specifically.

Exploit: Now it was time to look online for possible exploits. I stumbled upon this article. This exploit as explained in the article is caused by a buffer overflow in the ScStoragePathFromUrl function in the WebDAV service in Internet Information Services (IIS) 6.0 in Microsoft Windows Server 2003 R2 which allows remote attackers to execute arbitrary code via a long header beginning with “If: <http://&#8221; in a PROPFIND request, as exploited in the wild in July or August 2016. Below is the metasploit exploit with a similar description. Our target certainly meets all of the requirements for this exploit to work, now it’s time to exploit the target.

I executed the exploit and gained a meterpreter session with limited functionality, the session was running as Network Service. I couldn’t even run the “getuid” command and dropping the session into a shell was very unstable and caused the session to die after a few minutes. I then tried to escalate privileges using some suggested exploits but I received an error message indicating I had insufficient privileges.

I needed a more stable process to migrate to and I had very few options. I decided to try and migrate to the davcdata.exe process. I wasn’t sure if there would be a gain since it was in the same directory but it was worth a shot.

I migrated to davcdata.exe successfully and was presented with a NT AUTHORITY\SYSTEM session. I didn’t catch this until I tried to execute a privesc exploit and was met with the message below. This migration to System wasn’t expected and definitely not what I encountered the first time I exploited this system. It was nice to receive this session but I didn’t feel like it was a reliable poc to document. I wanted to try exploiting this box in a reliable manner so I tried the steps again.

I ran metasploit’s local_exploit_suggester and reviewed the suggested exploits. I decided to look at ms14_070_tcpip_ioctl because the target seemed to be a perfect fit for the target. It also allowed privesc which was my ultimate goal.

Escalation: I found this blog post from the team that submitted the Metasploit module. Basically, this is a buffer overflow exploit from a high overview perspective. An attacker can make an unprivileged IOCTL call which allows the attacker to assign a null value to the ESI register. This allows the attacker to control memory and dictate the flow that follows. I ran the exploit and gained System as shown below.

Below is the entire initial foothold and privilege escalation process shown in one screenshot.

Mitigations: Both exploits are certainly considered legacy and the obvious solution is to update the operating system and update the IIS version. I can think of instances where this may be hard to achieve. I did some work in a couple of manufacturing plants and their legacy control systems would almost be impossible to migrate. So in this case I have outlined mitigations to implement to limit the amount of risk. There’s no such thing as a company having zero risk, a company has to accept some amount of risk. It is our job to offer solutions to help limit the amount of risk a company has to accept. Microsoft hasn’t determined any mitigations for the WebDAV issue as stated here. Microsoft states the solution is to update, which the update link is included in the article link above. The update addresses the vulnerability by changing how WebDAV handles objects in memory. For the TCP/IP IOCTL exploit Microsoft hasn’t identified any mitigating factors and suggest apply the patch that will resolve the issue. That information can be read in the Microsoft Security Bulletin MS14-070