佰才邦应急记录
<!--kg-card-begin: markdown--><h1 id="">综述</h1>
<h1 id="">缘起</h1>
<h1 id="">涉事现象</h1>
<p>据苦主介绍，他们销售的一些设备于近日出现故障，系统无法正常登录，及操作配置。怀疑系统命令被删除。故障截图如下：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/problem-1.png" alt="problem-1" loading="lazy"></p>
<p>正常情况下 start-shell 后会启动一个 Shell 控制台供管理员管理基站，但受害后，则无法进入控制台。</p>
<p>在随后的跟进中，我们还发现，受害机器的80端口也无法正常使用，报错如下图所示：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/http_problem.png" alt="http_problem" loading="lazy"></p>
<p>这个截图显示，haserl 命令也无法执行，在涉事基站的管理中这是一个重要的命令。</p>
<p>基于以上了解，我方需要苦主，提供以下资料：</p>
<ol>
<li>一个全部瘫痪设备的IP list。用于评估影响范围。</li>
<li>受害前后的文件系统，用于对比，实现攻击路径回溯。</li>
<li>一个在线的测试环境，用于验证发现，固化结论。</li>
</ol>
<p>基于以上信息，我们开始对该事件进行调查。</p>
<h1 id="">初步线索</h1>
<p>拿到受害后文件系统后，我们快速的远程过了一遍，在 web 服务根目录下发现可疑文件hoho.arm7，事后证明，该文件是一条重要的线索，如下图所示：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/first_hoho_sample.png" alt="first_hoho_sample" loading="lazy"></p>
<p>但该文件的植入方式，在文件系统中并没有日志留存，基于苦主的资料很难继续还原攻击者实际的进入途径。</p>
<p>但在本部门的图系统中，我们惊喜的发现：该样本竟于2天前被我们自有的 Anglerfish 蜜罐系统捕获（该样本并未出现在VT中）。系统显示，这是一个基于 Telnet 服务传播的MIRAI变种样本。如下图所示：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/hoho_graph.png" alt="hoho_graph" loading="lazy"></p>
<p>但是该样本也让我们产生了新的困惑：</p>
<p>一方面，受害系统并没有开放telnet服务。 但另一方面，系统显示样本确实是通过 Telnet弱口令扫描传播的，样本本身也具有telnet弱口令扫描的能力；同时，样本中并没有除telnet以外其他的传播能力，即不会通过其他服务传播。</p>
<p>这就意味着，以下几种可能：</p>
<ol>
<li>系统可能会在某些条件下自发打开telnet服务；</li>
<li>系统中还拥有其他未知漏洞，能够启动 telnet 服务。</li>
<li>系统中可能还有其他未知漏洞，可以植入hoho样本；</li>
</ol>
<p>（PS： 2 和 3 的区别在于，3 对应的是一个通用漏洞，可以执行系统命令；而 2 则对应着是一个只能启动 telnet 服务而无法执行其他操作的漏洞。从攻击效果上看，2 应该是 3 的一个子集。）</p>
<p>基于以上可能性，我们将调查集中到三个方向：</p>
<ol>
<li>围绕 telnet 服务展开调查；</li>
<li>汇总设备暴露在外的攻击面，挖掘潜在可能存在漏洞的服务。</li>
<li>虽然 hoho.arm7 出现在现场，但不代表这个坏事就是它干的，需要证据。</li>
</ol>
<h1 id="">确定调查方向</h1>
<p>基于可能性：我们首先将关注点集中在 telnet服务 上，重新调查文件系统中各文件，最终得到以下事实：</p>
<ol>
<li>/bin/busybox 包含了telnetd 命令，链接位置 /usr/sbin/telnetd。</li>
<li>/bin/prepare.sh 中有加系统账号的代码，在 /etc/inittab 中引用执行，如果telnet被启动，就可以通过这里的账号密码进行登录。</li>
<li>/etc/init.d  和 /etc/rc.d/ 目录有 telnetd 的启动服务配置文件。telnet可以通过启动服务的方式启动。</li>
</ol>
<p>但我们并没有发现，telnetd 可以关联到其他进程或服务上。至此，可能性1基本排除。攻击者只能通过漏洞，进入系统。下一步就是判断设备暴漏出的攻击面。</p>
<p>在二次调查中，我们一共获知了以下几条线索（从涉事固件/苦主访谈/蜜罐数据/样本分析等维度）：</p>
<ol>
<li>受害设备中 /bin/busybox 执行权限被清除，所以感染后涉及到 busybox 的命令，均无法执行（佰才邦的同事们也验证了了这个线索）。</li>
<li>hoho.arm7 样本运行后，会将 &quot;/sbin/reboot&quot; &quot;/sbin/poweroff&quot; &quot;/sbin/halt&quot; 三个文件的权限清零，而这三个文件均链接到 busybox，这同受害设备中看到的现象完全吻合。</li>
<li>我们从蜜罐中拿到了hoho投递时的完整 payload，同涉事设备完全吻合。</li>
<li>/www-nui/ 目录中有 http（80）/https（443）服务 调用 haserl 的代码。且 hoho.arm7 文件也出现在该目录。</li>
<li>设备会开放 tr069 服务，绑定端口tcp-7547/udp-6016 （from:群成员-丹丹）。</li>
<li>hoho.arm7 的主控地址，为：<code>45.153.203.120</code></li>
</ol>
<p>结合以上线索，我们得到如下推论/结论：</p>
<p>线索 1-3 ，可以把 “本次事件”和“hoho.arm7样本”两个事情严格的关联在一起。“hoho.arm7” 相关的所有内容，都可以作为本次事件的关键线索。</p>
<p>线索 4 意味着 http/https 相关服务是设备暴露出来的一个攻击面，此时其根目录的 “hoho.arm7”样本则格外的显眼，似乎正在诉说着：“此处有漏洞，快来挖吧～”。</p>
<p>线索 5 中 tr069服务 是我们在以往和 MIRAI 对抗中，经常遇到的一个攻击点，它出现在多种 MIRAI 分支的传播中，同样也是一个可疑度很高的攻击面。</p>
<p>至此，我们将后续的调查范围约束为两个方向：</p>
<ol>
<li>调查 http/https 相关代码是否具有漏洞。</li>
<li>调查 tr069 是否存在漏洞。</li>
</ol>
<p><strong>本小节附带截图</strong></p>
<p>以上线索中，大部分线索不容易截图，这里仅把线索2 和线索3 的截图附在这里，以供参考。</p>
<p>下图是我们从自有蜜罐中看到的用于投递 hoho.arm7 的报文内容，</p>
<p><img src="__GHOST_URL__/content/images/2020/12/hoho_from_sandbox.png" alt="hoho_from_sandbox" loading="lazy"></p>
<p>可以看到，口令：<code>admin/admin</code>， 命令： <code>enable</code> 和 <code>start-shell</code> 均可以同涉事设备相对应，这条记录此时正在投递 hoho.arm7（c626b3c0390d03d822aa25388bb12b25）。</p>
<p>下一个截图则是我们内部关于busybox 权限清除原因的讨论截图：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/talk_about_busybox.png" alt="talk_about_busybox" loading="lazy"></p>
<p>在截图下方，我们通过逆向分析获知 <code>hoho.arm7</code> 可以清除一些系统命令的执行权限，而在截图上方，我们可以看到这几个系统命令最终都会链接到 busybox。也就是说，busybox执行权限被清零的原因正是 <code>hoho.arm7</code> 中这几行代码导致的。</p>
<h1 id="http">HTTP服务中存在漏洞的证明</h1>
<p>在随后的调查阶段，我们终于在 HTTP 相关代码中发现一处 RCE 漏洞，该漏洞无需后台登录，即可实现任意命令执行。并迅速同苦主沟通了 payload 的具体细节，下图是沟通过程中的一张截图：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/share_exploit.png" alt="share_exploit" loading="lazy"></p>
<p>并在苦主任意指出一个测试环境后，完成了远程验证。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/exploit_success.png" alt="exploit_success" loading="lazy"></p>
<p>至此，我们已经证明HTTP服务中确实存在漏洞，且该漏洞能够执行系统命令，包括开启 telnet 服务。</p>
<h1 id="">利用捕获</h1>
<p>通过修改蜜罐，我们在随后的一天中捕获了相同位置的漏洞利用代码，这次传播的是一个名为 yamaha.arm 的MIRAI变种。蜜罐日志如下所示：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/catch_wild_exploit.png" alt="catch_wild_exploit" loading="lazy"></p>
<p>通过对这个 Exploit 分析我们发现，HTTP报文头部有时间戳<code>1608466780</code> 是北京时间<code>2020/12/20 20:19:40</code> 这正是苦主找到我们的头一天。</p>
<p>所以，本次 yamaha.arm 投递可以得到如下线索：</p>
<ol>
<li>POC生成时间早于启动调查时间。</li>
<li>yamaha.arm 的CC地址为 45.153.203.121，同 hoho.arm7 的地址（45.153.203.120）连续。</li>
</ol>
<h1 id="">涉事样本的详细分析</h1>
<h1 id="">后期处置</h1>
<p>基于以上事实，我们给出了两个处置建议：</p>
<ol>
<li>在新版本发布时，关闭HTTP服务，等源码审查结束，再考虑是否重新打开。</li>
<li>对HTTP服务中部分URL的访问增加鉴权处理。</li>
</ol>
<p>随后厂商给出了他们在新版本中的修复tips：</p>
<p><img src="__GHOST_URL__/content/images/2020/12/try_fix_vuln.png" alt="try_fix_vuln" loading="lazy"></p>
<p>于此同时，我们也在试图联系国外相关机构，对恶意主控IP执行短期阻断。以免在修复期间攻击者通过发布DDos攻击指令危害公网安全。</p>
<!--kg-card-end: markdown-->
综述



缘起



涉事现象


据苦主介绍，他们销售的一些设备于近日出现故障，系统无法正常登录，及操作配置。怀疑系统命令被删除。故障截图如下：





正常情况下 start-shell 后会启动一个 Shell 控制台供管理员管理基站，但受害后，则无法进入控制台。


在随后的跟进中，我们还发现，受害机器的80端口也无法正常使用，报错如下图所示：





这个截图显示，haserl 命令也无法执行，在涉事基站的管理中这是一个重要的命令。


基于以上了解，我方需要苦主，提供以下资料：


 1. 一个全部瘫痪设备的IP list。用于评估影响范围。
 2. 受害前后的文件系统，用于对比，实现攻击路径回溯。
 3. 一个在线的测试环境，用于验证发现，固化结论。


基于以上信息，我们开始对该事件进行调查。



初步线索


拿到受害后文件系统后，我们快速的远程过了一遍，在 web 服务根目录下发现可疑文件hoho.arm7，事后证明，该文件是一条重要的线索，如下图所示：





但该文件的植入方式，在文件系统中并没有日志留存，基于苦主的资料很难继续还原攻击者实际的进入途径。


但在本部门的图系统中，我们惊喜的发现：该样本竟于2天前被我们自有的 Anglerfish 蜜罐系统捕获（该样本并未出现在VT中）。系统显示，这是一个基于 Telnet 服务传播的MIRAI变种样本。如下图所示：





但是该样本也让我们产生了新的困惑：


一方面，受害系统并没有开放telnet服务。 但另一方面，系统显示样本确实是通过 Telnet弱口令扫描传播的，样本本身也具有telnet弱口令扫描的能力；同时，样本中并没有除telnet以外其他的传播能力，即不会通过其他服务传播。


这就意味着，以下几种可能：


 1. 系统可能会在某些条件下自发打开telnet服务；
 2. 系统中还拥有其他未知漏洞，能够启动 telnet 服务。
 3. 系统中可能还有其他未知漏洞，可以植入hoho样本；


（PS： 2 和 3 的区别在于，3 对应的是一个通用漏洞，可以执行系统命令；而 2 则对应着是一个只能启动 telnet 服务而无法执行其他操作的漏洞。从攻击效果上看，2 应该是 3 的一个子集。）


基于以上可能性，我们将调查集中到三个方向：


 1. 围绕 telnet 服务展开调查；
 2. 汇总设备暴露在外的攻击面，挖掘潜在可能存在漏洞的服务。
 3. 虽然 hoho.arm7 出现在现场，但不代表这个坏事就是它干的，需要证据。



确定调查方向


基于可能性：我们首先将关注点集中在 telnet服务 上，重新调查文件系统中各文件，最终得到以下事实：


 1. /bin/busybox 包含了telnetd 命令，链接位置 /usr/sbin/telnetd。
 2. /bin/prepare.sh 中有加系统账号的代码，在 /etc/inittab 中引用执行，如果telnet被启动，就可以通过这里的账号密码进行登录。
 3. /etc/init.d 和 /etc/rc.d/ 目录有 telnetd 的启动服务配置文件。telnet可以通过启动服务的方式启动。


但我们并没有发现，telnetd 可以关联到其他进程或服务上。至此，可能性1基本排除。攻击者只能通过漏洞，进入系统。下一步就是判断设备暴漏出的攻击面。


在二次调查中，我们一共获知了以下几条线索（从涉事固件/苦主访谈/蜜罐数据/样本分析等维度）：


 1. 受害设备中 /bin/busybox 执行权限被清除，所以感染后涉及到 busybox 的命令，均无法执行（佰才邦的同事们也验证了了这个线索）。
 2. hoho.arm7 样本运行后，会将 "/sbin/reboot" "/sbin/poweroff" "/sbin/halt" 三个文件的权限清零，而这三个文件均链接到 busybox，这同受害设备中看到的现象完全吻合。
 3. 我们从蜜罐中拿到了hoho投递时的完整 payload，同涉事设备完全吻合。
 4. /www-nui/ 目录中有 http（80）/https（443）服务 调用 haserl 的代码。且 hoho.arm7 文件也出现在该目录。
 5. 设备会开放 tr069 服务，绑定端口tcp-7547/udp-6016 （from:群成员-丹丹）。
 6. hoho.arm7 的主控地址，为：45.153.203.120


结合以上线索，我们得到如下推论/结论：


线索 1-3 ，可以把 “本次事件”和“hoho.arm7样本”两个事情严格的关联在一起。“hoho.arm7” 相关的所有内容，都可以作为本次事件的关键线索。


线索 4 意味着 http/https 相关服务是设备暴露出来的一个攻击面，此时其根目录的 “hoho.arm7”样本则格外的显眼，似乎正在诉说着：“此处有漏洞，快来挖吧～”。


线索 5 中 tr069服务 是我们在以往和 MIRAI 对抗中，经常遇到的一个攻击点，它出现在多种 MIRAI 分支的传播中，同样也是一个可疑度很高的攻击面。


至此，我们将后续的调查范围约束为两个方向：


 1. 调查 http/https 相关代码是否具有漏洞。
 2. 调查 tr069 是否存在漏洞。


本小节附带截图


以上线索中，大部分线索不容易截图，这里仅把线索2 和线索3 的截图附在这里，以供参考。


下图是我们从自有蜜罐中看到的用于投递 hoho.arm7 的报文内容，





可以看到，口令：admin/admin， 命令： enable 和 start-shell 均可以同涉事设备相对应，这条记录此时正在投递 hoho.arm7（c626b3c0390d03d822aa25388bb12b25）。


下一个截图则是我们内部关于busybox 权限清除原因的讨论截图：





在截图下方，我们通过逆向分析获知 hoho.arm7 可以清除一些系统命令的执行权限，而在截图上方，我们可以看到这几个系统命令最终都会链接到 busybox。也就是说，busybox执行权限被清零的原因正是 hoho.arm7 中这几行代码导致的。



HTTP服务中存在漏洞的证明


在随后的调查阶段，我们终于在 HTTP 相关代码中发现一处 RCE 漏洞，该漏洞无需后台登录，即可实现任意命令执行。并迅速同苦主沟通了 payload 的具体细节，下图是沟通过程中的一张截图：





并在苦主任意指出一个测试环境后，完成了远程验证。





至此，我们已经证明HTTP服务中确实存在漏洞，且该漏洞能够执行系统命令，包括开启 telnet 服务。



利用捕获


通过修改蜜罐，我们在随后的一天中捕获了相同位置的漏洞利用代码，这次传播的是一个名为 yamaha.arm 的MIRAI变种。蜜罐日志如下所示：





通过对这个 Exploit 分析我们发现，HTTP报文头部有时间戳1608466780 是北京时间2020/12/20 20:19:40 这正是苦主找到我们的头一天。


所以，本次 yamaha.arm 投递可以得到如下线索：


 1. POC生成时间早于启动调查时间。
 2. yamaha.arm 的CC地址为 45.153.203.121，同 hoho.arm7 的地址（45.153.203.120）连续。



涉事样本的详细分析



后期处置


基于以上事实，我们给出了两个处置建议：


 1. 在新版本发布时，关闭HTTP服务，等源码审查结束，再考虑是否重新打开。
 2. 对HTTP服务中部分URL的访问增加鉴权处理。


随后厂商给出了他们在新版本中的修复tips：





于此同时，我们也在试图联系国外相关机构，对恶意主控IP执行短期阻断。以免在修复期间攻击者通过发布DDos攻击指令危害公网安全。

{"version":"0.3.1","atoms":[],"cards":[["markdown",{"markdown":"# 综述\n# 缘起\n\n# 涉事现象\n\n据苦主介绍，他们销售的一些设备于近日出现故障，系统无法正常登录，及操作配置。怀疑系统命令被删除。故障截图如下：\n\n![problem-1](__GHOST_URL__/content/images/2020/12/problem-1.png)\n\n正常情况下 start-shell 后会启动一个 Shell 控制台供管理员管理基站，但受害后，则无法进入控制台。\n\n在随后的跟进中，我们还发现，受害机器的80端口也无法正常使用，报错如下图所示：\n\n![http_problem](__GHOST_URL__/content/images/2020/12/http_problem.png)\n\n这个截图显示，haserl 命令也无法执行，在涉事基站的管理中这是一个重要的命令。\n\n基于以上了解，我方需要苦主，提供以下资料：\n\n1. 一个全部瘫痪设备的IP list。用于评估影响范围。\n2. 受害前后的文件系统，用于对比，实现攻击路径回溯。\n3. 一个在线的测试环境，用于验证发现，固化结论。\n\n基于以上信息，我们开始对该事件进行调查。\n\n# 初步线索\n\n拿到受害后文件系统后，我们快速的远程过了一遍，在 web 服务根目录下发现可疑文件hoho.arm7，事后证明，该文件是一条重要的线索，如下图所示：\n\n![first_hoho_sample](__GHOST_URL__/content/images/2020/12/first_hoho_sample.png)\n\n但该文件的植入方式，在文件系统中并没有日志留存，基于苦主的资料很难继续还原攻击者实际的进入途径。\n\n但在本部门的图系统中，我们惊喜的发现：该样本竟于2天前被我们自有的 Anglerfish 蜜罐系统捕获（该样本并未出现在VT中）。系统显示，这是一个基于 Telnet 服务传播的MIRAI变种样本。如下图所示：\n\n![hoho_graph](__GHOST_URL__/content/images/2020/12/hoho_graph.png)\n\n但是该样本也让我们产生了新的困惑：\n\n一方面，受害系统并没有开放telnet服务。 但另一方面，系统显示样本确实是通过 Telnet弱口令扫描传播的，样本本身也具有telnet弱口令扫描的能力；同时，样本中并没有除telnet以外其他的传播能力，即不会通过其他服务传播。\n\n这就意味着，以下几种可能：\n\n1. 系统可能会在某些条件下自发打开telnet服务；\n2. 系统中还拥有其他未知漏洞，能够启动 telnet 服务。\n3. 系统中可能还有其他未知漏洞，可以植入hoho样本；\n\n（PS： 2 和 3 的区别在于，3 对应的是一个通用漏洞，可以执行系统命令；而 2 则对应着是一个只能启动 telnet 服务而无法执行其他操作的漏洞。从攻击效果上看，2 应该是 3 的一个子集。）\n\n基于以上可能性，我们将调查集中到三个方向：\n\n1. 围绕 telnet 服务展开调查；\n2. 汇总设备暴露在外的攻击面，挖掘潜在可能存在漏洞的服务。\n3. 虽然 hoho.arm7 出现在现场，但不代表这个坏事就是它干的，需要证据。\n\n\n# 确定调查方向\n\n基于可能性：我们首先将关注点集中在 telnet服务 上，重新调查文件系统中各文件，最终得到以下事实：\n\n1. /bin/busybox 包含了telnetd 命令，链接位置 /usr/sbin/telnetd。\n2. /bin/prepare.sh 中有加系统账号的代码，在 /etc/inittab 中引用执行，如果telnet被启动，就可以通过这里的账号密码进行登录。\n3. /etc/init.d  和 /etc/rc.d/ 目录有 telnetd 的启动服务配置文件。telnet可以通过启动服务的方式启动。\n\n但我们并没有发现，telnetd 可以关联到其他进程或服务上。至此，可能性1基本排除。攻击者只能通过漏洞，进入系统。下一步就是判断设备暴漏出的攻击面。\n\n在二次调查中，我们一共获知了以下几条线索（从涉事固件/苦主访谈/蜜罐数据/样本分析等维度）：\n\n1. 受害设备中 /bin/busybox 执行权限被清除，所以感染后涉及到 busybox 的命令，均无法执行（佰才邦的同事们也验证了了这个线索）。\n2. hoho.arm7 样本运行后，会将 \"/sbin/reboot\" \"/sbin/poweroff\" \"/sbin/halt\" 三个文件的权限清零，而这三个文件均链接到 busybox，这同受害设备中看到的现象完全吻合。\n3. 我们从蜜罐中拿到了hoho投递时的完整 payload，同涉事设备完全吻合。\n4. /www-nui/ 目录中有 http（80）/https（443）服务 调用 haserl 的代码。且 hoho.arm7 文件也出现在该目录。\n5. 设备会开放 tr069 服务，绑定端口tcp-7547/udp-6016 （from:群成员-丹丹）。\n6. hoho.arm7 的主控地址，为：`45.153.203.120`\n\n结合以上线索，我们得到如下推论/结论：\n\n线索 1-3 ，可以把 “本次事件”和“hoho.arm7样本”两个事情严格的关联在一起。“hoho.arm7” 相关的所有内容，都可以作为本次事件的关键线索。 \n\n线索 4 意味着 http/https 相关服务是设备暴露出来的一个攻击面，此时其根目录的 “hoho.arm7”样本则格外的显眼，似乎正在诉说着：“此处有漏洞，快来挖吧～”。\n\n线索 5 中 tr069服务 是我们在以往和 MIRAI 对抗中，经常遇到的一个攻击点，它出现在多种 MIRAI 分支的传播中，同样也是一个可疑度很高的攻击面。\n\n至此，我们将后续的调查范围约束为两个方向：\n\n1. 调查 http/https 相关代码是否具有漏洞。\n2. 调查 tr069 是否存在漏洞。\n\n**本小节附带截图**\n\n以上线索中，大部分线索不容易截图，这里仅把线索2 和线索3 的截图附在这里，以供参考。\n\n下图是我们从自有蜜罐中看到的用于投递 hoho.arm7 的报文内容，\n\n![hoho_from_sandbox](__GHOST_URL__/content/images/2020/12/hoho_from_sandbox.png)\n\n可以看到，口令：`admin/admin`， 命令： `enable` 和 `start-shell` 均可以同涉事设备相对应，这条记录此时正在投递 hoho.arm7（c626b3c0390d03d822aa25388bb12b25）。\n\n下一个截图则是我们内部关于busybox 权限清除原因的讨论截图：\n\n![talk_about_busybox](__GHOST_URL__/content/images/2020/12/talk_about_busybox.png)\n\n在截图下方，我们通过逆向分析获知 `hoho.arm7` 可以清除一些系统命令的执行权限，而在截图上方，我们可以看到这几个系统命令最终都会链接到 busybox。也就是说，busybox执行权限被清零的原因正是 `hoho.arm7` 中这几行代码导致的。\n\n\n\n# HTTP服务中存在漏洞的证明\n\n在随后的调查阶段，我们终于在 HTTP 相关代码中发现一处 RCE 漏洞，该漏洞无需后台登录，即可实现任意命令执行。并迅速同苦主沟通了 payload 的具体细节，下图是沟通过程中的一张截图：\n\n![share_exploit](__GHOST_URL__/content/images/2020/12/share_exploit.png)\n\n并在苦主任意指出一个测试环境后，完成了远程验证。\n\n![exploit_success](__GHOST_URL__/content/images/2020/12/exploit_success.png)\n\n至此，我们已经证明HTTP服务中确实存在漏洞，且该漏洞能够执行系统命令，包括开启 telnet 服务。\n\n# 利用捕获\n\n通过修改蜜罐，我们在随后的一天中捕获了相同位置的漏洞利用代码，这次传播的是一个名为 yamaha.arm 的MIRAI变种。蜜罐日志如下所示：\n\n![catch_wild_exploit](__GHOST_URL__/content/images/2020/12/catch_wild_exploit.png)\n\n通过对这个 Exploit 分析我们发现，HTTP报文头部有时间戳`1608466780` 是北京时间`2020/12/20 20:19:40` 这正是苦主找到我们的头一天。\n\n所以，本次 yamaha.arm 投递可以得到如下线索：\n\n1. POC生成时间早于启动调查时间。\n2. yamaha.arm 的CC地址为 45.153.203.121，同 hoho.arm7 的地址（45.153.203.120）连续。\n\n# 涉事样本的详细分析\n\n# 后期处置\n基于以上事实，我们给出了两个处置建议：\n\n1. 在新版本发布时，关闭HTTP服务，等源码审查结束，再考虑是否重新打开。\n2. 对HTTP服务中部分URL的访问增加鉴权处理。\n\n随后厂商给出了他们在新版本中的修复tips：\n\n![try_fix_vuln](__GHOST_URL__/content/images/2020/12/try_fix_vuln.png)\n\n于此同时，我们也在试图联系国外相关机构，对恶意主控IP执行短期阻断。以免在修复期间攻击者通过发布DDos攻击指令危害公网安全。"}]],"markups":[],"sections":[[10,0],[1,"p",[]]],"ghostVersion":"3.0"}