|
|
Windows: AppInfo AiCheckSecureApplicationDirectory Bypass | ||||
| Project Member Reported by forshaw@google.com, Dec 15 2014 | Back to list | ||||
Windows: AppInfo AiCheckSecureApplicationDirectory Bypass Platform: Windows 8.1 Update, Windows 7 Class: Security Bypass/EoP Summary: The AppInfo service handles requests for UAC elevation. There's an issue with the checking of secure directories which allows a user to install a UIAccess application without requiring full access to a secure directory leading to the potential for EoP Description: When the AppInfo service launches a UIAccess or auto elevated application it checks that the location of the executable file is in certain secure directories. For example it checks \Windows and \Windows\System32 as well as Program Files. However because some directories are writable by normal users it explicitly excludes them. This includes \windows\tasks and \windows\tracing. It turns out though that it's possible to get a file in the \windows directory which bypasses this check as a normal user as the tracing directory gives a user write permissions. This also means that a normal user can create a named stream on that directory, as this isn't a file under tracing it bypasses the checks in the AppInfo service. As in you can create c:\windows\tracing:abc.exe which isn't under tracing\ and therefore passes the check. A normal user can copy their UIAccess signed executable there, execute it (I think you need to talk to the RPC service directly) and you'll gain UIAccess permissions. I actually documented the attack on my blog, but I didn't mention an actual attack vector as I didn't check very hard, probably because the documentation such as http://technet.microsoft.com/en-us/library/jj852244(v=ws.10).aspx doesn't list the \Windows directory as a valid secure directory. By blog post is http://tyranidslair.blogspot.co.uk/2014/05/abusive-directory-syndrome.html for your information. No doubt you'll consider this a UAC issue and consider it not a problem, that's your decision. Proof of Concept: I’ve provided a PoC which copies a signed file to the tracing directory then executes it to gain UIAccess permissions. 1) Install the root_cert.cer file into the trusted root store. You need to do this as the UIAccess binary is signed with a key I created. You could resign using a real signing key if you like. 2) Execute the LaunchAdminProcess.exe file 5) The PoC should copy the file then execute it, you should see a message indicating that UIAccess has been granted. Expected Result: It shouldn’t be possible to elevate privileges Observed Result: The executed file runs with UIAccess permission without general access to the Windows directory 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.
Project Member
Comment 1
by
forshaw@google.com,
Dec 16 2014
,
Jan 22 2015
As this is likely to be considered a UAC only bypass and might not be fixed I'm providing more context for potential issues. When a UIAccess program executes it not only sets a special flag in the process token but it also increases the integrity level of the token. The IL increase is to bypass UIPI. How much of an increase depends on the type of user being elevated. For split-token administrators this increase is from Medium to High (the assumption being it needs to interact with elevated admin processes which also run at High IL). For a normal user the current IL is taken (so Medium is 0x2000) and 0x10 is added to it. So the result of this increase is to elevate the IL to being just above the current IL, so in this case 0x2010. If you start a new UIAccess program from an existing one the IL is not increased. It's possible to circumvent this and allow a normal user to elevate their token to High IL by exploiting this situation. A normal user can drop their UIAccess privileges using the SetTokenInformation API. So by dropping UIAccess before creating a new process we can ratchet up the IL in 0x10 increments until we hit the maximum limit of High. This has potential implications if there are resources which either do incorrect administrator checks using just the IL or resources which are marked with High IL. A simple example is the root of the C drive. On Windows 8.1 it has an IL label with the following SDDL options, (OI)(NP)(IO)(NW). This means that any object created inherits the IL (though not containers), the IL is only applied to inheritance and isn't propagated and finally a lower IL can't write to the resource. The DACL allows for files to be modified by normal users but restricts that through the IL. Therefore a normal user which can reach High IL can modify certain files in the root of the C drive, by default there's nothing of interest (bootmgr doesn't have the right DACL) but potentially other software might add files which are security critical.
,
Jan 22 2015
To address another potential concern with regards to the requirement that the file is signed with a trusted certificate it's sufficient to place the root cert into the current user's trusted root certificate store. It does not need to be in the local machine store. While the normal UI framework shows confirmation prompts they are not required or enforced by any higher privileged process. Therefore from an attacker perspective it would be possible for malicious code to register a trusted cert and perform the elevation without requiring administrator privileges.
,
Feb 11 2015
Correspondence Date: 10 Feb 2015 > Microsoft indicate that they do consider this a UAC issue so this doesn't meet the bar for a security bulletin. Changes might be considered for a future version of Windows.
,
Feb 26 2015
Microsoft have confirmed that they will not be fixing this issue. Marking as WontFix and de-restricting.
,
Apr 10 2015
Hi, can you please elaborate a little bit on the signing process? I did some changes on your binary but I am getting "Didn't get UIAccess level" - I'm guessing that I need to resign my new binary with a new certificate. Lastly having UIAccess means that I would be able to create a new file in e.g. C:\, right? Thanks!
,
Apr 22 2015
p.s. I found how to sign the binary, it turns out that I neither have write access to C:\ nor I can spawn a cmd with sys privileges. It's something else that it's out of my expertise but thanks for your research. |
|||||
| ► Sign in to add a comment | |||||
