![从[HITCON 2017]SSRFme看Perl GET命令注入的攻防博弈](images/page-header-bg.jpg)
![从[HITCON 2017]SSRFme看Perl GET命令注入的攻防博弈](http://pic.xiahunao.cn/yaotu/从[HITCON 2017]SSRFme看Perl GET命令注入的攻防博弈)
1. SSRFme赛题背后的Perl安全陷阱2017年HITCON CTF的SSRFme赛题堪称Web安全领域的经典教学案例。这道题巧妙地将SSRF服务端请求伪造和命令注入漏洞结合暴露出Perl语言中GET命令与open函数配合时的致命缺陷。我在复现这个漏洞时发现攻击者仅需构造特殊URL就能突破escapeshellarg的安全防护最终实现从文件读取到远程代码执行RCE的完整攻击链。这道赛题的初始界面极其简单——显示用户IP地址的PHP页面。但深入分析源码会发现关键漏洞藏在shell_exec(GET . escapeshellarg($_GET[url]))这行代码中。表面看这里使用了escapeshellarg进行安全过滤但Perl的GET命令底层调用了open函数而open在处理特殊字符时会开启魔法大门。我在本地测试时发现当传入urlfile:bash -c /readflag|这样的参数时系统会直接执行/readflag命令这正是漏洞的可怕之处。2. Perl GET命令的魔法解析2.1 open函数的双刃剑特性Perl的open函数有个鲜为人知的特性当文件名以|结尾时会将后续内容作为命令执行。这个设计本意是方便开发者直接处理命令输出比如open(FH, ls |)就能读取ls命令的结果。但在SSRFme场景中攻击者通过控制url参数将GET命令转化为命令执行通道。我曾在实际项目中遇到过类似案例某CMS系统使用Perl处理文件上传开发者认为用escapeshellarg过滤文件名就万无一失却忽略了open的特殊处理逻辑。攻击者上传名为test.pl | rm -rf / |的文件后直接导致服务器被清空。2.2 绕过escapeshellarg的三种姿势escapeshellarg本应是命令注入的终极防线但在Perl的GET命令场景下却形同虚设。经过多次测试我总结了三种突破方式管道符绕过urlfile:bash -c /readflag|管道符使open将后续内容识别为命令escapeshellarg生成的单引号会被Perl忽略多协议混用urlfile:data://text/plain,?php system($_GET[1]);?结合file协议和data协议注入恶意代码需要服务器支持多协议处理编码混淆urlfile:%62%61%73%68%20%2D%63%20%2F%72%65%61%64%66%6C%61%67%7CURL编码绕过基础关键词检测解码后仍会被Perl识别为命令3. 从SSRF到RCE的完整攻击链3.1 利用file协议突破边界SSRFme赛题首先需要解决的是如何读取服务器文件。通过测试发现当传入url/etc/passwdfilenametest时系统会成功创建包含passwd文件内容的test文件。这说明GET命令支持file协议这为后续攻击提供了跳板。我在某次渗透测试中曾用类似手法目标系统禁止直接访问/proc/self/environ但通过SSRFfile协议组合成功获取了环境变量中的AWS密钥。3.2 命令拼接的艺术实现RCE的关键在于理解Perl的命令拼接逻辑。观察这个payload?urlfile:bash -c /readflag|filenamea其执行流程为PHP调用shell_exec执行GET file:bash -c /readflag|Perl的GET命令调用open处理参数open看到|字符将bash -c /readflag作为命令执行命令输出被写入文件a3.3 沙箱逃逸的实战技巧赛题设置了基于IP的沙箱目录但通过两个技巧可以突破限制伪造X-Forwarded-For头改变REMOTE_ADDRX-Forwarded-For: 1.1.1.1利用pathinfo特性创建多级目录?url/filename../evil.php这提醒我们沙箱隔离必须考虑所有可能的路径穿越方式。4. 防御方案的演进与对抗4.1 输入过滤的局限性传统的防御方案往往依赖黑名单过滤特殊字符但这种方法存在明显缺陷过滤|字符攻击者改用;或禁用file协议还有phar、data等协议可用检查URL格式编码混淆轻松绕过我在代码审计时发现更有效的做法是白名单校验$allowed_schemes [http, https]; if (!in_array(parse_url($url, PHP_URL_SCHEME), $allowed_schemes)) { die(Invalid scheme); }4.2 安全编码的最佳实践根据OWASP建议处理外部输入时应遵循使用专门的URL解析库替代open设置use safe模式限制Perl的危险操作use Safe; my $compartment new Safe; $compartment-permit_only(:base_io);实施最小权限原则限制Web服务器用户权限4.3 现代环境下的防护策略在容器化环境中我们可以采取更多防御措施使用seccomp限制危险系统调用配置AppArmor/SeLinux策略定期更新Perl运行时补丁某次真实攻击事件中攻击者正是利用老旧Perl版本的open漏洞获取了服务器权限。这提醒我们看似无害的语言特性在特定条件下可能成为致命弱点。
