隔壁的女神买了所谓不“kiss”便不让上的“kisslnk”路由器，这是对我有什么暗示吗？只怪我太年轻，“kiss”之路漫漫修远兮，屌丝还须上下去摸索。索性我也买个 kisslink 路由器来，对其一探究竟。
女神的诱惑还是蛮大的，我费了九牛二虎之力把买来的 kisslink 组成下面的网络环境，用来分析 kisslink 的安全性。
分析思路是：
1. 通过笔记本对 kisslink 扫描，用于检测路由器开放端口情况；
2. 通过 burp suite 抓取 app 和 kisslink 路由器通讯的数据，用于检测路由器是否存在漏洞；
3. 通过 openwrt 上 tcpdump 抓取 kisslink 和云端通讯数据，用于检测路由器和云端是否存在漏洞；
4. 通过 openwrt 上 tcpdump 抓取 kisslink 和云端通讯数据，获取路由器固件下载地址；
按照思路行动起来，经过漫长的 配置->抓包->分析->测试过程，我们得到如下结果：
1. 路由器开放 23 端口，用户名密码未知；
2. 路由器某接口存在命令注入漏洞，gw 参数过滤不严格造成命令注入
3. 路由器固件地址为：http://api.kisslink.com:31082/NBOS-1.1.0.1766，包如下：
战果不错，其实到这里我们通过命令注入漏洞已经能够获取到路由器的权限。但是对于接近女神毫无卵用。
有了路由器的权限我们继续深挖，通过前面的命令注入漏洞，直接覆盖 /etc/passwd 和 /etc/shadow 文件，添加一个空密码的 root 用户，先登录到路由器里面，找啊找，找啊找，找到了好多有用的信息
1. 路由器启动 dropbear，但是却监听到了 127.0.0.1 的 2222 端口；
2. 在 /usr/local/sbin 目录内发现一个好有爱的 start_ssh 文件，内容：
dbclient 是 openwrt 下的 SSH 客户端，上面的那条命令应该是端口转发的，把路由器本地的 2222 端口转发到 debug.kisslink.com 这台服务器的 10000 端口
我在路由器上手动执行下这条命令
命令没有任何错误回显，执行成功，通过 ps 和 netstat 验证下
请注意，我们没有输入任何密码。也就是说路由器上存放有私钥或者密码等认证信息，找啊找，找啊找，找到了，在 /etc/rc.d 目录下 kickoff.sh 这个文件，这是路由器启动初始化的脚本文件，里面有这么一行：
在这个过程中我让同事帮我逆向了 dbclient 这个文件，看看密码是不是存放在这个文件里面，很快他就告诉我看看是不是有 DROPBEAR_PASSWORD 这个环境变量。
我们知道了 root debug.kisslink.com
，还有什么好说的，登录呀
还记得上面所说的反弹端口吧，这个功能我揣测是官方留的调试“后门”，不过是不是所有的路由器都可以反弹呢？感觉离女神又近了，我就在服务器上继续，找啊找，找啊找，还真被我找到了，http://debug.kisslink.com:8080/login.html，既然我们有服务器权限，想办法登录进去
所有路由器啊，不但能够远程更新路由器固件，还能够对任意一台在线路由器启动反弹 SSH 的操作，BUT，我们不知道路由器密码。女神就在眼前，我怎么能让自己看不见，既然管理员是通过这台服务器管理的路由器，那我就想办法在管理员去管理其他路由器的时候记录下路由器的密码，反正不管你信不信，我是相信所有路由器的密码都是一样的。
功夫不负人，不日就获取到了路由器密码
女神我来了！！！
我想 kisslink 厂商自己内部肯定使用了 kisslink 路由器，我们想办法连到内网去。首先我们通过服务器的日志获取到 kisslink 办公出口 IP，不出所料应该是下面这个：
通过管理后台，查询到有下面三个路由器
通过链接 http://debug.kisslink.com:8080/ap_detail.php?wtpindex=5067 查看这台路由器，然后“启动反向”功能，反弹到本地的 10122 端口，我们在服务器上登录下试试
简单对内网做了下探测，192.168.2.250 应该是内部的测试服务器，
该服务器的 8080 端口应该是 Bugzilla 系统
好吧，到此为止，以上所有操作均以安全研究为出发点，没有对服务器，路由器做任何多余的操作，尤其是破坏性操作，同时没有获取任何数据。
