Windows: Local WebDAV NTLM Reflection Elevation of Privilege
Platform: Windows 8.1 Update, Windows 7
Class: Elevation of Privilege

Summary:
A default installation of Windows 7/8 can be made to perform a NTLM reflection attack through WebDAV which allows a local user to elevate privileges to local system. 

Description:

NTLM reflection is a well known issue with Windows authentication. It’s typically abused in networked scenarios to reflect credentials from one machine to another. It used to be possible to reflect credentials back to the same machine but that was mitigated in MS08-068 by not honouring NTLM authentication sessions already in flight. However this did nothing to stop cross-protocol attacks. 

The WebClient service for WebDAV (which is installed and enabled by default, although you’d need to start it using its service trigger) also does NTLM authentication if the server requests it. As Windows has no block on binding to TCP ports < 1024 from a normal user account then we can setup our own WebDAV server running as a normal user bound to localhost (so also no firewall issues). If we can convince another user, ideally local system to connect to the WebDAV server we can start an NTLM authentication session. This can then be replayed locally to the TCP/IP CIFS service endpoint to authenticate as that user. If this was a local system account then that gives you full local admin privs, you can read/write any file on the system through the admin shares. You could also bind to local named pipes such as the service manager and create a new privileged service. 

I’d put money on there being many ways of getting local system to open an arbitrary file, but the easiest one to exploit is Windows Defender (at least on Windows 8.1). You can tell it to initiate a scan of a file which gets opened under the local system token. Of course this might be a bug in and of itself. No processing of the path is done, it seems to be passed directly to CreateFile. This will cause a webdav connection to start to localhost and then NTLM can be negotiated. 

I don’t believe I’ve changed the settings on my VMs which would enable this attack. Certainly reading Group Policy settings it seems like localsystem shouldn’t authenticate with the machine account by default, but it seems that you can. I’ve checked my security settings and they look correct. I’ve tested it on Windows 8.1 Update with defender, and on Windows 7 manually executing the open as local system and they both work. 

After a quick search I can’t find anyone documenting this for the purposes of local privilege escalation attacks although it’s perhaps an obvious way of abusing the functionality so I would expect this is not common knowledge. It is the sort of bug which could be being exploited in the wild considering all it needs is socket access (which is any user) and some way of convincing a privileged user to open the local webdav share. Of course no-doubt it can be effectively mitigated using SMB signing although it isn’t clear that the NTLM extended protection is doing anything to stop it. That said this works in a default installation even with file sharing effectively disabled (at least as far as the GUIs will allow). 

Even with signing enabled on the client I guess it’s possible that you can reflect the NTLM credentials to a local TCP DCE/RPC endpoint instead to achieve a similar effect. Also I wouldn’t be so sure that WebDAV is the only way of doing this. Again another one might be COM marshaling and specifying a endpoint locally (although it might be clever enough to not directly communicate for that one). Another use for this attack is for negotiating a local impersonation token for local system which could be used for Token Kidnapping purposes. Calling AcceptSecurityContext from any account with permissions to handle enterprise auth will be handed back an impersonation level token, even normal users. But of course network service etc would have most use for the token. 

Proof of Concept:

I’ve provided a PoC which causes the Windows Defender service to open a WebDAV connection as Local System. This is for Windows 8.1 only as Windows 7’s defender doesn’t support the command as far as I know. The credentials are reflected to the local SMB service to write the file dummy.txt to the root of the C: drive. Of course more dangerous things could be done at this point. The PoC is written in Java just because it was the easiest to modify it’s library. No doubt an existing relay application could be repurposed, for example SmbRelay3 is supposed to be able to relay HTTP to SMB auth, but I didn’t try that. 

1) Install latest Java 8 JRE.
2) Start the WebClient service, this could be done in many ways from a normal user, for now just start it using the service manager. 
3) Extract the PoC to a directory.
4) Run “java -jar SmbTest.jar” in the extracted directory. This binds the WebDAV server then starts a scan with defender, after some seconds the exploit should run (there’s some slowness in everything starting). 


Repro Notes:
If the PoC prints that the WebClient service isn’t started then start it. If no HTTP/NTLM traffic is printed to the console then webdav/mup had marked the server as down. Restart the webclient service and it should fix it. 

Expected Result:
It shouldn’t be possible to elevate privileges, the SMB connection should fail to authenticate

Observed Result:
Authentication was successful as local system and a file written to the root of the C drive .

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.


 

poc.zip 741 KB Download