今天分享的论文主题为Windows代码签名PKI的信任破坏，该工作由美国马里兰大学的研究人员完成。作者指出，当前代码签名PKI体系存在多种安全缺陷，攻击者可以利用安全缺陷破坏代码签名的信任机制，为恶意软件配置“合法的”签名，从而绕过操作系统、浏览器及杀毒软件的安全检测。论文收集了真实的恶意软件，构建代码签名数据集，对Windows代码签名PKI的滥用行为首次展开了系统性的测量分析。论文发表于网络安全顶级学术会议CCS 2017（录取率：18.1%）。
01【背景介绍】
终端操作系统及用户在安装及运行第三方软件时，需要判断其是否来自可信的开发者。该过程依赖于代码签名公钥基础设施 (PKI）。其中，证书颁发机构(CA)负责向可信的软件开发者颁发代码签名证书，开发者使用证书对其发布的软件进行签名，用户则通过验证软件文件中的代码签名决定其是否可信。目前，各操作系统尚未形成统一的代码签名规范。其中，Windows的代码签名标准为Microsoft Authenticode[1]。该标准基于公钥加密标准(PKCS) #7，用于对Windows平台可移植的可执行文件(Portable Executable，PE)进行数字签名，具体包括可执行文件(.exe)、动态加载库(.dll)、目录文件(.cat)、安装程序(.msi)等。此外，代码签名PKI还引入了时间戳机构(TSA)来验证软件的有效期限。
理论上，恶意软件开发者无法从CA处获取代码签名证书并生成合法的代码签名。然而，已有安全事件表明，攻击者可能通过窃取证书私钥、冒充合法公司获取证书等方式，为恶意软件配置代码签名，从而绕过安装或启动程序的系统保护机制及杀毒软件的安全检查，对终端主机形成严重安全威胁。例如，Stuxnet蠕虫窃取了两家台湾半导体公司的证书私钥，对其设备驱动程序进行数字签名[2]；Flame恶意软件通过对MD5散列值的选择前缀碰撞攻击伪装成来自Windows 系统更新文件[3]。
尽管已经发生多起恶意程序滥用代码签名PKI的安全事件，此前学术界还未有针对代码签名PKI滥用的方法、有效性和实际安全隐患的系统研究。本篇论文对Windows代码签名PKI的信任破坏安全威胁展开分析，基于大规模杀毒软件报告数据集，提出了启发式方法，区分不同类型的代码签名PKI滥用行为，对代码签名PKI存在的脆弱性进行系统讨论。
02【数据收集】
为分析现实网络中恶意软件样本代码签名安全隐患，作者收集了多个来源的研究数据集，包括：
1. 全球情报网络环境(WINE)
WINE来自赛门铁克安全公司，是从全球(1090 万)真实用户终端采集的安全事件数据集[4]。作者主要关注WINE的两类数据：1）杀毒软件(anti-virus，AV)采集的恶意软件代码签名信息，包括二机制文件的SHA256以及分配给二进制文件的防病毒签名(anti-virus signatures)，去重后的数据规模约为7千万；2）软件信誉数据，为用户终端主机的下载事件日志，包括二进制文件的SHA256、事件的服务器端时间戳、发布者和CA的名称，去重后的数据规模为5.8亿。
2. VirusTotal
VirusTotal提供了一个API，可使用多达63种不同的杀毒 (AV) 产品扫描文件，并可查询已有的扫描报告。作者利用该API获取了文件首次提交至VirusTotal的时间戳、将该文件检测为恶意的AV数量、检测结果和文件代码签名信息。
3. OpenCorporates
OpenCorporates维护了全球最大的开放式企业数据库，提供超过1亿家公司的信息。作者使用此数据库来确定用于恶意软件代码签名的证书持有者是否来自合法公司。
4. HerdProtect
此外，作者还利用HerdProtect数据集查询公司作为软件发行商的信誉信息，包括其是否已被发现发布隐匿垃圾程序(potentially unwanted program，PUP) 、公司基本信息（位置、业务类型等）及其持有的证书样例。
03【研究方法】
论文认为，代码签名证书的攻击者主要有两个目标：(1) 在终端用户机器上分发和安装恶意软件；(2) 隐瞒身份。为了实现这些目标，攻击者利用代码签名PKI的安全缺陷绕过各种防御措施。安全缺陷主要包括：客户端验证缺陷、发布者密钥管理不善和 CA 端验证缺陷。为了探究Windows代码签名PKI的信任破坏情况，作者收集了恶意软件样本签名的Authenticode证书信息，并对三种安全缺陷滥用案例进行分类，具体方法介绍如下。
1. 数据分析
论文的数据处理主要包括四个步骤：种子收集、数据过滤、输入数据准备和识别潜在的滥用证书，如下图所示：
图表 1：数据分析流水线
1）种子收集：作者首先根据软件哈希值对WINE中来自杀毒软件报告的数据进行了去重处理，筛选出其中带有代码签名的软件，形成了一个可能为恶意的、带有代码签名的候选软件种子数据集。
2）数据过滤：针对种子数据中可能包含的隐匿垃圾程序(PUP)和正常程序，作者根据已有工作识别的PUP列表、HerdProtect数据集以及人工抽样检测对其进行了过滤。
3）输入数据准备：作者对过滤后的软件哈希值，利用VirusTotal API进行查询，获取与其相关的代码签名证书及杀毒引擎检测结果；此外，作者还将WINE中与已知的恶意软件共享相同代码签名证书的软件筛选出来，并利用VirusTotal识别出其中的正常软件。该部分数据将用于后续代码签名证书PKI滥用类型的识别。
4）识别潜在的滥用证书：对于用于签署恶意软件的代码签名证书，使用滥用检测算法来推断其滥用类型。
2. 滥用检测算法
如前所述，作者认为攻击者可滥用的代码签名PKI缺陷主要包括3种：客户端验证缺陷、发布者密钥管理不善和 CA 端验证缺陷。为判断论文收集到的恶意软件具体滥用了哪种安全缺陷，作者设计了如图表2所示的检测算法，具体介绍如下：
图表 2：滥用检测算法流程图
1）Malformed Certificate，即滥用“客户端验证缺陷”。在数据分析的第三步“输入数据准备”中，VirusTotal提供了代码签名的验证结果。如果签名格式错误或与程序哈希值不匹配，则该恶意软件的签名很可能是直接从其他已签名的二进制文件中复制而来。也就是说，虽然不持有合法的代码签名证书，为使恶意软件“看起来”拥有合法签名，攻击者可能会伪造（非法的）签名。而由于某些客户端对于代码签名的验证并不严格，这种方式也能一定程度绕过安全机制。
2）Stolen Certificate，即滥用“发布者密钥管理不善”。若恶意软件的签名是合法的，而且提供签名的证书同时也还签发了正常软件，则该证书很可能来自正常发布者，只是由于密钥管理不善，被攻击者盗用签发了恶意软件。
3）Faudulent or Shell company，即滥用“CA验证缺陷”。若恶意软件的签名是合法的，且相应的代码签名证书仅用于签发恶意软件，则很有可能是攻击者通过身份盗用或建立“空壳”公司骗取了CA的信任、获得了合法的代码签名证书。
04【主要发现】
1. 规模及有效性。本文最终在153,853个签名样本中检测出325个恶意软件，其中58.2%的恶意软件拥有合法签名，其余41.8%使用错误的签名。在189个持有合法签名的恶意软件中，22.8%的代码签名证书已被撤销，19.6%的代码签名证书已过期且没有有效的时间戳，但值得注意的是，超过一半的恶意软件(57.7%)代码签名在该论文撰写的时刻仍然有效。
图表 3：证书状态统计
2. 客户端代码签名验证缺陷。有101个恶意代码的签名与authentihash不匹配，很可能是攻击者直接将其他程序的数字签名复制过来、进行签名伪造。然而作者发现，Windows操作系统对伪造签名的检测非常不严格，而浏览器的防御机制也可以被绕过。更令人惊讶的是，这种伪造签名甚至可以轻易地绕过多款杀毒产品的恶意软件检测。
3. 合法签名恶意软件特征。持有合法签名的189个证书签名样本来自111张代码签名证书。作者通过AVClass确定了样本所属的恶意软件族，共识别出116个软件族。平均而言，滥用证书会对1.5个恶意软件族的样本进行签名。其中，大部分证书(79.3%)的持有者来自中国、韩国、美国、巴西和英国。尽管数据集中所有滥用证书目前均已过期，由于软件签名的有效性由其是否在证书有效期内获得可信时间戳决定，使用未撤销的84张证书进行签名的可执行文件仍然有效。在189个持有合法签名的恶意软件中，66.8%的软件通过TSA副属签名时间戳，其中Versign是大多数样本的首选TSA(34.2%)。
4. 滥用证书生命周期。为了确定滥用证书的威胁持续时间，作者对其进行了生存时间方面的分析，评估被滥用证书在给定天数后“存活”（即未被撤销）的概率。如图表4所示，在长达15年的时间内，只有20%的用于签署恶意软件的证书可能会被吊销。因此，代码签名证书的安全威胁将持续较长时间。
图表 4：威胁有效性的估计
05【结论】
本文首次对代码签名PKI的安全缺陷进行了系统分析，共总结出三类安全问题：客户端验证缺陷、发布者密钥管理不善和CA端验证缺陷。作者收集了现实网络中带有代码签名的恶意软件数据集，并通过设计检测算法，识别恶意软件对应的具体安全缺陷滥用方式，并对恶意代码签名的有效性、家族特征等进行了测量分析。
原文链接
https://doi.org/10.1145/3133956.3133958
参考文献
[1]Windows Authenticode Portable Executable Signature Format. https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx
[2]Nicholas Falliere, Liam O’Murchu, and Eric Chien. 2011. W32.Stuxnet Dossier. Symantec Whitepaper. (February 2011). http://www.symantec.com/content/en/ us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf
[3]Swiat. 2012. Flame malware collision attack explained. (Jun 2012). https://blogs.technet.microsoft.com/srd/2012/06/06/ flame- malware- collision- attack- explained/
[4]Tudor Dumitras and Darren Shou. 2011. Toward a Standard Benchmark for Computer Security Research: The Worldwide Intelligence Network Environment (WINE). In EuroSys BADGERS Workshop. Salzburg, Austria.
赵汉卿,编辑&审校|张一铭、刘保君
声明：本文来自NISL实验室，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
