严正声明：本文仅限于技术讨论与学术学习研究之用，严禁用于其他用途（特别是非法用途，比如非授权攻击之类），否则自行承担后果，一切与作者和平台无关，如有发现不妥之处，请及时联系作者和平台
翻译：ForrestX386
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
SEC 的安全人员在一些WiMAX 路由器上发现了一个漏洞， 这个漏洞允许攻击者更改路由器上的管理员密码，进而获取对这些漏洞的设备的控制权限。更糟糕的是，如果攻击者控制了这些含有漏洞的路由器，他们就可以对这个漏洞设备背后的网络进行进一步攻击，或者将这些漏洞的设备加入了僵尸网络中，亦或通过这些漏洞设备监听用户信息。 这个漏洞的影响设备厂商包括GreenPacket， 华为， MADA， 中兴通讯，ZyXEL等。其中有些含有漏洞的设备可以通过web访问。 这个漏洞已经报给了CERT/CC (漏洞编号为CVE-2017-3216)，CERT也已将此漏洞通告给上述厂商。
更多关于此次漏洞披露的信息和漏洞影响的设备信息，请访问我们的漏洞通告页面(https://sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20170607-0_Various_WiMAX_CPEs_Authentication_Bypass_v10.txt )。
部分WiMAX 路由设备存在认证绕过和后门漏洞
本篇文章将主要讨论针对此次漏洞分析中几个重要的点，当我们的安全人员在研究关于HTTPS 证书和SSH key重用的问题时，意外的发现一组（大约80台）设备使用了一个颁发给MatrixSSL Sample Server Cert的HTTPS证书， 这一组设备中就包括ZyXEL 公司和他的姊妹公司MitraStar研发的WiMAX 网关，我们的安全人员选择了其中的一台进行了一点研究。
WiMAX是一种类似LTE的技术，虽然没有LTE那么地流行，但是，世界上还是有很多的WiMAX设备在使用。
通过我们搜集的大量数据集信息，我们发现很多的WiMAX设备将web访问接口暴露给互联网， 造成这种结果的原因可能是错误的配置，也可能是ISP的粗心。通过web访问接口都是挖掘漏洞的很好的切入点。
像所有的IoT（物联网）的渗透测试一样，我们搞到了一份含有漏洞的WiMAX 设备的固件（感谢ZyXEL 的官网提供给我们 O(∩_∩)O），我们直接上这个问题固件上传到我们的 IoT 分析系统（一个基于云的固件分析系统）， 几分钟之后，一份分析报告就出现在我们的眼前。
首先，我们看了一眼固件的文件系统结构。 在/var/www 目录下，我们发现了很多HTML 文件，按照我们的经验，通常这些HTML 文件只是视图模板文件（学过MVC的都知道），一般不会包含业务逻辑。
摘自 IoT 固件自动分析系统分析结果一部分
认证绕过漏洞
我们没有发现传统的CGI脚本，所以，我们推断，web接口的业务逻辑可能内嵌如web server本身，当我们发现web server的执行路径为：/bin/mini_httpd.elf， 我们敏锐地联想到这可能和开源项目mini_httpd 项目有关，但是，接着我们就我发现我们手头的这个mini_httpd和开源的mini_httpd完全不同，也许经过了重大的修改， 首先，我们手头的这个mini_httpd没有任何web 接口业务代码， 但是我们发现有一个函数通过dlopen()库函数从/lib/web_plugin 目录加载库文件。
于是，我们去/lib/web_plugin目录下看了一眼， 发现就只有一个名为libmtk_httpd_plugin.so的动态链接库文件， 在mime_handlers 符号连接处， 有一个用于描述针对不同的MIME 如何处理的结构数组。libmtk_httpd_plugin.so 库中包含了对于http请求的处理函数。
对于每一个接收到的HTTP请求，web server 都会根据上述提到的MIME结构数组找到匹配项，如果匹配ok，则从这个匹配结果中找到相应的请求处理函数并调用之。分析到这里，我们心情都很不错，我们打开IDA pro 神器帮助我们继续分析，根据上述提到的MIME结构数组的特征，我们找到了mime_handlers 符号列表中的入口项：
至此，我们已经非常清晰的明白了web server 中存在哪些URIs可以被解析处理，已经他们是如何被解析处理的， 在上图的mime_handlers 符号列表中的入口项的结构中，我们发现竟然还有一个枚举类型，这个枚举类型标识是否当前用户的请求应该被认证或者不认证（我们称之为AUTH_REQUIRED/UNAUTHENTICATED），我们还发现其中很多的URIs是不需要任何认证的， 这些URIs是非常值得我们去仔细分析的，我们将目标锁定在了 commit2.cgi 上。
这个URL的处理函数将POST请求的参数和值都存在在内置数据库中（key-value 存储形式，也许是存储在NVRAM中），其实这里就是一个漏洞，最简单的利用方式就是通过提交参数为ADMIN_PASSWORD=xxxx (xxx为你要修改后的管理员密码)的POST请求到commit2.cgi的URI, 这样就可以修改管理员的密码，从而可以通过web 界面成功登录，然后就可以进一步进行攻击
从web 界面登录成功之后，我们发现有很多可以利用的功能点（hacker的目的不同，选择的攻击点也不一样），其中有一个功能点可以修改DNS 服务器的配置 （聪明的你可能已经想到这里可以进行钓鱼攻击，通过劫持DNS，进行网银欺诈，或者广告植入）， 还有一处可以上传固件，这样攻击者就可以上传一个含有恶意代码的固件，用于监控用户行为，或者充当僵死网络中的一员。
随着分析的深入，我们发现这个含有露的WiMAX 路由器允许SSH 和Telnet登录， 这两个服务引起了我们的兴趣。
OEM 后门
SSH 和Telnet 远程登录功能可以通过web 界面进行配置启用，启用之后，攻击者可以使用web 界面的登录的账号和密码登录SSH 和Telnet， 登录成功之后， 或得到一个类似 Cisco 路由器命令行 的界面，然后就可以执行各种各样的命令，甚至有的命令还可以实现类似Linux shell的功能。
我们打开IoT 自动检测分析系统的分析报告， 看看能不能找到让我们感兴趣的结果， 我们发现了若干硬编码的类似 Unix形式的密码hash串，我们立即将其提交到我们的GPU-SERVER 进行破解
其中的一些密码hash看起来好像是默认密码， 位于minihttpd.trans中的hash值引起了我们的兴趣。
在minihttpd.trans中，我们发现这个脚本会在系统启动的时修改/etc/passwd 和/etc/shadow 两个文件的内容，从而添加后门用户。
上图显示，这段脚本会在系统启动的时候添加两个后门用户到/etc/passwd 和/etc/shadow ， 后门用户 mfgroot 的密码hash一直没变，都是h $1$.3r0/KnH$eR.mFSJKIiY.y2QsJVsYK. (明文为： %TGBnhy6m), root 密码hash根据系统变量ZY_CUSTOMER的不同而不一样，在不同的设备商的固件中root密码hash也不一样，下面列举了一些不同厂商的root hash值：
Greenpacket:
$1$38HlpaTA$bVNplU36JnUr.Xt1IHDCV/
华为:
$1$k2I9hJe4$Vg4Qw0w5IwMWb8GlfYhoi1
$1$7cHnPpHF$GbYUst3uAh0sFix3fz7B21
Mitrastar:
$1$k2I9hJe4$VibREr.QRvL4HUkaUAyDr1
ZyXEL:
$1$T6ecjm0M$EzKDcv0pezh9OItLRG8hY/
ZTE:
$1$k2I9hJe4$VibREr.QRvL4HUkaUAyDr1上面这一串 root hash的破解工作就留给读者了，这里暂且不表，即使不知道root的密码也可以利用已知的mfgroot:%TGBnhy6m 账户密码组合登录系统获取系统的root shell
闲扯IoT的供应链
IoT 设备的供应链通常是很复杂的，上面提到的”commit2.cgi” 接口的漏洞在动态链接库 libmtk_httpd_plugin.so 中被发现， 从文字上看，libmtk好像暗示，libmtk_httpd_plugin.so是MediaTek 软件公司提供的， 也许是MediaTek 软件公司提供的SDK（客户用此SDK进行MediaTek SoCs的开发）中的一个动态链接库。 这样的分析有一定道理，因为所有这些含有漏洞设备都是基于MediaTek 的硬件平台进行开发的 ，一般SDK都会包含了开发这款硬件所必须的东西，甚至包含一个web接口。 设备厂商可以选择使用整个SDK 其开发，也可以选择只使用其中一部分驱动或者中间件进行开发他们自己的产品。
CERT/CC 已经就这个漏洞联系了MediaTek公司，MediaTek公司回应他们的SDK没有任何漏洞，并声明他们怀疑ZyXEL 植入了漏洞代码。
根据我们自己搜集的信息，我们怀疑事情是这样的：
1. MediaTek 为WiMAX 设备提供了SoC芯片 和相应的SDK（包括web接口
程序）
2. ZyXEL 和他的 姊妹公司MitraStar基于MediaTek的SDK 进行了开发，引入了commit2.cgi 接口漏洞和OEM 后门代码
3. ZyXEL 将含有漏洞的设备卖给了ISP 服务商
4. MitraStar 作为OEM厂商，提供WiMAX设备给GreenPacket， 华为，中兴等，这些公司又把设备卖给了ISP服务商
5. ISP 服务商又把这些漏洞设备卖给或者租给他们的用户
一般的OEM 的用户不会承认他们的产品是OEM的， 我们为此咨询了华为，得到如下回复：
复杂的设备供应链加上OEM厂商的存在，所以去判断谁的产品含有漏洞不是一件简单的事，这也是我们开发IoT 自动检测分析系统的原因之一，其中一个用户案例就是去检查是否他的固件中存在漏洞，我们把这个固件上传到IoT 固件自动化检测系统， 然后得到了结果。 我们使用这种方式解决了很多问题，比如KCodes NetUSB 和 AMX 的漏洞。
为了检测存在commit2.cgi 接口漏洞的设备，我们开发了一个简单的基于IoT 自动化检测系统的插件，这个插件包含了几千种固件产品的信息，包括我们从网上发现的所有WiMAX CPE的固件信息，使用这个插件，我们就可以确定这些固件哪一个是来自GreenPacket, 华为, MADA, ZyXEL and 中兴， 关于漏洞影响设备列表，请查看我们的漏洞披露公告。
IoT 设备生命周期
这些含有漏洞的设备都已经很陈旧了， 有的在2010年前就被生产了，根据华为的反馈信息，它们所有受到漏洞影响的设备在2014 年后就不在提供技术支持， 也不会进行任何升级更新 。安全研究员Pierre Kim 在2015年发现了华为其他系列的WiMAX 设备中存在漏洞，华为的回应也是已经不再对存在漏洞的设备提供技术支持了。 我们把这个漏洞报告给了CERT/CC ,它们接收了这个漏洞，并给这个漏洞编号，非常感谢，但是很不幸，CERT 没有收到来自ZyXEL的对此漏洞的回应。 给所有的含有漏洞的设备进行升级是不可能的了，唯一的办法就是更换新的设备。ISP 服务商应该尽可能的减少 此次漏洞的攻击面，不仅仅要限制对web 接口、SSH、Telnet的访问，还要限制通过TR-O69协议的连接。有关更多关于此次漏洞的信息，请参阅我们的漏洞披露公告。