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.

 

set_temp.bat 207 bytes View Download