Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86371305

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Windows: Desktop Bridge Virtual Registry NtLoadKey Arbitrary File Read/Write EoP
Platform: Windows 1703 (version 1709 seems to have fixed this bug)
Class: Elevation of Privilege

Summary: The handling of the virtual registry NtLoadKey callback reloads registry hives insecurely leading to arbitrary file creation resulting in EoP.

Description:

NOTE: This bug seems to have been fixed in 1709, but the fix hasn’t been backported to 1703 (I’ve not checked 1607). I don’t know if the fix was intentional or not, however as (according to https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet) 1703 should be supported until at least September 2018 this should be something you’d consider fixing.

The desktop bridge functionality introduced in Anniversary edition allows an application to set up a virtual registry to add changes to system hives and user hives without actually modifying the real hives. This is implemented through the normal registry callback functionality. One of the callbacks implemented is to handle the NtLoadKey system call (VrpPreLoadKey). On 1703 it doesn’t check for the Application Key flag, but then recalls ZwLoadKey with the arguments passed by the user mode caller. This effectively allows you to circumvent the requirement for SeRestorePrivilege as will also create a new hive file with kernel privileges in the context of the current user. This is a trivial EoP by dropping a arbitrary file to disk then getting system privileges.

Proof of Concept:

I’ve provided a PoC as a C# project. In order for the exploit to work you need a copy of the Get Office/My Office application installed (I tested with version 17.8830.7600.0). It could be any desktop bridge application however as you just need to run a program inside the container. Again I’ll note that this will only work on 1703 as the code seems to have been fixed in 1709. The registry hives files it creates will be locked (we can’t easily unload the hive) until reboot although it’s probably possible to trick the system into failing the load while still creating some files.

1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
2) Start the Get Office/My Office application
3) Start the poc. It should print that it successfully created the registry files.

Expected Result:
Loading the registry key should fail.

Observed Result:
The registry key is loaded and the file test.hiv has been created in the windows folder with full access for the current user.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44315.zip