文章

AWS web3 GameDay-远程代码执行

一、RCE 底层原理

1.1 什么是 RCE?

RCE,远程代码执行,是指攻击者通过网络,利用应用程序或服务的漏洞,在目标主机上执行任意命令或代码。这类漏洞通常危害极大,因为攻击者不需要物理接触目标机器即可控制其行为。

1.2 RCE 实现原理

RCE 的实现,通常依赖于以下几个底层机制:

  • 输入未过滤:应用程序允许用户上传或输入的数据被直接拼接或用作代码执行入口(如eval、system命令等)。

  • 命令注入:程序将外部输入拼接到命令行里执行,没做严格检查,攻击者就能注入要运行的恶意命令。

  • 反序列化漏洞:在反序列化未经验证的数据时,攻击者构造带恶意代码的对象串,反序列化时即触发执行。

  • 文件包含/上传漏洞:通过合法接口上传木马,或通过如PHP的file包含本地/远程文件被执行。

  • 脚本执行漏洞:如XSS结合服务端处理,最终导致远程脚本被执行。

1.3 执行流程(以Web服务器为例)

  1. 用户发起携带恶意代码/命令的请求。

  2. 服务端处理时,未对输入做严格校验,将输入内容用于拼接Shell命令、eval、反序列化、文件操作等敏感操作。

  3. 系统或解释器实际解析并执行了恶意代码,达到命令执行目的。

  4. 攻击者获得主机权限,继续横向渗透或者部署后门。


二、现实例子

2.1 典型命令注入(PHP)

<?php
$ip = $_GET['ip'];
system("ping $ip");
?>

攻击者访问:

 http://site.com/?ip=8.8.8.8;id

实际执行:ping 8.8.8.8;idid命令被执行,系统信息被返回。

2.2 反序列化 RCE(Java)

如果服务端会反序列化客户端传来的对象且没做校验:

攻击者构造带有恶意 payload 的序列化数据包,触发远程加载或执行任意代码。

2.3 Log4j 2 RCE(CVE-2021-44228)

攻击者通过精心构造的请求包,利用Log4j的JNDI功能让服务端去访问恶意LDAP服务器,下载和执行Java类代码,导致RCE。


三、如何识别未授权进程与恶意代码

3.1 系统和网络层面

  • 检查异常的进程(如名称、路径异常或非标准位置出现)。

  • 审计新启动/异常进程的二进制文件哈希,发现未知程序。

  • 检查持久化手段(如计划任务、服务、注册表、Autorun等)。

  • 审查关键目录下的新文件(如 /tmp/, /var/tmp/, C:\Windows\Temp\, 用户家目录等)。

  • 查看端口监听异常(如莫名其妙开启的 4444、3389、8080等)。

3.2 日志和行为层面

  • 审计shell、powershell等命令执行日志。

  • 检查Web日志中是否有形如;cat /etc/passwd${jndi:ldap://..}等可疑请求。

  • 使用HIDS(如AIDE、OSSEC、Wazuh)监控文件和进程变化。

  • 应用层增加WAF,观察是否拦截了恶意 payload。


四、修复与防御建议

4.1 代码层面修复

  • 永远不直接拼接用户输入到命令、文件名、路径等敏感位置。

  • 对所有输入严格白名单过滤、转义。

  • 如果需要执行系统命令,使用参数数组方式调用如exec(command, args),避免字符串拼接。

  • 禁止高危函数(evalsystemshell_execpopen、反射等)。

4.2 配置与系统层面

  • 权限最小化,服务账户无root/管理员权限。

  • 应用进程以独立账户运行,禁止shell、脚本解释器等不被直接调用。

  • 禁止Web服务下写权限目录可执行,如给上传目录加noexec

  • 打开系统和Web服务器的补丁自动更新。

4.3 应急加固与检测

  • 对未知来源文件和脚本定期杀毒、沙箱扫描。

  • 定期巡检后台进程、计划任务、自动服务项。

  • 使用主机入侵检测系统(如Wazuh)加强主机的安全基线和日志告警管理。


五、总结

远程代码执行属于非常严重的安全漏洞,底层本质是程序在执行代码的过程中对输入信任、校验力度不够,或调用了一些高危系统接口。结合监测、审计和加固手段,可以在一定程度上实现防御和快速响应,杜绝类似威胁。

 

许可协议:  CC BY 4.0