***防火墙密码恢复手记

防火墙密码恢复手记

公司在用的一款防火墙，密码意外遗失，无法登陆管理平台。虽然防火墙可以正常工作，但却无法修改配置，不能根增加和删除访问列表中的IP地址，不能调整访问策略。防火墙默认仅开通https web管理界面，未开启telnet、ssh等其他管理通道。

联系厂家寻求技术支持，被告知必须返厂更换芯片，费用大约在2000元左右（网上搜了一下，几乎所有密码遗失的客户最终都只能选择返厂）。公司用于该网络联网的仅此一台防火墙设备，终端数量在500以上，无其他硬件备份方案。因用户众多，管理要求细致，防火墙配置非常复杂，保存的配置文件也不是最新的。若返厂维修的话，则无法找到完备的替代方案。

于是决定先自己想办法，开启密码恢复之旅。Go！

猜测密码，自动验证

首先想到的是根据可能的密码规则和常用组合，构造一个密码字典，通过编写简单的Python脚本进行登录验证。万一不行的话，就穷举来尝试暴力破解。

可是开始跑脚本的时候发现想法实在太天真了，存在两个致命的问题：

1. 防火墙白天负荷过重，Web响应非常慢。有时候一个请求可能在半分钟以上。
2. Web管理平台有登录次数限制，大约6次密码错误以后，就会锁定账号一段时间。

在尝试了几十个最可能出现的密码组合后，彻底放弃了这条捷径。

看来偷懒是不成了，必须得动真格的。

搜寻漏洞，获取控制权

nmap扫描发现防火墙只开通了https端口。不是专业的安全研究人员，只能在网上搜索该款防火墙的漏洞资料，不(suo)幸的是，还真发现了不少。

找到的第一篇文章提到了Heartbleed漏洞，却未对漏洞利用方式做过多解释。需要更多学习资料，根据这个方向继续搜索，又找到了一些文章。其中，NSA Equation Group那篇文章信息量最高，对漏洞的特征和产生的原因分析的非常透彻，利用方式也做了简要说明。由于该设备尚未按厂家要求进行“方程式”漏洞修复升级，按照文章的提示，用Brup进行Eligible Candidate漏洞测试（打算用Postman，但因chrome的https证书问题放弃），漏洞果然还在！

怀着激动的心情，尝试了 ls -la />/www/htdocs/1、 find / -type f>/www/htdocs/1 等指令，对防火墙文件系统的目录结构进行初步了解，也看到了配置文件存放的位置。执行 cp /XXX/conf/config>/www/htdocs/1，把配置文件down下来一看，果然是新鲜的味道。

启动telnetd服务并尝试连接，报错，估计是没有加特定启动参数的缘故，没做深入研究。看来暂时还是只能通过https漏洞方式跑命令了。

随着执行命令次数越来越多，Brup构造请求的方式效率太低，于是写了简单的Python函数在IPython下面跑，终觉得灵活性不够。最后决定采用HTTPie命令行的方式发送https请求（curl没有httpie方便），后续所有命令都通过这种方式交互。

$ http --verify=no https://x.x.x.x/cgi/maincgi.cgi 'Cookie: session_id=x`ls -la /tmp>/www/htdocs/1`'

文件上传，执行脚本文件

之前都是一次请求执行一条命令，效率太低，也存在诸多限制。最好的方式是上传一个sh脚本在防火墙上执行，这就需要以某种方式传送文件到防火墙上去。

另一方面，根据漏洞名称和Equation Group搜索到这篇文章：Equation Group泄露文件分析，才注意到这是国际顶尖黑客组织，也是NSA合作的方程式黑客组织（Equation Group），被另一个名为“The ShadowBrokers”的黑客组织攻下了，珍藏的系列高级工具被打包分享。这可是个好东西！赶紧下载解密，找到ELCA的漏洞利用代码，运行后却发现没有如逾期般的启动nopen远程管理软件，原因未知，颇有些失望。不过在py源码中看到了文件上传的方式，其实就是利用了cgi文件上传处理方式，它