search

v4ng3l1s / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows: Local WebDAV NTLM Reflection Elevation of Privilege #222

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by fors...@google.com on 18 Dec 2014 at 3:53

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 18 Dec 2014 at 9:08

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Correspondence Date: 20 Jan 2015

> Microsoft asked if we'd considered Extended Protection for Authentication 
when disclosing the issue. They state that for SMB the issue can be remove but 
to quote: "The only complication is that, due to application compatibility 
concerns (i.e., trying not to break the universe) the features need to be 
enabled and are not on by default." They provided links to documents from 
2009/2010 discussing how to enable this. They also state that "Absent arguments 
to the contrary we are inclined to consider the issue already addressed by the 
existing materials."

< We informed Microsoft that yes this had been considered and the original 
write-up makes reference to SMB signing etc as a mitigation and that there 
seems to be extended protection but that doesn't seem to mitigate in the 
default case. The references provided were consulted but they refer 
specifically to XP/2003/Vista which didn't have EPA available, and even then it 
wasn't enabled by default. As this issue affects Windows 7 and 8 where EPA 
should be on by default then specific SMB settings not liked in the documents 
would need to be considered to mitigate the issue. These are internal policy 
settings which could be deployed easily in a enterprise environment but not 
really for average consumers. Asked for clarification on their final statement 
regarding it being already addressed. Did this mean that even though a local 
system elevation exists in a default installation of Windows that they would 
not provide a fix but just request end users change the defaults?

Original comment by fors...@google.com on 11 Mar 2015 at 3:58

GoogleCodeExporter commented 9 years ago 
Correspondence Date: 10 Mar 2015

< Asked Microsoft if any further progress had been made on this case 
considering the 90 day deadline expires on the 18th March.

Original comment by fors...@google.com on 11 Mar 2015 at 3:59

GoogleCodeExporter commented 9 years ago 
Correspondence Date: 18 Mar 2015

> Microsoft indicated that they felt their previous response indicated they 
would not be servicing this issue with a bulletin due to application 
compatibility concerns. Enabling SMB signing or SPN validation settings 
mitigates the issue and they might consider making it the default going 
forward.

Original comment by fors...@google.com on 18 Mar 2015 at 7:23

GoogleCodeExporter commented 9 years ago 
As this is a known issue Microsoft have provided some links to advisories and 
Knowledge Base articles which discuss how to deploy mitigations. 

Security Advisory: https://technet.microsoft.com/library/security/973811
KB Article: http://support.microsoft.com/kb/973811
SMB EPA KB article http://support.microsoft.com/kb/2345886

Additionally you can also disable the Webclient service which makes it more 
difficult to elevate to local system. This doesn't necessarily mitigate against 
other local attacks (such as sandbox escapes) which only require user level 
permissions.

Original comment by fors...@google.com on 18 Mar 2015 at 8:51

GoogleCodeExporter commented 9 years ago 
Marking as WontFix and opening the issue to the public.

Original comment by fors...@google.com on 18 Mar 2015 at 11:37

GoogleCodeExporter commented 9 years ago 
Why the anti-reflection check isn't effective in the cross-protocol scenerio?

Original comment by davidson...@gmail.com on 19 Mar 2015 at 7:56

GoogleCodeExporter commented 9 years ago 
@davidson.shahar

The anti-reflection check added in MS08-068 is explicitly per-service and 
opt-in, no doubt for compatibility reasons. The typical scenario is causing an 
SMB connection outbound (such as a boobytrapped web page) and reflecting the 
credentials back to the same place. This is achievable cross-protocol by using 
NTLM auth over HTTP but due to default security policies this is usually only 
possible to do in domain joined machines in the victim machines Intranet which 
limits the impact. Of course from what I can find no-one has publicly 
documented the case where this is abused locally where many different security 
restrictions (such as blocking admin shares) seems to not be in force.

Original comment by fors...@google.com on 20 Mar 2015 at 4:49