playboisk8/poc-cve-2017-8464-opencalculatorExploiting the .lnk vulnerability and operating system handling mechanisms regarding explorer.exe and USB drives.
Create 1 Shortcut + 1 .DLL containing malicious payload => Put it on a USB and send to victim => victim opens USB => Payload automatically triggers !
First, we need to know exactly where this bug comes from! It's because of a feature called Plug-and-Play — the OS automatically detects devices, allocates resources, and loads the appropriate driver so they work immediately without rebooting. When you plug in a USB and open the folder with Windows Explorer explorer.exe, the OS scans through the files to display the corresponding icon for the user!
From old Windows versions, Microsoft wanted shortcuts (.lnk) pointing to Control Panel items (essentially .cpl or .dll files) to be able to display dynamic icons flexibly. Therefore, Windows' core UI management library, shell32.dll, was designed with a function called
Using LoadLibrary blindly: To get the icon from a Control Panel Applet structure file, the OS doesn't just read a static image file; it uses the LoadLibraryW function to load that entire dynamic-link library directly into the memory space of the explorer.exe process. After loading, it calls a standard exported function, CPlApplet, to get and draw the icon on screen.
To prove that LoadLibraryW is really involved in the above exploitation chain:
1/ Enable
x64dbg với quyền admin2/ Attach to
explorer.exe3/ Type the command
bp LoadLibraryW4/ Press F9 to let
explorer.execontinue run5/ Plug in a USB and it will immediately
hit breakpoint!
I ran into an issue where the exploit chain was completely silent. I tried to check and debug everything but couldn't find a way to fix it! Then I tried to find someone else's PoC and run it, but it also failed!
However, when I went away for lunch and came back, I regained my focus and calm. I started asking myself: why did that guy's PoC work but not on my machine? Okay, I started lightly reverse-engineering his .lnk and .dll and found two things!
1 / My .dll is longer than his! But that's fine, it's not the issue!
2 / When I threw the .lnk into HxD to read strings, I discovered that this guy didn't use a relative path but an absolute one!
Relative: ../example.dll
Absolute: O:/example.dll
Okay now the fix would be: we need to know what drive letter the USB will be auto-assigned when plugged into the victim's machine, then we set the absolute path accordingly and it will work. On my Win7, plugging in a USB always mounts it as drive F, so my build syntax is:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Because this is a flaw in system architecture design (Logic/Architecture Flaw) rather than a memory overflow bug, Microsoft had to completely change the way Control Panel is handled:
.cpl or .dll files loaded by system processes to have a valid Microsoft digital signature or reside in strictly protected system directories (such as System32) to avoid "Binary Planting" from USB.explorer.exe [cite: 1058], newer Windows versions run Control Panel applets through an isolated intermediary process (such as dllhost.exe or rundll32.exe). If the DLL crashes or contains malware, it only takes down that intermediary process and cannot control the entire UI system.Research VN
PoC
Tool build vul .lnk