作者：Duncan SecTeam
0x00、引言
自从Team转向IoT安全后，我们确实发现了一些有趣的现象以及让人揪心的网络安全隐患，本以为这些问题只存在于中小微企业或者说非网络安全企业，直到发表上一篇文章【1】之后，我们才开始反思之前的假设或者基于已有经验得出的推定。随着互联网的飞速发展以及智能化设备（手机，平板，智能家电，智能机器人以及智能查询终端），传统的企业信息化不可避免的要向物联网过渡，一是节约企业建设和运营成本（比如，部署WiFi/IP摄像头可以减少传统网络布线的人财物消耗），二是智能设备的引入的确可以进一步压缩人力成本支出（HR和财务部门最喜欢这个吧）。 中小微企业出于成本考虑，往往会在安全与效益这个两难抉择中，“莫名其妙”地选择后者（或许，这也是国内网络安全企业生存压力始终没能缓解的原因之一吧）。当然，Team前一篇文章【1】中的某网络安全公司应该不能算作此例之中，他们内网的曝露的确是公司IoT建设中的一个绝对偶然。
然而，小白最近因为家中遭受灾害的原因，意外发现了成都市某消防部门IoT设备所导致的一系列安全隐患。出于小白天生的“呆萌”与“自保”心理，小白第一时间把详细情况和关键截图全部提交到该消防部门的2家主管单位（由于该消防部门的主管衙门上报渠道实在太少了，费了很大力气终于成功提交了相关内容，好不容易得到了所上报事件的处理流水单号）。本想上报了就完了，没想到今天因为同样的原因，小白又去了一趟该消防部门，相关漏洞还没有被堵上，想了想还是写点东西吧，万一成都市政府信息部门的技术大牛看到了，咱好歹也算为消防工作做了点贡献吧，再不济还有几百大洋的稿费啊（毕竟，快过年了嘛）。
0x01、背景介绍
前些日子，小白因为自己家里的事情去消防部门配合工作。出于职业习惯，小白通过某WiFi共享软件在该消防部门的大门口（确切地说，还在围墙外面），发现了一个名为“cd****”的WiFi，并查看到WiFi密码为“xfdd119”（**是该消防部门管辖区域的拼音缩写），该WiFi信号强度不算强，没有达到满格信号。由于这个消防部门周围没有任何商业设施（不要说咖啡厅，就连麻将馆或者茶馆都没有啊），小白心想这应该就是这个消防大队的WiFi了吧。
向站岗的消防队员出示证件并报备后（还用84消毒液喷了鞋底，但没消毒手部，WHY？），小白进入了该消防部门，此时的WiFi信号强度已经明显变强，最终WiFi信号满格。此外，WiFi信号在大院里头（因为旁边全是消防车，小白不敢拍照，不能犯原则性错误），一楼以及三楼等不同地理位置信号强度都是满格，当然只是基于一加6手机检测到的信号，至于iPhone是否能够如此，不得而知（毕竟，iPhone烂的掉渣站的WiFi芯片早已臭名昭著）。由此可见，这个部门应该部署了一个很专业的无线路由器并且应该配备了很多无线中继，或许是因为消防部门内部需要部署的很多专业设备必须入网吧。整个测试的背景大概就是这样个情况。
以下是近源渗透过程中的软硬件及网络资源：
硬件：
——一加（OnePlus） 6，8G+128G
——型号：ONEPLUS A6000
软件：
——Android：10
——H2OS：A6000_22_201022
——文件管理器：X-plore （Android）
——Linux模拟器：Andrax v5
——Linux模拟器：Kali NetHunter
0x02、接入网络
小白此次整个测试过程的起点，也算是整个网络的接入点，就是这个名为“cd****”的WiFi。手机接入的是该WiFi的4G频段，后来发现该WiFi还有一个5G频段。
0x03、基于Android手机的近源测试
如前文所说，因为家里遭受了灾害损失，小白需要到该消防部门报告情况并申领相关表格，因此没有带笔记本电脑，身边可用计算设备就只有一台快停更的OP6（一加6）手机。
按照常规的测试套路，小白分别在andrax和nethunter上做了一些简单的内部网络探测操作。下面是andrax是执行nmap扫描的操作结果和转换为xls格式的扫描结果。内网里面有不少开放telnet的设备，好奇。。。。。。
如team之前发布的文章所说【1】，andrax默认没有安装traceroute，懒惰的小白选择了使用Nethunter来查看路由，但是忘了保存截屏。小白很清楚的记得，traceroute的第二条是一个公网地址，所以认为这个部门的网络建设还是不错的，至少WiFi网络没有通过别的内部网络再接入互联网。WiFi网络直接进互联网的话，最起码可以少暴露一些不必要的信息，加大内网发现难度，尤其在近源测试的时候，测试人员几乎是没有足够的时间进行A段，B段网络的扫描的（即便带了一个2万毫安的充电宝）。
从扫描结果看得出来，192.168.*.0/24网段网关应该是192.168.*.1，毕竟开放的端口还是很典型的网关端口。于是，小白试了试，确实看到了一个H3C路由器的管理登录口，发现admin账户（H3C默认的管理员账户，默认密码与用户名相同）的密码居然与WiFi密码相同！！！恕小白直言，这样的低级错误真不应该出现在这么重要的职能部门，毕竟这个错误完全赖不着别人，全是网管人员自己给自己挖的坑。
其中，111.9.*.22这个公网IP居然在被静态绑定了，那么就有意思了，我想擅长内网渗透的大牛应该半秒就懂了吧，小白属于后知后觉那种类型的（愚钝型），反应了老长时间才想明白。。。然后，用nmap尝试探测了111.9.*.0/24网段，挺有意思的，感觉是该部门完全使用的一个公网C段。
通过Android上超好用的X-plore，小白验证了一下SMB服务都是可以访问的，进一步印证111.9.*.0/24是一个有公网IP的内部网段，估计是运营商预留的。对于消防等涉及老百姓安危的行业和部门，这么做完全合情合理！
其中，有一个网段的445使用的全是SMB v1.0协议，另一个网段使用的是SMB v2.0及以上协议，并且设置了密码保护，这算是网管做的很好的地方（此处应有掌声）。
0x04、后续处理
虽然小白只是一个IoT安全领域的小学生，但是基本的法律常识是有的，不仅讲“武德”，还遵纪守法，以白帽子的标准严格要求自己，因此该部分不给出任何可能的内网（横向）渗透措施，并且第一时间通告了该消防部门的2家主管单位。
0x05、总结
1.IoT环境下，WiFi是一种高效、便捷的通讯手段，但也是黑客入侵的一种有效途径，是IoT环境下很现实的网络安全隐患。
2.网络安全运维人员的安全意识仍旧是IoT网络安全中一个不可忽视的短板（至少相对较短的短板）。
3.年底了，各位同行主要保重身体，同时更要保住Job，下班了别着急回家“吃鸡”，“打农药”，看看自己的一亩三分地有没有被WiFi密码泄露给坑了。
4.建议政府机构畅通一下网络安全反馈渠道，健全反馈机制，比如找安全客合作一下什么的。白帽子想要做点好事真的好难啊，要么反馈网站错误，要么无法提交反馈，要么提交了反馈却始终不搭理你。。。。。。
参考：
1.基于智能手机的近源渗透案例分享——“点到为止”的测试某网络安全公司.https://www.anquanke.com/post/id/229286
2.双龙战记：Andrax vs. Nethunter. https://www.anquanke.com/post/id/223493
3.IoT环境下的渗透测试之构建高效WiFi破解字典. https://www.anquanke.com/post/id/219315
4.基于安卓设备的Hacking. https://www.freebuf.com/articles/terminal/246679.html
5.pHacking Highway Service Station. https://www.freebuf.com/articles/terminal/247145.html