Vulnerability Analysis of Windows Contact File
Security researcher ‘xxByte’ published one vulnerability POC of Windows contact file (file extension is .contact) in Twitter .
‘hyp3rlinx’ also disclosed this vulnerability last year .
We dived into technical details of this POC and reproduced exploitation steps.
Windows Contact File
Windows Contacts  is a contact manager that is included in Windows Vista, Windows 7, Windows 8, and Windows 10. It replaced but retains most of the functionality of Windows Address Book and worked with Windows Live Mail and the Vista version of Windows Mail.
Windows Contacts uses an XML-based schema format. Each contact appears as an individual .contact file, in which custom information including pictures can be stored. Window Contacts features extensibility APIs for integration with other applications and for storing custom information. The legacy *.wab format and the open standards *.vcf (vCard) and *.csv (CSV) are also supported.
.contact file is located in ‘Contact’ folder of current login user.
The content of .contact file is organized in XML format.
We follow POC’s instruction to change email field to ‘email@example.com’.
We change the email address to another one, like firstname.lastname@example.org
The Summary page shows our new email address. If we click the ‘mailto’ link, calc.exe is activated successfully.
In our reproduction, vulnerability logic doesn’t work for Microsoft.com email address.
Exploit VCF File
‘hyp3rlinx’ also disclosed one VCF vulnerability which was not recognized by Microsoft. However, ZDI issued one vulnerability index to it.
We also reproduced VCF exploitation as follows.
First, we create a new Outlook email and insert Business Card.
We select ‘Recommended Contact’ since card list is empty for first use.
Two contacts are listed in ‘Recommended Contact’.
We choose one and insert it as email attachment.
We copy the vcf file to Desktop.
The content of vcf file is almost same as .contact file. However, the content is read-only in UI mode.
We change the email address via editor.
Calc.exe is run when we click the ‘mailto’ link.
In windbg, we can see that wab.exe loads .contact file and .vcf file.
Wab32.dll is responsible for processing contact files, specifically, fnSummaryProc processes the mailto link in click action.
There are several switch branches, but our mailto link is dispatched to 0xfffffffe branch which is taken over by SafeExecute function.
Our POC injection command (calc.exe) is passed to SafeExecute as one of parameters.
Apparently, URL is not checked properly in SafeExecute function.
URL (calc.exe in here) is passed to UrlCanonicalizeW. pszCanonicalized is returned after execution.
UrlCanonicalizeW doesn’t check URL string properly.
If absolute file path is passed to UrlCanonicalizeW, that path won’t trigger vulnerability because of verification logic is applied to the path.
ShellExecuteExW processes URL parameter.
VCF file is processed as .contact file.
We did some experiments to test if the vulnerability can be triggered in common payload delivery approaches, like Email attachment and SMB sharing folder.
We send out an email with vulnerable VCF file as attachment as follows.
If the VCF is not saved into local disk, the full mailto link is shown in preview mode of Outlook. Unfortunately, the calc.exe can not be executed after the link is clicked.
.contact file works better than .vcf file. Our calc.exe in mailto link in .contact file can be executed if we click the link in email attachment.
However, if we use PowerShell command, like ‘ipconfig /all’, as POC command instead of calc.exe, the PowerShell command can not be run successfully. Possible reason is that, shellexecutexw function doesn’t pass any parameters which are PowerShell commands here.
We also try to execute remote file since Shellexecutexw supports HTTP protocol. Unfortunately, this approach didn’t work neither in IE8 nor in Chrome.
hyp3rlinx mentioned the idea of implementing exploitation by CPL file. We also tested this idea as follow.
Create ‘http’ directory in the directory where VCF file locates
One testing DLL file is put into the directory, and then it is renamed to ‘test.cpl’
Click the http link
Our test shows that idea is working successfully.
We also consider the approach of pack vulnerable .vcf and .contact file into a compressed file, which is a quite common delivery method of APT attack.
However, this approach doesn’t work if we want to run the contact file directly in compressed file without decompression operation. The reason is that contact files are placed into a temporary directory with a random path first, but we cannot predict the directory path and write it into contact file.
SMB Sharing Folder
Someone raised the idea of leveraging SMB sharing folder in Twitter. But this idea didn’t work in our test since UrlCanonicalizeW cannot process the SMB path correctly, like \\WIN-EOBT1L0G3TQ\share\1.exe.
This vulnerability exists in both .contact file and .vcf file. Due to natural limitation, such vulnerability cannot be implemented in real attack easily.