search

Temptationx / google-security-research

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

Windows Elevation of Privilege in User Profile Service #123

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Platform: Windows 8.1 Update 32/64 bit (No other OS tested)

When a user logs into a computer the User Profile Service is used to create 
certain directories and mount the user hives (as a normal user account cannot 
do so). In theory the only thing which needs to be done under a privileged 
account (other than loading the hives) is creating the base profile directory. 
This should be secure because c:\users requires administrator privileges to 
create. The configuration of the profile location is in HKLM so that can’t be 
influenced. 

However there seems to be a bug in the way it handles impersonation, the first 
few resources in the profile get created under the user’s token, but this 
changes to impersonating Local System part of the way through. Any resources 
created while impersonating Local System might be exploitable to elevate 
privilege. Note that this occurs everytime the user logs in to their account, 
it isn't something that only happens during the initial provisioning of the 
local profile. 

Some identified issues are:

* When creating directories the service does a recursive create, so for example 
if creating c:\users\user it will first create c:\users then c:\users\user. 
Probably not exploitable because Users already exists but of course worth 
remembering that normal users can create directories in the c: drive root. So 
always a possibility being able to place a junction point at c:\users on some 
systems.

* The service creates the temporary folder for the user in 
CreateTempDirectoryForUser and gets the value from the user’s hive 
Environment key (TEMP and TMP). This folder is created under system privileges. 
All it requires is the string starts with %USERPROFILE% so you can do relative 
paths or just replace USERPROFILE in the environment. This probably isn't that 
useful on the whole as the security of the directory is inherited from the 
parent.

* Creation of AppData\LocalLow folder in EnsurePreCreateKnownFolders. This 
might be exploited to set an arbitrary directory’s integrity level to Low as 
it tries to set the label explicitly. But that’s probably only of interest if 
there’s a directory which a normal user would be able to write to but is 
blocked by a high/system integrity level which is unlikely. 

* Probably most serious is the handling of the 
%USERPROFILE\AppData\Local\Microsoft\Windows\UsrClass.dat registry hive. The 
profile service queries for the location of AppData\Local from the user’s 
registry hive then tries to create the Windows folder and UsrClass.dat file. By 
creating a new folder structure, changing the user's  shell folders registry 
key and placing a junction in the hierarchy you can get this process to open 
any other UsrClass.dat file on the system, assuming it isn't already loaded. 

For example you could create a directory hierarchy like:
%USERPROFILE%\AppData\NotLocal\Microsoft\Windows -> 
c:\users\administrator\appdata\local\Microsoft\windows

Then set HKCU\Software\Microsoft\Windows\Explorer\User Shell Folders\Local 
AppData to %USERPROFILE%\AppData\NotLocal.

It seems to even set the root key security when it does so, this might be 
useful for privilege escalation. This has a chicken-and-egg problem in that the 
NtLoadKey system call will create the file if it doesn't exist (it sets the 
FILE_OPEN_IF disposition flag), but you must be running as an administrator  
otherwise the privilege check for SeRestorePrivilege will fail.

I've looked at the implementation on Windows 7 and there are a few similar 
issues but Windows 8.1 implementation of the services does a lot more things. 
At least the most serious UsrClass.dat issue exists in 7. 

Attached is a batch file PoC for Windows 8.1 Update which demonstrates the 
temporary folder issue. To verify perform the following steps:
1) Execute the batch file as a normal user (this was tested with a local 
account, not a Microsoft online linked account, or domain). This will change 
the environment variables TEMP and TMP to be 
%USERPROFILE%\..\..\..\..\Windows\faketemp
2) Logout then log back in again
3) Observe that the directory \Windows\faketemp has been created.

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 13 Oct 2014 at 4:39

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 13 Oct 2014 at 9:29

GoogleCodeExporter commented 9 years ago 
Correspondance Date: 11 Nov 2014

> Microsoft confirmed that they are on target to provide fixes for these issues 
in February 2015. They asked if this would cause a problem with the 90 day 
deadline.

< Microsoft were informed that the 90 day deadline is fixed for all vendors and 
bug classes and so cannot be extended. Further they were informed that the 90 
day deadline for this issue expires on the 11th Jan 2015.

Original comment by fors...@google.com on 9 Jan 2015 at 1:12

GoogleCodeExporter commented 9 years ago 
Correspondance Date: 11 Dec 2014

> Microsoft confirmed that they anticipate to provide fixes for these issues in 
January 2015.

Original comment by fors...@google.com on 9 Jan 2015 at 1:15

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Deadline exceeded - automatically derestricting

Original comment by fors...@google.com on 12 Jan 2015 at 2:01

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Note that the bug tracker is intended for technical analysis and bookkeeping 
related to the specific issue described. In this instance, we're looking to 
keep comments strictly about the technical aspects of this issue.

If you're looking to join a community discussion about disclosure deadlines, we 
have a robust discussion on Issue 118 in our bug tracker 
(https://code.google.com/p/google-security-research/issues/detail?id=118).

Thanks!
Ben

Original comment by haw...@google.com on 12 Jan 2015 at 8:13

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Also works in Win 7 Professional SP 1 64bit.

Original comment by leibi...@googlemail.com on 13 Jan 2015 at 7:33

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Fixed in https://technet.microsoft.com/en-us/library/security/ms15-003.aspx

Original comment by fors...@google.com on 13 Jan 2015 at 6:44

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 14 Jan 2015 at 10:03