Full Disclosure mailing list archives

By Date By Thread Defense in depth -- the Microsoft way (part 33): arbitrary code execution (and UAC bypass) via RegEdit.exe From: "Stefan Kanthak" <stefan.kanthak () nexgo de>

Date: Fri, 11 Sep 2015 17:10:35 +0200

Hi @ll, part 31 (see <http://seclists.org/fulldisclosure/2015/Mar/92>) showed how to execute arbitrary (rogue) executables planted as - %SystemRoot%\System32\Write.exe, - %SystemRoot%\System32\WinHelp.exe, - %SystemRoot%\System32\RegEdit.exe, - %SystemRoot%\System32\Explorer.exe etc. instead of - %SystemRoot%\Write.exe, - %SystemRoot%\WinHelp.exe, - %SystemRoot%\RegEdit.exe, - %SystemRoot%\Explorer.exe etc., including the possibility to bypass the UAC via RegEdit.exe This works since Microsoft (mis)places these executables (for historical "reasons") in %windir%\ alias %SystemRoot%\ (the path returned from the GetWindowsDirectory() function), although the hard-coded search order looks up %SystemRoot%\System32\ (the path returned from the GetSystemDirectory() function) before %windir%\ alias %SystemRoot%\ JFTR: not all executables (mis)placed in %SystemRoot%\ are there for historical "reasons"; some of them were but not present in Windows 3.x: - %SystemRoot%\BFSvc.exe - %SystemRoot%\FVEUpdate.exe - %SystemRoot%\HelpPane.exe - %SystemRoot%\HH.exe - %SystemRoot%\SplWoW64.exe - %SystemRoot%\TWUnk_16.exe - %SystemRoot%\TWUnk_32.exe - %SystemRoot%\WinHlp32.exe JFTR: in x64 versions of Windows these historical "reasons" are but abandoned completely for 32-bit executables: the 32-bit counterparts of all 64-bit executables located in %SystemRoot%\ have been moved to %SystemRoot%\SysWoW64\. This is backwards compatible since %SystemRoot%\System32\ is redirected to %SystemRoot%\SysWoW64\ for 32-bit executables and due to the hard-coded search order, plus <https://msdn.microsoft.com/en-us/library/aa384187.aspx>: | Access to %windir%\regedit.exe is redirected to | %windir%\SysWOW64\regedit.exe. (Un)fortunately there is no redirection from %SystemRoot%\RegEdit.exe to %SystemRoot%\System32\RegEdit.exe for 64-bit executables and in x86 versions of Windows. RegEdit.exes load various DLLs; since the hard-coded search order (see <https://msdn.microsoft.com/en-us/library/ms682586.aspx>) looks up the application directory first it is possible to have RegEdit.exe load arbitrary (rogue) DLLs planted into %SystemRoot%\ instead of the system DLLs installed in %SystemRoot%\System32\ (except for the "known DLLs", see <https://support.microsoft.com/en-us/kb/164501>). Of course any other executable (mis)placed in %SystemRoot%\ might be (ab)used too! JFTR: it's your turn to fix your poor installation, Realtek et. al.! Proof of concept (for Windows 2000 to Windows 10; use your own "sentinel" ~~~~~~~~~~~~~~~~ instead of mine for Windows NT4): 1. get <http://home.arcor.de/skanthak/download/SENTINEL.DLL> (this is a 32-bit executable [*]; 64-bit executables are available on request); 2. copy SENTINEL.DLL as %SystemRoot%\ACLUI.DLL (use the method shown in <http://seclists.org/fulldisclosure/2015/Mar/92> to bypass UAC); 3. execute %SystemRoot%\RegEdit.exe Mitigation(s): ~~~~~~~~~~~~~~ 1. Create "copies" of the executables installed in %SystemRoot%\ only in %SystemRoot%\System32\ too: For %! In (%SystemRoot%\*.exe %SystemRoot%\*.dll) Do If Not Exist %SystemRoot%\System32\%~nx! MkLink /H %SystemRoot%\System32\%~nx! %! This but only helps if RegEdit.exe etc. are called without their fully qualified pathname %SystemRoot%\RegEdit.exe etc. 2. Define ACLUI.DLL as "known DLL": [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs] "aclui"="ACLUI.DLL" 3. Prevent elevation of RegEdit.exe per UAC in "protected administrator" accounts: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\Windows\RegEdit.Exe"="RUNASINVOKER" [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\Windows\RegEdit.Exe"="RUNASINVOKER" 4. Demote your "protected administrator" account created during Windows setup to a standard user account. See <http://windows.microsoft.com/en-us/windows/user-accounts-faq> and <http://windows.microsoft.com/en-us/windows/change-users-account-type>: | When you set up Windows, you were required to create a user account. | This account is an administrator account that allows you to set up | your computer and install any programs that you'd like to use. Once | you finish setting up your computer, we recommend that you create a | standard account and use it for your everyday computing. If you create | new user accounts, you should also make them standard accounts. Using | standard accounts will help keep your computer more secure. stay tuned Stefan Kanthak [*] see <http://home.arcor.de/skanthak/sentinel.html> PS: more than 22 years after introduction of Windows NT Microsoft STILL continues their VERY BAD and REALLY NASTY habit to give the user account(s) created during Windows setup administrative rights! No, UAC is NOT a security boundary, but just a convenience feature: see <https://support.microsoft.com/en-us/kb/2526083>, <https://blogs.msdn.com/b/e7/archive/2009/02/05/update-on-uac.aspx>, <https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx>, <https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx>, <https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx>, ... Jane and Joe Average will happily give consent to almost any program (like RegEdit.exe) which asks for elevated privileges, DESPITE most warnings! _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/ By Date By Thread Current thread: Defense in depth -- the Microsoft way (part 33): arbitrary code execution (and UAC bypass) via RegEdit.exe Stefan Kanthak (Sep 11)