First entry: Welcome and fileless UAC bypass
Hello world,
welcome to my blog about Windows and scripting in Windows. This is my first entry and I would like to start with a post about an UAC bypass which I found.
I’m a German student and began reading a lot of things about User Access Control (UAC) bypasses for my master’s thesis and I started investigating my own system environment. A few days ago, I found an UAC bypass I want to share with you.
Please note: It is a proof of concept and is not intended for illegal usage.
Tested on: Windows 10.0.15063
Attack vector:
- fodhelper.exe
Preconditions:
- The current user is member of the local administrator group
- The operating system is Windows 10
Implementation:
Fodhelper.exe was introduced in Windows 10 to manage optional features like region-specific keyboard settings. It’s location is: C:\Windows\System32\fodhelper.exe and it is signed by Microsoft.
You can check the signature of a file with a tool named “sigcheck” which is part of the Sysinternal Suite by Mark Russinovich.
As you can see in the picture above, the program is allowed to elevate itself to run in a high integrity context automatically. There is no need for any user interaction to allow the process to elevate. This means that if we are able to tamper the behavior of the binary to load a file of our choice, this file may start in a high integrity context, too.
How to investigate the behavior of the file to find a concrete attack vector? => Process Monitor!
The Process Monitor is another tool written by Mark Russinovich which is also a part of the Sysinternals Suite. Alternatively, you can get just the Process Monitor here.
When initiating the start of fodhelper.exe, process monitor starts to capture the process and reveals (among other things) every read- or write-activity to the registry and filesystem. One of the interesting activities are the read accesses to registry, although some specific keys or values are not found. Especially registry keys in HKEY_CURRENT_USER are great to test how the behavior of a program may change after the creation of a not yet existing registry key, because we do not need special privileges to modify entries.
E.g. fodhelper.exe is looking for “HKCU:\Software\Classes\ms-settings\shell\open\command”. By default this key does not exist in Windows 10.
After creation of the key: “HKCU:\Software\Classes\ms-settings\shell\open\command”, fodhelper.exe will find it and will start looking for the value: “HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute” which it would not look for, if the mentioned key did not exist. As soon as the value “DelegateExecute” exists, it will be found, too, even if it is empty.
Once the value “DelegateExecute” is created, fodhelper.exe will look for the default value in: “HKCU:\Software\Classes\ms-settings\shell\open\command\”.
This value is the critical point. The registry value “shell\open\command\(default)” enables us to provide to the program additional instructions what to do when the program opens.
In this scenario, I set the value of “shell\open\command\(default)” to: “C:\Windows\System32\cmd.exe /c powershell.exe”. After this modification, fodhelper.exe will lookup the (default)-value and follow the instructions how to behave after the process starts. => start cmd.exe which starts powershell.exe (just checking if it is possible to pass parameters to cmd.exe, too)
As you can see, fodhelper.exe reads the (default)-value and starts cmd.exe with the provided parameters.
The result is an cmd.exe starting in a high integrity context which starts a powershell.exe in a high integrity context. In the picture below, you can see both the exact registry structure needed for this proof of concept and the cmd.exe started as an administrator.
To demonstrate this vulnerability, I created and published a script on Github, which will create the registry keys, opens up “C:\Windows\System32\cmd.exe /c powershell.exe” and which deletes the registry keys.
This technique is based on a similiar flaw, found by Matt Nelson (https://enigma0x3.net/) and has the following benefits:
- There is no need to drop a file on disk.
- There is no need to hijack any .dll file
- There is no need for any suspicious action on the operating system which could alert an antivirus software.
Ways of mitigation:
- Do not use a local administrator account if you do not have to. Restricted users are not able to execute and elevate such programs.
- Set the UAC level to “Always notify”, which leads to a prompt that needs to be accepted by the user.
Comments
Post a Comment