安全研究员Simone Margaritelli披露了Unix通用打印系统CUPS存在一系列安全漏洞，利用多个漏洞组合可在受影响的系统上执行远程命令。启明星辰ADLab研究人员对该漏洞的原理进行深入分析，同时提出修复建议和缓解措施。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

一、漏洞描述

2024年9月，安全研究员Simone Margaritelli披露了Unix通用打印系统CUPS(Common UNIX Printing System)存在一系列安全漏洞，利用多个漏洞组合可在受影响的系统上执行远程命令。启明星辰ADLab研究人员对该漏洞的原理进行深入分析，同时提出修复建议和缓解措施。

二、相关介绍

CUPS是一个开源的打印系统，用于Linux和其他类UNIX操作系统。CUPS 提供 Web界面和Berkeley命令行界面等多种方式来管理打印机和打印任务。例如访问http://localhost:631可管理打印机。

CUPS主要使用Internet Printing Protocol(IPP)来实现本地和网络打印机的打印功能。IPP是一个在互联网上打印的标准网络协议，它容许用户可以通过互联网作远距离打印及管理打印工作等。IPP采用的超文本传输协议HTTP的POST方法在客户端和打印服务器之间进行会话。

cups-browsed是一个开源的打印服务组件，它是Common UNIX Printing System(CUPS)的一部分。cups-browsed负责在本地网络上自动发现和添加打印机，使用mDNS（多播DNS）或DNS-SD（DNS服务发现）协议来侦测网络上的打印设备。它使得用户能够无需手动配置即可使用网络打印机。

三、原理分析

该漏洞源于cups-browsed服务，该服务绑定在UDP INADDR_ANY:631端口上，接受任何ip发送过来数据。同时该服务适配大多数UNIX系统，且大多数设备默认开启该服务。

该服务的功能是发现互联网上的打印机，然后将打印机添加到系统服务上，相关功能的实现代码在cups-browsed.c文件中。代码中创建一个名为BrowseSocket的套接字，然后绑定在631端口。

当检查到系统支持BrowseRemoteProtocols时，创建一个 UNIX 套接字通道，并设置监视该通道上的输入事件。一旦有数据可读，将调用process_browse_data函数来处理这些数据。

BrowseRemoteProtocols参数可通过/etc/cups/cups-browsed.conf文件进行配置，此处一般默认开启。

process_browse_data是关键的数据处理函数，该函数调用recvfrom从BrowseSocket套接字读取数据包packet。数据包格式遵从HEX_NUMBER HEX_NUMBER TEXT_DATA，使用该格式的数据的原因时是程序在处理packet时使用了下面的函数对数据进行处理。

sscanf (packet, "%x%x%1023s",&type, &state, uri)

接收到数据包后会调用allowed函数对ip进行合理性检查，该检查规则可通过/etc/cups/cups-browsed.conf文件进行配置。

allowed检查通过后会将数据包传入found_cups_printer函数进行进一步处理。

found_cups_printer函数中调用httpSeparateURI函数解析传入的uri参数并将其拆分为协议、用户名、主机名、端口、资源路径等部分。然后根据解析得到的各部分信息，对uri是否等于”/printers/”和”/calsses/”字符串进行检查。检查通过后调用examine_discovered_printer_record函数来处理发现的打印机记录。

处理完数据后调用cfGetPrinterAttributes函数进行回连，其中先使用httpConnect函数先建立http连接，然后调用ippNewRequest建立IPP连接，最后向IPP Server发送获取打印机属性的请求。

发送完请求后cups-browsed程序会调用ppdCreatePPDFromIPP2函数创建PPD文件然后将接收的打印机属性依次保存到文件里面。

至此，已经可以成功设置PPD的属性，接下来就是想办法执行写入的数据。这需要使用CUPS的一个过滤器指令cupsFilter2，该指令用于处理打印作业中的筛选和转换操作。

例如下面的指令要求cups将符合打印机属性的postscript格式的数据传递给program过滤器进行处理，优先级为0。

*cupsFilter2:"application/pdf application/vnd.cups-postscript 0 program

CUPS规定只能使用/usr/lib/cups/filter路径下面的可执行文件，最终以foomatic-rip过滤器作为利用的目标。该过滤器接受PPD文件中的FoomaticRIPCommandLine指令，通过它可以执行任意命令。

四、漏洞修复

截至目前，Ubuntu，Debian，Fedora等多个系统中涉及漏洞的多个版本已基本修复。

在Ubuntu最新版的修复方案中完全删除对旧版 CUPS 协议和 LDAP 的支持。

五、缓解措施

漏洞修复版本已经上传，Ubuntu系统中运行下面两条命令即可进行升级。

sudo apt update

sudo apt upgrade

如果上面的升级不成功，使用下面两种办法缓解该漏洞：

（1）直接禁用cups-browsed服务

sudo systemctl stop cups-browsed

sudo systemctl disable cups-browsed

（2）如果该功能需要使用，建议将/etc/cups/cups-browsed.conf中BrowseRemoteProtocols指令值从默认的“dnssd cups”更改为“none”。

参考链接：

[1]https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/

[2]https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1

[3]https://censys.com/common-unix-printing-service-vulnerabilities/

[4]https://blog.ostorlab.co/cups-vulnerabilities.html

[5]https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8

[6]https://ubuntu.com/security/notices/USN-7043-4

[7]https://ubuntu.com/security/notices/USN-7042-3

[8]https://launchpad.net/ubuntu/+source/cups-browsed/2.0.1-0ubuntu2.1

[9]https://www.upwind.io/feed/analyzing-the-latest-cups-rce-vulnerability-threats-and-mitigations

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

本文将对我们分析Android恶意软件过程中所遇到的常见混淆技术进行总结和分析，从恶意软件混淆与对抗的视角来阐述另一面的安全攻防技术，以帮助安全工程师和用户们更加深入理解这一领域的技术情况，同时也有助于分析人员更高效地分析恶意代码。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

第一章

概 述

近年来，Android恶意软件数量不断攀升，其采用的攻击和对抗技术也变得越来越复杂。为了对抗安全分析，绕过安全检测，窃取敏感数据或破坏系统安全，恶意软件利用各种对抗技术来伪装和隐藏其恶意行为和代码逻辑。这些对抗技术中，针对资源、文件、字节码指令及机器码指令的混淆技术被广泛地引入到恶意软件中，成为高级黑客与逆向工程师对抗的重要战场。

混淆技术的核心目标是增加分析复杂性来对抗逆向工程，同时也能提高免杀能力，主要对抗目标包含逆向工程师、静态分析工具、动态调试工具以及自动化检测系统。混淆技术通过设置分析陷阱、改变文件结构、增加指令复杂度、虚拟化指令、隐藏代码和资源等各种繁杂的技术来掩盖其行为特征和攻击意图，同时给分析人员尽可能大的制造分析障碍，延后其恶意行为暴露的时间。同时，恶意软件通过组合运用各种各样的混淆与分析对抗技术，对现有安全检测工具和防护机制形成了严峻挑战。这需要不断跟进各种技术的发展，对新的手段进行深入研究，制定有效且快速的应对方法，强化分析工具和检测工具，同时也有助于快速应对高级且复杂的恶意软件攻击。

本文将对我们分析Android恶意软件过程中所遇到的常见混淆技术进行总结和分析，从恶意软件混淆与对抗的视角来阐述另一面的安全攻防技术，以帮助安全工程师和用户们更加深入理解这一领域的技术情况，同时也有助于分析人员更高效地分析恶意代码。

第二章

Android恶意软件混淆技术的演进

随着移动安全领域对抗的不断升级，Android 恶意软件的混淆技术也经历了显著的发展，从简单的标识符混淆逐步演进到复杂的虚拟化保护（VMP）技术，呈现出由浅入深、逐步升级的趋势。为更清晰地理解这一变化，我们将混淆技术的发展大致划分为早期、中期和当前阶段，并从不同层面进行详细解析。

2.1 早期阶段：基础伪装与简单加密 

在早期，恶意软件的混淆技术主要以掩盖代码和资源内容为目标，手段较为简单直接，其混淆技术主要集中于Java层，利用Android应用以Java语言开发的特性，通过简单的混淆手段规避安全分析和检测。在这一时期，恶意软件开始探索文件格式相关的混淆策略。例如，通过修改ZIP格式的APK伪加密，以及2012年黑帽大会上首次提出的利用DEX头隐藏代码的技术，这一策略随后被Syrup恶意软件所采用。同时，木马Obad利用商业混淆工具DexGuard（ProGuard的增强版）实现了Manifest字段的复杂混淆以及基于clinit方法的动态代码解密，被誉为“史上最强Android木马”。

这一阶段，短信拦截类和锁机勒索类恶意软件广泛采用多种混淆手段，包括代码混淆、字符串加密、代码分割、垃圾代码注入，以及商业加固工具的使用。这些技术尽管相对基础，但在当时的安全环境中，已经显著提高了恶意软件的隐蔽性和抗检测能力。下图展示了一款短信拦截木马的混淆效果。

图1 一个短信拦截木马的混淆示例

2.2 中期阶段：逻辑复杂化与动态对抗 

随着安全检测技术的不断提升，恶意软件逐步引入更加复杂的混淆手段，以提高隐蔽性并有效规避分析。为规避静态分析，它们利用动态加载和反射机制，通过反射动态调用隐藏的关键代码。同时，恶意软件采用多重加密与解压策略，对关键代码进行多层次加密，并在运行时通过复杂的解密过程逐步释放真实的恶意逻辑。例如：在我们发布的分析报告《新型Android银行木马“MoqHao”利用社交网络隐藏C&C服务器》中，恶意软件将真正的恶意dex文件加密后，以Base64编码的形式保存在原始APK的assets目录下。在这种情况下，原始APK仅作为一个外壳存在，其在运行时会动态解密并加载真正的恶意dex文件，以实现其攻击目的，其过程如下图所示：

图2 Java层混淆dex文件的示例

为了扰乱分析路径，恶意软件引入控制流混淆技术。通过插入无关的分支、循环和跳转语句，恶意软件使代码执行路径更加复杂，阻碍分析人员还原其逻辑。而在结合商业加固解决方案后，通过内存加载、指令抽取和指令转换等技术，进一步提升了对抗分析的能力，使得分析人员难以准确还原其实际的执行逻辑。

随着反混淆技术的进步和现代化反编译工具的普及，恶意软件逐渐将混淆策略向Native层转移，以进一步提升逆向分析的难度。其常用技术包括对会话数据加密以防止敏感信息泄露、加密关键函数体以隐藏恶意行为、插入花指令干扰反汇编工具分析、利用LLVM框架实施复杂的代码混淆，以及通过反调试技术检测和阻止调试器介入。这些策略相辅相成，不仅显著增加了逆向工程的复杂性，也进一步提高了安全研究人员分析的技术门槛。例如：在我们发布的《一款通过SO进行自保护的银行APP劫持木马深度分析报告》中，详细分析了该木马的运行行为。具体而言，libload.so模块负责解密并加载实际的恶意代码。该模块利用Java反射机制调用javax.crypto包中的加解密函数，对存储在assets目录下的mycode.so文件进行AES解密。解密后的文件通过自定义的DexClassLoader加载并执行，执行完毕后，解密的文件会被删除。这些精心设计的混淆手段有效隐藏了恶意行为，显著增加了安全分析的复杂性，使得恶意软件的检测和分析变得更加困难。加载Native解密库的部分代码如下图所示：

图3 Natvie层混淆示例

此外，针对文件格式的混淆策略也变得更加多样和复杂。它们巧妙利用 Android系统对某些文件格式字段宽松校验的特性，同时借助反编译工具对文件格式的严格解析逻辑，设计了多种干扰和隐藏机制。通过对这些文件格式的灵活利用，恶意软件得以实现更高程度的隐蔽性，进一步提高了逆向分析和检测的难度，同时也为混淆技术的持续发展奠定了基础。

2.3 当前阶段：复杂混淆与多层对抗 

在当前阶段，恶意软件的混淆技术已经高度复杂化，广泛结合动态和静态对抗手段，以增强隐蔽性并对抗多种检测方法。通过将Java层代码混淆、动态加载与Native层加壳技术融合使用，恶意软件将核心逻辑分布于不同层次中，大幅提高了检测和分析的复杂性。以下是目前常见的混淆策略：

• Java层与Native层相结合：恶意软件通过将Java层的代码混淆、动态加载、VMP等技术与Native层的代码混淆手段相结合，将恶意逻辑分散在不同层次中。这种跨层混淆策略显著增加了检测和分析的复杂度，要求分析人员同时掌握多种技术，才能全面理解其运行机制。

• 使用其他开发语言：恶意软件常利用Lua、GoLang、Flutter、易语言等非传统的 C/C++ 语言进行开发，从而显著增加逆向分析的难度。这些语言独特的特性进一步提高了分析的复杂性，同时削弱了传统逆向分析工具的效率和效果。

• 运行环境检测及反调试：恶意软件通过检查设备的系统属性、文件系统结构、系统权限状态等，判断目标设备是否为模拟器或已获取Root权限，并在检测到这些特征时阻止恶意逻辑的运行。同时，它们调用系统API检查调试状态，监测调试工具特有的行为，甚至主动引发异常以捕获调试工具的反应，有效阻止动态分析工具的干扰。

• 商业加固保护技术：一些恶意软件使用商业加固保护技术，进一步加强了代码的抗逆向能力，使得传统的安全工具和分析方法难以奏效。

• 代码虚拟化技术：通过将代码翻译为自定义的虚拟指令集，并在运行时通过嵌入的虚拟机解释执行，这种技术极大地提高了逆向分析的难度。

例如，某恶意软件通过使用Native代码实现对Frida和IDA的检测，其代码如下：

图4 Natvie层检测调试器的代码示例

Android恶意软件的混淆技术已经从简单的代码混淆逐渐发展到如今复杂的跨层结合形式，其隐蔽性持续增强，技术手段也愈发多样化。这种发展趋势对传统安全检测工具而言是严峻的挑战，同时也促使研究人员必须不断创新应对策略，以此来应对恶意软件日益复杂的混淆手段。在此背景下，深入了解并解析常见的混淆技术，是提升恶意软件分析和检测能力的关键。接下来，我们将通过实际工作中常遇到的恶意软件混淆技术进行详细分析，探讨这些技术的应用方式及相应的防范对策。

第三章

常见混淆手段与技术解析

在分析Android恶意软件时，安全研究人员通常需要从静态分析和动态分析两方面入手。静态分析往往是最先进行的步骤，而混淆技术通过修改代码的结构和表达方式（如字符串加密、代码拆分、动态加载等），使恶意软件的分析难度显著增加。本文将以安全研究人员分析APK文件的过程为切入点，逐步介绍各种反混淆策略，帮助研究人员有效应对不同层次的混淆技术挑战。

3.1 APK反编译工具的对抗

在分析Android应用时，首先需要使用APK反编译工具（如Apktool、Jadx）提取APK文件中的源代码和资源。然而，恶意软件往往会通过多种混淆手段对APK进行保护，以干扰反编译过程。例如，恶意软件可能利用Android在解析APK文件时未严格校验ZIP格式的某些字段，从而通过篡改APK文件的ZIP格式字段来绕过基于ZIP格式解析的反编译工具。这种手段尤其常见于一些基于Android的银行木马（如BianLian、Cerberus和TeaBot）中，目的是阻止安全研究人员和自动化分析平台有效提取APK文件内容，进而对抗静态分析和反病毒检测。

为了更好地理解恶意软件的混淆策略，尤其是如何通过篡改ZIP格式字段来干扰反编译过程，有必要了解一些ZIP文件结构的基本信息。虽然ZIP格式的详细结构超出了本文的讨论范围，但我们可以简单介绍一些常见的、恶意软件经常篡改的字段。我们以 Python 的zipfile.py 模块中的 ZipInfo 类为例，展示了 ZIP文件元数据中的多个关键字段。具体字段及其含义如图所示：

图5 Zipinfo类的结构信息

其中，compress_type、extract_version、reserved和flag_bits都是恶意软件常常篡改的字段。这些修改可以导致反编译工具在解析文件时出现错误或无法正确读取文件内容，从而有效地阻碍静态分析过程。通过篡改这些字段，恶意软件不仅能够规避常见的反编译工具，还能增加被检测的难度，提高其在静态分析中的隐蔽性。

在了解了恶意软件如何通过篡改ZIP格式字段来对抗静态分析后，接下来我们需要关注Android应用中另一个常见的反编译手段——AndroidManifest.xml文件（以下简称“清单文件”）。清单文件是反编译过程中必须解析的关键部分，它包含了应用的核心配置，如组件、权限等信息。因此，提取、读取和分析清单文件是静态分析APK样本时的首要步骤。为了规避反编译工具的识别，恶意软件通常通过精心篡改清单文件来干扰其正常解析。由于清单文件在静态分析中的重要性和复杂性，它成为了恶意软件常用的反编译对抗手段之一。如果读者对清单文件的具体结构不太了解，可以自行访问以下链接（https://bbs.kanxue.com/thread-194206.html）查阅相关信息。

接下来，我们将介绍几种常见的清单文件混淆手段，探讨恶意软件是如何通过这些手段对抗反编译工具并隐藏其恶意行为的：

（1）修改XML文件的魔术：恶意软件通过篡改清单文件中的魔术字段，使得静态分析工具在解析时出现错误。这些修改通常不会影响应用的正常运行，但会导致分析工具无法正确解析清单文件的结构，甚至可能引发反编译工具的异常错误，从而阻止反编译过程，无法提取源代码。

图6 左图为正常的魔术，右图为混淆的魔术示例

（2）篡改关键字段：恶意软件可能会篡改清单文件中的关键字段，例如通过修改StringPool中字符串的个数。虽然Android系统在运行时并不依赖这个字段来计算字符串的个数，而是通过动态计算来处理字符串，但一些反编译工具却会依赖这个字段来解析XML文件中的内容。通过篡改这个字段，恶意软件可以干扰反编译工具的正常解析，导致工具读取到错误的字符串个数，从而无法正确解析清单文件的结构，进而影响静态分析的准确性和完整性。这种手段有效增加了静态分析工具的分析难度，提升了恶意软件的隐蔽性。

图7 篡改StringPoolSize的混淆示例

在上图中，我们可以看到，stringCount的值为2907，而StringOffsets开始于偏移位置36，大小为 11628。StringOffsets是一个包含每个字符串在字符串池中的相对偏移量的数组，其大小为 stringCount * 4，即 11628。反编译工具按照混淆后的stringCount值计算StringOffsets大小，并进行解析，因此解析结果出错。这种不一致性是导致反编译工具解析失败的原因。然而，Android系统在处理清单文件时并未直接依赖stringCount字段的值。通过查看 Android 源码可以发现，Android系统在运行时根据实际数据动态计算 stringPoolSize，而非直接使用文件中提供的数值。

图 8  Android系统源码中计算mStringPoolSize的代码示例

（3）插入脏数据：有些恶意软件会故意在清单中插入一些脏数据。这种数据不会被实际使用，但会破坏清单文件的格式，使得解析工具难以识别其中的有效信息。

图9 左图显示`startEle0`内容，右图展示`startEle0`和`startEle1`的偏移量及大小

上图展示了一个混淆后的清单文件。在左图中，第一个startElement的大小字段为196，但header中的size字段为224，意味着startElement后附加了28字节的未知数据。右图中，第二个startElement的起始位置为0x15A4，正好位于插入的这28字节垃圾数据之后（右图中绿色部分所示）。这些多余的28字节会导致反编译工具在后续解析时出错。Android系统能够正常解析，是因为系统计算每个startElement的位置时，仅依赖上一个startElement的起始位置和大小字段，从而自动跳过垃圾数据。

（4）插入超长字符串或特殊字符：为了干扰静态分析工具的正常解析，恶意软件可能会在特定字段中插入超长字符串、特殊符号、emoji表情或不可见字符。这些字符虽然不会影响应用的正常功能，但它们显著增加了分析工具的处理难度。如果反编译工具的容错能力较差，这些修改可能导致工具崩溃或无法正确解析清单文件，从而使静态分析变得更加困难。

图10 通过不可见字符实现超长应用名称（label）的示例

上图中，清单文件中的label字段从string.xml中的app_name字段读取，而app_name字段则包含了不可见字符（如\u0000）和超长字符串。通过这种方式，恶意软件可以有效干扰反编译工具的解析过程。如果自动化分析平台的容错机制不足，如数据库字段对app_name或version字段长度有限制，这些篡改可能导致异常，进而使恶意软件在自动化分析平台上“隐身”，难以被检测到。

在正常的清单文件中，Start Namespace Chunk通常存储命名空间信息，其中Prefix是一个4字节的索引，指向字符串池中相应的字符串，用于标识命名空间前缀；Uri也是一个索引，指向字符串池中表示命名空间URI的字符串。例如，在一个未经过混淆的清单文件中，我们可以看到Prefix的值对应的字符串为android，即它引用了标准的Android命名空间。

图11 正常的prefix前缀示例

然而，通过对恶意软件中发Prefix字段进行恶意篡改，攻击者可以导致反编译工具在解析时发生错误。这种混淆方式利用了反编译工具对Prefix的依赖，使得其在解析时发生异常，干扰分析人员对恶意软件的判断。下图是一个经过混淆的清单文件。

图12 混淆后的prefix示例

从图中可以看到，命名空间的Prefix显示为非标准字符串。Prefix的索引值指向字符串池中的位置67，而Uri显示正常。查看字符串池中索引67的内容，我们发现该字符串是一段长度为20470的乱码字符。如下图所示：

图13 索引值67处的prefix字符串的值示例

这种超长字符串会导致Apktool在反编译时崩溃。在Apktool的错误日志中，显示了“Array Size”异常信息。

图14 Apktool反编译时出现的异常错误示例

经过对崩溃问题的绕过处理后，生成的AndroidManifest.xml文件达到了16.7MB，且包含大量乱码，难以阅读。

图15 包含大量垃圾字符的AndroidManifest.xml文件示例

一个有效的处理方法是将Prefix的索引值指向字符串池中较短的字符串，以便生成的清单文件内容正常显示，便于后续分析和阅读。

此外，一些恶意软件会在清单中插入符号或表情符号，若反编译工具在解析时未正确处理这些特殊字符，也可能导致反编译工具崩溃。插入表情符号进行混淆的清单如下图所示：

图16 通过表情符号进行混淆的示例

除了通过篡改ZIP格式字段和混淆清单文件来对抗反编译工具外，恶意软件还常常采用一种强有力的策略——混淆resources.arsc文件。resources.arsc文件是Android应用中存储资源映射关系的核心文件，它维护了资源ID与实际资源文件之间的映射。恶意软件通过篡改这个文件，能够有效干扰反编译工具对资源的正确解析，甚至可能导致反编译工具崩溃或异常退出。例如，BOOMSLANG（树蚺）移动欺诈家族就利用这一策略对抗Apktool的反编译过程，下图是其反编译失败时Apktool提示的错误信息。

图17 混淆后的BOOMSLANG样本导致Apktool反编译失败

3.2 代码混淆与反混淆技术

一旦研究人员突破了APK包的初步混淆，接下来便会进入到代码层面的分析。在这一层面，恶意软件通常采用各种混淆技术，大幅地增加了静态和动态分析的难度。

3.2.1 标识符混淆

标识符重命名是代码混淆中最常见且最有效的技术之一，旨在通过将有意义的包名、类名、方法名和变量名替换为无意义的、随机生成的名称，从而干扰逆向工程师的分析过程。此外，标识符混淆还能有效避开一些自动化分析平台，这些平台通常依赖于标识符来制定检测规则。通过混淆标识符，恶意软件能够规避基于标识符的检测，减少被识别的风险。常见的标识符混淆策略包括使用随机字符组合（如数字、字母或特殊符号）、采用非英语语言的标识符（如中文、日语、韩语、俄文等）、使用超长字符标识符，或通过替换形状相似但含义不同的字符（如字母“O”与数字“0”、字母“I”与小写字母“l”等）来干扰分析。这些混淆策略使恶意软件能够有效隐藏其功能并增加逆向分析的难度，从而延缓被检测和识别的时间。为了应对这种混淆，安全研究人员可以使用带有反混淆功能的反编译工具，如Gda、Jeb、Jadx等，这些工具有助于快速恢复被混淆的代码并帮助识别恶意行为。标识符混淆示例如下图所示：

图18 标识符混淆示例

3.2.2 字符串加密

恶意软件通常采用编码或加密手段对代码中的敏感字符串进行处理，以防止恶意关键字（如恶意URL、命令或其他敏感数据）在反编译过程中被直接暴露。这些技术有效地阻止了分析人员从反编译结果中提取关键信息，尤其在对抗自动化分析平台的静态分析时，具有较强的防护效果。常见的字符串混淆方法包括字符拆分和编码混淆。字符拆分将敏感字符串分割成多个部分，程序在运行时再拼接成完整的字符串；而编码混淆则通过对字符串进行加密或使用编码技术（如Base64编码、简单加密算法等），在程序运行时再进行解码。这些手段不仅增加了静态分析的难度，也使得分析工具无法直接识别出恶意行为。这种技术使得静态分析工具无法直接看到关键数据。安全研究人员可以使用动态分析工具，如Frida，来捕捉运行时的解密过程，揭示恶意软件在运行时所做的操作。字符串加密示例如下图所示：

图19 字符串加密混淆示例

3.2.3 控制流混淆

控制流混淆技术通过插入无意义的控制结构（如多余的条件分支、循环或冗余代码），故意改变程序的执行路径，代码块重新排序等手段使得分析工具在尝试解析程序时，陷入过于复杂的代码结构中，导致无法准确地还原程序的真实逻辑。由于控制流混淆引入了大量不必要的执行路径，静态分析工具可能无法有效提取出程序的实际行为。

为了应对这种混淆，安全研究人员通常需要通过模拟执行以及动态分析技术来辅助手动追踪程序的执行流，逐步还原程序的真实逻辑。下图展示了一个简单的控制流混淆示例，展示了在混淆前后的控制流结构差异。

图20 控制流混淆前后的差异对比

3.2.4 反射机制与动态加载

动态加载机制是恶意软件常用的反静态分析技术，主要包括本地动态加载和远程动态加载两种方式。本地动态加载通过加载本地存储的动态库或dex文件，动态调用方法或类，使得恶意行为在静态分析阶段无法被发现。远程动态加载则通过在运行时从远程服务器下载动态库或dex文件来加载并执行恶意代码，这种方式进一步规避了静态分析工具的检测，因为恶意代码并未出现在apk文件中。恶意软件往往通过反射技术结合动态加载，利用运行时的反射调用机制隐藏恶意行为，使得初期静态分析无法识别这些恶意活动。为了应对这一挑战，安全研究人员通常依赖动态分析手段，如通过Frida注入脚本、使用调试工具动态跟踪或通过日志分析捕捉反射调用的过程，从而揭示恶意代码的真实行为。这些动态分析方法能够绕过静态分析的限制，识别通过反射和动态加载隐藏的恶意行为。

接下来，我们来看一个利用本地动态加载的恶意代码示例。下图展示了该恶意代码的目录结构。

图21 目录树信息

虽然从表面上看，该目录仅包含几个方法，但深入分析后发现，恶意代码通过attachBaseContext方法调用了一个名为b的方法，进一步实现了从assets目录加载加密的代码文件。该文件经过异或解密后，通过动态调用的方式被加载并执行，代码如下图所示：

图22 动态加载后通过反射调用代码示例

3.2.5 Native混淆

Native混淆技术是通过多种手段加大对恶意软件逆向分析的难度，常见的技术包括以下几种：

（1）JNI接口混淆：恶意软件通过JNI（Java Native Interface）将关键逻辑转移到.so文件中，并通过混淆的JNI接口调用本地代码。通过将原本清晰的本地方法名替换为无意义的符号或随机字符，恶意代码的功能和结构变得更加难以理解和追踪。

图23 JNI接口混淆示例

（2）Session加密：将关键方法存储在自定义的.section中，并对这些自定义的.section内容进行加密。由于.so文件在加载时会优先执行.init_array段，因此将解密逻辑嵌入到.init_array中。在运行时，通过解密方法获取内存中各个.section的起始地址和大小，对加密的.section进行解密还原，从而恢复关键方法的正常执行。

图24 Session加密的示例

（3）函数加密：解析.so文件，通过方法名定位目标方法后，对其进行加密。在加载.so文件时，通过指定方法的地址调用解密逻辑，将加密的方法动态解密还原，以实现对关键逻辑的保护。

图25 JNI加解函数经解密还原的部分代码示例

（4）字符串加密与动态解密：恶意软件通过加密关键字符串（如URL、命令、密钥等），并在运行时通过动态解密恢复其原始内容。加密的字符串通常存储在静态数据区域，而解密则通过特定算法或在内存中动态完成，从而使得静态分析工具无法直接提取恶意信息。

图26 Native解密字符串示例

（5）花指令与垃圾代码插入：通过在代码中插入伪指令或无效代码，恶意软件能够混淆程序的实际行为。这些花指令没有实际功能，但增加了逆向工程的复杂性。垃圾代码不仅增加了程序的体积，还使得追踪和理解恶意代码变得更加困难。

图27 一个简单的垃圾指令示例

（6）代码加壳与自修改代码：在Native层，恶意软件经常使用加壳技术来隐藏核心恶意代码。加壳后，恶意代码以加密或压缩形式存储，只有在运行时才会解密或解压。自修改代码技术则允许恶意软件在运行时动态生成、修改和执行代码，进一步阻止静态分析工具识别完整的恶意行为。

图28 通过Hook修改代码的示例

（7）反调试与模拟器检测：为了抵抗动态分析，恶意软件往往会在Native层嵌入反调试机制，例如通过检测调试器的存在（如gdb或Frida）来中断分析过程。此外，恶意软件也会进行模拟器检测，通过检查设备是否运行在模拟器或沙盒环境中来避免被动态分析工具捕捉。

图29 检测模拟器示例

（8）控制流混淆：控制流混淆通过改变程序的执行路径，使得分析人员难以理解程序的实际流程。常见的方法包括插入无效的控制流（如跳转、分支语句）、无用的循环和函数调用，扰乱分析工具追踪指令的顺序。

图30 一段控制流混淆代码示例

（9）LLVM混淆：LLVM是一种强大的编译器框架，恶意软件通过使用LLVM技术来对Native代码进行复杂的混淆处理。LLVM混淆能通过优化编译过程，生成难以阅读和理解的二进制文件，同时对文件大小影响较小。这种技术有效增加了逆向工程的复杂度。

图31 LLVM混淆前后对比示例

这些Native混淆技术通常被组合使用，构建多层次的保护机制，从而使传统的静态分析和动态分析方法面临巨大的挑战。借助这些技术，恶意软件能够有效隐藏其真实行为，规避安全研究人员的检测以及防护系统的拦截。此外，商业加固保护进一步提升了防护的全面性。恶意软件常利用商业加固产品对自身进行保护，甚至黑灰产软件也频繁采用此类技术进行防护，如下图所示：

图32 使用商用加固的诈骗应用

3.2.6 代码虚拟化

代码虚拟化是目前最先进的混淆手段之一，它通过将原始代码转换为自定义的虚拟机指令，极大地提高了代码复杂度和分析难度。与传统的控制流混淆不同，虚拟化技术将关键代码的执行逻辑封装在虚拟机中，使得核心功能和控制流几乎无法通过常规反编译手段还原。以下从DEX虚拟化和SO虚拟化两个维度进行分析：

DEX虚拟化技术主要针对Android应用中的Dalvik字节码。这种技术通过将DEX中的字节码转换成自定义的虚拟机指令，然后由Native层虚拟机解释执行，从而保护关键代码和核心逻辑。这种转换使得传统的反编译工具难以还原代码的原始逻辑，因为它们无法识别转换后的指令集。例如，某电商平台通过漏洞提权实施恶意行为，并为隐藏其核心代码逻辑，采用了一套基于JVM构建的虚拟机保护（VMP）技术对代码进行加固。下图展示了其保护后的二进制内容，可以明显看出，代码已被虚拟化为高度抽象的虚拟机指令，使得传统的反编译和静态分析方法几乎无效。

图33 解析经vmp保护的dex文件示例

SO虚拟化技术则关注于保护应用中的Native代码，即SO文件。这种技术可以通过隐藏符号表、资源加密等方式来保护SO文件中的功能不被轻易分析和篡改。例如，Virbox Protector提供了对SO文件的保护选项，包括隐藏符号表和对特定SO文件的加密保护。通过这种方式，即使攻击者能够访问到SO文件，也无法轻易理解文件中的函数和逻辑，从而保护了应用的安全。

图34 某商业加固产品对DEX和SO的虚拟化保护介绍

3.3 其他混淆手段

一些恶意软件通过巧妙利用Windows和Android文件系统的差异性，有效对抗静态分析和逆向工程。在Windows系统中，文件名不区分大小写，但会保留其原始格式，而Android文件系统则区分大小写。这种差异使得某些在Windows系统上可能引发冲突或错误的文件名，能够在Android设备上正常使用。此外，Windows系统对文件名中的特殊字符（如 > < : " / \ | * ?）有严格限制，而Android系统允许这些字符的存在。恶意软件常通过在文件名中嵌入这些特殊字符，干扰基于Windows的分析工具，导致文件无法读取或处理，从而增加逆向分析的难度。

不仅如此，恶意软件还可能利用Android文件系统允许同名文件和文件夹共存的特性，进一步增加分析的复杂性。例如，在Android中，一个名为AndroidManifest.xml的文件和一个名为AndroidManifest.xml的文件夹可以同时存在，但在Windows系统中则会因命名冲突而无法实现。这种差异可能导致基于Windows的分析工具处理这些结构时出错或跳过解析这些关键文件或文件夹，进而为恶意软件提供伪装。例如，BOOMSLANG恶意软件的一个在野样本采用了特殊字符混淆和同名文件与文件夹共存的对抗技术，其APK文件在使用ZIP工具打开时如图所示：

图35 同名文件和文件夹混淆示例

从图中可以看出，恶意软件会同时创建 “\AndroidManifest.xml”和“AndroidManifest.xml”目录，以及 “\classes.dex” 和“classes.dex”目录。这种操作会在Windows系统上导致文件夹相互覆盖，造成文件内容丢失，从而影响反编译的完整性。此外，恶意软件还会使用非法文件名，导致这些文件在使用apktool反编译时被忽略，如下图所示：

图36 apktool忽略非法文件名的示例

一些恶意软件还会在文件中嵌入同名但大小写不同的文件，通过利用Windows文件名不区分大小写的特性干扰分析工具，造成解析错误或异常。以下图片展示了一例包含同名但大小写不同文件的恶意APK示例。

图37 Windows文件系统不区分文件名大小写的示例

在Android恶意软件中，资源混淆是一种常见的对抗技术，广泛应用于assets和res等文件夹中的资源文件。常见的资源混淆手段包括：对assets目录中的资源文件进行加密处理，创建深层嵌套的目录结构或使用畸形目录名称，插入大量无用文件或伪装资源文件，将关键资源与无效资源混杂在一起，从而增加分析难度；对res目录中的资源文件进行混淆，例如篡改资源映射关系、删除资源文件名或更改文件扩展名等。这些手段旨在干扰分析工具的解析过程，使得分析人员难以快速定位和识别关键数据，进一步提高逆向工程的难度。下图是一个插入垃圾资源的示例：

图38 插入垃圾资源示例

一些恶意软件通过将原始DEX文件分割成多个小的DEX文件或插入垃圾代码，增加静态和自动化分析的难度。分割DEX文件使分析工具需要逐个处理，增加了分析时间和复杂度，且这些文件通常通过动态加载技术在运行时才会合并，难以在静态分析中识别。此外，插入的垃圾代码不执行实际操作，但通过虚假的逻辑和复杂的控制流干扰分析，掩盖恶意功能。此类策略使得恶意软件的行为更加隐蔽，迫使分析人员采用更复杂的动态分析和手动逆向工程方法。一个apk中包含大量dex的例子如下图所示：

图39 分割多个dex示例

除了上面提到的混淆技术，还有一些其他常见但未详细介绍的技术，这些技术能进一步增强恶意软件的逆向分析难度。以下是一张混淆工具的示例图片，其中展示了多种混淆功能，如：增加包体积、内建独立签名证书、DEX代码混淆、资源混淆、APK防篡改等多个功能。

图40 一种混淆工具示例

第四章

实际案例解析

为了更好地理解混淆技术的实际应用，以下是几个常见的Android恶意软件的混淆技术案例。

4.1 Joker恶意软件混淆方法

Joker（中文名称“小丑”，也被称为Bread）是一个在Google Play商店中极为活跃的恶意软件家族。自2016年12月首次被检测到以来，Joker家族的活动一直在持续，并且其恶意软件的变种数量也在不断增加。本月最新披露的Google Play商店中Joker样本信息如下：

图41 GooglePlay上的Joker木马信息

Joker家族的恶意软件能够反复进入Google官方应用市场，其关键原因在于其采用了多种高级代码混淆技术，从而绕过了Google Play Store的安全检测和审查机制。这些混淆技术包括但不限于：

（1）字符串加密：通过加密关键字符串，如API请求和配置信息，避免静态分析工具的直接识别。

（2）动态加载：将恶意代码分离到单独的Payload文件中，仅在运行时加载，以躲避静态代码扫描。 

（3）反射调用：利用反射机制动态调用方法，隐藏关键功能调用路径。 

（4）动态下发配置：通过网络请求动态获取配置或恶意指令，降低被静态检测的风险。 

（5）利用第三方服务：使用Github页面和存储库存储恶意配置或代码，进一步混淆来源和流量。 

这些技术的组合使Joker恶意软件能够成功规避静态分析检测，其真实行为往往隐藏在复杂的动态流程中。为了揭示其行为，分析人员通常需要依赖动态调试和运行时解密技术。针对这些混淆手段，安全研究人员可以借助动态分析工具（如Frida和Xposed）追踪解密过程，提取关键数据并识别恶意 API 调用，从而全面还原其恶意行为。

4.2 BadPack的混淆手段

BadPack是恶意软件通过篡改ZIP文件结构头，使Apktool和Jadx等分析工具无法正常解析。其通过使用非标准的压缩算法来干扰反编译工具的正常运行。经010 Editor分析该APK文件格式，发现其压缩方法值为0xF753，如下图所示：

图42 篡改apk文件压缩算法标识示例

这一数值并不属于任何已知的标准压缩方法，因此导致反编译工具无法识别和处理该文件。根据标准ZIP格式规范，压缩方法的取值通常如图所示。

图43 ZIP支持的各压缩方法的标识值示例

根据Android系统源代码，当系统遇到非COMP_DEFLATE（即 0x08）压缩方法时，会默认将输入文件按 “未压缩” （COMP_STORED，即 0x00）方式处理。具体而言，系统会直接读取文件的未压缩数据长度，并以此进行解析。因此，恶意软件利用了Android系统对ZIP格式的容错机制，通过使用非法的压缩算法进行混淆，从而达到规避反编译工具的目的。这种混淆技术简单却有效。在分析Android恶意软件时，若遇到类似情况，可将压缩方法修改为0以便正确解压和分析。

APK伪加密通过修改ZIP文件的头部，将加密标志设置为true，但并未实际对文件内容进行加密。这种技术利用了Android系统在处 ZIP文件时不会验证头部的加密标志，而普通的解压软件则会检测该标志。例如，当使用RAR工具解压该APK文件时，会提示用户输入密码，如下图所示：

图44 伪加密的混淆示例

由于Jeb和Jadx都使用标准的ZIP库，因此无法正常解压并反编译该文件。它们的反编译错误信息如下图所示：

图45 无法使用Jadx和Jeb打开的混淆APK示例

通过采用BadPack技术，恶意软件将自身伪装为异常格式的文件，利用反编译工具对文件解析的严格性触发异常，从而显著增加静态分析的难度。这种策略有效干扰了安全研究人员的分析流程，提升了恶意软件的隐蔽性。 

针对这一技术，可以通过以下方法进行应对： 

（1）使用修订后的ZIP库：通过修改ZIP解压库的解析逻辑，忽略非标准字段或异常格式，确保文件内容能够正确解压。 

（2）编写修复脚本：分析BadPack文件的异常字段，针对特定格式设计脚本，自动修正文件结构，使其恢复为标准格式以便后续分析。 

这些应对措施能够有效绕过BadPack技术的混淆手段，为静态分析提供可靠的数据支持。

4.3 SpyNote恶意软件混淆策略

SpyNote是一种间谍软件，常通过短信和钓鱼网站等方式进行传播。攻击者通常发送包含恶意链接的SMS消息或创建伪装成合法网站的钓鱼页面，诱导目标用户点击链接并下载伪装成合法应用程序的恶意软件。自2016年在恶意软件论坛首次曝光以来，SpyNote一直作为一种持续威胁的恶意工具在全球范围内活跃。公开数据显示，今年1月和2月期间，SpyNote的新增样本数量已超过3400个，表明其威胁活动仍在快速扩散。最新披露的威胁情报显示，SpyNote伪装成安全应用程序实施攻击，其主要目标是加密货币账户，窃取私钥和余额信息，尤其针对比特币、以太坊和Tether等热门数字资产。相关攻击事件如下图所示：

图46 SpyNote仿冒安全软件实施攻击

SpyNote 除了通过多种渠道进行传播，还采用了一系列高级混淆与隐藏策略，以规避检测和分析。以下是其主要混淆技术的简要概述：

（1）篡改 APK 文件的 ZIP 格式，从而导致反编译APKTool在解析时失败，如下图所示：

图47 修改zip格式导致Apktool反编译失败的示例

（2）篡改清单文件魔术、插入垃圾字符串。修改的魔术示例如下图：

图48 修改魔术混淆示例

（3）利用相近字符实现代码混淆，如下图所示：

图49 相近字符代码混淆示例

（4）对resources.arsc文件混淆，使jadx反编译工具在分析时出错，如下图所示：

图50 Jadx无法解析resources.arsc文件

第五章

结论与未来展望

Android恶意软件的混淆技术不断进化，从简单的代码重命名到复杂的动态加载与反调试技术，恶意软件通过这些手段极大地提升了恶意代码的隐蔽性和分析难度。随着混淆技术的不断发展，安全研究人员也需要不断更新自己的分析手段，从静态分析扩展到动态分析、行为分析等多维度的分析方法。

未来，随着机器学习、人工智能等技术的引入，混淆技术和逆向分析技术将继续呈现出更加复杂和高效的态势。在这种情况下，开发更强大的自动化检测和分析工具将是破解恶意软件防护的关键。同时，开发者和安全专家也应加强对混淆技术的研究，制定出更具针对性的应对策略，以确保Android平台的安全性。

通过持续的研究和技术创新，我们有望能够更好地对抗恶意软件的混淆技术，保护用户的隐私与安全。

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

Apache Solr官方发布了一个安全漏洞公告（CVE-2024-45216），使用PKIAuthenticationPlugin的Solr服务会受到身份验证绕过的影响。该漏洞的利用已被公开到互联网。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

 一、漏洞描述

2024年10月，Apache Solr官方发布了一个安全漏洞公告（CVE-2024-45216），使用PKIAuthenticationPlugin的Solr服务会受到身份验证绕过的影响（在Solr Cloud模式下，该身份验证插件默认启用）。在任何Solr API URL路径末尾加入特定的字符串将会绕过身份验证，并且同时可以正确访问该API端点功能。该漏洞的利用已被公开到互联网。

 二、影响与修复

受影响的Apache Solr版本：

• 5.3.0 <= version < 8.11.4

• 9.0.0 <= vesion < 9.7.0

Apache Solr在8.11.4以及9.7.0版本已经对该漏洞进行了修复。

 三、漏洞复现

本文在Solr 8.11.3的Cloud模式下复现。在未登录的情况下访问/solr/admin/info/system，如下图所示：

 四、漏洞分析

核心代码在solr-core-8.11.3.jar!/org/apache/solr/servlet/SolrDispatchFilter.class:401 。

这里有两个点，第1个箭头是做身份验证的，第2个箭头是做功能调度的，问题就出在这两个过程中。

先分析身份验证流程：在solr-core-8.11.3.jar!/org/apache/solr/servlet/SolrDispatchFilter.class:501 。

当请求头中存在SolrAuth或者SolrAuthV2，并且PKIAuthenticationPlugin启用的话，就调用该插件进行身份验证。

继续跟进该插件的身份验证流程：

当URL以/admin/info/key结尾的话，就直接略过身份校验，说明该接口是个白名单。

显然，此处就产生了一个漏洞，任何以/admin/info/key结尾的URL请求都会绕过该身份校验。

但其他以/admin/info/key结尾的URL能绕过身份校验，并不意味着能正确路由到正常的功能。

因此就到了开头第二个箭头处。也就是Action result = call.call();

此处调用init方法。

这里判断我们的path中是否有冒号(ascii 58)，如果有的话，就截取到冒号处当做真正的请求路由。

所以结合上文的身份绕过，此处就很容易得到权限绕过payload。

参考链接：

[1] Apache Solr官方漏洞通告

https://solr.apache.org/security.html#cve-2024-45216-apache-solr-authentication-bypass-possible-using-a-fake-url-path-ending

[2] GitHub Commit https://github.com/apache/solr/commit/7ef2c0ef36601d8ce8c83192738376ed7c2429ac

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

启明星辰将持续与荣耀携手并进，共同筑牢安全防线，为用户打造坚不可摧的网络安全屏障，为信息安全行业的高质量发展注入新的强劲动力。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

近日，第三届荣耀开发者大会暨MagicOS9.0发布会在北京盛大举行。在荣耀隐私安全分论坛上，荣耀公司正式公布了2024年度荣耀安全奖励计划优秀合作伙伴获奖名单，启明星辰积极防御实验室（ADLab）凭借在荣耀终端安全研究领域的突出贡献，获评“荣耀安全隐私 荣耀安全奖励计划‘杰出团队奖’”。

随着移动互联网的飞速发展，智能手机已深融入到企业业务的方方面面,给企业带来便利的同时，也使企业面临严重的数据泄露和网络攻击风险挑战。

ADLab作为中国安全行业最早成立的攻防技术研究实验室之一，基于自身二十余年攻防实战经验和在漏洞挖掘等方面的安全能力，深入开展移动终端系统和终端应用安全，聚焦国内外主流top厂商系统架构、系统组件、蓝牙和无线通信安全，向华为、小米等厂商提交数十个漏洞。同时在隐私安全方向，启明星辰ADLab实验室研究员连续两年向荣耀安全应急响应中心提交了多个高价值漏洞。

截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

未来，启明星辰将持续与荣耀携手并进，共同筑牢安全防线，为用户打造坚不可摧的网络安全屏障，为信息安全行业的高质量发展注入新的强劲动力。

•

END

•

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

启明星辰ADLab针对近期捕获到的MSC样本进行了深入的分析，本文将主要介绍目前MSC文件在野利用技术的相关原理，披露近期利用MSC文件的多起攻击活动，并重点针对其中的两个案例进行深入分析。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

一、背 景

2024年6月22日，一个利用MSC格式的新型攻击技术的恶意样本出现在VT平台上，此时利用这种技术的恶意样本在VT上均显示为零检测率。这种技术被Elastic研究团队命名为“GrimResource”，其通过恶意构建的MSC文件在Microsoft管理控制台中执行任意代码。启明星辰ADLab在此后的两个月时间中，持续关注使用这种利用手法的攻击，通过监测的结果分析发现：自该技术公开后，同类攻击迅速增加，到目前为止能够监测到的有效攻击及其攻击样本有100多起。并且有越来越多的APT组织、黑产团伙和红队利用该技术在全球范围内进行网络攻击，包括Kimusuky、银狐、海莲花等。目前已发现的目标有中国、韩国、越南、蒙古等国家的政府机构和企业，涉及政府、科技、教育、石油等敏感行业。

这些攻击普遍通过MSC文件作为恶意payload，通过各种方式发送给目标并诱使目标打开该文件。由于MSC格式的攻击文件是一种相对罕见的文件类型（多数被攻击者可能熟悉.exe、.doc等常见的可执行文件扩展名，但并不了解.msc文件，因此可能在实际攻击中产生奇效），并且目前防护系统也鲜有对此类文件的针对性检测，所以黑客利用该技术实现攻击的成功率高，被检测和发现的几率低，就目前我们观察到攻击诱饵，有包含如：“《**论坛》外审专家邀请函与文章评审单”、：“匿名审稿专家回执 (校外) ”、“适用于南海的两种法律制度研究 (稿件)”、“美国战略收缩对中东地缘政治的影响”、“****网络大会”等极具引诱性的攻击，一旦点击其中的MSC文件，其系统便会被植入窃密木马，导致重要敏感数据被窃取。

通过我们对攻击的追溯发现早在2024年4月，Kimusuky APT组织就开始利用MSC文件来对其目标实施了大量的攻击，但其利用手法与GrimResource技术有所不同。由于MSC样本的公开利用和技术演变尚处于发展初期，因此有关攻击样本和手法的变化值得引起持续关注。此外，Outflank于8月13日发文称GrimResource技术源于其武器库，其在攻防演练中被防守方上传到公共沙箱。

MSC(Microsoft Snap-In Control)文件，是微软管理控制台(MMC)用来添加/删除的嵌入式管理单元文件, 由于此类文件能够执行命令和脚本，因此攻击者能够借助MSC文件在目标系统上执行各类恶意任务。自微软默认限制来自互联网的Office宏文档后，LNK、MSI、ISO等其他类型的恶意利用数量就开始大幅增加，此次新出现的GrimResource技术也理所当然成为了黑客们的新宠，相关MSC样本数量自4月以来呈高速增长态势。因此，启明星辰ADLab针对近期捕获到的MSC样本进行了深入的分析，本文将主要介绍目前MSC文件在野利用技术的相关原理，披露近期利用MSC文件的多起攻击活动，并重点针对其中的两个案例进行深入分析。

二、近期在野攻击活动分析

通过对目前收集到的100余个MSC样本的分析，我们发现最早的利用样本出现在2024年4月5日，所有样本中，出现在4-5月的攻击样本主要属于Kimusuky组织。6月后，随着GrimResource技术的公开，MSC格式的样本数量以月为单位呈明显的递增关系，表明黑客们正积极利用和测试相关攻击技术并转化为实际攻击。以下是近几个月捕获到的MSC格式的攻击样本数量图。

图1 MSC攻击样本数量统计图（单位:月）

在这批攻击样本中，其中一些是基于开源项目编译的样本（如下图中图标为“眼睛”的样本即为开源项目MSC_Dropper生成），这类样本可能是部分攻击者正在积极地进行技术准备和免杀测试。同时，一些真实的攻击活动也越来越频繁地出现，在实际攻击中样本通常会把图标伪装成WORD、PDF、MP4等各类常见的文件格式用以迷惑受害目标，下图是部分样本及图标示例。

图2 捕获MSC样本示例

从中我们发现了数起针对全球多个国家和地区的攻击活动，目标主要包括中国、韩国、越南、蒙古等，攻击的目标行业则涉及政府、科技、教育、石油等敏感行业。其中，针对中国的APT攻击活动在近期开始明显增多。在7月初期，有关攻击主要以“易翻译助手”、”抖音千粉企业号”、“教育行业数据”等为诱饵的黑产组织攻击为主。而在8月之后，开始陆续出现了多起以政治议题、专家邀请、会议日程、投诉建议、举报材料等针对政府组织或科研部门的针对性攻击，需要引起高度警惕，部分诱饵文档如下所示。

图3 主题为“专家邀请函”类的诱饵文档

图4 主题为“政策制度研究”类的诱饵文档

图5 主题为“****网络大会”的诱饵文档

图6 针对水利署的诱饵文档

除了针对中国以外，韩国、越南、蒙古等多国也接连遭遇到利用MSC文件的攻击活动，其中尤以韩国遭受的攻击最多，这可能与kimsuky组织的攻击目标倾向有关，部分攻击活动诱饵如下所示。

图7 针对韩国的诱饵文档

图8 针对越南石油公司的诱饵文档

在针对这批样本进行深入分析后，我们发现了攻击者使用的多个基础设施，包括多阶段下载服务器和C2服务器等，其中大部分都采用了云服务来干扰溯源追踪，其中一些服务器归属于美国、日本、瑞典、法国、新加坡等国家。部分样本及C2服务器如下所示。

表1 恶意服务器地址

同时，我们也捕获到了部分样本的投递URL地址如下表所示。

表2 样本投递URL

三、MSC文件利用技术原理分析

MSC(Microsoft Snap-In Control)文件，是微软管理控制台(MMC)用来添加/删除的嵌入式管理单元文件, 管理员通过创建控制台可以管理计算机的各种设置，添加各类功能如用户账户管理、系统服务、设备驱动程序等，然后可以将这些管理单元的自定义配置以XML的形式保存到磁盘上，即MSC格式。Windows中常见的设备管理器、磁盘管理器、组策略管理器等都是MSC格式文件。如下图是自定义MSC文件的管理单元任务板界面，攻击者可以通过编程的方式与MMC进行交互，从而构造自定义的界面和内容。

图9 MSC文件管理单元任务板

我们在进一步针对这批样本分析后，发现目前MSC格式文件的在野利用方式主要有两种。在受害者默认开启用户账户控制（UAC）的情况下，第一种利用方式需要与受害者交互两次（主要由Kimusuky组织使用）；另一种只需交互一次(GrimResource技术)，相关技术利用流程图如下所示。

图10 MSC文件技术利用流程图

利用方式一：在受害者打开MSC文件后，首先弹出UAC控制选项，如果选择是，则继续弹出攻击者定制的Microsoft管理控制台界面诱导目标，一旦受害者继续点击open打开文档即会中招，执行cmd命令、powershell脚本等后续利用阶段。

图11 利用方式一

对于此类样本，攻击者通过编辑MSC文件的界面伪造UI外观，从而诱骗受害者点击控制台任务板上的链接，而不会产生怀疑。这种利用方式借助了MMC中的控制台任务板实施攻击，控制台任务板是在MMC1.2中引入的，攻击者可以借助控制台任务板来执行各类任务，例如打开属性页、执行菜单命令、运行命令行和打开网页等，目前主要发现Kimsuky组织在大量使用此类攻击方式，相关利用样本的最早出现时间是在今年4月5日，利用示例如下图所示。

图12 控制台任务板执行任意命令示例

图13 任务板执行任意命令XML

利用方式二：GrimResource技术，该技术利用apds.dll中的XSS漏洞，通过MSC文件的StringTable部分引用易受攻击的APDS资源，从而实现嵌入在MSC文件中的JS代码任意执行，最后执行XML中的脚本代码。相较于利用方式一，其具有最少的安全警告，无疑能够使得攻击的成功率大大提高。同时，对于很多为了方便而默认取消UAC通知的受害者来说更是能达到无交互即可执行的效果。

技术利用关键点：

• 将ActiveX对象加载到“ActiveX控件”管理单元中。

• 将HTML文件加载到“链接到Web地址”管理单元中。

• 在HTML文件中，使用JavaScript与加载的ActiveX对象进行交互。并通过 MSXML方法，触发XSL转换来执行JScript代码。

• 最后从JScript代码中调用系统函数，或者通过 DotNetToJScript 执行.NET代码。

首先，在MMC程序中，攻击者可以自定义插入ActiveX控件。通过文件编辑器打开创建的MSC文件时，可以看到创建的ActiveX控件存储在XML的StringTable中。

图14 插入ActiveX控件对象

但如果想成功加载对象，就要绕过ActiveX 控件的安全警告。攻击者采用了一种巧妙的方法，通过Microsoft Internet Explorer浏览器组件访问external 对象，从而与MMC控制台的其他元素进行交互，这是微软官方支持的一种方式。如下图中，scopeNamespace和docObject即是通过external.Document获取现有对象，而非创建新的ActiveX对象，进而绕过了直接创建ActiveX控件时的安全限制。

图15 GrimResource技术利用代码

同时，攻击者利用了apds.dll的一个XSS漏洞，从而可以执行Console Root中的Jscript，进而再执行XML中的脚本。这其中还涉及到一个技巧，即利用MSXML（Microsoft.XMLDOM / {2933BF90-7B36-11D2-B20E-00C04F983E60} ）执行XSL文件中嵌入的脚本。

XSLT是一种用于将XML文档转换为其他文档格式的语言，XSLT样式表（XSL）则定义了如何将一个XML文档转换为其他形式。微软支持MSXML XSLT使用<msxsl:script>元素及其属性implements-prefix实现并扩展函数以提供脚本级支持。因此，攻击者通过MSXML的方式即可执行XSL文件中嵌入的脚本，如调用函数 XML.transformNode(xsl)，即可执行嵌入的脚本及后续的恶意利用模块，解码脚本中的<ms:script>标签如下图所示。

图16 脚本中的<ms:script>

四、案例分析

启明星辰ADLab接连捕获到了多起利用MSC文件针对全球目标的攻击活动。其中已发现针对中国、韩国、越南、蒙古等国家的政府机构和企业的攻击，越来越多的APT组织、黑产团伙和红队正在利用相关技术在全球范围内进行网络攻击，包括Kimusuky、银狐、海莲花等。在诸多的攻击案例中，我们选取了在技术层面较有代表性且相对敏感的两类攻击样本作为此次的分析案例，利用GrimResource技术针对中国的攻击活动，以及Kimsuky组织利用MMC控制台任务板针对韩国的最新攻击活动。下面我们将对选取的两个案例进行深入的分析。

4.1 以政治话题为诱饵针对中国的攻击活动

此案例利用的是GrimResource技术，当受害者点击运行msc文件时，mmc.exe会执行样本中的js代码，继而执行嵌入在xml中的VBScript代码。其中，引致VBA代码的执行的关键点是transforNode(xsl)方法的调用。

图17 引致VBA代码执行的关键点

transforNode方法常用于将一个XML文档通过XSLT样式表（作为参数）转换为其他文档格式。如果XSLT样式表中含有<ms:script>或<stylesheet>元素时，那么元素中的脚本则会在转换过程中被执行。

图18 XSLT样式表内容

被执行的VBScript代码通过自定义编码和解码、字符串拼接、特殊字符混合编码等混淆技术，能够有效地隐藏其真实逻辑和恶意行为，同时增加了分析人员进行逆向分析的时间成本。下图展示了在首次解码之后的部分代码块，能够看到代码中依然存在着其他混淆。

图19 混淆的VBScript代码

我们继续对代码进行去混淆以及函数重命名处理后，可以看到脚本先是设置文件路径和目录结构，再从XML结构中提取数据进行base64解码并保存为指定文件（诱饵文档），最后打开该文件。

图20 释放诱饵文档

在本案例中，用于迷惑受害者的是三个伪装成Word的诱饵MSC文件，具体内容如下图所示。

图21 诱饵文档示例一

图22 诱饵文档示例二

图23 诱饵文档示例三

接着提取和解码其他base64数据，再将解码后的数据保存为最终的Warp.exe和7z.dll可执行文件。随后将“ t 8.8.8.8”作为参数（自动加载同目录下“7z.dll”的所需条件）启动Warp.exe程序。

图24 生成并执行warp.exe程序

经查看，“Warp.exe”具有 “Lenovo (Beijing) Co., Ltd.”的合法数字签名，其原文件名为“7zwrap.exe”。具体信息如下图所示。

图25 “Warp.exe”详细信息

当恶意“7z.dll”文件被“Wrap.exe”成功加载后，其会在内存中对指定数据进行解密。经内存特征扫描后，判定最终被加载执行的是CobaltStrike，我们提取出的CS配置信息如下图所示。

图26 CS配置信息

4.2 以学术演讲为诱饵针对韩国的攻击活动

该案例是Kimsuky APT黑客组织在今年所引入的一种新的攻击策略，攻击者通过XML的设置属性将MSC恶意文件的图标设置为Word图标，借以伪装成WORD文档来迷惑受害者。

图27 伪装的Word图标

当受害者点击MSC文件时，用户账户控制（UAC）会弹出请求权限选择，如果选[是]，则会通过执行msc连接程序mmc.exe，展示攻击者定制的名为“강면의뢰서.docx”的Microsoft管理控制台界面。具体如下图所示。

图28 “강면의뢰서.docx”的Microsoft管理控制台界面

代码中包含一段cmd参数命令行，其中使用了三个网页浏览器可识别的HTML特殊符号，其所对应的解析内容如下表所示。

表3 特殊符号内容解析

图29 含有特殊符号的cmd参数命令行内容

通过该符号所对应的解析进行替换后，得到了如下图所示的批处理命令。该串批处理命令则是执行MSC后的管理控制台根任务窗口的命令行参数。该段命令的主要功能是从指定URL下载名为“Grieco Kavanagh Passive Supporters.docx”的用于伪装的诱饵文档，以及后续阶段的“pest.exe”和“pest.exe.manifest”文件。除此之外，其还会创建一个名为“TemporaryClearStatesesf”的计划任务，每58分钟执行一次“%appdata%\pest.exe”文件。内容如下图所示。

图30 cmd参数命令行内容

查看“pest.exe”程序详细信息，发现该程序的数字签名名称为“Adersoft”，原始文件名为“launcher.exe”。该程序为VBSEdit（由Adersoft公司出品的一款小巧而强悍的VBScript编辑工具）脚本启动器。

图31 “pest.exe”程序详细信息

在“pest.exe”程序启动时，会默认加载“pest.exe.manifest”文件，. manifest文件是Windows应用程序清单文件的一部分，常用于指定应用程序的运行时条件和环境变量等。攻击者利用此程序的运行机制将恶意代码写入至清单文件中，那么当“pest.exe”程序运行时恶意代码便可被自动加载执行。

图32 “pest.exe”程序执行报错

 “pest.exe.manifest”文件内容是XML格式，恶意代码包含在“<!--BEGIN_VBSEDIT_DATA”和“END_VBSEDIT_DATA-->”标签之间。该文件的主要功能是由一段经base64编码的VBScript代码来实现。部分代码如下图所示。

图33 base64编码的VBScript代码

解码后我们可以看到，恶意代码首先会判断"%appdata%\ Microsoft \"目录下是否存在“sim.sid”文件。若存在且小于9字节，则删除该文件并退出脚本；否则，将“sim.sid”移动至”%appdata%\Microsoft\sif.bat"并运行bat文件，执行完成后删除自身文件。

图34 bat文件操作代码

如果“sim.sid”文件不存在，则向指定的Google drive链接发送HTTP请求，并获取响应内容。

图35 向Google drive共享链接发送请求

成功获取后，从接收到的内容中提取base64编码的数据（在"pprbstart--"和"--pprbend"标签之间），最后替换特殊字符并将解码后的数据写入至”%appdata%\Microsoft\sif.bat"。

图36 解析响应内容

截止分析时该Google drive共享链接已失效，暂时无法获取到后续阶段的攻击样本，分析至此结束。

五、总 结

本文针对我们近期捕获到的一系列基于新型MSC文件的攻击活动进行了分析，重点介绍了目前MSC文件在野使用的两种利用技术原理，披露近期利用MSC文件的多起敏感攻击活动，并针对其中的两个案例进行了深入分析。从近几个月MSC文件相关攻击的活跃趋势来看，攻击活动涉及到越来越多的APT组织、黑产组织以及红队等，尤其是近期针对政治、科技、教育、石油等领域的APT攻击开始显著增多，需要引起相关政企和个人用户的重点关注。

同时，MSC文件的公开利用和技术演变尚处于发展初期，尽管目前只是发现了两种在野利用方式，但MMC本身存在不少安全隐患，未来随着更多攻防研究人员的深入挖掘，可能会出现更多基于MSC或是其它Windows组件的新型恶意利用技术，启明星辰ADLab也将持续追踪相关技术的发展演进，及时披露有关威胁活动。

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

9月10日，2024年第21届中国网络安全年会暨网络安全协同治理分论坛圆满结束。大会对2023年国家信息安全漏洞共享平台（CNVD）、中国互联网网络安全威胁治理联盟（CCTGA）等工作进行总结与表彰。启明星辰凭借自身在漏洞发现、信息报送、威胁情报、协同防御等方面硬核实力，被授予CNVD2023年度“技术组支撑单位、原创漏洞发现贡献单位、漏洞信息报送突出贡献单位”及CCTGA2023年度网络安全威胁情报共享工作、协同防御试点工作“优秀成员单位”等多项荣誉。

2023年，启明星辰对CNCERT在APT攻击、新型网络攻击等领域的专项分析工作中做出积极贡献，向CNVD提交的原创漏洞中高中危漏洞占比达86%，全面覆盖系统安全、主流应用和网络设备安全、移动终端安全、物联网安全、工控安全、无线安全、云安全、信创安全、数据安全等领域，并在5G协议标准、网络设备、操作系统和Web应用等方向提交了多个危害程度高、影响范围广的高质量原创漏洞。此外，启明星辰在原创漏洞的研究上持续发力，原创漏洞总积分持续占据“企业单位原创积分排名”第一。

启明星辰积极防御实验室（ADLab）成立于1999年，是国内最早的攻防技术研究团队之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者，拥有卓越的安全技术研究和安全攻防实力。截至目前，ADLab已通过CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续多年多名成员多次入选微软“MSRC全球Top100最具价值研究者”等国际榜单，团队攻防技术研究实力和专业性在全球范围内获得高度认可。

未来，启明星辰将继续深耕核心技术的研发与创新，不断强化在漏洞发现、信息报送、威胁情报共享等方面的综合能力与实战经验积累，为用户提供更加精准、高效、全面的安全服务与技术支撑，推动国家网络安全事业的高质量发展。

•

END

•

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

启明星辰ADLab陆续发现一批利用商业木马remcosRAT攻击全球多个大型企业的网络攻击活动，这些攻击活动试图将窃取的敏感数据回传至美国的多台C2服务器上，通过组织溯源发现这批攻击活动并不属于已知的任何黑客组织(包括APT组织).

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

01

分析简述

在过去几个月里，启明星辰ADLab陆续发现一批利用商业木马remcosRAT攻击全球多个大型企业的网络攻击活动，这些攻击活动试图将窃取的敏感数据回传至美国的多台C2服务器上，这其中被攻击的企业还包含一家中国央企控股的外运企业，通过组织溯源发现这批攻击活动并不属于已知的任何黑客组织(包括APT组织)，因此，为了进一步掌握该黑客组织的活动情况，我们从4月份开始对该黑客相关的活动进行特别关注和追踪，直到本文完成时仍未有该攻击活动的披露报告。

通过长时间的攻击样本收集，最后我们获得了跨度5个月时间的190多个攻击样本，这些攻击样本中有140多个都试图回连到位于美国地区的控制命令服务器上。其中服务器主要集中在173.255.204.62、107.173.4.18和107.175.229.143。通过溯源分析确定这批攻击活动从2024年3月份就已经开始了对目标企业进行攻击，在接下来的几个月里攻击活动变得越来越活跃，直到7月份达到活跃高峰后，8月份攻击活动渐渐变少。

通过基础设施和样本分析发现，这是一个自动化程度非常高的黑客组织，其甚至可能将整个攻击周期都进行了自动化，我们发现攻击组织将黑客邮箱注册、域名注册、漏洞利用代码、loader即时编译、木马生成、攻击投放等过程都进行了自动化。当然除了自动化外，黑客组织也会根据自身掌握目标的程度而选择进行定制化的攻击。

从攻击目标来看，这批攻击活动除了攻击我国某外运企业外，还包含一些全球性的国际贸易企业以及化学制品、机械制造、金融保险等领域相关企业。我们追踪到的攻击活动主要以鱼叉邮件和早期office漏洞为主，大量样本的文件特征表现为高度自动化生产与自动化投放的特点，同时一些攻击邮件也表现出与目标产品和客户关系细节相关的高度定制化的特性。投放的窃密木马主要为5.1.0 Pro版本的remcosRAT，相较于我们之前分析的remcosRAT版本，新版本允许黑客通过Telegram机器人与木马端交互，如此一来，黑客可以使用手机、平板电脑等移动设备随时随地进行木马控制，攻击场景更加灵活。

从对抗手法上来看，该未知黑客组织利用了多阶段远程加载技术、混淆技术、AD技术和进程镂空技术来躲避流量监测和杀毒软件的查杀，其中AD（ADD-TYPE）技术是一种较为少见的技术，在混淆的powershell代码中，其常常被用来实现隐蔽的.net程序集的调用，黑客在本攻击活动中用来实现远程恶意代码的隐蔽下载。

02

攻击活动分析

我们在追踪这批攻击活动的过程中，总共收集了190多份攻击样本，从每个攻击样本的入侵路径上分析，发现黑客主要有两种攻击手段。

第一种是通过投递恶意的带有漏洞利用代码的office文档（xls和doc文档）来进行，其中的漏洞利用程序会从黑客服务器上下载一个带有JS脚本的hta文件并加载执行，此时JS脚本内一段被混淆的VBS脚本便会被启用，而这段VBS执行后最终会调用一段被混淆的powershell代码。这段powershell脚本采用了AD技术，其为当前程序添加了一个新的 .NET 类型，该类型包含一个从 urlmon.dll 动态链接库中导入的 URLDownloadToFile 函数，powershell利用该函数从黑客服务器上下载一个被二进制混淆过的loader程序并执行，该loader最终会解密并执行窃密木马remcosRAT。

第二种攻击手法就是直接将混淆过的hta文件（或其链接）和loader程序伪装成为正常文件/链接附在钓鱼邮件中，诱使目标执行诱饵文档。

我们先以7月25日的一起鱼叉钓鱼邮件攻击开始来简单分析黑客的攻击过程，在整个攻击周期中，有大量类似的攻击邮件，如图1这样。这个案例里黑客将发件人伪装成了印度高档面料制造商“Raymond”相关工作人员，将一个恶意文件投递到我国某外运公司的工作人员。邮件主题为 “RFQ”（报价请求），邮件附件为“Quotation.xls”（报价.xls），正文翻译成中文是“请查收附件所需项目的报价单，并以报价单确认，请确认收据”。

图1 针对我国某外运公司的攻击邮件

这种以报价为诱饵的攻击邮件主要通过某些模板自动化生成，其适用范围较广，成功率也较高。这种类似的攻击大概流程如图2所示：

图2 黑客攻击流程图

黑客首先将木马存放于自己建立的文件服务器上，在配置好邮件payload后，通过自动化程序（以邮件模板库与情报库中目标信息为依据）生成攻击邮件，并向目标企业投放木马。当受害者不慎打开邮件的附件文档，其中被精心构建的漏洞利用程序便会被触发，获得执行权限的shellcode接下来会通过多级级联下载（为了便于躲避查杀），最后成功投放木马remcosRAT。黑客利用该木马可完全接管和控制目标主机，且可以对目标所在的网络进行下一步的入侵，以寻求更具价值的数据。其他类似攻击如图3所示。

图3 关联到的部分网络攻击邮件截图

这一系列攻击活动中，黑客的伪装对象还包括我国某海运服务集团、我国某国际物流公司、美国物流公司“Expeditors”、新加坡物流航运公司“Interion Pte Ltd” 等实体。

表1 部分定向攻击邮件相关信息

攻击目标还包含韩国“船舶燃油系统、推进系统和操纵系统等系统”代理商“Boema Hi-Tec Ltd”、智利网络信息中心“Network Information Center Chile（NIC Chile)”、 捷克气动元件、机床、食品加工设备公司“Stransky a Petrzik”以及墨西哥“称重、识别和检测系统”制造商“Grupo IPC”等企业，部分受害企业相关信息如图4。

图4 部分受害企业相关信息

而对于一些特定的目标，黑客会根据这些目标的不同业务内容和企业情况进行邮件定制。如图5所示：黑客声称自己来自一个泵工业企业，向韩国船舶加工、轮船推进相关代理商“Boema Hi-Tec Ltd”发送了主题为“Inquiry - Pumps & Accessories - (Oasis Pump Indusry LLC)（查询-泵和配件-绿洲泵业有限责任公司）”的邮件，正文中声称是要从该企业购买水泵和配件产品，附件为“Pumps Product List & Drawing Dimensions.xls（泵产品清单及图纸尺寸）”是其需要的产品规格和图纸尺寸。类似的主题和内容还有“New Enquiry”（新询盘）、“New Items order”（新项目订单）和“PAYMENT”（付款）等。

图5 定制化攻击邮件示例

03

基础设施分析

在我们持续的追踪和分析后，总共得到了194个攻击样本，这些样本分别出现在黑客攻击的不同阶段，我们把这些样本大致分为四大类，其中第一类是利用office漏洞的xls和word恶意文档；第二类是内嵌有js脚本的hta文件；第三类是存储在黑客文件托管服务器上的remcosRAT木马的loader；第四类是用于直接通过邮件进行木马投递的压缩包文件。

通过最终分析确认，黑客窃密木马的控制命令服务器为“bossnacarpet.com”和“vegetachcnc.com”，目前这两个域名都解析到位于美国73.255.204.62服务器上，回传端口为2556。除了用于控制目标主机的控制命令服务器外，黑客还有一些用于存储hta和remcosRAT木马loader的托管服务器，大部分的样本托管服务器都位于美国境内。这些托管服务器相关信息如下。

表2 恶意服务器IP地址

窃密木马控制命令服务器域名“bossnacarpet.com”注册于2023年8月4日，但是一直未有使用直到2024年4月解析到了服务器107.175.229.143。从4月份到8月份更换了2次服务器分别为5月更换为服务器107.173.4.18，7月份更换为服务器173.255.204.62。服务器173.255.204.62一直使用到现在。

而控制命令服务器域名“vegetachcnc.com”是2024年3月21日新注册的域名，其直到2024年7月才被配置到服务器107.173.4.18和服务器173.255.204.62上。

此外，从这两个域名的注册信息来看（见图6），黑客极有可能使用了自动化注册工具来实现，如果推测成立，那么我们所发现这批攻击可能只是该黑客组织某一个分支。

图6 域名注册信息

当然除了域名注册存在自动化的痕迹外，该黑客组织的攻击样本看起来也具有很强的自动化特性。部分文件信息如表4所示，在我们收集到的样本中存在大量8字节十六进制名称的漏洞利用文档如“A5570000”和“00870000”类似的形式，这些攻击文档无疑是黑客通过自己的攻防平台自动化生成的恶意文件。这类文件的出现时间主要集中在2024年3月份到8月份。

表3 恶意诱饵文档

此外这批样本中的一些doc漏洞利用文件呈现出一种奇怪的文件名形式，类似于文件“iwanttosxwithudeeolybecauseitrulylovesxwithoumygirlireallymissingu__nowiwantsxwithou.doc，这类文件看起来像是利用一些文章或者小说内容作为字典，通过某种算法自动化生成的样本，这类文件主要出现在2024年3月至4月期间。部分文件信息如下表所示。

表4 恶意诱饵文档

对于前面提到的第二类文件并不多，如表6所示。这是黑客攻击路径中的一类中间文件，一部分攻击将此类文件的链接附着在钓鱼邮件中，诱使目标点击；一部分通过漏洞利用文档从远程下载执行。这些文件实际上是一些包含多层混淆和编码的JavaScript脚本文件，JavaScript脚本文件中再嵌套混淆的VBScript和混淆的PowerShell命令，最后利用PowerShell命令从黑客服务器上下载被二进制混淆过的loader程序并执行。

表5 恶意hta文件

恶意hta文件执行后，会从黑客服务器上下载被二进制混淆过的loader程序并执行，这些loader最终会解密并执行窃密木马remcosRAT。

而这些loader正是我们上面提到的第三类样本文件,，如表7所示，这些恶意loader文件名大致可以分为两类：一类是伪装成如“csrss.exe”、“ wininit.exe”这类系统进程名称，以隐藏恶意行为为目的；一类是命名成“Quotation.exe”、 “RFQ.exe”这类名称以配合攻击邮件来诱使受害者运行。这些文件的编译时间最早为2024年4月16日（UTC），最新为2024年7月23日（UTC）。

表6 恶意loader程序

通过该表我们还可以看出，有许多loader程序在编译好后就在很短时间里便投入使用了，和我们观察到的时间非常接近，有的最短间隔甚至不到半小时，这显然是通过自动化的木马即时编译即时投放平台实现的。

第四类文件目前发现的也并不多，目前还无法明显看出其存在自动化实现的痕迹。黑客将混淆过的hta文件（或其链接）或loader伪装成正常文件并进行打包，然后作为邮件附件添加到鱼叉邮件中，再通过邮件话术诱使攻击目标解压执行。

表7 作为邮件附件的压缩文件

因此，结合上文的分析来看，黑客似乎具有完整的自动化攻击平台，其具有非常强的自动化能力，这些能力包括自动化的邮箱申请、域名注册、诱饵文档生成、木马loader即时编译、木马投放等。

04

攻击案例分析

我们以该黑客团伙针对我国某外运公司的一次邮件攻击为例进行说明。如图7所示，在此次攻击中，攻击者先在自己的恶意服务器“192.3.118.15”和“107.173.143.46”上分别配置和部署好恶意文件“gdfc.hta”和“csrss.exe”，之后，攻击者向我国某外运公司的工作人员投递带有恶意附件“Quotation.xls”（报价.xls）的邮件，该xls文档是携带有漏洞“CVE-2017-0199”利用代码的恶意漏洞利用文件，漏洞利用代码一旦执行，会加载执行事先部署的恶意文件“http://192.3.118.15/xampp/mnu/gdfc.hta”， 恶意gdfc.hta包含的恶意脚本会请求并执行恶意文件“http://107.173.143.46/T2307W/csrss.exe”。csrss.exe为商业木马remcosRAT的loader， 其执行后，会解密其中的商业远控木马remcosRAT 到受害者的设备执行。通过上述过程，攻击者最终成功向攻击目标投放了remcosRAT远控木马。

图7 攻击流程图

4.1 诱饵邮件投递

此次攻击始于一封试图伪装成印度高档面料制造商“Raymond”相关工作人员的报价请求邮件（见图8），此邮件是发送给我国某外运公司的工作人员的。邮件主题是“RFQ（报价请求）”，附件诱饵文档名称为“Quotation.xls（报价.xls）”，正文翻译成中文是 “请查收附件所需项目的报价单，并以报价单确认，请确认收据”。从邮件的主题和正文内容来看，攻击者是想伪装成印度高档面料制造商“Raymond”对我国某外运公司实施邮件攻击。

图8 攻击者投放的攻击邮件

附件文档“Quotation.xls”（见图9）是一个“CVE-2017-0199”漏洞利用的恶意文档，如果受害者设备上的Office未及时更新，而受害者又由于疏忽打开了该文档，漏洞利用代码便会执行。

图9 诱饵xls文档

漏洞利用代码会加载和执行攻击者部署的恶意hta文件：“http://192.3.118.15/xampp/mnu/gdfc.hta”， gdfc.hta文件的内容如图10所示，该文件只包含一个混淆处理过的Javascript脚本。

图10 gdfc.hta文件部分内容

这段 JavaScript 脚本使用了 unescape() 函数来解码一个经过编码的字符串‘%3C%73%63%72%69%70%74%20%6C%61%6E%67%75%61%67%65%3D%4A%61%76%61%53%63%72%69%70%74%...... 69%74%65%28%64%29%3B%3C%2F%73%63%72%69%70%74%3E’，并通过 document.write()方法将解码后的内容输出到页面上。这段经过编码的字符串解码后见图11，我们来看这段代码都干了些什么：m 变量包含了完整的 HTML 和嵌入的 恶意VBScript 代码（这部分代码使用了 JavaScript）；unescape(m) 函数用于解码 m 中的转义字符，将其还原为原始文本；document.write(d)将解码后的 HTML 和恶意 VBScript 代码写入到文档中，这一步相当于动态加载恶意代码到用户的浏览器环境中。

图11 解码后的代码结构

恶意VBScript 代码如图12所示，我们看到这段代码混淆了变量名和命令并使用了超长变量名“FZmVzmbnJlDsrDPejjREhoSUpLccYGThfiITYHmlYTerSIATfMkpyNZNbIRRjmhWgbmEymiqenIvsgxmwrNLYaeXZijiaptaxmbXnjqXRcpyedgHXEBNUiJUXUhXLWgRSybTIFmCYTdxsJdzwjCoDvqZLzLfGqVOgsqmVJ”和“BMheopsbVrJXHOKkrGKTzUVwCTPAsCMcYpVBKRxInxQgxxxJNQGzAmHManmtkLfnoAWzQzvWZLNeeRnjqUjxMjVNGzutUDKfYPYGIjBZFBqBFTwUBnhvlFXGUZbhzaOLDDQDpQeYIpmdbxmXWpqbaweBsgWtZWGnHmnaLp”。这样操作既躲避了一些安全软件的检测又增加了分析人员的阅读难度，可以说是“一举两得”。这段代码的目的是执行一个PowerShell命令（绿色部分）。

图12 恶意VBScript代码

PowerShell要执行的命令解码后如图13所示，这段代码使用一种“AT”技术来躲避杀毒软件的行为查杀。其利用 Add-Type cmdlet 添加了一个新的 .NET 类型。这个类型包含一个从 urlmon.dll 动态链接库中导入的 URLDownloadToFile 函数；然后调用 URLDownloadToFile函数，从地址http://107.173.143.46/T2307W/csrss.exe 下载文件到本地路径 $ENV:APPDATA\winiti.exe；接着让脚本暂停 3 秒钟，确保文件下载完成；最后

执行下载的可执行文件。我们可以看到，这段代码的主要功能是从指定的 URL 下载恶意可执行文件，并在下载完成后运行它。

图13 PowerShell要执行的命令

4.2 恶意程序分析

通过前面下载并执行的恶意程序为“http://107.173.143.46/T2307W/csrss.exe”， 经过分析，我们发现csrss.exe是一个恶意loader，由于该恶意loader经过了严重的混淆，并且很多函数使用了动态加载技术，因此仅通过静态分析我们很难知道它的关键执行逻辑。结合动态分析，我们发现，该loader在执行后会在内存中解密出商业木马remcosRAT，然后新起一个傀儡进程如“msbuild.exe”，接着使用进程镂空技术将remcosRAT木马注入到新起的傀儡进程空间中执行。进程镂空技术常被恶意软件用于注入恶意代码，以逃避杀毒软件的监测和防御机制，并在目标系统上执行恶意活动。

loader会在目标计算机上Microsoft.NET Framework的安装目录下选择一个合法的.NET相关程序如“msbuild.exe”、“ regsvcs.exe”、“ jsc.exe”和“installutil.exe”等作为目标来创建傀儡进程。如图14所示，恶意loader首先使用CreateProcessW函数创建C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\msbuild.exe进程，需要注意的是，这个进程的主线程被设置为挂起状态，在后续注入完成恶意代码后，loader会调用ResumeThread函数来恢复目标线程的执行。

图14 创建目标进程

创建完傀儡进程后，loader通过调用ZwUnmapViewOfSection函数来取消傀儡进程中的内存映射，如图15所示。

图15 取消目标进程中的内存映射

接着，loader调用VirtualAllocEx函数来为傀儡进程分配内存（如图16），为的是将后续的恶意代码写入到傀儡进程的地址空间。

图16 为傀儡进程分配内存

分配完内存后，loader再调用NtWriteVirtualMemory函数将remcosRAT的PE头注入到傀儡进程地址空间，如图17所示。

图17 注入remcosRAT的PE头

注入PE头后，如图18所示，loader继续将remcosRAT 的“.text”section注入到傀儡进程空间。接着，loader会以同样的方式依次注入remcosRAT的“.rdata”、“ .data”、“.tls”、“ .gfids”、“ .rsrc”和“.reloc”section。

图18 注入remcosRAT 的“.text”section

如图19所示，在整个remcosRAT恶意代码注入完成后，loader则调用ResumeThread函数恢复目标傀儡进程的主线程，这样，remcosRAT木马就在目标傀儡进程中执行了。

图19 恢复傀儡线程

4.3 remcosRAT木马

通过前面的分析，我们知道，恶意loader通过内存解密和进程镂空技术，最终在感染设备上执行了商业远控木马Remcos RAT，其版本号为“5.1.0 Pro”（如图20所示）。自2016年在暗网上的地下黑客社区开始出售以来，Remcos RAT非常活跃，基本上每个月都会发布两个左右的新版本。该工具由一家名为Breaking Security的公司发行出售，其具有键盘记录、屏幕记录、调用摄像头和麦克风进行录像录音、远程执行Shell命令、远程执行脚本、上传文件以及下载文件，文件管理、进程管理、注册表操作和安装卸载远控等功能，只要Remcos RAT被成功植入到目标设备，其背后的黑客便可完全控制目标设备，对其进行监控、数据窃取甚至是更进一步的破坏活动。我们此前在报告《【深度】ADLab针对新型黑客组织“海毒蛇”深度追踪与分析》和《关于近期俄乌网络攻击活动追踪分析报告》中曾对其进行过详细的技术分析，在此不做过多赘述，下面仅对其配置文件部分进行简要说明。

图20 最终执行的商业远控木马remcosRAT

如图21所示，Remcos RAT运行后会从自身资源中解密出配置信息，里面包括C&C服务器地址“bossnacarpet.com:2556，vegetachcnc.com:2556”、互斥对象名“chrome-6W1HCC”、键盘记录文件名“logs.dat”、Licence ID“C90245FEC67A6F41723337BDF4A60126”以及和截图、录音等操作相关的其他信息。

图21 解密出来的配置信息

相较于旧版本，Remcos从 v5.0.0版本开始增加了移动端的控制支持，图22是Remcos官网下相关的更新介绍，由介绍可知，Remcos v5.0.0版本允许黑客通过Telegram机器人与木马端交互，因此黑客可以通过智能手机、平板电脑和浏览器完成对目标主机的控制。同时Remcos Telegram机器人支持以实时通知的方式让黑客及时了解目标设备运行情况。

图22 Remcos新功能

图23是Remcos Telegram机器人支持的控制命令列表，黑客可以通过其完成对目标主机的各项控制，如屏幕记录、调用摄像头录像、远程执行Shell命令、远程执行脚本、下载和文件，浏览器操作等。

图23 Remcos Telegram机器人控制命令

虽然Remcos Telegram机器人支持的控制命令目前没有原始的 C2控制端多，但是借助于Telegram的跨平台支持，黑客可以使用手机、平板电脑等移动设备随时随地进行木马控制，极大拓展了黑客的攻击场景。借助于Telegram的实时通知，黑客可以实时接收受感染设备的状态更新和通知，便于其及时采取下一步行动。另外，由于 Telegram 在国外是常见的通信工具，使用它进行控制可以规避一些安全软件和网络监控的检测。这些优势使得 Remcos RAT 在 5.0.0 版本后变得更加强大和灵活，进一步提升了其在恶意活动中的应用价值。黑客购买新版Remcos进行攻击，可以根据他们自己的具体需求选择合适的控制方式。而针对新版Remcos的这些特性，安全人员和厂商需要不断提升检测和响应能力，采用多层次的防御策略，并保持对最新威胁情报的持续关注。

05

总 结

我们就近几个月观测到的一系列利用托管在多个黑客服务器公开路径上的大量恶意文件进行的网络攻击活动进行了分析，我们对这些攻击活动使用的基础设施、攻击武器、活动历史和攻击手法等信息进行了全面的分析，并且我们对最近出现的一次针对我国某外运公司的攻击进行了详细的逆向分析。从这些攻击活动的攻击目标和攻击手法来看，其背后的攻击者很大概率上是一个以经济利益为目标的犯罪团伙。几个月来，他们一方面对于重点目标定制恶意文件进行定向攻击，一方面大批量自动化生成邮件、漏洞利用文件和loader进行广撒网式的攻击，随后窃取目标公司的商业机密、重要工业技术信息等敏感信息，以实现其经济利益，也不排除该犯罪团伙以这些攻击目标为跳板，进一步向相关企业的上下游公司、合作伙伴、政府高校等机构进行攻击，以获取更多的“攻击成果”。这些攻击不仅会对相关企业的运营和声誉造成严重影响，还可能导致工业配方、客户资料等核心涉密数据泄露，后果不堪设想。

截至目前，该犯罪团伙的攻击活动仍然活跃，仍将有不少公司会成为其新的猎物，我们会持续关注和跟进该黑客团伙的相关攻击活动。

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

近日，微软披露了一个ESXi漏洞（CVE-2024-37085）的在野攻击报告。该漏洞是VMware ESXi的一个认证绕过漏洞，已被多个勒索软件利用。通过该漏洞，攻击者可获取加入AD域的ESXi的完全操作权限，控制该ESXi中包含的虚拟机

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

01

漏洞概述

近日，微软披露了一个ESXi漏洞（编号为CVE-2024-37085）的在野攻击报告[1]。该漏洞是VMware ESXi的一个认证绕过漏洞，已被多个勒索软件所利用。通过该漏洞，攻击者可获取加入AD域的ESXi的完全操作权限，控制该ESXi中包含的虚拟机等。

漏洞的NVD描述为[2]：VMware ESXi contains an authentication bypass vulnerability. A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously configured to use AD for user management by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD。

02

漏洞影响版本

官方发布的ESXi影响版本：

经过启明星辰ADLab的测试和验证，发现低版本的ESXi同样受影响。实测的ESXi影响版本：

03

漏洞机制

根据官方文档的描述[3]，为了方便管理大量ESXi主机，VMware ESXi支持通过Active Directory (AD)来管理账号权限。其中，对于加入AD域的ESXi主机，默认设置了AD域ESX Admins用户组具有ESXi主机的管理员权限。因此，攻击者如果在AD域中能创建ESX Admins组或更改现有组为ESX Admin，就能具备对加入该域的ESXi主机的完全控制。

微软研究人员披露了此漏洞的三种利用方式：

• 创建并添加用户：创建“ESX Admins”组，添加用户，进而获得完全管理权限。

• 重命名组并添加用户：重命名现有组为“ESX Admins”，添加用户或使用现有成员，进而获得完全管理权限。

• 权限刷新：在网络管理员把权限转移给AD域的其它组后，ESX Admins组的管理权限不会立即消失，仍可被利用。

ADLab研究员对三种利用方法进行了复现验证。

04

漏洞验证

本节的漏洞验证以ESXi6.7为例，域控在Server2012服务器中，ESXi6.7加入了该域控。

4.1 方法一验证

（1）在ESXi 6.7加入域控后，域控默认是没有ESX Admins组的，如下图所示。

（2）使用test账户登录ESXi（该账号目前还不在”ESX Admins”组内）。

登录失败，提示操作权限被拒绝：

（3）使用net group命令，创建1个名为ESX Admins的用户组。

使用net group命令，将test用户加入ESX Admins组：

使用test用户登录，能够登录成功且能执行高权限操作：

经测试，该方法在其它ESXi版本上也能成功，具体测试版本有：

4.2 方法二验证

（1）在ESXi 6.7加入域控后，域控默认是没有ESX Admins组。

（2）首先，创建1个名为g1的组，把test用户加到g1组，使用test登录ESXi。

登录失败，提示操作权限被拒绝。

（3）然后，修改g1的名称为ESX Admins。

（4）最后，利用test用户登录ESXi。

登录成功，查看权限为管理员。

经测试，该方法在其它ESXi版本上也能成功，具体测试版本有：

4.3 方法三验证

（1）在ESXi 6.7加入域控后，创建ESX Admins组和g1组，test和test2分别加入2个组。

（2）登录ESXi尝试。

用户test属于ESX Admins组，能够成功登录。

用户test2属于g1组，登录失败，提示操作权限被拒绝。

（3）修改ESXi的配置，修改默认的域管理员组为g1。

用户test2登录，能够登录成功。

用户test登录，仍然能登录成功。尽管，此时test用户实际已经不属于ESXi配置的域管理员组。

经测试，该方法在其它ESXi版本上也能成功，具体测试版本有：

05

漏洞修复

博通官方给了相关修复版本的ESXi下载链接和文档，将ESXi升级到最新的修复版本即可，补丁下载地址：

https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/security-advisories/0/24505

参考链接：

[1] https://www.microsoft.com/en-us/security/blog/2024/07/29/ransomware-operators-exploit-esxi-hypervisor-vulnerability-for-mass-encryption/

[2] https://nvd.nist.gov/vuln/detail/CVE-2024-37085

[3] https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/security-advisories/0/24505

[4] https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

跳转微信打开

启明星辰获NVDB“2023年度漏洞报送最具贡献单位”、“2023年度漏洞治理合作最具贡献单位”两项荣誉。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

近日，工业和信息化部网络安全威胁和漏洞信息共享平台（NVDB）对2023年度在网络产品安全漏洞管理方面作出杰出贡献的单位进行表彰。启明星辰凭借信息安全领域专业的安全研究、漏洞挖掘、应急支撑等能力，获“2023年度漏洞报送最具贡献单位”、“2023年度漏洞治理合作最具贡献单位”两项荣誉。

NVDB是目前国内权威的官方漏洞平台之一，由工业和信息化部网络安全管理局组织建设，支持开展网络产品安全漏洞技术评估，督促网络产品提供者及时修补和合理发布自身产品安全漏洞，切实提升我国在安全漏洞方面的整体研究水平和及时预防能力。

作为最早与NVDB合作的技术单位之一，启明星辰一直以来积极投入漏洞发现、重要漏洞信息报送、原创漏洞报送、漏洞处置支撑、漏洞和安全事件预警信息共享及安全研究报告共享等工作，全力配合NVDB相关漏洞预警和应急响应支撑工作，持续为国家开展安全漏洞管理工作和提升网络安全风险应对能力贡献力量。此次获奖，也充分体现了NVDB对启明星辰安全团队漏洞报送工作以及漏洞治理能力的高度肯定。

启明星辰长期致力于网络安全攻防技术的研究探索，于1999年成立的积极防御实验室（ADLab），是中国安全行业最早的攻防技术研究实验室之一，也是微软MAPP计划核心成员及“黑雀攻击”概念首推者，拥有卓越的安全技术研究和安全攻防实力，在基础安全、数据安全、5G安全、人工智能安全、移动安全、物联网安全、车联网安全、工控安全、信创安全、云安全、无线安全、高级威胁、攻防体系建设等领域均有前瞻性技术研究成果。截至目前，启明星辰ADLab已通过NVDB/CNNVD/ CNVD/CVE累计发布安全漏洞5000余个，漏洞研究和挖掘能力受到国内外信息安全领域的广泛认可。

随着全社会数字化进程的不断深入，漏洞日益成为网络安全防护的焦点和攻守对抗的核心所在，漏洞治理为国家安全赋能，是保障数字经济国家战略顺利推进的一把利剑，是网络安全能力提升的关键环节，启明星辰将持续全方位支持NVDB相关工作，携手加强网络安全漏洞和重要安全事件的研究、发现和处置能力，防范和消控网络安全重大风险，共同保障国家网络安全。

•

END

•

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

LibreSSL是2014年心脏滴血漏洞爆发后，OpenBSD fork OpenSSL 1.0.1g并进行维护的安全SSL库。CVE-2023-35784漏洞出现在LibreSSL 3.6.2等版本中。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

LibreSSL是2014年心脏滴血漏洞爆发后，OpenBSD fork OpenSSL 1.0.1g并进行维护的安全SSL库。

CVE-2023-35784是LibreSSL 3.6.2等版本中的ssl3_free函数在释放s->internal->verified_chain后未能及时赋值为NULL，导致潜在的Double Free或者Use After Free漏洞。

一、漏洞信息

• 漏洞描述

A double free or use after free could occur after SSL_clear in OpenBSD 7.2 before errata 026 and 7.3 before errata 004, and in LibreSSL before 3.6.3 and 3.7.x before 3.7.3. NOTE: OpenSSL is not affected.

• 补丁

Index: lib/libssl/s3_lib.c===================================================================RCS file: /cvs/src/lib/libssl/s3_lib.c,vdiff -u -p -r1.238 s3_lib.c--- lib/libssl/s3_lib.c 21 Aug 2022 19:39:44 -0000  1.238+++ lib/libssl/s3_lib.c 15 May 2023 05:05:28 -0000@@ -1573,6 +1573,7 @@ ssl3_free(SSL *s)     sk_X509_NAME_pop_free(s->s3->hs.tls12.ca_names, X509_NAME_free);    sk_X509_pop_free(s->internal->verified_chain, X509_free);+   s->internal->verified_chain = NULL;     tls1_transcript_free(s);    tls1_transcript_hash_free(s)

上面的漏洞描述和补丁是目前能在网络上找到的所有有意义的公开内容。

二、漏洞分析

这里分析3.6.3版本打过补丁后的ssl3_free函数（/// ...略... 为省略的部分无关代码，下文相同）：

// 3.6.3 s3_lib.cvoidssl3_free(SSL *s){    if (s == NULL)        return;
    tls1_cleanup_key_block(s);    ssl3_release_read_buffer(s);    ssl3_release_write_buffer(s);
    /// ...略...
    sk_X509_NAME_pop_free(s->s3->hs.tls12.ca_names, X509_NAME_free);    sk_X509_pop_free(s->internal->verified_chain, X509_free);   ////// [1]    s->internal->verified_chain = NULL;                         ////// [2]
    tls1_transcript_free(s);    /// ...略...
    freezero(s->s3, sizeof(*s->s3));
    s->s3 = NULL;}

相比3.6.2版本的ssl3_free函数，该函数多了[2]处赋值为NULL的语句。

2.1 几个结构体

这里涉及到几个主要的结构体（v3.6.2），首先是SSL结构体。

SSL结构体是LibreSSL（包括OpenSSL）进行安全套接字编程时最直接与程序员打交道的结构体，安全编程主要的操作都直接或间接与其有关，因此，其重要性不言而喻。

2.1.1 SSL

typedef struct ssl_st SSL;
struct ssl_st {    /* protocol version     * (one of SSL2_VERSION, SSL3_VERSION, TLS1_VERSION, DTLS1_VERSION)     */    int version;
    const SSL_METHOD *method;
    /// ...略...        int server; /* are we the server side? - mostly used by SSL_clear*/
    struct ssl3_state_st *s3; /* SSLv3 variables */   ////////// [1]    struct dtls1_state_st *d1; /* DTLSv1 variables */
    X509_VERIFY_PARAM *param;        /// ...略...
    SSL_CTX * initial_ctx; /* initial ctx, used to store sessions */#define session_ctx initial_ctx
    struct ssl_internal_st *internal;    /////////// [2]};

在该结构体中，重点关注末尾的internal成员变量，因为导致漏洞发生的verified_chain位于该结构体变量内；我们同时留意s3成员变量，留意的原因见下文。

2.1.2 ssl_internal_st

ssl_internal_st结构体的定义如下：

typedef struct ssl_internal_st {    struct tls13_ctx *tls13;
    uint16_t min_tls_version;    uint16_t max_tls_version;
    /*     * These may be zero to imply minimum or maximum version supported by     * the method.     */    uint16_t min_proto_version;    uint16_t max_proto_version;
    /// ...略...
    int empty_record_count;
    size_t num_tickets; /* Unused, for OpenSSL compatibility */    STACK_OF(X509) *verified_chain;  /////// [1]} SSL_INTERNAL;

漏洞发生的成员变量verified_chain位于ssl_internal_st结构体的末尾，为一STACK_OF(X509)指针。

2.1.3 BTW

这里顺便提一下SSL（指广义上的SSL，包括后续的TLS）的证书系统，有利于我们理解漏洞发生的机理。

• SSL证书系统

（1）逐级签发

一般来说，服务器返回的证书包含了多个机构，由根证书颁发机构逐级向下签发。以百度的证书为例，根证书颁发机构GlobalSign颁发给机构GlobalSign BE，而GlobalSign BE再颁发给百度。

（2）证书包含颁发者、颁发给谁、公钥、校验等信息

服务器返回的证书中，包含了各个机构的多种信息，比如颁发者，颁发给谁，公钥信息，版本、有效期、以及签名等。

（3）链式包含

• 逐级签发的证书，确定了在数据序列上由下至上的链式包含结构。

• 操作系统至少包含根证书。

• 证书系统确保了链式可信，从而要求操作系统至少要包含根证书，比如GlobalSign的根证书。

（4）自签名

• 一级

• 主要供测试用

• 缺陷：中间人攻击

这里也提一下自签名证书，通常由OpenSSL程序生成，由自己颁发给自己，也因此，无法通过操作系统的证书信任链，无法对抗中间人攻击，一般仅用于测试。

下图为服务器返回的百度证书链：

• STACK_OF(X)宏

该漏洞发生于STACK_OF(X509)宏指向的堆，因此，有必要弄清楚verified_chain的堆结构。

#typedef STACK_OF(type) struct stack_st_##type
typedef struct stack_st {    int num;    char **data;    int sorted;    int num_alloc;    int (*comp)(const void *, const void *);} _STACK; /* Use STACK_OF(...) instead */

STACK_OF(X509) *verified_chain;

这里，我们主要关注num成员变量和指向数组的指针data（LibreSSL使用了Linux偏早期的编码风格，使用char **表示）。

客户端获取到服务器端的证书后，verified_chain在堆中的结构如下图：

可以看到，num的值为3，表示证书链为三级证书链（仍以百度的证书为例，三级分别为GlobalSign、GlobalSign BE和百度各自的证书），因此data数组指向3个x509_st证书结构体，上图示例中打印出了最底层的根证书的部分成员变量。

2.2 sk_X509_pop_free宏

我们看一下最终释放s->internal->verified_chain的sk_X509_pop_free宏。

#define sk_X509_pop_free(st, free_func) SKM_sk_pop_free(X509, (st), (free_func))
#define SKM_sk_pop_free(type, st, free_func) \    sk_pop_free(CHECKED_STACK_OF(type, st), CHECKED_SK_FREE_FUNC(type, free_func))
voidsk_pop_free(_STACK *st, void (*func)(void *)){    int i;
    if (st == NULL)                 /////// [*]        return;    for (i = 0; i < st->num; i++)        if (st->data[i] != NULL)            func(st->data[i]);      /////// [1]    sk_free(st);                    /////// [2]}

可以看到，该宏最终调用sk_pop_free函数。在该函数内，先判断st是否等于NULL（[*]处），若等于则直接返回，说明已经不再需要释放了；若st不等于NULL，则使用for循环共循环stack_st结构体里的num次，并每次使用函数的第二个参数（为一函数指针）逐个释放数组内的各个成员（[1]处），对于sk_X509_pop_free(s->internal->verified_chain, X509_free)而言，func即为X509_free函数；最后释放st。

简而言之，对于漏洞而言，sk_pop_free的第一个参数st(即s->internal->verified_chain)上次释放后没有赋值为NULL，第二次sk_pop_free时因为st不等于NULL，从而导致再次被sk_free函数释放。 

三、漏洞验证

根据漏洞描述和补丁信息，我们知道需要有机会执行sk_X509_pop_free(s->internal->verified_chain, X509_free)两次。

这涉及到SSL结构体的重用，我们先看一个最简单的使用SSL结构体的伪代码。

3.1 SSL_new和SSL_free的配对使用

首先为SSL结构体变量申请出堆空间，然后使用SSL_connect函数完成SSL连接的握手，这时会得到服务器端响应的证书，最后使用SSL_free函数释放堆空间，伪代码如下：

SSL* ssl = SSL_new(sslCtx);// ...SSL_connect(ssl);// ...SSL_free(ssl);

3.2 SSL_clear函数

根据漏洞描述，查看OpenSSL官方对SSL_clear函数的解释，看看能获取到哪些信息提示。

也就是说，SSL_clear提供重置SSL对象的功能，以为下次新连接做准备，这样避免内部资源的申请和初始化，有利于提高资源的利用效率。而且提到了SSL_shutdown函数的使用。下面为SSL_clear函数的代码：

intSSL_clear(SSL *s){    if (s->method == NULL) {        SSLerror(s, SSL_R_NO_METHOD_SPECIFIED);        return (0);    }
    /// ...略...
    s->internal->first_packet = 0;
    /*     * Check to see if we were changed into a different method, if     * so, revert back if we are not doing session-id reuse.     */    if (!s->internal->in_handshake && (s->session == NULL) &&        (s->method != s->ctx->method)) { /////// [1]        s->method->ssl_free(s);          /////// [2]        s->method = s->ctx->method;        if (!s->method->ssl_new(s))      /////// [3]            return (0);    } else        s->method->ssl_clear(s);
    return (1);}

在重置SSL结构体对象时，如果我们创造条件满足[1]处，能够使程序代码运行到[3]处，从而有机会使得sk_X509_pop_free(s->internal->verified_chain, X509_free)执行两次。留意到，在[2]处已经有一次对ssl_free指向的函数的调用，以及[3]处的ssl_new指向的函数的一次调用。

3.3 ssl3_new函数

先看看ssl3_new函数：

intssl3_new(SSL *s){    if ((s->s3 = calloc(1, sizeof(*s->s3))) == NULL)        return (0);
    s->method->ssl_clear(s);    /////// [1]
    return (1);}

留意[1]处。

3.4 ssl3_clear函数

还有，ssl3_clear函数的源代码：

voidssl3_clear(SSL *s){    unsigned char *rp, *wp;    size_t rlen, wlen;
    tls1_cleanup_key_block(s);    sk_X509_NAME_pop_free(s->s3->hs.tls12.ca_names, X509_NAME_free);    sk_X509_pop_free(s->internal->verified_chain, X509_free);   ///////// [1]    s->internal->verified_chain = NULL;
    freezero(s->s3->hs.sigalgs, s->s3->hs.sigalgs_len);    s->s3->hs.sigalgs = NULL;    s->s3->hs.sigalgs_len = 0;
    /// ...略...
    memset(s->s3, 0, sizeof(*s->s3));
    s->s3->rbuf.buf = rp;
    /// ...略...
    s->s3->hs.state = SSL_ST_BEFORE|((s->server) ? SSL_ST_ACCEPT : SSL_ST_CONNECT);}

观察[1]处的代码。

3.5 触发过程

如果我们能先后触发ssl3_free和ssl3_new，那么也就能触发该漏洞。

• 创建SSL需要的上下文环境；

• 调用SSL_connect函数，使得SSL连接返回证书链;

• 然后使用SSL_shutdown函数关闭该SSL连接;

• 接下来调用TLSv1_method函数，以返回一个新的SSL_METHOD指针（和第一次使用SSL_CTX_new函数创建SSL_CTX变量时传入的参数不同）;

• 调用SSL_set_ssl_method函数，其第二个参数为上一步返回的新SSL_METHOD指针；

• 正常释放相关资源。

• 使用TLSv1_method函数的原因

我们看一下TLSv1_method函数的相关代码：

// ssl_methods.cconst SSL_METHOD *TLSv1_method(void){    return (&TLSv1_method_data);}
// ...
static const SSL_METHOD TLSv1_method_data = {    .dtls = 0,    .server = 1,    .version = TLS1_VERSION,    .min_tls_version = TLS1_VERSION,    .max_tls_version = TLS1_VERSION,    .ssl_new = tls1_new,    .ssl_clear = tls1_clear,    .ssl_free = tls1_free,  /////// [1]    .ssl_accept = ssl3_accept,    .ssl_connect = ssl3_connect,    .ssl_shutdown = ssl3_shutdown,    /// ...略...    .enc_flags = TLSV1_ENC_FLAGS,};

能够看到，此时，ssl_free函数其实指向了tls1_free函数，而tls1_free函数内部调用了ssl3_free。

// t1_lib.cvoidtls1_free(SSL *s){    if (s == NULL)        return;
    free(s->internal->tlsext_session_ticket);    ssl3_free(s);   /////// [1]}

我们再来看一下SSL_set_ssl_method函数：

intSSL_set_ssl_method(SSL *s, const SSL_METHOD *method){    int (*handshake_func)(SSL *) = NULL;    int ret = 1;
    if (s->method == method)        return (ret);
    if (s->internal->handshake_func == s->method->ssl_connect)        handshake_func = method->ssl_connect;    else if (s->internal->handshake_func == s->method->ssl_accept)        handshake_func = method->ssl_accept;
    if (s->method->version == method->version) { //// [1]        s->method = method;    } else {        s->method->ssl_free(s);                  //// [2]        s->method = method;                      //// [3]        ret = s->method->ssl_new(s);             //// [4]    }    s->internal->handshake_func = handshake_func;
    return (ret);}

我们使用TLSv1_method函数返回的method->version故意不等于s->method->version，从而导致[2]的执行，而此时的s->method->ssl_free的值为tls1_free，且运行到[4]处时，s->method->ssl_new的值为tls1_new：

根据tls1_free函数的代码，它会调用ssl3_free一次，而ssl3_free内部会执行一次sk_X509_pop_free(s->internal->verified_chain, X509_free)，导致s->internal->verified_chain被释放。

当程序执行到SSL_set_ssl_method内的[4]处时，会调用tls1_new函数。

我们再来看一下tls1_new的代码：

inttls1_new(SSL *s){    if (!ssl3_new(s))        ///// [1]        return (0);    s->method->ssl_clear(s);    return (1);}

可以看到，无论如何，[1]处的ssl3_new函数都会执行，而ssl3_new内部会调用s->method->ssl_clear，此时的s->method->ssl_clear指向tls1_clear函数，tls1_clear函数的实现如下：

voidtls1_clear(SSL *s){    ssl3_clear(s);      /////// [1]    s->version = s->method->version;}

注意到tls1_clear内部会调用ssl3_clear，而ssl3_clear内部一定会执行sk_X509_pop_free(s->internal->verified_chain, X509_free)语句，从而导致s->internal->verified_chain被再次释放。在调试器中的崩溃如下图：

四、漏洞修复

4.1 对于3.6.3

对于3.6.3版，官方直接在ssl3_free函数里把s->internal->verified_chain赋值为NULL：

// ssl3_free(SSL *s)    sk_X509_pop_free(s->internal->verified_chain, X509_free); /////// [1]    s->internal->verified_chain = NULL;                       /////// [2]

4.2 最新版本3.9.2

在分析打过补丁后的较新版本时，会发现ssl3_free函数没有了3.6.3版时把verified_chain赋值为NULL的语句，比如最新版3.9.2的：

voidssl3_free(SSL *s){    if (s == NULL)        return;
    tls1_cleanup_key_block(s);    ssl3_release_read_buffer(s);    ssl3_release_write_buffer(s);
    /// ...略...
    sk_X509_pop_free(s->s3->hs.peer_certs, X509_free);    sk_X509_pop_free(s->s3->hs.peer_certs_no_leaf, X509_free);    sk_X509_pop_free(s->s3->hs.verified_chain, X509_free); /////// [1]    tls_key_share_free(s->s3->hs.key_share);
    /// ...略...
    freezero(s->s3->peer_quic_transport_params,        s->s3->peer_quic_transport_params_len);
    freezero(s->s3, sizeof(*s->s3));     /////// [2]
    s->s3 = NULL;}

同时，留意[2]处的freezero函数。 

原因在于结构体定义的变化，从sk_X509_pop_free宏的第一参数可以看出一些端倪：

sk_X509_pop_free(s->s3->hs.verified_chain, X509_free);

该版本几个相关结构体的定义如下：

// 3.9.2struct ssl_st {    /* protocol version     * (one of SSL2_VERSION, SSL3_VERSION, TLS1_VERSION, DTLS1_VERSION)     */    int version;
    const SSL_METHOD *method;    /// ...略...    int server; /* are we the server side? - mostly used by SSL_clear*/
    struct ssl3_state_st *s3; /* SSLv3 variables */    /////// [1]    struct dtls1_state_st *d1; /* DTLSv1 variables */    /// ...略...};
typedef struct ssl3_state_st {    long flags;
    unsigned char server_random[SSL3_RANDOM_SIZE];    /// ...略...    int in_read_app_data;
    SSL_HANDSHAKE hs;                                  /////// [2]    /// ...略...} SSL3_STATE;

以及ssl_handshake_st：

typedef struct ssl_handshake_st {    /*     * Minimum and maximum versions supported for this handshake. These are     * initialised at the start of a handshake based on the method in use     * and the current protocol version configuration.     */    uint16_t our_min_tls_version;    /// ...略...
    /* Certificate chain resulting from X.509 verification. */    STACK_OF(X509) *verified_chain;                    /////// [1]
    SSL_HANDSHAKE_TLS12 tls12;    SSL_HANDSHAKE_TLS13 tls13;} SSL_HANDSHAKE;

可以看到在[2]处的hs是一个SSL_HANDSHAKE类型的结构体成员变量。ssl3_free函数里的freezero函数会把s->s3的堆空间的内容全部设置为零，查看freezero函数及其内部的explicit_bzero的代码即可得知。

• freezero函数和explicit_bzero函数

// freezero.cvoidfreezero(void *ptr, size_t sz){    /* This is legal. */    if (ptr == NULL)        return;
    explicit_bzero(ptr, sz);    free(ptr);}
// explicit_bzero.cvoidexplicit_bzero(void *buf, size_t len){    memset(buf, 0, len);               /////// [1]    __explicit_bzero_hook(buf, len);}

这样，[1]处的memset函数会导致s->s3->hs.verified_chain被赋值为NULL，从而在sk_pop_free函数[1]处时即返回，进而避免了漏洞的发生。

参考链接：

[1]https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/026_ssl.patch.sig

[2]https://www.cvedetails.com/cve/CVE-2023-35784/

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

启明星辰集团荣获CNNVD两项大奖，彰显技术支撑与漏洞贡献实力

被CNNVD授予“2023年度优秀技术支撑单位”和“2023年度高质量漏洞优秀贡献单位”两项殊荣。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

6月18日，国家信息安全漏洞库（CNNVD）2023年度工作总结暨优秀表彰大会在中国信息安全测评中心隆重举行。启明星辰集团借卓越的技术实力以及在高质量漏洞报送等方面的突出贡献，在260多家技术支撑单位中脱颖而出，荣获“2023年度优秀技术支撑单位”和“2023年度高质量漏洞优秀贡献单位”两项殊荣。

自2013年首批获得国家信息安全漏洞库(CNNVD)技术支撑单位（一级）起，启明星辰集团至今已连续11年获得“年度优秀技术支撑单位”荣誉，并在2023年CNNVD开展的网络安全漏洞消控专项工作中，充分发挥了网络安全漏洞分析和预警消控领域的专业技术水平，为专项工作成功开展提供了坚实支撑。

多年来，启明星辰集团积极履行其作为CNNVD技术支撑单位的职责，包括重要漏洞信息报送、原创漏洞报送、漏洞发现、漏洞处置支撑、漏洞和安全事件预警信息共享及安全研究报告共享等任务。通过远程和现场支撑等方式，集团积极配合CNNVD相关漏洞预警和应急响应支撑工作，为提升国家网络安全漏洞治理体系和信息安全保障发挥了重要作用。

启明星辰积极防御实验室（ADLab）成立于1999年，是国内最早的攻防技术研究团队之一，拥有卓越的安全技术研究和安全攻防实力，在基础安全、数据安全、5G安全、人工智能安全、移动安全、物联网安全、车联网安全、工控安全、信创安全、云安全、无线安全、高级威胁、攻防体系建设等领域均有前瞻性技术研究成果，以攻促防带动重要网络信息系统安全防御能力的提升，推动安全行业的不断发展。

在原创漏洞挖掘方面，ADLab的表现尤为突出。截至目前，已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，并持续多年荣获优秀技术支撑单位、原创漏洞发现突出贡献单位、漏洞信息报送贡献单位、漏洞处置突出贡献单位等荣誉，持续多年多名成员多次入选微软“MSRC全球Top100最具价值研究者”等国际榜单，团队攻防技术研究实力和专业性在全球范围内获得高度认可。

此次获奖，不仅是对启明星辰集团长期坚持高质量漏洞报送、积极推动国家级网络安全漏洞综合运筹能力建设的肯定，更是对其技术实力和专业精神的高度认可。未来，启明星辰集团将继续发挥技术支撑单位的作用，深化技术研究，拓展服务边界，不断提升信息安全防护能力，为构建安全可信的信息环境贡献更多力量。

•

END

•

启明星辰积极防御实验室（ADLab）

ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞5000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、数据安全研究、5G安全研究、人工智能安全研究、移动安全研究、物联网安全研究、车联网安全研究、工控安全研究、信创安全研究、云安全研究、无线安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。

2024年6月6日，PHP官方发布了多个新版本，其中都包含对编号为CVE-2024-4577的安全漏洞的修复更新。该漏洞是PHP CGI的参数注入漏洞，是对CVE-2012-1823漏洞的修复绕过。

更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）

一、漏洞描述

2024年6月6日，PHP官方发布了多个新版本，其中都包含对编号为CVE-2024-4577的安全漏洞的修复更新。该漏洞是PHP CGI的参数注入漏洞，是对CVE-2012-1823漏洞的修复绕过。

该漏洞产生的原因是：在PHP CGI模式下，未正确处理Windows系统中的“Best-Fit Mapping”特性，导致简体中文、繁体中文、日文或其他受影响语言环境将某些字符错误的识别成了'-'。攻击者可通过引入恶意参数实现任意代码执行。

二、漏洞复现

如下图所示：

三、漏洞分析

CVE-2012-1823补丁的修复措施是，PHP处理传递进来的字符串时，在跳过前面空白符后，判断第一位是否是'-'；如果是'-'，就不对后面的字符进行参数解析，比如-d,-s,-c等参数。

PHP官方的commit如下图所示：

可以看到，当运行系统环境为Windows时，PHP调用WideCharToMultiByte函数来加强对宽字符的判断。如果转换后的字符为'-'，则将skip_getopt置为1，使得后续就不会对传入的字符串进行参数解析。

那么，什么样的宽字符能够转换后变成'-'，从而绕过之前的修复呢？

以受影响的简体中文、繁体中文、日文举例，他们对应的Windows 代码页分别是936、950、932。其中都有将0x00ad映射为0x002d的操作，如下图所示：

因此通过引入0x00ad即可替代0x002d，实现参数注入来执行任意代码。

四、总结

CVE-2024-4577漏洞利用简单，危害严重。特别在某些对Apache、PHP进行集成部署和管理的流行软件中，如果未正确配置php cgi，即可造成严重危害。