# 对某创新路由的安全测试
### 0x00 题外话
* * *
很荣幸能够参加乌云的众测，之前一直都是以旁观者的身份在乌云Zone里头围观的，也感谢Insight Labs&乌云的基友给了我这次参加测试的机会。可以说这次整体测试下来，有成功，也有失败，可谓是收益良多。接下来我就把我这次测试的经验和大家分享一下。本人技术有限，如有遗漏和不足，敬请大家多多指教。
### 0x01 测试背景
* * *
本次众测的题目是叫做“某创新应用安全众测”，一看到这个标题，一种神秘的感觉油然而生，把创新和安全联系起来，感觉就比较带劲儿了。根据以往的测试经验，一个新产品与老产品相比，往往可能存在更多的漏洞，创新也给我们白帽子提供了很好的发现漏洞的机会。其实本次测试的产品，在此之前确实比较少见，不过最近互联网上又有好几个厂家在推这类产品。它是一款基于云平台的家庭路由器产品，官方对它的描述是“可安装APP的路由器，功能无限扩展，极客为您定制开发！”，把APP的概念引入到路由器上，让路由器的功能更加的丰富，也是一种趋势所在。不过个人感觉，涉及到云平台的东西，一旦安全性出现问题，就将给用户带来巨大的影响，所以厂商花大力气在产品安全上下工夫，也是对用户负责的体现。
### 0x02 测试方向
* * *
本次测试的产品分为两个方面，一个是云端服务器的安全，另外一个就是路由器本身的安全。 云端服务器的安全相信大家比较都熟悉，主要就是对网站常见的漏洞、网站逻辑问题和服务器安全进行测试，这里我就不再做过多的表述。本文的重点主要放在对路由器本身的安全测试上。
### 0x03 验明真身
* * *
收到路由器后，我迫不及待的为他宽衣解带，取出真身，插上电源，进行连接。连接上管理界面以后，发现UI做的十分精致，登陆之后使用FireBug抓包查看其请求的地址，具体如图所示： 
玩过OpenWrt的同学应该十分熟悉这串字符，它是登陆后系统所赋予的一个会话令牌，用于验证用户是否登陆的。于是，我就联想到，这款基于云平台的智能路由器，是不是就是基于OpenWrt二次开发的呢？如果使用OpenWrt进行开发的话，是不是就有可能打开SSH连接端口？最终我的猜想得到了证实，我在云插件当中找到了工程模式插件，进行了安装，之后使用NMAP对路由器进行端口扫描，扫描结果如图所示： 
发现路由器的SSH端口已经打开了，于是使用SSH进行连接，输入帐号密码，如图所示，连接成功！ 
既然这是一款基于OpenWrt二次开发的产品，一般web界面都是使用lua进行开发，然而lua语言是一款脚本语言，可以直接查看其源码来对其进行漏洞分析。既然这样，我们就可以通过SFTP下载固件当中的lua源码，通过黑白盒测试的结合，来更加快速的发现问题。 但是，通过连接测试，发现SFTP服务并未被安装，于是执行以下两条命令进行安装：
“`
opkg update
opkg install vsftpd openssh-sftp-server
“`
执行后，系统出现以下提示： 
系统提示找不到vsftpd和openssh-sftp-server这两个软件包，仔细一看，opkg的更新软件源为https://upgrade.turboer.com，而不是OpenWrt默认的http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages，可见厂商把更新源修改成了自己的服务器地址，并且该地址并不包含这两个软件包。 解决这个问题的办法很简单，只要使用vim命令，编辑替换/etc/opkg.conf文件当中的相关内容，就可以将软件包安装地址指向官网的地址了。 修改之后，重新执行以下命令，就可以启动SFTP服务了！
“`
opkg update
opkg install vsftpd openssh-sftp-server
/etc/init.d/vsftpd enable
/etc/init.d/vsftpd start
“`
### 0x04 下载源码
* * *
根据以往对OpenWrt的研究经验，知道OpenWrt的Web界面源码是保存在/usr/lib/lua目录下，于是，使用FileZilla将该目录下的所有文件都下载到本地，以便分析。如图所示。 
### 0x05 分析源码
* * *
由于之前对lua语言研究的也不多，所以这回也只能够硬着头皮的来翻源码。经过了一段时间的查看以后，发现该路由器Web界面大量采用Ajax技术来调用API接口，而主要功能实现代码也就是在这些API接口上，这些API接口的代码则是在/usr/lib/lua/luci/controller/api/下的lua文件当中实现，如图所示。 
首先，我对这些代码的用户验证机制进行了分析，在分析后发现，API中的每个功能都在lua文件的头部进行定义，其中有一个很重要的参数就是控制是否需要用户验证通过才能访问该接口，具体代码如图： 
这些以entry开头的代码，就是对功能函数进行定义，经过测试，如果最后一个参数如果为true，就意味着该接口无需用户登陆即可访问！ 由于需要验证的接口采用URL中的stok参数和Cookie中的stok字段来进行验证，这种验证方式由于URL中的stok参数无法预测，从而避免了CSRF和XSS攻击。从危害性上来考虑，无需验证的接口存在漏洞，将直接影响到路由器以及客户端计算机的安全。 基于以上几方面的原因，我们着重对这些无需用户登陆即可调用的接口进行测试。
### 0x06 远程命令执行漏洞
* * *
经过了全面的阅读源代码，发现代码当中大量使用fork_exec、os.execute、luci.sys.call、luci.util.execi等函数，来调用一些系统命令。这类函数在PHP、JSP、.NET代码审计当中，一度被列为危险函数。因为这类函数一旦过滤不严格，将用户输入的非法内容带入，将直接继承web服务的权限来执行有害的系统指令。在OpenWrt当中，Web服务的运行权限为ROOT！ 所以，一旦无需用户登陆即可调用的接口当中存在这类的漏洞，攻击者即可构造恶意页面，远程执行任意命令！本地局域网攻击者也可以直接提交相应的数据，来获取路由器的权限！ 于是，我采用正则表达式来对这些危险函数进行查找，分析其是否有可能执行用户带入的危险参数，终于，在system.lua -> set_systime() 函数当中，发现了问题。该函数具体代码如图： 
该API接口从客户端以POST方式接收date、h、mi、s这是个值，并且没有经过任何过滤，就放到了luci.util.execi函数当中执行，通过构造date、h、mi、s其中任意值，都可执行任意系统命令，攻击代码如下： 向
“`
http://192.168.199.1/cgi-bin/turbo/api/system/set_systime
“`
页面post以下数据：
“`
date=1&h=1&mi=1&s=1’%3Bid>/tmp/aa.txt%3B’
“`
就会在/tmp/目录下生成aa.txt，其内容为id命令执行后的结果
“`
uid=0(root) gid=0(root)
“`
远程攻击着可以构造自动POST的js代码，使用xss或者诱骗方式让用户访问，以达到远程攻击的效果。 攻击代码如下：
“`
请登录后查看评论内容