0day.today - Biggest Exploit Database in the World.
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn
GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Contact us
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Microsoft Windows - Desktop Bridge Virtual Registry NtLoadKey Arbitrary File Read/Write Privilege Es
Author
Risk
[Security Risk High
]0day-ID
Category
Date add
CVE
Platform
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://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44315.zip # 0day.today [2024-11-14] #