CVE-2022-44666: Microsoft Windows Contacts (VCF/Contact/LDAP) syslink control href attribute escape vulnerability

CVE-2022-44666 (still 0day) is a Microsoft Windows Contacts (wab.exe) vulnerability while parsing "href" attributes into syslink controls, which was originally discovered, reported through ZDI and publicly disclosed by John Page (aka hyp3rlinx) of ApparitionSec long time ago (~ 5 years). Full credits for discovery go to him!

Last summer I started to study this vulnerability, either finding out further vectors to exploit this by using URL protocol handlers such as search-ms and LDAP, or file types accepted for the latest Windows versions (VCF vs Contact files). Thanks to URL protocols, there are more applications which might trigger the vulnerability (Microsoft Office + remote templates aka linked htmlfile OLE objects, web browsers and even PDF Readers).

My best contribution was using LDAP URL protocol which makes the impact a bit higher given that the crafted contact file will be opened without further user interaction for Microsoft Word.

On December 2022, Microsoft decided to release a patch for this vulnerability but unfortunately the fix stays incomplete and was easy to find a variant out by using a single char "@" before the target payload. So this vulnerability still remains as 0day nowadays.

There are some caveats for this vulnerability:

✅ Windows Contacts application (wab.exe) does not verify MoTW flag.

✅ It's triggerable by URI protocol LDAP.

✅ This file type (.contact) associated by default to Windows Contacts application (wab.exe).

✅ Downloads of these file types (.contact & .vcf) aren't blocked by browsers, mail servers and so on.

❌ Syslink control click is necessary to trigger the vulnerability (1-click).

❌ The payloads have to already be somehow on the target system, this might imply security warnings, MoTW prompts... What about diagcab files? There are some cons but higher impact occasionally.

❌ Network share paths as "href" attribute are blocked by default.

❌ Full paths as "href" attribute are blocked by default.

Long time ago, 0patch released a micropatch for this issue which has been successfully working with some minor fixes (offsets) in order to cover all the Windows versions, something that, some weeks ago, has already been deployed. It's the only unofficial fix which actually is full patching the vulnerability right now, waiting for an official patch that hopefully comes soon.

My full write-up can be found in this GitHub repository and John's post in his website.

#CVE-2022-44666 #0day

My thoughts and more on this bug!