德国电信断网：mirai僵尸网络的新变种和旧主控
<!--kg-card-begin: markdown--><p>【更新】</p>
<ol>
<li>2016-11-29 18:40:00 初始版本</li>
<li>2016-11-29 20:10:00 增加了对德国电信断网事件相关的描述</li>
</ol>
<h4 id="20161128">德国电信断网事件 2016-11-28</h4>
<p>德国电信在2016年11月28日前后遭遇一次大范围的网络故障。在这次故障中，2千万固定网络用户中的大约90万个路由器发生故障（约4.5%），并由此导致大面积网络访问受限。很多媒体给出了网络受限的示意图，如下。</p>
<p><img src="__GHOST_URL__/content/images/2016/11/telekom_network_issue_map.png" alt="" loading="lazy"></p>
<p>德国电信进一步确认了问题是由于路由设备的维护界面被暴露在互联网上、并且互联网上正在发生针对性的攻击而导致。德国电信连夜与设备供应商生成了新的升级包，并且要求客户如果怀疑受到影响就断电重启路由器，之后利用自动/手动的升级过程来减轻问题显然，德国电信还采取了一系列的过滤措施来保证升级过程不受攻击影响。德国电信对该事件给出了较为详细的描述。</p>
<p><a href="https://www.telekom.com/en/media/media-information/archive/information-on-current-problems-444862">https://www.telekom.com/en/media/media-information/archive/information-on-current-problems-444862</a></p>
<p><strong>按照360网络安全研究院对这次事件以及mirai僵尸网络的理解，这次事件前后的时间脉络如下</strong>（以下均为北京时间）：</p>
<ol>
<li>2016-11-07，kenzo发布了一个针对7547端口上路由器等设备的TR-069/TR-064相关的安全公告；</li>
<li>2016-11-26 21:27:23 360网络安全研究院首次探测到mirai僵尸网络发起了针对 7547 端口的扫描；</li>
<li>2016-11-26 ～ 2016-11-28，端口7547上的mirai僵尸网络规模积累到足以影响大面积网络；</li>
<li>～2016-11-28 telekom 德国电信累积大约90万个路由器被mirai僵尸网络的扫描过程打宕，网络大面积受影响</li>
<li>2016-11-28 ～ 至今 telekom 德国电信在自身网络范围内采取措施遏制mirai僵尸网络的扫描过程。</li>
</ol>
<h4 id="">概述</h4>
<p>众所周知，mirai的源码在北京时间2016-09-30附近泄漏，随后被托管到<a href="https://github.com/jgamblin/Mirai-Source-Code">github</a>上。自那以后，不管是黑帽子还是白帽子都对mirai的源码进行了大量深入的分析。换句话说，随着时间的推移，各路新玩家终将逐渐入场，目前为止我们的观察也映证了上述观点。我们已经发现了若干mirai的新变种，例如出现了新的主控域名，或者登录界面从俄文变为英文/中文，也有一些明显还是新玩家摸索阶段的设定，比如将主控域名设为<em>8.8.8.8</em>或者<em>baidu.com</em>。基于种种mirai变种，<strong>我们推测mirai家族对网络空间安全的威胁将会长期持续，周期也许会以年为单位计。</strong></p>
<p>11月26日21点27分, 一个新的变种引起了我们的注意。之前的Mirai各种变种基本都是小改动，<strong>核心内容扫描<code>23</code>和<code>2323</code>端口上弱口令的行为模式没有变化，但是这个变种出现了扫描TCP 端口<code>7547</code>远程命令执行漏洞的行为</strong>，这是利用了最近新公布的一个安全公告中提到的问题，将感染目标转移到支持<strong>TR-069/TR-064</strong>并错误暴露TR-064的设备，bot扫描端口也随之转移到<code>7547</code>，感染过程利用了TR-064实现中存在的命令注入问题。该变种仍然会扫描mirai传统的端口23/2323，但是使用的弱口令进一步精简到精心挑选的三组密码。这种变化表明，mirai泄漏源码已经逐步成为成熟的开发包，一旦有新的（也许是旧的）设备弱口令被发现，很快就会被mirai家族感染。这其中，<strong>扫描端口<code>7547</code>而非<code>23</code>和<code>2323</code>、利用远程命令执行漏洞而非弱口令种植木马都与既往mirai的行为显著区分。</strong></p>
<p>另一方面，尽管这个新变种有若干变化，它仍然重用了mirai的部分代码，进而顺带继承了mirai代码中的缺陷，并与既有mirai僵尸网络共享控制端基础设施。</p>
<p>11月27日17点04分,我们监测到又出现一个变种,和26日的新变种类似,这次的变种出现了扫描TCP端口<code>5555</code>的行为。</p>
<p>从我们的统计数据上来，这两个变种处于异常活跃的状态，同时从国外合作伙伴的数据来看，这两个变种的扫描范围造成了世界范围的影响，日记录的活跃扫描源在百万级别。</p>
<p><strong>鉴于mirai的源码已经公开, 结合上述两个变种的行为,我们深度担忧mirai会成为一个ddos攻击库的母体，通过模块化对源代码部分内容进行更新，就可以随时增加对新的漏洞的支持。</strong></p>
<h4 id="">数据更新</h4>
<p>我们在<a href="http://data.netlab.360.com/mirai-scanner">http://data.netlab.360.com/mirai-scanner</a>提供了对mirai感染设备的各种统计和数据下载供研究者使用。</p>
<p>根据新观察到的数据，我们更新了<a href="http://data.netlab.360.com/mirai-scanner">data.netlab.360.com</a>上的mirai监控页面，并且将对应样本的md5和域名附录在文末。对已经使用API访问我们提供bot list的合作者，请重新下载2016-11-26及以后的数据以获得7547及5555端口数据的更新。</p>
<h4 id="mirai">新Mirai变种的僵尸网络能力评估</h4>
<p>目前活跃的所有已知版本的mirai(包括今天报告的在端口<code>7547</code>和<code>5555的</code>)由于编码手法问题,导致可以精确定位和标示来自mirai的扫描行为。如前所述,我们在2016-11-26首次观察到<code>7547</code>端口上的新变种，一天后的2016-11-27首次观察到<code>5555</code>端口上的新变种。</p>
<p>在各个端口上首次发现扫描时间对比<br>
<img src="__GHOST_URL__/content/images/2016/11/26A6E2BA-AE19-42D4-B521-FCAACB1FF303.png" alt="scan first seen" loading="lazy"></p>
<p>每日bot规模增长情况(最右侧的的蓝色和红色是新增加的这两个变种)<br>
<img src="__GHOST_URL__/content/images/2016/11/F2223CCD-1D12-45F5-9A37-BE3473395D57.png" alt="" loading="lazy"></p>
<p>按照当前的增速排名，四个端口上bot的增长速度分别是：<br>
<img src="__GHOST_URL__/content/images/2016/11/1A7619BC-9268-47FC-92FC-9852A53D65D9.png" alt="" loading="lazy"></p>
<p>当前端口<code>7547</code>上的bot增长速度已经远超过了已知 端口<code>23/2323</code>上的bot数量增速。当前端口<code>7547</code>上的bot总量已经超过3万；我们从安全社区合作伙伴处得知，全网潜在的可感染设备总数量在3～5百万之间。这也是促使我们撰写本blog的原因之一。</p>
<p>端口 7547 上bot增速曲线，分解到每十分钟：<br>
<img src="__GHOST_URL__/content/images/2016/11/5F01A7D3-FACF-4C81-A77F-0811A6646804.png" alt="" loading="lazy"><br>
上图显示，Bot的增速很快就达到一个高峰，并且平稳的维持在较高水平上。</p>
<p>另一方面，在整个互联网的视角来看，端口7547的扫描在2016-11-26日晚间开始有急剧的上升。</p>
<p><img src="__GHOST_URL__/content/images/2016/11/8FD11DE0-4D60-4AA9-BE15-6EF78A7C704A.png" alt="" loading="lazy"></p>
<h2 id="botmirai">在新变种的感染bot的地理分布方面，<strong>巴西依然遥遥领先</strong>，与既有mirai僵尸网络的地理分布保持一致。<br>
<img src="__GHOST_URL__/content/images/2016/11/794D5FFB-CF94-41E1-88E8-BBB1CC891BE8.png" alt="" loading="lazy"></h2>
<h4 id="mirai">新变种共享了既有mirai僵尸网络主控的基础设施</h4>
<p>通过分析和网络追踪，我们得到了端口<code>7547</code>上的mirai变种样本。进一步分析样本发现，样本中的主控有两组，如下。值得注意的是,这两组主控都是之前已经发现并跟踪的mirai僵尸主控。我们最早在2016-11-09就已经在其他样本中发现了同时出现两组主控的情况，并且那两组主控就是本次新变种中涉及的这两组。也就是说,这次利用<code>7547</code>漏洞的新变种和之前的mirai最开始的使用者是一组人。</p>
<ul>
<li>
<p>*.securityupdates.us</p>
</li>
<li>
<p>*. timeserver.host</p>
</li>
</ul>
<p><mark>目前我们可以断言以下这四组主控背后的控制者是同一组人</mark></p>
<p><img src="__GHOST_URL__/content/images/2016/11/3CE2D45C-F314-4A7C-9E17-F55D82F172B9.png" alt="" loading="lazy"></p>
<p>判定的依据有下面这些：</p>
<ol>
<li>
<p>在本次发现的样本中（以及最早在2016-11-09发现的样本），一个样本中同时出现了<em>securityupdates.us</em>和<em>timeserver.host</em>两组C&amp;C控制服务器。</p>
</li>
<li>
<p>上述四组域名大量共享IP地址，特别是<em>5.188.232.1/24</em>这个C类段，几乎所有的IP地址都拥有完全相同的扫描banner。</p>
</li>
<li>
<p>有意思的是,在我们内部不久前做的一个数据观察的可视化图形中,我们也的确可以看到<em>securityupdates.us</em>和<em>timeserver.host</em>这两个主控下的感染bot有较高的重合度，这从另外一个维度验证了这两个主控有一定关系。</p>
</li>
</ol>
<p><img src="__GHOST_URL__/content/images/2016/11/D6700A66-B35A-4783-9714-97F06556E420.png" alt="" loading="lazy"></p>
<h4 id="miraibot">新变种与既有mirai僵尸网络在bot列表上也有一定覆盖交叉</h4>
<p>整体四个端口 <code>23/2323/5555/7547</code> 的botIP列表也有一定交叉覆盖。<br>
<img src="__GHOST_URL__/content/images/2016/11/port_client_ip_overlap.png" alt="" loading="lazy"></p>
<p>可以看出：</p>
<ol>
<li>
<p>主要的bot还是仅仅扫描<code>23</code>端口上，占了79%；加上顺带扫描<code>2323</code>端口的11%、以及仅仅扫描<code>2323</code>端口的6.4%，共计96.4%，这占据了当前mirai僵尸网络的绝对大头；</p>
</li>
<li>
<p>仅仅扫描 <code>7547</code> 端口的bot有 3.1%，考虑到当前这个端口上仅工作了3天，mirai的在这个端口上感染速度仍然是惊人的；</p>
</li>
<li>
<p>其他交叉扫描的所有bot合并攻击占据0.5%，目前仍然不是主体。</p>
</li>
</ol>
<h4 id="">新变种的设备特性</h4>
<p>我们汇总了手头所有<code>7547</code>相关的botIP列表，共计<code>46653</code>个。我们尝试读取这些IP的设备型号，共计获得了<code>5976</code>个回应。这里的样本耗损比较大，我们反复尝试了多次，相信可以排除网络抖动情况，剩下的损耗我们归因为mirai；也许是因为设备上的开放端口被mirai关闭，也许是因为设备当时网络忙。</p>
<p>我们筛选了返回的<code>5976</code>个回应中个数超过10个的细分类，列出他们的生产厂商（打码）、型号列表如下。<br>
<img src="__GHOST_URL__/content/images/2016/11/7547_client_ip_manufactor.png" alt="" loading="lazy"></p>
<p>我们建议这些厂商联合他们的客户一起对上述情况做出适当响应以减轻mirai的危害程度，但同时仍然必须强调这些只是我们能够看到的冰山一角，也许还需要更多其他设备厂商一起来做更多的网络安全工作。</p>
<h4 id="">相关安全公告</h4>
<p>2016-11-07，kenzo/kenzo2017在<em>devicereversing.wordpress.com</em>上发布了一个TR-064相关的安全公告。原文见：<br>
<a href="https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/">https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/</a></p>
<p>理解该公告的技术细节有助于理解mirai新变种的行为。<br>
公告中公开了Eir D1000 Modem的一个配置错误和一个命令注入问题。该配置错误使得原本仅应该暴露在LAN一侧的TR-064协议栈暴露在了WAN一侧；而对命令注入手段的充分利用可以使得攻击者完全接管设备。</p>
<p>Eir D1000 Moden向互联网暴露了端口<code>7547</code>。该端口上运行了两组协议，TR-069和TR-064，前者设计为在WAN上运行，而后者仅设计为在LAN侧运行。正常情况下在互联网上无法与TR-064协议栈交互，但是由于该设备的错误配置，该协议栈被暴露在WAN上，形成一个攻击面。</p>
<p>公告中提及，在该设备上可以执行TR-064中的多个命令，包括获取设备信息、获取设备WiFi密码、获取设备SSID/MAC、设定时间服务器等等。特殊的，在设定时间服务器的时候存在一个命令注入漏洞，利用该漏洞可以执行该设备上busybox的诸多命令，比如可以设定iptables来关掉设备上<code>80</code>端口管理员界面的防火墙。而要命的是，管理员界面的登录密码，就是前面提到可以获取的设备WiFi密码。</p>
<p>组合使用上述配置错误/漏洞，可以使得攻击者在WAN侧获得设备的完全控制权。Kenzo在公告中给出了一个利用的概念验证。</p>
<p>该公告中还有其他若干槽点可看。不过我们的注意力集中在网络侧的技术特征，包括：</p>
<ol>
<li>
<p>开放端口为<code>7547</code>，这意味着新变种的bot需要发起针对该端口的扫描。</p>
</li>
<li>
<p>体系架构为MIPS。概念验证中提到的两个Targets分别是MIPS的大端和小端。</p>
</li>
</ol>
<p>另外在安全社区的其他信息源中，我们了解到端口<code>5555</code>上也同样运行了TR-069/TR-064协议，并且有其他mirai变种开始扫描了上述端口。我们的数据中，映证了以上关于端口<code>5555/7547</code>的说法。</p>
<h3 id="mirai">新mirai变种的感染和植入过程</h3>
<p>新变种的感染和植入过程已经被安全社区广泛讨论，例如下面的这篇文章，这里不再赘述，读者可以自行扩展阅读。</p>
<p><a href="https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/">https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/</a><br>
值得一提的有这么一些地方：</p>
<ul>
<li>
<p>新变种的样本覆盖了多个平台，如下列表:<br>
<img src="__GHOST_URL__/content/images/2016/11/B3A12F5D-446A-4EB3-94E1-26EDE8E24186.png?size=standard#border" alt="" loading="lazy"><br>
在诸多解释中，我们选择相信这可能反映了攻击者的工程环境比较成熟，攻击者已经拥有较为成熟的交叉编译工程环境，新的扫描方式出现后顺手就编译了多种平台样本。</p>
</li>
<li>
<p>精简所使用的弱口令集合<br>
这一变种里，针对23/2323 端口弱口令字典已经精简到了3条。</p>
</li>
</ul>
<blockquote>
<p>root     xc3511<br>
root     vizxv<br>
root     admin</p>
</blockquote>
<p>对照下表中已经公开的弱口令可知，前述第一对弱口令是针对雄迈设备的；第二对是针对大华设备的。第三条适用范围较广，没有明确的指向性。<br>
<img src="__GHOST_URL__/content/images/2016/11/D45D88C6-0948-4B26-A1CF-3DAB36D695C1.png?size=mini" alt="" loading="lazy"></p>
<p>我们相信从攻击者的角度看来，对比之前的约60对弱口令，当前的三对弱口令在覆盖率上不会有多少损失，但是扫描速度方面会有很大提高。</p>
<h4 id="">附录</h4>
<ul>
<li>IOC, MD5</li>
</ul>
<pre><code>dc2464aefa7ba00eeccbd18baceeb9e9
a4487a7b2040de43ba3e0d7468f070c7
238a67e6f9b129680b618a3c579a8c6c
a490bb1c9a005bcf8cfe4bdffe7b991f
0dd3e7899183e93e5967e87ac6ea48a9
83bb43a36c49496a96f41926d80ec97d
99f9e7c6d7786555a7d067220b3c0d7d
a00a630b5f2c5e142f35c9df7df9f919
b6e0b8327fa3ab5abe761fb627a9cba1
</code></pre>
<ul>
<li>域名</li>
</ul>
<pre><code>
kernelorg[.]download  
update[.]kernelorg[.]download
securityupdates[.]us
check[.]securityupdates[.]us
rep[.]securityupdates[.]us
timeserver[.]host
ntp[.]timeserver[.]host
ocalhost[.]host
l[.]ocalhost[.]host

</code></pre>
<!--kg-card-end: markdown-->
【更新】


 1. 2016-11-29 18:40:00 初始版本
 2. 2016-11-29 20:10:00 增加了对德国电信断网事件相关的描述


德国电信断网事件 2016-11-28


德国电信在2016年11月28日前后遭遇一次大范围的网络故障。在这次故障中，2千万固定网络用户中的大约90万个路由器发生故障（约4.5%），并由此导致大面积网络访问受限。很多媒体给出了网络受限的示意图，如下。





德国电信进一步确认了问题是由于路由设备的维护界面被暴露在互联网上、并且互联网上正在发生针对性的攻击而导致。德国电信连夜与设备供应商生成了新的升级包，并且要求客户如果怀疑受到影响就断电重启路由器，之后利用自动/手动的升级过程来减轻问题显然，德国电信还采取了一系列的过滤措施来保证升级过程不受攻击影响。德国电信对该事件给出了较为详细的描述。


https://www.telekom.com/en/media/media-information/archive/information-on-current-problems-444862


按照360网络安全研究院对这次事件以及mirai僵尸网络的理解，这次事件前后的时间脉络如下（以下均为北京时间）：


 1. 2016-11-07，kenzo发布了一个针对7547端口上路由器等设备的TR-069/TR-064相关的安全公告；
 2. 2016-11-26 21:27:23 360网络安全研究院首次探测到mirai僵尸网络发起了针对 7547 端口的扫描；
 3. 2016-11-26 ～ 2016-11-28，端口7547上的mirai僵尸网络规模积累到足以影响大面积网络；
 4. ～2016-11-28 telekom 德国电信累积大约90万个路由器被mirai僵尸网络的扫描过程打宕，网络大面积受影响
 5. 2016-11-28 ～ 至今 telekom 德国电信在自身网络范围内采取措施遏制mirai僵尸网络的扫描过程。


概述


众所周知，mirai的源码在北京时间2016-09-30附近泄漏，随后被托管到github上。自那以后，不管是黑帽子还是白帽子都对mirai的源码进行了大量深入的分析。换句话说，随着时间的推移，各路新玩家终将逐渐入场，目前为止我们的观察也映证了上述观点。我们已经发现了若干mirai的新变种，例如出现了新的主控域名，或者登录界面从俄文变为英文/中文，也有一些明显还是新玩家摸索阶段的设定，比如将主控域名设为8.8.8.8或者baidu.com。基于种种mirai变种，我们推测mirai家族对网络空间安全的威胁将会长期持续，周期也许会以年为单位计。


11月26日21点27分, 一个新的变种引起了我们的注意。之前的Mirai各种变种基本都是小改动，核心内容扫描23和2323端口上弱口令的行为模式没有变化，但是这个变种出现了扫描TCP 端口7547远程命令执行漏洞的行为，这是利用了最近新公布的一个安全公告中提到的问题，将感染目标转移到支持TR-069/TR-064并错误暴露TR-064的设备，bot扫描端口也随之转移到7547，感染过程利用了TR-064实现中存在的命令注入问题。该变种仍然会扫描mirai传统的端口23/2323，但是使用的弱口令进一步精简到精心挑选的三组密码。这种变化表明，mirai泄漏源码已经逐步成为成熟的开发包，一旦有新的（也许是旧的）设备弱口令被发现，很快就会被mirai家族感染。这其中，扫描端口7547而非23和2323、利用远程命令执行漏洞而非弱口令种植木马都与既往mirai的行为显著区分。


另一方面，尽管这个新变种有若干变化，它仍然重用了mirai的部分代码，进而顺带继承了mirai代码中的缺陷，并与既有mirai僵尸网络共享控制端基础设施。


11月27日17点04分,我们监测到又出现一个变种,和26日的新变种类似,这次的变种出现了扫描TCP端口5555的行为。


从我们的统计数据上来，这两个变种处于异常活跃的状态，同时从国外合作伙伴的数据来看，这两个变种的扫描范围造成了世界范围的影响，日记录的活跃扫描源在百万级别。


鉴于mirai的源码已经公开, 结合上述两个变种的行为,我们深度担忧mirai会成为一个ddos攻击库的母体，通过模块化对源代码部分内容进行更新，就可以随时增加对新的漏洞的支持。


数据更新


我们在http://data.netlab.360.com/mirai-scanner提供了对mirai感染设备的各种统计和数据下载供研究者使用。


根据新观察到的数据，我们更新了data.netlab.360.com上的mirai监控页面，并且将对应样本的md5和域名附录在文末。对已经使用API访问我们提供bot list的合作者，请重新下载2016-11-26及以后的数据以获得7547及5555端口数据的更新。


新Mirai变种的僵尸网络能力评估


目前活跃的所有已知版本的mirai(包括今天报告的在端口7547和5555的)由于编码手法问题,导致可以精确定位和标示来自mirai的扫描行为。如前所述,我们在2016-11-26首次观察到7547端口上的新变种，一天后的2016-11-27首次观察到5555端口上的新变种。


在各个端口上首次发现扫描时间对比




每日bot规模增长情况(最右侧的的蓝色和红色是新增加的这两个变种)




按照当前的增速排名，四个端口上bot的增长速度分别是：




当前端口7547上的bot增长速度已经远超过了已知 端口23/2323上的bot数量增速。当前端口7547上的bot总量已经超过3万；我们从安全社区合作伙伴处得知，全网潜在的可感染设备总数量在3～5百万之间。这也是促使我们撰写本blog的原因之一。


端口 7547 上bot增速曲线，分解到每十分钟：



上图显示，Bot的增速很快就达到一个高峰，并且平稳的维持在较高水平上。


另一方面，在整个互联网的视角来看，端口7547的扫描在2016-11-26日晚间开始有急剧的上升。






在新变种的感染bot的地理分布方面，巴西依然遥遥领先，与既有mirai僵尸网络的地理分布保持一致。




新变种共享了既有mirai僵尸网络主控的基础设施


通过分析和网络追踪，我们得到了端口7547上的mirai变种样本。进一步分析样本发现，样本中的主控有两组，如下。值得注意的是,这两组主控都是之前已经发现并跟踪的mirai僵尸主控。我们最早在2016-11-09就已经在其他样本中发现了同时出现两组主控的情况，并且那两组主控就是本次新变种中涉及的这两组。也就是说,这次利用7547漏洞的新变种和之前的mirai最开始的使用者是一组人。


 * 
   
   
   *.securityupdates.us
   

 * 
   
   
   *. timeserver.host
   


目前我们可以断言以下这四组主控背后的控制者是同一组人





判定的依据有下面这些：


 1. 
    
    
    在本次发现的样本中（以及最早在2016-11-09发现的样本），一个样本中同时出现了securityupdates.us和timeserver.host两组C&C控制服务器。
    

 2. 
    
    
    上述四组域名大量共享IP地址，特别是5.188.232.1/24这个C类段，几乎所有的IP地址都拥有完全相同的扫描banner。
    

 3. 
    
    
    有意思的是,在我们内部不久前做的一个数据观察的可视化图形中,我们也的确可以看到securityupdates.us和timeserver.host这两个主控下的感染bot有较高的重合度，这从另外一个维度验证了这两个主控有一定关系。
    





新变种与既有mirai僵尸网络在bot列表上也有一定覆盖交叉


整体四个端口 23/2323/5555/7547 的botIP列表也有一定交叉覆盖。




可以看出：


 1. 
    
    
    主要的bot还是仅仅扫描23端口上，占了79%；加上顺带扫描2323端口的11%、以及仅仅扫描2323端口的6.4%，共计96.4%，这占据了当前mirai僵尸网络的绝对大头；
    

 2. 
    
    
    仅仅扫描 7547 端口的bot有 3.1%，考虑到当前这个端口上仅工作了3天，mirai的在这个端口上感染速度仍然是惊人的；
    

 3. 
    
    
    其他交叉扫描的所有bot合并攻击占据0.5%，目前仍然不是主体。
    


新变种的设备特性


我们汇总了手头所有7547相关的botIP列表，共计46653个。我们尝试读取这些IP的设备型号，共计获得了5976个回应。这里的样本耗损比较大，我们反复尝试了多次，相信可以排除网络抖动情况，剩下的损耗我们归因为mirai；也许是因为设备上的开放端口被mirai关闭，也许是因为设备当时网络忙。


我们筛选了返回的5976个回应中个数超过10个的细分类，列出他们的生产厂商（打码）、型号列表如下。




我们建议这些厂商联合他们的客户一起对上述情况做出适当响应以减轻mirai的危害程度，但同时仍然必须强调这些只是我们能够看到的冰山一角，也许还需要更多其他设备厂商一起来做更多的网络安全工作。


相关安全公告


2016-11-07，kenzo/kenzo2017在devicereversing.wordpress.com上发布了一个TR-064相关的安全公告。原文见：

https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/


理解该公告的技术细节有助于理解mirai新变种的行为。

公告中公开了Eir D1000 Modem的一个配置错误和一个命令注入问题。该配置错误使得原本仅应该暴露在LAN一侧的TR-064协议栈暴露在了WAN一侧；而对命令注入手段的充分利用可以使得攻击者完全接管设备。


Eir D1000 Moden向互联网暴露了端口7547。该端口上运行了两组协议，TR-069和TR-064，前者设计为在WAN上运行，而后者仅设计为在LAN侧运行。正常情况下在互联网上无法与TR-064协议栈交互，但是由于该设备的错误配置，该协议栈被暴露在WAN上，形成一个攻击面。


公告中提及，在该设备上可以执行TR-064中的多个命令，包括获取设备信息、获取设备WiFi密码、获取设备SSID/MAC、设定时间服务器等等。特殊的，在设定时间服务器的时候存在一个命令注入漏洞，利用该漏洞可以执行该设备上busybox的诸多命令，比如可以设定iptables来关掉设备上80端口管理员界面的防火墙。而要命的是，管理员界面的登录密码，就是前面提到可以获取的设备WiFi密码。


组合使用上述配置错误/漏洞，可以使得攻击者在WAN侧获得设备的完全控制权。Kenzo在公告中给出了一个利用的概念验证。


该公告中还有其他若干槽点可看。不过我们的注意力集中在网络侧的技术特征，包括：


 1. 
    
    
    开放端口为7547，这意味着新变种的bot需要发起针对该端口的扫描。
    

 2. 
    
    
    体系架构为MIPS。概念验证中提到的两个Targets分别是MIPS的大端和小端。
    


另外在安全社区的其他信息源中，我们了解到端口5555上也同样运行了TR-069/TR-064协议，并且有其他mirai变种开始扫描了上述端口。我们的数据中，映证了以上关于端口5555/7547的说法。



新mirai变种的感染和植入过程


新变种的感染和植入过程已经被安全社区广泛讨论，例如下面的这篇文章，这里不再赘述，读者可以自行扩展阅读。


https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/

值得一提的有这么一些地方：


 * 
   
   
   新变种的样本覆盖了多个平台，如下列表:
   
   
   
   在诸多解释中，我们选择相信这可能反映了攻击者的工程环境比较成熟，攻击者已经拥有较为成熟的交叉编译工程环境，新的扫描方式出现后顺手就编译了多种平台样本。
   

 * 
   
   
   精简所使用的弱口令集合
   
   这一变种里，针对23/2323 端口弱口令字典已经精简到了3条。
   





root xc3511

root vizxv

root admin



对照下表中已经公开的弱口令可知，前述第一对弱口令是针对雄迈设备的；第二对是针对大华设备的。第三条适用范围较广，没有明确的指向性。




我们相信从攻击者的角度看来，对比之前的约60对弱口令，当前的三对弱口令在覆盖率上不会有多少损失，但是扫描速度方面会有很大提高。


附录


 * IOC, MD5


dc2464aefa7ba00eeccbd18baceeb9e9
a4487a7b2040de43ba3e0d7468f070c7
238a67e6f9b129680b618a3c579a8c6c
a490bb1c9a005bcf8cfe4bdffe7b991f
0dd3e7899183e93e5967e87ac6ea48a9
83bb43a36c49496a96f41926d80ec97d
99f9e7c6d7786555a7d067220b3c0d7d
a00a630b5f2c5e142f35c9df7df9f919
b6e0b8327fa3ab5abe761fb627a9cba1



 * 域名



kernelorg[.]download  
update[.]kernelorg[.]download
securityupdates[.]us
check[.]securityupdates[.]us
rep[.]securityupdates[.]us
timeserver[.]host
ntp[.]timeserver[.]host
ocalhost[.]host
l[.]ocalhost[.]host



{"version":"0.3.1","markups":[],"atoms":[],"cards":[["markdown",{"cardName":"card-markdown","markdown":"【更新】\n\n1. 2016-11-29 18:40:00 初始版本\n2. 2016-11-29 20:10:00 增加了对德国电信断网事件相关的描述\n\n####德国电信断网事件 2016-11-28\n德国电信在2016年11月28日前后遭遇一次大范围的网络故障。在这次故障中，2千万固定网络用户中的大约90万个路由器发生故障（约4.5%），并由此导致大面积网络访问受限。很多媒体给出了网络受限的示意图，如下。\n\n![](__GHOST_URL__/content/images/2016/11/telekom_network_issue_map.png)\n\n德国电信进一步确认了问题是由于路由设备的维护界面被暴露在互联网上、并且互联网上正在发生针对性的攻击而导致。德国电信连夜与设备供应商生成了新的升级包，并且要求客户如果怀疑受到影响就断电重启路由器，之后利用自动/手动的升级过程来减轻问题显然，德国电信还采取了一系列的过滤措施来保证升级过程不受攻击影响。德国电信对该事件给出了较为详细的描述。\n\nhttps://www.telekom.com/en/media/media-information/archive/information-on-current-problems-444862\n\n**按照360网络安全研究院对这次事件以及mirai僵尸网络的理解，这次事件前后的时间脉络如下**（以下均为北京时间）：\n\n1. 2016-11-07，kenzo发布了一个针对7547端口上路由器等设备的TR-069/TR-064相关的安全公告；\n2. 2016-11-26 21:27:23 360网络安全研究院首次探测到mirai僵尸网络发起了针对 7547 端口的扫描；\n3. 2016-11-26 ～ 2016-11-28，端口7547上的mirai僵尸网络规模积累到足以影响大面积网络；\n4. ～2016-11-28 telekom 德国电信累积大约90万个路由器被mirai僵尸网络的扫描过程打宕，网络大面积受影响\n5. 2016-11-28 ～ 至今 telekom 德国电信在自身网络范围内采取措施遏制mirai僵尸网络的扫描过程。\n\n####概述\n\n众所周知，mirai的源码在北京时间2016-09-30附近泄漏，随后被托管到[github](https://github.com/jgamblin/Mirai-Source-Code)上。自那以后，不管是黑帽子还是白帽子都对mirai的源码进行了大量深入的分析。换句话说，随着时间的推移，各路新玩家终将逐渐入场，目前为止我们的观察也映证了上述观点。我们已经发现了若干mirai的新变种，例如出现了新的主控域名，或者登录界面从俄文变为英文/中文，也有一些明显还是新玩家摸索阶段的设定，比如将主控域名设为*8.8.8.8*或者*baidu.com*。基于种种mirai变种，**我们推测mirai家族对网络空间安全的威胁将会长期持续，周期也许会以年为单位计。**\n\n11月26日21点27分, 一个新的变种引起了我们的注意。之前的Mirai各种变种基本都是小改动，**核心内容扫描`23`和`2323`端口上弱口令的行为模式没有变化，但是这个变种出现了扫描TCP 端口`7547`远程命令执行漏洞的行为**，这是利用了最近新公布的一个安全公告中提到的问题，将感染目标转移到支持**TR-069/TR-064**并错误暴露TR-064的设备，bot扫描端口也随之转移到`7547`，感染过程利用了TR-064实现中存在的命令注入问题。该变种仍然会扫描mirai传统的端口23/2323，但是使用的弱口令进一步精简到精心挑选的三组密码。这种变化表明，mirai泄漏源码已经逐步成为成熟的开发包，一旦有新的（也许是旧的）设备弱口令被发现，很快就会被mirai家族感染。这其中，**扫描端口`7547`而非`23`和`2323`、利用远程命令执行漏洞而非弱口令种植木马都与既往mirai的行为显著区分。**\n\n另一方面，尽管这个新变种有若干变化，它仍然重用了mirai的部分代码，进而顺带继承了mirai代码中的缺陷，并与既有mirai僵尸网络共享控制端基础设施。\n\n11月27日17点04分,我们监测到又出现一个变种,和26日的新变种类似,这次的变种出现了扫描TCP端口`5555`的行为。\n\n\n从我们的统计数据上来，这两个变种处于异常活跃的状态，同时从国外合作伙伴的数据来看，这两个变种的扫描范围造成了世界范围的影响，日记录的活跃扫描源在百万级别。\n\n\n**鉴于mirai的源码已经公开, 结合上述两个变种的行为,我们深度担忧mirai会成为一个ddos攻击库的母体，通过模块化对源代码部分内容进行更新，就可以随时增加对新的漏洞的支持。**\n\n\n#### 数据更新\n我们在[http://data.netlab.360.com/mirai-scanner](http://data.netlab.360.com/mirai-scanner)提供了对mirai感染设备的各种统计和数据下载供研究者使用。\n\n根据新观察到的数据，我们更新了[data.netlab.360.com](http://data.netlab.360.com/mirai-scanner)上的mirai监控页面，并且将对应样本的md5和域名附录在文末。对已经使用API访问我们提供bot list的合作者，请重新下载2016-11-26及以后的数据以获得7547及5555端口数据的更新。\n\n#### 新Mirai变种的僵尸网络能力评估\n目前活跃的所有已知版本的mirai(包括今天报告的在端口`7547`和`5555的`)由于编码手法问题,导致可以精确定位和标示来自mirai的扫描行为。如前所述,我们在2016-11-26首次观察到`7547`端口上的新变种，一天后的2016-11-27首次观察到`5555`端口上的新变种。\n\n在各个端口上首次发现扫描时间对比\n![scan first seen](__GHOST_URL__/content/images/2016/11/26A6E2BA-AE19-42D4-B521-FCAACB1FF303.png)\n\n\n每日bot规模增长情况(最右侧的的蓝色和红色是新增加的这两个变种)\n![](__GHOST_URL__/content/images/2016/11/F2223CCD-1D12-45F5-9A37-BE3473395D57.png)\n\n按照当前的增速排名，四个端口上bot的增长速度分别是：\n![](__GHOST_URL__/content/images/2016/11/1A7619BC-9268-47FC-92FC-9852A53D65D9.png)\n\n当前端口`7547`上的bot增长速度已经远超过了已知 端口`23/2323`上的bot数量增速。当前端口`7547`上的bot总量已经超过3万；我们从安全社区合作伙伴处得知，全网潜在的可感染设备总数量在3～5百万之间。这也是促使我们撰写本blog的原因之一。\n\n端口 7547 上bot增速曲线，分解到每十分钟：\n![](__GHOST_URL__/content/images/2016/11/5F01A7D3-FACF-4C81-A77F-0811A6646804.png)\n上图显示，Bot的增速很快就达到一个高峰，并且平稳的维持在较高水平上。\n\n另一方面，在整个互联网的视角来看，端口7547的扫描在2016-11-26日晚间开始有急剧的上升。\n\n![](__GHOST_URL__/content/images/2016/11/8FD11DE0-4D60-4AA9-BE15-6EF78A7C704A.png)\n\n在新变种的感染bot的地理分布方面，**巴西依然遥遥领先**，与既有mirai僵尸网络的地理分布保持一致。\n![](__GHOST_URL__/content/images/2016/11/794D5FFB-CF94-41E1-88E8-BBB1CC891BE8.png)\n---\n#### 新变种共享了既有mirai僵尸网络主控的基础设施\n通过分析和网络追踪，我们得到了端口`7547`上的mirai变种样本。进一步分析样本发现，样本中的主控有两组，如下。值得注意的是,这两组主控都是之前已经发现并跟踪的mirai僵尸主控。我们最早在2016-11-09就已经在其他样本中发现了同时出现两组主控的情况，并且那两组主控就是本次新变种中涉及的这两组。也就是说,这次利用`7547`漏洞的新变种和之前的mirai最开始的使用者是一组人。\n\n* *.securityupdates.us\n\n* *. timeserver.host \n\n==目前我们可以断言以下这四组主控背后的控制者是同一组人==\n\n![](__GHOST_URL__/content/images/2016/11/3CE2D45C-F314-4A7C-9E17-F55D82F172B9.png)\n\n判定的依据有下面这些：\n\n1. 在本次发现的样本中（以及最早在2016-11-09发现的样本），一个样本中同时出现了*securityupdates.us*和*timeserver.host*两组C&C控制服务器。\n\n2.  上述四组域名大量共享IP地址，特别是*5.188.232.1/24*这个C类段，几乎所有的IP地址都拥有完全相同的扫描banner。\n\n3. 有意思的是,在我们内部不久前做的一个数据观察的可视化图形中,我们也的确可以看到*securityupdates.us*和*timeserver.host*这两个主控下的感染bot有较高的重合度，这从另外一个维度验证了这两个主控有一定关系。\n\n![](__GHOST_URL__/content/images/2016/11/D6700A66-B35A-4783-9714-97F06556E420.png)\n\n#### 新变种与既有mirai僵尸网络在bot列表上也有一定覆盖交叉\n\n整体四个端口 `23/2323/5555/7547` 的botIP列表也有一定交叉覆盖。\n![](__GHOST_URL__/content/images/2016/11/port_client_ip_overlap.png)\n\n可以看出：\n\n1. 主要的bot还是仅仅扫描`23`端口上，占了79%；加上顺带扫描`2323`端口的11%、以及仅仅扫描`2323`端口的6.4%，共计96.4%，这占据了当前mirai僵尸网络的绝对大头；\n\n2. 仅仅扫描 `7547` 端口的bot有 3.1%，考虑到当前这个端口上仅工作了3天，mirai的在这个端口上感染速度仍然是惊人的；\n\n3. 其他交叉扫描的所有bot合并攻击占据0.5%，目前仍然不是主体。\n\n#### 新变种的设备特性\n我们汇总了手头所有`7547`相关的botIP列表，共计`46653`个。我们尝试读取这些IP的设备型号，共计获得了`5976`个回应。这里的样本耗损比较大，我们反复尝试了多次，相信可以排除网络抖动情况，剩下的损耗我们归因为mirai；也许是因为设备上的开放端口被mirai关闭，也许是因为设备当时网络忙。\n\n我们筛选了返回的`5976`个回应中个数超过10个的细分类，列出他们的生产厂商（打码）、型号列表如下。\n![](__GHOST_URL__/content/images/2016/11/7547_client_ip_manufactor.png)\n\n我们建议这些厂商联合他们的客户一起对上述情况做出适当响应以减轻mirai的危害程度，但同时仍然必须强调这些只是我们能够看到的冰山一角，也许还需要更多其他设备厂商一起来做更多的网络安全工作。\n\n\n#### 相关安全公告\n\n2016-11-07，kenzo/kenzo2017在*devicereversing.wordpress.com*上发布了一个TR-064相关的安全公告。原文见：\n[https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/](https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/)\n\n理解该公告的技术细节有助于理解mirai新变种的行为。\n公告中公开了Eir D1000 Modem的一个配置错误和一个命令注入问题。该配置错误使得原本仅应该暴露在LAN一侧的TR-064协议栈暴露在了WAN一侧；而对命令注入手段的充分利用可以使得攻击者完全接管设备。\n\nEir D1000 Moden向互联网暴露了端口`7547`。该端口上运行了两组协议，TR-069和TR-064，前者设计为在WAN上运行，而后者仅设计为在LAN侧运行。正常情况下在互联网上无法与TR-064协议栈交互，但是由于该设备的错误配置，该协议栈被暴露在WAN上，形成一个攻击面。\n\n公告中提及，在该设备上可以执行TR-064中的多个命令，包括获取设备信息、获取设备WiFi密码、获取设备SSID/MAC、设定时间服务器等等。特殊的，在设定时间服务器的时候存在一个命令注入漏洞，利用该漏洞可以执行该设备上busybox的诸多命令，比如可以设定iptables来关掉设备上`80`端口管理员界面的防火墙。而要命的是，管理员界面的登录密码，就是前面提到可以获取的设备WiFi密码。\n\n组合使用上述配置错误/漏洞，可以使得攻击者在WAN侧获得设备的完全控制权。Kenzo在公告中给出了一个利用的概念验证。\n\n该公告中还有其他若干槽点可看。不过我们的注意力集中在网络侧的技术特征，包括：\n\n1. 开放端口为`7547`，这意味着新变种的bot需要发起针对该端口的扫描。\n\n2. 体系架构为MIPS。概念验证中提到的两个Targets分别是MIPS的大端和小端。\n\n另外在安全社区的其他信息源中，我们了解到端口`5555`上也同样运行了TR-069/TR-064协议，并且有其他mirai变种开始扫描了上述端口。我们的数据中，映证了以上关于端口`5555/7547`的说法。\n\n### 新mirai变种的感染和植入过程\n\n新变种的感染和植入过程已经被安全社区广泛讨论，例如下面的这篇文章，这里不再赘述，读者可以自行扩展阅读。\n\n[https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/](https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/)  \n值得一提的有这么一些地方：\n\n* 新变种的样本覆盖了多个平台，如下列表:\n![](__GHOST_URL__/content/images/2016/11/B3A12F5D-446A-4EB3-94E1-26EDE8E24186.png?size=standard#border)\n在诸多解释中，我们选择相信这可能反映了攻击者的工程环境比较成熟，攻击者已经拥有较为成熟的交叉编译工程环境，新的扫描方式出现后顺手就编译了多种平台样本。\n\n* 精简所使用的弱口令集合\n这一变种里，针对23/2323 端口弱口令字典已经精简到了3条。\n\n>root     xc3511  \nroot     vizxv\nroot     admin\n\n对照下表中已经公开的弱口令可知，前述第一对弱口令是针对雄迈设备的；第二对是针对大华设备的。第三条适用范围较广，没有明确的指向性。\n![](__GHOST_URL__/content/images/2016/11/D45D88C6-0948-4B26-A1CF-3DAB36D695C1.png?size=mini)\n\n我们相信从攻击者的角度看来，对比之前的约60对弱口令，当前的三对弱口令在覆盖率上不会有多少损失，但是扫描速度方面会有很大提高。\n\n#### 附录\n* IOC, MD5\n\n```\ndc2464aefa7ba00eeccbd18baceeb9e9\na4487a7b2040de43ba3e0d7468f070c7\n238a67e6f9b129680b618a3c579a8c6c\na490bb1c9a005bcf8cfe4bdffe7b991f\n0dd3e7899183e93e5967e87ac6ea48a9\n83bb43a36c49496a96f41926d80ec97d\n99f9e7c6d7786555a7d067220b3c0d7d\na00a630b5f2c5e142f35c9df7df9f919\nb6e0b8327fa3ab5abe761fb627a9cba1\n```\n\n* 域名\n\n```\n\nkernelorg[.]download  \nupdate[.]kernelorg[.]download\nsecurityupdates[.]us\ncheck[.]securityupdates[.]us\nrep[.]securityupdates[.]us\ntimeserver[.]host\nntp[.]timeserver[.]host\nocalhost[.]host\nl[.]ocalhost[.]host\n\n```\n\n\n\n\n\n\n\n\n"}]],"sections":[[10,0]],"ghostVersion":"3.0"}