基于时延的盲道研究：受限环境下的内容回传信道

在一次漏洞赏金活动中，挖到个命令注入的洞，我先以时延作为证明向厂商提交该漏洞，厂商以国内网络环境差为由（的确得翻墙）拒收，几次沟通，告知若我能取回指定文件 secret.txt 才认可。目标是个受限环境：禁止出口流量、NAT 映射至公网、无页面回显、无法猜测 web 目录，换言之，没有出口流量无法反弹 shell、NAT 隔离也就不能建立正向 shell、页面无输出想看到命令结果不可能、找不到 web 目即便成功创建 webshell 没有容器能解析。我如何才能查看 secret.txt，顺利拿到赏金呢？（嗯，金额是敏感信息嘛 5C7ZR2FOWDS35FZANBQXEZDTMVSWIIHFSCL67PE74W7IRZN7VPS25A7FWCDOLJEN422LX354QEFA====）

0×00 浅入深出

探讨技术问题，我习惯拿大家都能访问得到的环境作为例子，这样，一方面，你能通过操作来验证我的想法是否正确，另一方面，实践也能触发你对同个问题的不同思考。由于保密协议的原因，我没法对前面提到的真实案例作更多的细节描述，好不容易找到了一个环境类似的 wargame，与你分享。

，账号 natas9:W0mMhUcRRnG8dcghE4qvk3JA9lGt8nDl，提供源码，你得想法查看 /etc/natas_webpass/natas10 的内容：

命令注入，我习惯上先摸清服务端有哪些限制条件，是否限制内容长度、是否过滤特殊字符、是否过滤系统命令、白名单还是黑名单、是否要闭合单/双引号、操作系统类别，这些信息对于构造载荷至关重要。页面右下角给出了源码，难度降低了不少，但摸清限制条件，是你在其他黑盒测试场景中值得优先考虑的。ok，现在查看源码：

命令注入，我习惯上先摸清服务端有哪些限制条件，是否限制内容长度、是否过滤特殊字符、是否过滤系统命令、白名单还是黑名单、是否要闭合单/双引号、操作系统类别，这些信息对于构造载荷至关重要。页面右下角给出了源码，难度降低了不少，但摸清限制条件，是你在其他黑盒测试场景中值得优先考虑的。ok，现在查看源码：

从代码可知，服务端未作任何恶意输入检查，直接将输入 $key 作为 grep -i $key dictionary.txt 的命令行参数传递给 passthru() 函数执行系统命令。

从代码可知，服务端未作任何恶意输入检查，直接将输入 $key 作为 grep -i $key dictionary.txt 的命令行参数传递给 passthru() 函数执行系统命令。

显然，未过滤最基本的命令替换符 $()，那么，提交 $(sleep 4)，若应答延迟 4s 则可确认漏洞存在。（关闭攻击端网络带宽占用高的应用，避免影响结果）我先提交普通字符串 xxxx，应答为：

页面无实际内容输出，耗时约 0.3s。接下来提交 xxxx%24%28sleep+4%29，应答如下：

页面无实际内容输出，耗时约 0.3s。接下来提交 xxxx%24%28sleep+4%29，应答如下：

耗时约 4.3s，那么，可确认该接口存在命令注入漏洞。其中，两点注意：一是，载荷直接写在 burp 拦截的数据包中，没有经过浏览器 URL 编码，所以你得手动将字母和数字之外的字符按 URL 编码（burp 的 decoder 模块）；二是，攻击载荷尽量包含先前一样的普通字符串，避免引起计时误差。

耗时约 4.3s，那么，可确认该接口存在命令注入漏洞。其中，两点注意：一是，载荷直接写在 burp 拦截的数据包中，没有经过浏览器 URL 编码，所以你得手动将字母和数字之外的字符按 URL 编码（burp 的 decoder 模块）；二是，攻击载荷尽量包含先前一样的普通字符串，避免引起计时误差。

要利用漏洞获取 /etc/natas_webpass/natas10 内容，当前的代码环境为 grep -i $key dictionary.txt，首先呈现的思路是，注入命令分隔符以结束 grep -i，注入查看 natas10 内容的命令，注释掉余下的 dictionary.txt，这样，原始命令行被分隔成语法正确的三部份。命令分隔符用 ;，注释符号用 #。所以，构造如下载荷（黄色高亮）作为参数 key 的输入：