防火墙密码恢复手记
公司在用的一款防火墙，密码意外遗失，无法登陆管理平台。虽然防火墙可以正常工作，但却无法修改配置，不能根增加和删除访问列表中的IP地址，不能调整访问策略。防火墙默认仅开通https web管理界面，未开启telnet、ssh等其他管理通道。
联系厂家寻求技术支持，被告知必须返厂更换芯片，费用大约在2000元左右（网上搜了一下，几乎所有密码遗失的客户最终都只能选择返厂）。公司用于该网络联网的仅此一台防火墙设备，终端数量在500以上，无其他硬件备份方案。因用户众多，管理要求细致，防火墙配置非常复杂，保存的配置文件也不是最新的。若返厂维修的话，则无法找到完备的替代方案。
于是决定先自己想办法，开启密码恢复之旅。Go！
猜测密码，自动验证
首先想到的是根据可能的密码规则和常用组合，构造一个密码字典，通过编写简单的Python脚本进行登录验证。万一不行的话，就穷举来尝试暴力破解。
可是开始跑脚本的时候发现想法实在太天真了，存在两个致命的问题：
- 防火墙白天负荷过重，Web响应非常慢。有时候一个请求可能在半分钟以上。
- 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文件上传处理方式，它每次会在/tmp目录下生成一个cgi*的临时文件。ELCA利用代码的流程是连续执行多次指令，第一次 rm /tmp/cgi*清理tmp目录，接着post上传文件同时复制保存一份 cp /t*/cg* /tmp/.a，再加执行权限 chmod +x /tmp/.a，最后执行 /tmp/.a。
当然，代码并没有直接上传一个可执行文件，而是巧妙（恕见识少，我知道*nix下经常这样干）的将需要的多个文件用tar打包后，附到sh脚本的最后。在sh脚本中用dd命令将tar包copy出来再解压运行。下面是工具中stage.sh的部分代码：
文件tar打包的Python代码片段：
就我的需求而言，只是上传脚本执行，就不用做得那么复杂了。简单的post我的sh脚本，同时执行 sh /tmp/cgi*。前提是我的sh脚本中都做了清理工作 rm /tmp/cgi*。
http --verify=no -b -f POST https://x.x.x.x/cgi/maincgi.cgi \'Cookie: session_id=x`sh /t*/cg*`\' a@test.sh; http --verify=no https://x.x.x.x/1
HTTPie可以用 uploadfilename@localfilename 的方式很方便的实现文件上传。之所以两条指令在一行是为了方便查看前一个脚本的输出。
#!/bin/sh
# 清除/tmp/cgi*，防止干扰下次运行
rm -f /t*/cgi*
echo =============================== >/www/htdocs/1
date >>/www/htdocs/1
echo "***************" >>/www/htdocs/1
cd /tmp
ps >>/www/htdocs/1
netstat -nltp >>/www/htdocs/1
ls -la /xxx/etc /data/auth/db /tmp >>/www/htdocs/1
上面的示例脚本就可以一次进行多种操作，获取进程信息、网络连接情况、目录文件等多种信息，大幅减少交互次数提高效率。
逆向分析，寻找密码
做了很多准备工作，找到了比较便捷的脚本执行方式。而且根据ps结果来看，指令是以root权限运行的。接下来要开始干正事了，tar cf /home/htdocs/1 / 打包文件系统，down下来准备逆向分析。因为web登录入口指向maincgi.cgi，就从它开始。
逆向分析的过程相当繁杂、漫长、枯燥乏味，具有相当的挑战性，所以需要坚定的毅力和不时涌现的灵感。无数次调整思路和方向，无数次寻找新的突破口。
我现在也记不清当初分析时的前因后果，就把一些分析的结果整理下，做一个简单的分享。
入口 maincgi.cgi
maincgi.cgi 位于 /www/cgi/ 目录下。用IDA进行逆向分析。
根据登录form提交的 username 和 passwd 在string窗口搜索，x跟踪调用情况分析，最终来到 000403D4 函数内。
下面是更容易理解的C伪代码（我开始分析的时候没找到可用的hexrays，这是事后撰写此文时找到的。