远程命令执行漏洞复现：一次教科书式的远程沦陷

凌晨两点，我敲下最后一个payload，命令屏幕上的执行响应代码从400变成200。目标服务器像被捏住喉咙的漏洞鸟，安静地吐出了`/etc/passwd`的复现内容。这已经不是远程第一次了——每当我演示远程命令执行（RCE）漏洞，总有观众觉得我在变魔术。命令实际上，执行这漏洞简单得让人后背发凉。漏洞

拿最常见的复现Web应用举例。某后台管理系统有个"Ping检测"功能，远程运维人员输入IP地址，命令系统返回丢包率。执行开发人员图省事，漏洞直接调用了系统命令：system("ping -c 4 " . $_GET['ip'])。复现你输入`127.0.0.1`，它老老实实执行；但你输入`127.0.0.1; cat /etc/shadow`，分号后面的命令照样被吞进去执行。没有过滤，没有白名单，没有参数化调用。

我复现过最讽刺的一次，是在某政府网站的"网络诊断"页面。那个输入框甚至没做长度限制，我直接提交了`8.8.8.8 | whoami`，返回结果里明晃晃躺着`www-data`。服务器是Linux，Web服务用root跑的——这等于把整台机器的钥匙挂在了大门口。

更常见的坑藏在文件上传功能里。某个图片处理接口，允许上传GIF动图，后端用ImageMagick转换格式。攻击者上传一个精心构造的图片文件，文件名写成`shell.gif;id`，配合命令拼接漏洞，服务器就乖乖执行了`id`命令。我见过有团队用这种方式直接反弹shell，拿到内网权限后横向移动，最后把整个数据库拖走了。整个过程不超过十分钟，而他们防火墙日志里连条告警都没有。

防护手段说起来也简单，但执行起来总有人偷懒。最蠢的是用黑名单过滤，把`;`、`|`、`&&`这些符号全禁掉。可编码绕过呢？URL编码、Unicode编码、反斜杠转义，甚至换行符`%0a`都能让黑名单失效。我见过一次，开发者过滤了空格，结果我用`${ IFS}`（Linux下的内部字段分隔符）替代空格，照样执行了命令。

真正有效的办法是彻底抛弃命令拼接。用PHP的`escapeshellarg()`转义参数，或者干脆不用system函数，改用`exec()`配合参数数组。Python那边，subprocess模块必须用列表传参，别用shell=True。这些细节写出来轻飘飘，但每次漏洞通告里都有公司栽在上面。

有一次我拿到一个漏洞报告，对方厂商的修复方案是把`ping`换成`ping -c 4`，以为加了参数限制就安全了。结果我用`127.0.0.1$(cat /etc/passwd)`，命令替换照样生效。那瞬间我差点笑出声——他们连最基础的命令注入原理都没搞懂。

复现RCE漏洞最迷人的地方在于，它不像SQL注入那样需要猜字段，也不像XSS那样要等用户点击。命令执行是直接的，粗暴的，像拿螺丝刀捅进服务器的心脏。你输入什么，它就执行什么，这种确定性给了攻击者极大的掌控感。而防御方往往要等到日志里出现异常进程，或者磁盘被写满恶意脚本，才后知后觉地发现沦陷。

写这篇东西不是教人作恶。我见过太多开发者在漏洞报告里写"已修复"，实际上只是把错误信息隐藏了。真正的修复需要重构代码逻辑，把外部输入永远当作不可信数据。如果你现在正维护着任何调用系统命令的接口，花十分钟检查一下：输入有没有经过严格过滤？命令是否用参数化方式调用？如果答案是否定的，那么你的服务器，现在可能正被别人远程握着。那种感觉，比凌晨两点的咖啡还提神。