提示:本文记录了博主的一次曲折的打靶经历。
目前只知道目标靶机在172.16.71.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 172.16.71.0/24
锁定目标靶机地址为172.16.71.135(kali逐渐是71.134,虚拟机网关是71.2)。
用下面的命令扫描一下靶机上开放的端口。
$ sudo nmap –p- 172.16.71.135
接下来通过下面的命令,枚举一下端口上运行着什么服务。
$ sudo nmap -p22,80 -A -sV -sT 172.16.71.135
又是OpenSSH和Apache,接下来探查一下Apache。
先手工用浏览器访问一下看看。
额,是一个静态页面,没有什么特别的。
通过dirsearch枚举一下目录。
$ dirsearch –u http://172.16.71.135
貌似有管理控制台,先不急着下手,用dirb挂上big字典再扫一遍。
$ dirb http://172.16.71.135 /usr/share/wordlists/dirb/big.txt -X .php
$ dirb http://172.16.71.135 /usr/share/wordlists/dirb/big.txt -X .html
$ dirb http://172.16.71.135 /usr/share/wordlists/dirb/big.txt -X .htm
$ dirb http://172.16.71.135 /usr/share/wordlists/dirb/big.txt -R
没有扫描出太特别的内容,只是把joomla目录更进一步枚举了一下。
既然扫出了这么多内容,接下来还是手工进去看看都包含些什么吧。
进入/joomla的时候,默认会进入如下所示的页面,还附带有登录表单。
尝试猜测用户名密码也没有效果,接下来看看下面的administrator目录。
嗯,这个基本上就是管理控制台的入口了,先查查joomla是个什么鬼吧,这竟然是个零代码建站的内容管理系统。不过到目前为止不知道joomla的具体版本,默认用户等相关内容,先继续往下看。通过/joomla/administrator/components/com_admin/admin.xml文件基本可以判断joomla的版本应该是3.1.1或者3.0.0。
除此之外,在手工探查的时候,没有找到任何有用的信息。
感觉没啥招了,搜索一下EXP试试看。
搜索出来了海量的EXP,绝大部分都是跟component和plugin有关系的,不过这对我来说如同大海捞针,现在连joomla的版本号都还没有确定下来。不过有一个名为Admin Takeover的EXP引起了我的注意,直接弄下来试试,一直报如下的错误。
实际验证了一下,当前版本的joomla上,确实没有EXP中对应的URL(http://172.16.71.135/joomla/index.php/component/users/?view=registration
)。
安装并使用joomscan进行扫描。
$ sudo apt install joomscan
$ joomscan --url http://172.16.71.135/joomla
其实这里面扫出来的内容,真正对我们有用的是版本号3.7.3。我们再扫描一下有没有对应版本的可以利用的EXP。
确实有个跨站的EXP,不过这个对我们构建反弹shell没啥帮助,暂时放弃。
到目前为止,没有任何进展,连用户名都没有锁定。初步的想法是分别对几个最可能的用户名进行爆破:admin、administrator、joker、joomla、glasgow。这里我们用到一个叫cewl的工具来构造密码字典,它的原理是爬取页面内容,进行密码字典构建,好处是具有针对性,命中率比较高。
$ cewl http://172.16.71.135/joomla > my_dic.txt
运行效果如下。
接下来,通过浏览器使用随意的用户名密码登录/joomla/administrator页面,并使用burp抓取交互过程,这里不再赘述。这里先用admin用户尝试爆破,相关配置如下图。
针对admin用户,没有爆破出来,status code一直是200,response消息都是Username and password do not match or you do not have an account yet.,如下图。
用同样的方法,爆破administrator、joker、joomla、glasgow。
最终,在爆破joomla的时候,有两个请求的status code是303(重定向),response中也没有报错信息,大概率是爆破成功了,我们手动试试,最终锁定用户名密码是joomla:Gotham。
登录到administrator下面看看。
是个控制台页面。
接下来,主要的目标是寻找构建反弹shell的突破口,最好是有能够编辑的.php文件这种,一般会在报错文件、模板文件等地方出现。
经过仔细查看,我们在上述菜单下找到了对应的模板管理,进去看看。
确实有两个模板,我们随便选一个进去看看,这里选择第二个吧。
也确实有一些php文件,我们进入index.php看看吧。
进来后,还可以编辑并保存,太好了。我们在开头添加下图所示的内容构建反弹shell,注意地址和端口号。
保存完成后,在kali建立针对8888端口的监听。
然后在前面保存php更改后的页面上点击下图所示的 Template Preview菜单。
这时候,成功构建了反弹shell,如下图。
这样,我们就完成了突破边界。
通过python优化一下shell。
$ which python
$ /usr/bin/python -c "import pty;pty.spawn('/bin/bash')"
通过下面的命令枚举一下系统信息。
$ uname –a
$ cat /etc/*-release
$ getconf LONG_BIT
这就得到了目标靶机的系统详细信息,64为的debian 10,内核版本是4.19.118-2。
先手工看一下。
www-data@glasgowsmile:/var/www/html/joomla$ cat /etc/passwd | grep -v "nologin"
还是有几个看上去正常的账号的,实在不行的话回来爆破一下。这里先尝试写入一个用户试试看。
www-data@glasgowsmile:/var/www/html/joomla$ echo "testusr:$1$SPbFLyHT$R9OwyQlyRTARX4ujvNBGY0:0:0:root:/root:/bin/bash" >> /etc/passwd
$ sudo –l
$ find / -type f -user root -perm -o=w 2>/dev/null | grep -v "/sys/" | grep -v "/proc/"
$ find / -user root -perm -4000 2>/dev/null
实在没有别的招数了,还是用linpeas扫描一下吧。首先扫出来的是一个highly probable的CVE漏洞。
直接下载poc代码,并在kali本地编译。
$ wget https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2019-13272/poc.c
$ gcc -Wall --std=gnu99 -s poc.c -o ptrace_traceme_root
上传到目标靶机后,赋予权限并运行。
ww-data@glasgowsmile:/tmp$ chmod u+x ptrace_traceme_root
www-data@glasgowsmile:/tmp$ ./ptrace_traceme_root
缺少库,现在旧版本的系统上编译一下,然后再上传靶机执行。
EXP利用失败,这个漏洞应该是补上了。接下来试试pkexec,直接下载EXP。
$ git clone https://github.com/Almorabea/pkexec-exploit.git
将pkexec-exploit文件夹下面的CVE-2021-4034.py文件上传到靶机。然后在靶机上直接运行一下。
$ chmod 775 CVE-2021-4034.py
$ python3 CVE-2021-4034.py
靶机上执行的时候,一直卡在这里不动,这个漏洞应该是确实堵上了。用另一个编译版本的EXP验证了一下,果真如此。
实在没啥招了,搜索一下EXP把,看看能不能直接通过系统漏洞进行提权,先从内核开始。
$ searchsploit kernel 4.19.118
主要就是上图中所示的两个,第二个我们刚刚试过了,没成功,接下来我们尝试试一下第一个。同样的办法,直接在低版本的linux上编译,然后拿到靶机上尝试。
$ gcc -static -o 50135 50135.c
$ searchsploit debian 10
上图中所示的两个,不过搜索了一下,这个两个漏洞只会在debian 9或者之前的版本中。
到目前为止,一直没有提权成功,不过我们知道home下除了joomla之外,还有三个用户:abner、rob、penguin。分别对这三个用户爆破一下试试看。这里使用hydra工具,先挂载前面爆破joomla的时候生成的密码字典。
$ hydra -l abner -P my_dic.txt -vV -e ns 172.16.71.135 ssh
$ hydra -l rob -P my_dic.txt -vV -e ns 172.16.71.135 ssh
$ hydra -l penguin -P my_dic.txt -vV -e ns 172.16.71.135 ssh
$ hydra -l abner -P /usr/share/wordlists/rockyou.txt -vV -e ns 172.16.71.135 ssh
$ hydra -l rob -P /usr/share/wordlists/rockyou.txt -vV -e ns 172.16.71.135 ssh
$ hydra -l penguin -P /usr/share/wordlists/rockyou.txt -vV -e ns 172.16.71.135 ssh
结果折腾了半天,始终没有爆破出来。还是回来看看home目录有没有什么遗漏吧。
/home目录下只有上述爆破的三个用户的目录,竟然没有joomla用户的目录,先找找joomla用户的默认反弹目录/var/www/html/joomla或者其上一级目录。
在joomla目录下没有发现特别有意义的内容,跟之前浏览器上找到的内容大差不差。不过在joomla的上级目录,有个how_to.txt文件指的让人怀疑。
看看内容再说。
感觉像是给Rob的一个留言,不过留言内容本身没啥稀奇的。再到更上层目录看一下,没有其它内容的话,就拿Rob开刀了。
有意思,再上层的目录下有个joomla2,这可能是备份目录啊,进去看看。
内容上感觉跟joomla目录的内容差不多,还是仔细逐个看看,不能掉以轻心。
功夫不负有心人,在joomla2的configuration.php文件中发现了上图所示的蛛丝马迹,貌似是mysql的登录登录信息,数据库信息。先不往下探查了,直接登录mysql吧。
www-data@glasgowsmile:/var/www/joomla2$ mysql -u joomla -p
本以为比较顺利,遗憾的是卡在这里了,一直没有反应,重新启动靶机还是同样的问题。
查看了一下进程和端口也是正常的,如上图所示。后来通过python3重新执行pty后,生效了,日了狗了,前面使用python3执行pty一直报错的啊(如下图)。
不过后面再次执行,很丝滑。
$ /usr/bin/python3 -c "import pty;pty.spawn('/bin/bash')"
进入joomla_db后,发现表挺多的,我们直接找跟用户有关的。
先看users表。
只有joomla用户的信息,这个我们已经不关心了。再看看其它的几个表。
最终在batjoke数据库的taskforce表中发现了我们感兴趣的内容,如上图,感觉像是经过base64编码后的用户密码。分别尝试解开看看吧。
妥妥的,如丝般顺滑。既然前面joomla给rob留了消息,那就拿Rob开刀吧。
先进入到rob用户。
这里再次查看可执行程序,没有发现特殊的内容。接下来还是看看刚才没权限访问的rob的home目录下面的内容。
先看Abnerineedyourhelp里面有些啥。
未发现特殊的信息,不过有两点值得可疑:内容好像是做了字母的rot轮换,另外最后一串信息貌似是base64编码过的内容,先尝试解码最后的字符串看看。
是乱码,再尝试用rot还原一下上面的内容(工具地址:https://gchq.github.io/CyberChef
)。
需要设置轮换数字试一下,幸运的是,轮换数字是1的时候,看上去输出的内容比较正常,这是发给Abner的消息,并且提到了密码,意思是用这个密码可以解决问题。重新把输出内容中最后的字符串进行base64解码。
这个密码有点长啊,既然有密码了,我们尝试且兑换到abner用户数进行提权试试。
切换到abner用户,然后看看home目录下有些啥。
貌似没啥特别的,逐个看看。
.bash_history里面的信息有些意思,首先貌似这个用户可以运行systemctl指令,另外貌似这个用户跟penguin有些瓜葛。先搜索一下这里提到的.dear_penguins.zip文件。
还真是有这个文件,并且文件的属主就是abner,连切换用户都省了,直接拷到/tmp目录下解开看看是啥。
嗯,文件被加密了,并且abner用户的当前密码解压成功了,看一下具体的内容。
有意思,又是一个留言,感觉像是一段台词,没啥实际意义,不过最后的一个串可能是个密码。我们用这个密码尝试登录一下penguin用户试试。
真的登录成功了。
通用先看看home目录下有些啥。
也有些值得进一步查看的内容,逐个看看。最终在SomeoneWhoHidesBehindAMask目录下的PeopleAreStartingToNotice.txt文件中发现了一些蛛丝马迹,是Joker给Penguin的留言,貌似说正在编写一个程序,只能用root运行,完成以后joker将会考本到当前目录。
提到了root权限,感觉快要搞定了。继续往下看,在user3.txt文件中的内容也挺有意思,个人猜测应该是joker用户的密码。
尝试切换到joker用户试试。
貌似没有这个用户,搜索了一下/etc/passwd文件,确实没有类似的用户。不过SomeoneWhoHidesBehindAMask目录下还有个文件.trash_old,其内容类似于一个shell脚本,如下图所示。
但是肯定没啥实际意义,不管怎么样,执行一下吧。
确实没啥用,不过这个文件是属于root组的,有没有可能通过这个玩意儿提权呢?下你看看是哪个进程在用这个文件。
貌似查不到,换个工具试试看,这里使用pspy64($ wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy64
)。下载并上传到目标靶机的/tmp目录下。
$ chmod u+x pspy64
$ ./pspy64 -p -i 2000
这次抓到了,发现root权限每分钟运行一次.trash_old程序。我们尝试直接将反弹shell写入到.trash_old文件中替换原来的“exit 0”,这个文件我们是有权限的,如下图所示。
在kali上的9999端口建立监听,可以建立反弹shell。
成功了,进一步验证一下。