称心常识网vcf通讯录编辑器
背景 1月28日，Twitter上一名为xxByte的安全研究人员公布了一个代码执行POC[1]，通过构建Windows联系人文件（.contact文件）并内嵌HTML执行代码，相关推文如下图所示。
而该漏洞实际最早由hyp3rlinx披露[2]。
攻击复现 360威胁情报中心随后对公开的POC细节进行进一步分析，并尝试复现其攻击利用过程。
Windows联系人文件 Windows联系人[3]是WindowsVista，Windows 7，Windows 8和Windows 10中包含的联系人管理器。它取代了但保留了Windows通讯录的大部分功能，并与Windows Live Mail和Vista版本的Windows Mail一起使用。
WindowsContacts使用基于XML的架构格式。每个联系人都显示为单独的.contact文件，其中可以存储包括图片在内的自定义信息。Window Contacts具有可扩展性 API，可与其他应用程序集成并存储自定义信息。其还支持传统* .wab格式和开放标准* .vcf（vCard）和* .csv（CSV）。
.contact文件在上述版本的windows系统中都存在，如当前登录用户的.contact文件就位于对应用户的联系人目录下。
双击.contact文件后如下，其实际内容为XML格式文件。
按公开的POC中在其中“姓名及电子邮件”标签下将电子邮件修改为<a href=”calc.exe”>pwn@microsoft.com</a>，再双击打开如下所示。
对此，当将电子邮件修改为其他邮箱，这里如<a href=”calc.exe”>pwn@sina.com</a>时。
修改后双击打开如下所示，在“摘要”中电子邮件部分显示了设置的邮件地址，并且其邮箱地址识别为链接，当点击邮箱地址后，计算器执行并弹出。
这里我们注意到原推文中的POC使用microsoft.com邮箱并未显示如上所示的效果，推测可能是微软实现逻辑的问题。
虽然这里POC展示的只是执行了计算器，但除了邮箱标签之外，web站点标签也是可以触发的。
VCF文件利用 而hyp3rlinx在两周前还披露了一个利用VCF文件的代码执行漏洞，与上述利用.contact文件漏洞一致，但是该漏洞报给微软后，微软同样不认为这是一处漏洞，但是ZDI却给了漏洞编号。
由于在Windows系统中默认并不存在.vcf文件，这里展示如何构造利用漏洞的VCF文件过程。
在Outlook下，新建一封邮件，在主题中插入选择名片。
如果是第一次使用，名片列表实际上是空的，选择联系人，建议联系人。
这里可以看到两个推荐的联系人。
选择之后，附件上就自动附加上了一个vcf文件，右键复制。
粘贴保存到桌面
点击之后打开，可以看到和之前的.contact文件几乎一样，但是这里需要注意的是这种方式保存的vcf文件在UI界面下是不可编辑的。
直接通过编辑器将邮箱地址修改为之前的POC。
可以看到效果和.contact利用方式一致，点击后弹出计算器。
原理分析 通过Windbg可以看到.contact文件实际上是通过wab.exe起起来的，传入对应的.contact文件路径参数。
同理可以看到.vcf也是通过该wab.exe启动的，这两种启动执行逻辑基本一致，这里以.contact文件打开流程为例。
具体的调用如下所示，wab.exe直接加载wab32.dll对文件进行处理，主要的功能在wab32.dll中，最终在fnSummaryProc中响应用户的点击动作。
可以看到传入的switch分支条件为0xfffffffe，进入到对应的default分支中，该分支调用函数SafeExecute。
SafeExecute的第三个参数即为我们构造POC中的注入命令（此处为calc.exe）。
SafeExecute如下所示，从代码来看这个函数是用于执行URL，但是其中似乎并没有对传入的URL进行校验。
其中UrlCanonicalizeW传入的第一个参数为插入的URL命令（这里为calc.exe），并返回第二个参数pszCanonicalized。
UrlCanonicalizeW内部似乎未对URL命令字符串进行校验。
但是需要注意的是传入绝对文件路径的话UrlCanonicalizeW是会检测的，如下所示此时绝对路径返回之后将导致路径前附加上file:,从而在之后的UrlIsW函数中返回不同的结果，进入另外的分支流程，在错误的分支流程中会判断对应的参数是否是目录，如果不是目录则不会执行（即参数的构造上不能依赖于绝对路径），但是这里需要说明的是虽然绝对路径无法使用但是子目录及目录遍历的方式是可以使用的，如..\virus\2.exe，virus\2.exe都是没有问题的。
而正常传入calc.exe时，从下图可以看到UrlCanonicalizeW调用返回的pszCanonicalized参数直接被设置为calc.exe。
之后通过ShellExecuteExW执行URL中的内容。
Vcf类型的执行流程一致。
利用尝试鱼叉邮件 结合这个漏洞的效果，我们首先想到了通过鱼叉邮件的方式进行利用，如下所示投递一个vcf文件
如果利用鱼叉邮件投递构造的恶意的VCF文件，可以看到VCF文件在不下载的情况下，点击之后如下所示，其对应的POC信息直接暴露了，且在outlook中无论如何点击都无法触发执行计算器。
若利用鱼叉邮件投递构造的.contact文件，可以看到直接点击附件中的contact文件，确认后直接打开，此时点击对应的邮箱，代码执行，且全程POC代码没有暴露，因此contact的利用似乎要比vcf效果要更为理想。
但是事实并非如此，由于此处代码执行由shellexecutexw导致，shellexecutexw本身的问题在于调用系统中的exe时，并不能传入任何参数，如下所示为ipconfig /all时直接报错。
如下所示可以看到shellexecutexw中参数和执行路径是分离的。
从调试器也可以看到实际上href中的值，包括参数是可以完整传入的。
但是这样的带参数的字符却并不复合shellexecutexw的参数要求，因此会报错。
由于shellexecutexw本身也支持http等协议，因此我们想到是否可以远程加载恶意文件，但是这条路也是不可行的，支持http协议并不意味着可以直接代码执行，如下所示：
Ie8下。
Chrome下
由上所诉可知，虽然我们可以调用系统中的任意程序，但是却无法向程序传递对应的参数，这就导致包括powershell在内的很多攻击方式无法奏效，如果无法传参，我们就需要考虑在目标系统上直接部署恶意代码的问题，但是这一问题却不是那么容易处理的，毕竟通过单一的鱼叉邮件很难在用户不感知的情况下进行部署。
Cpl利用方式Cpl的利用方式来自于hyp3rlinx文章，CPL文件解释如下：
即通过加载.cpl文件的方式运行恶意代码，如下图所示
vcf文件中网站域被设置为http.\test.cpl，注意http之后的冒号去掉也是可以的（UrlCanonicalizeW对于该类型的参数并不会检测）
在vcf文件当前目录创建http目录(目录名可换)
在http目录下放置编译好的恶意测试dll，dll被修改为test.cpl1
点击恶意测试dll加载运行
但是该方式同样面临之前提到的问题，cpl文件如何部署？
鱼叉邮件+压缩包这里很自然的想到相关的部署方式是通过鱼叉邮件+压缩包的方式进行投递。
但是这样的方式也是不可行的，在理想情况下受害者直接点开附件压缩包，点击联系人文件，点击对应邮箱之后漏洞无法触发，主要原因是不同于压缩包中附加exe的方式，exe在压缩包点击之后，对应压缩包文件会被解到tmp目录下，而联系人文件点击之后压缩包并不会默认解压，从而导致联系人文件中的exp无法找到对应的http目录下的载荷（当然用户直接下载，解压再运行联系人文件也是可行的，但是交互要求过高）。
Smb共享该方式是twitter上的人提出的，但是该方式同样有问题，一般的文件共享如下所示
\WIN-EOBT1L0G3TQshare1.exe.但是该路径会被函数UrlCanonicalizeW处理，因此也无法成功，同时该攻击方式是基于获取到内网一台主机权限之后的钓鱼，实在是比较鸡肋。
总结 此报告中分析的漏洞是通过构造带有恶意代码的联系人文件（.contact或.vcf），而联系人功能是作为人与人间的社交关系和通信录使用的。
结合对漏洞利用过程的复现效果，从目前来看该漏洞的利用要求过高，主要体现在以下两方面：
启用指定程序时无法传入参数，这导致类似powershell一系列的攻击方式无法使用
在无法指定参数的情况下，类鱼叉攻击中无法通过低交互的方式部署相关的恶意软件
基于以上两点也能看出为什么微软没有对这系列的问题给出指定的cve。
参考链接1. https://twitter.com/xxByte/status/1089214985438457865
2.http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-VCF-FILE-INSUFFICIENT-WARNING-REMOTE-CODE-EXECUTION.txt、
3.http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-CONTACT-FILE-HTML-INJECTION-MAILTO-LINK-ARBITRARY-CODE-EXECUTION.txt
4. https://en.wikipedia.org/wiki/Windows_Contacts
5.https://blog.csdn.net/yangyang031213/article/details/64121915
