常见中间件漏洞

总结

IIS：PUT漏洞、短文件名猜解、远程代码执行、解析漏洞等

Apache：解析漏洞、目录遍历等

Nginx:文件解析、目录遍历、CRLF注入、目录穿越等

Tomcat:远程代码执行、war后门文件部署等

JBoss:反序列化漏洞、war后门文件部署等

WebLogic:反序列化漏洞、SSRF任意文件上传、war后门文件部署等

IIS

PUT漏洞

根据put协议，当我们浏览某个网站，访问某个资源时，如果网站存在这个资源，则会进行替换，若网站不存在这个资源，则会创建这个资源，所以我们可以利用put直接对网站写shell。

而IIS Server 如果在 Web 服务扩展中开启了 WebDAV ，配置了可以写入的权限，结合put协议就会造成任意文件上传漏洞。

漏洞修复方案

Web 服务扩展中关闭 WebDAV

禁用访客写入权限。

短文件名猜解

IIS的短文件名机制，用户通过特殊payload访问构造的某个存在的短文件名，会返回404，访问不存在的短文件名，返回400，故而可以暴力猜解短文件名。

它使攻击者可以获取Web根目录下的文件/文件名，造成敏感信息泄露

payload

http://192.168.111.138/{文件名}*~1*/a.aspx
漏洞修复方案

1升级.net framework；

2修改注册表禁用短文件名功能：

快捷键Win+R打开命令窗口，输入regedit打开注册表窗口，找到路径‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem’，将其中的 NtfsDisabledotNameCreation这一项的值设为 1，1代表不创建短文件名格式，修改完成后，需要重启系统生效；

3CMD关闭NTFS 8.3文件格式的支持；

4将web根目录的内容拷贝到另一个位置，如c:\wwwroot到d:\wroot,然后删除原文件夹，再重命名d:\wroot到c:\wwwroot。

目录解析

IIS5.x/6.0，在网站下建立文件夹的名称中带有.asp、.asa等可执行脚本文件后缀为后缀的文件夹时，其目录内的任何扩展名的文件都被IIS当作可执行文件来解析并执行

文件解析

在IIS6.0下，分号后面的不被解析，也就是说xx.asp;.jpg将被当做xx.asp解析并执行。

其他解析类型

在IIS6.0的版本，如下几种文件类型也会被执行。
xxx.asa xxx.cer xxx.cdx

php-cgi漏洞

在IIS-7.0和IIS-7.5的版本，在php配置文件中，开启cgi.fix_pathinfo，然后上传一个1.jpg的一句话木马文件。然后用菜刀访问1.jpg/.php即可连接一句话木马。

漏洞修复方案

1.对新建目录文件名进行过滤，不允许新建包含‘.’的文件;

2.曲线网站后台新建目录的功能，不允许创建文件夹;

3.限制上传的脚本执行权限，不允许执行脚本;

4.编写正则过滤.asp/xm.jpg，通过ISApi组件过滤.

Apache

Apache HTTPD 换行解析漏洞

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

http:ip地址:端口/文件名.php%0a

Apache多后缀解析漏洞

apache httpd支持一个文件多个后缀，windows对于多后缀的识别是看最后一个“.”之后的后缀名。apache对于多后缀文件的识别是从后往前识别，最后一个后缀不能被识别时，会往前识别。

http://IP地址/uploadfiles/1.php.jpg

Apache HTTP 路径穿越漏洞

在其2.4.49版本中，引入了一个路径穿越漏洞，满足下面两个条件的Apache服务器将会受到影响：
  版本等于2.4.49
  穿越的目录允许被访问（默认情况下是不允许的）
  攻击者利用这个漏洞，可以读取位于Apache服务器Web目录以外的其他文件，或者读取Web目录中的脚本文件源码，或者在开启了cgi或cgid的服务器上执行任意命令。

读取任意文件poc
/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
执行任意命令poc

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

/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh   最下面添加echo;id

Nginx

Nginx 配置错误导致漏洞

下面两种情景十分常见：

用户访问http://example.com/aabbcc，自动跳转到https://example.com/aabbcc
用户访问http://example.com/aabbcc，自动跳转到http://www.example.com/aabbcc
第二个场景主要是为了统一用户访问的域名，更加有益于SEO优化。

在跳转的过程中，我们需要保证用户访问的页面不变，所以需要从Nginx获取用户请求的文件路径。查看Nginx文档，可以发现有三个表示uri的变量：

$uri
$document_uri
$request_uri
解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。

错误配置：

location / {
    return 302 https://$host$uri;
}
#因为`$uri`是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。
利用方式
#请求内容
curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
#测试结果
[root@blackstone insecure-configuration]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Date: Thu, 12 Jan 2023 12:18:16 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: http://192.168.2.169:8080/
Set-Cookie: a=1

我们使用burp抓包可以看到另一种可能性：在我们发送两个连续的换行\r\n后，可以直接修改返回报文的返回体。插入js代码引发xss

解决方案

在获取用户的请求路径时，配置文件内出现的配置应当是$request_uri,例如：

location / {
    return 302 https://$host$request_uri;
}
#1.编辑配置文件，投放进docker
[root@blackstone configuration]# cat fix1.conf
server {
        listen 8080;

​```
    root /usr/share/nginx/html;

    index index.html;

    server_name _;

    location / {
            return 302 http://$host:$server_port$request_uri;
    }
​```

}

#2.将配置文件放到特定目录，重启nginx
[root@blackstone configuration]# docker exec -it fa2e43aabeec /bin/bash
root@fa2e43aabeec:/# cp fix1.conf /etc/nginx/conf.d/
root@fa2e43aabeec:/# rm -f /etc/nginx/conf.d/error1.conf 
root@fa2e43aabeec:/etc/nginx/conf.d# nginx -s reload

#3.查看效果，确实可以有效消除CRLF的影响
[root@blackstone ~]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Date: Wed, 08 Feb 2023 18:44:14 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1

目录穿越漏洞

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass传递给后端端口，而静态文件需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就需要用alias设置目录的别名

location /files {
    alias /home/;
}
此时，访问http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。

但我们注意到，url上/files没有加后缀/，而alias设置的/home/是有后缀/的，这个/就导致我们可以从/home/目录穿越到他的上层目录：

2.2.2 利用方式
http://192.168.2.169:8081/files../

Nginx 解析漏洞复现

这二者合在一起，在网页有文件上传功能时，百分百引发文件上传漏洞。属于高危配置手法

#php.ini --- 在php.ini中开启路径修复功能
cgi.fix_pathinfo=1

#php-fpm.conf --- 在php-fpm模块中开启了.jpg的php解析
security.limit_extensions = .php .jpg

漏洞成因就是同时开启路径修复和图片后缀名解析(或者直接将解析配置为空)

http://192.168.2.169/uploadfiles/c3d13d4e323f0927a9dadb85ece4aea3.jpg/.php

一、低版本nginx
空字节代码执行漏洞：nginx 0.5.x、nginx 0.6.x、Nginx 0.7-0.7.65、Nginx 0.8-0.8.37中可以通过在任意文件名后面增加%00.php解析为php，如1.jpg%00.php

二、php-cgi漏洞
和IIS的第四点相同，在php配置文件中，开启了cgi.fix_pathinfo，导致图片马1.jpg可以通过访问1.jpg/.php、1.jpg%00.php解析成php文件

windows解析漏洞

Windows操作系统中，文件名不能以空格或.开头，也不能以空格或.结尾。
当把一个文件命名为以空格或.开头或结尾时，会自动地去掉开头和结尾处的空格和.。利用此特性，也可能造成文件解析漏洞

Tomcat

Tomcat 弱口令 && 后台getshell

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接口权限


      

    用户tomcat拥有上述所有权限，密码是tomcat

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

    为什么上传war包

    
war包是用来进行Web开发时一个网站项目下的所有代码,包括前台HTML/CSS/JS代码,以及后台JavaWeb的代码。

当开发人员开发完毕时,就会将源码打包给测试人员测试,测试完后若要发布则也会打包成War包进行发布。War包

可以放在Tomcat下的webapps或word目录,当Tomcat服务器启动时，War包即会随之解压源代码来进行自动部署。


详情可以参考：[16.Tomcat弱口令 && 后台getshell漏洞 - bmjoker - 博客园](https://www.cnblogs.com/bmjoker/p/9892653.html)

### WebLogic

#### WebLogic弱口令 && 后台getshell

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

详情可以参考[12.Weblogic 弱口令 && 后台getshell漏洞 - bmjoker - 博客园](https://www.cnblogs.com/bmjoker/p/9822886.html)

#### WebLogic反序列化漏洞

T3协议在开放WebLogic控制台端口的应用上默认开启. 攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击.
（可通过nmap脚本–script=weblogic-t3-info查看weblogic版本信息和t3协议是否开启）

[Weblogic漏洞复现(全漏洞版本) - Arrest - 博客园](https://www.cnblogs.com/arrest/articles/17506650.html#0x01:CVE-2017-10271 XMLDecoder 反序列化漏洞)

#### Weblogic SSRF漏洞

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。

SSRF漏洞存在于`http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp`，我们在burpsuite下测试该漏洞。访问一个可以访问的IP:PORT，如`http://127.0.0.1:80`：(发送get请求也是一样)

[Weblogic漏洞复现(全漏洞版本) - Arrest - 博客园](https://www.cnblogs.com/arrest/articles/17506650.html#0x01:CVE-2017-10271 XMLDecoder 反序列化漏洞)

### JBoss

#### Jboss 4.x版本jmx-console控制台弱口令getshell

Jboss4.x版本在jmx-console控制台下存在像tomcat后台一样的控制台，我们可以通过上传war包的形式来上传马达到getshell

http://192.168.18.181:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.deployment:type=DeploymentScanner,flavor=URL


[Jboss漏洞复现(全漏洞版本) - Arrest - 博客园](https://www.cnblogs.com/arrest/articles/17509983.html#0x04:Jboss 4.x版本jmx-console控制台弱口令getshell)

#### CVE-2017-12149(JBoss 5.x6.x 反序列化漏洞)

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

[Jboss漏洞复现(全漏洞版本) - Arrest - 博客园](https://www.cnblogs.com/arrest/articles/17509983.html#0x03:CVE-2017-12149(JBoss 5.x6.x 反序列化漏洞))