Windows: DosDevices Impersonation Process Creation Elevation of Privilege
Platform: Windows 8.1 Update, Windows 7
Class: Elevation of Privilege
Summary:
The fix for CVE-2015-1644 doesn't take into account process creation scenarios. If a process is created by a system service while impersonating another user their per-user drive mappings will still be used which could lead to EoP.
Description:
As far as I can tell the fix for CVE-2015-1644 was to add a new object attribute flag (0x800) which disables the impersonation device mapping in the name lookup process. This has been applied to the DLL loader code inside ntdll, but doesn't seem to be used anywhere else. One area of attack still available is process creation, if an explicit token isn't specified then the new process inherits its token from the parent, regardless of whether another user was being impersonated at the time.
Looking at the kernel after CVE-2015-1644 there are no changes to NtCreateUserProcess and family to open the executable files with the new object attribute. This means that if a system service was to impersonate a logged on user but call CreateProcess or ShellExecute for an executable it would use the impersonating user’s device map rather than the service's. This could lead to EoP as the new process would run as the service user, while the executable can be specified by the normal user. Calling CreateProcessAsUser is less likely to be vulnerable as in the majority of cases the token being passed is the same as the impersonating user. Of course the attacker doesn't need to control the path to the executable or the command line, they just need to replace the drive mappings so the process creation could be completely inadvertent or a byproduct of an API call.
I wouldn't have probably considered reporting this as I've yet to discover an actual vulnerable service, however the fixes applied in CVE-2014-1807/MS14-027 indicates that there are some services, maybe 3rd party which call ShellExecute under a user’s impersonation token. If this is the case then those services are again vulnerable using this attack instead of the previous registry file extension one. About the only thing I've found which can exploit this is creation of UI Access processes as they are created under the current user’s context, but of course that would be a UAC bypass.
I’d guess that the new object attribute should be applied when impersonating another user and either no explicit token is specified or the token’s user is not the same as the impersonating user.
Proof of Concept:
As I've mentioned I've not found a vulnerable service yet, although one might exist on a default installation of Windows. Therefore instead I've provided a simple RPC PoC which tests out the theory that impersonating while calling CreateProcess or ShellExecute in a privileged service is vulnerable to the attack described. The server will try and execute c:\windows\notepad.exe under impersonation, assuming that the low-privileged user couldn't influence the executable itself. The password for the 7z file is ‘password’.
1) Extract the PoC to a location on a local hard disk which is writable by a normal user
2) As a high-privileged user (one with SeImpersonatePrivilege) execute RpcServer.exe
3) As a low-privileged user run RpcClient.exe
4) The server should execute the arbitrary notepad.exe rather than the real notepad.exe
You can also try passing -s to the client which will instead test ShellExecute. It should work, but it’s not been rigorously tested.
Expected Result:
The original notepad executable should run as the service user
Observed Result:
Arbitrary process runs at the same privilege as the service user
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.
