中间件常见漏洞

中间件漏洞

IIS

文件解析漏洞

IIS 5.x-6.x 解析漏洞

---

1：/xx.asp/xx.jpg 、/xx.asa/xx.jsp

• 漏洞原理：.asp或者 .asa目录名字，这些目录下服务器会将其中所有文件视为asp解析。比如：http://xxx.xxx.xxxx/xxx.asp/a.jpg，a.jpg会当成asp解析，原因是在.asp目录下。
• 影响版本：IIS 5.x-6.x

---

2：xx.asp;.jpg

• 原理：IIS6.0版本以下，会将 “ 1.asp ;.jpg ” 文件名从前往后读 结果就是当作 ASP文件解析。结合下面的文件后缀解析漏洞，可以将asp换成其他后缀同样在影响版本内能够解析。
  即：*.asp;.jpg、*.asa;.jpg、*.cer;.jpg 后缀的文件，就可以通过服务器校验，并且服务器会把它当成asp文件执行。
• 影响版本：IIS6.0版本以下

---

3：xx.asa、xx.cer、xx.cdx

其他文件后缀名解析，被运维人员疏漏掉的名单。

• 原理：asp.dll解析执行这三种文件，所以漏洞引发的是asp.dll文件
• 影响版本：配置出错导致，无关版本问题

下面解释一下文件后缀：

• asa 全局配置文件
  解释：相当于全局变量，可以被一个web应用程序中所有asp文件访问到，里面可以写变量以及函数等等，所以说这个也可以当成asp文件进行解析。

• cer 证书
  证书文件也能够被IIS解析，可自行配置解析哪些文件。

• .cdx 文件
  复合索引文件

---

4：IIS.7/8 + CGI配置不当=解析漏洞

这里很容易和nginx的解析漏洞搞混，IIS单单cgi开启就可能导致漏洞，而nginx需要配合配置文件不当。
访问方式：webshell.jpg/xxx.php
与Nginx cgi开启配置不当一同理解效果更好
(在IIS 中 需要配置很多东西，比较难出现，但是测试的时候发现在版本内不妨可以尝试一下，但是对于nginx，配合上nginx的配置不当就影响很大了)

• 原理：webshell.jpg/xx.php 会将webshell.jpg的内容当成php程序进行解析，这时候由于最后的那一个.php。
  漏洞前提：cgi.fix_pathinfo=1
  且恰好php.ini里默认cgi.fix_pathinfo=1，所以漏洞现如今还是有可能存在的，对其进行访问的时候，在URL路径后添加.php后缀名会当做php文件进行解析，漏洞由此产生。
• 影响版本：IIS.7~8

Apache

文件解析漏洞

apache解析漏洞

---

1：apache2.2版本解析漏洞

• 漏洞原理
  (多后缀名解析，老版本通杀漏洞)
  test.php.php123：文件解析规则是从右到左解析，有不可解析识别的就继续往左识别，因此上传文件可以通过该漏洞进行绕过，然后访问的时候正好符合了apache的解析漏洞。（现在还有很多网站还有该问题）
  比如在apache2.2版本之前是能够直接将test.php.xxx解析成php文件执行的。（但是也不妨一试现在的网站，因为这个解析漏洞影响十分之大）

  比如利用该漏洞可以打7z，漏洞影响下apache能解析xx.php.7z
  这个可能还真的很容易被人忽略可能会将7z加进白名单或者没有加上黑名单等等，有的版本可以有的版本不可以，在版本2.2之前都行
  注：目前还测试了apache5.2.17是能直接解析.php.7z后缀名的文件。
  (记住，一定是 .php.7z 后缀名能够当成php解析，还要特定的版本，反正都试一下准没错，不一定说7z就能过)

• 影响版本：apache 2.2

---

2：其余配置问题导致漏洞

漏洞原理：

• AddHandler php5-script
  （1）如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要 文件名里包含.php 即使文件名是test2.php.jpg 也会以 php 来执行。
• AddType application/x-httpd-php
  （2）如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg，一样能以 php 方式执行xx.jpg
  (但是这种情况比较少出现)

影响版本：配置问题，无关版本

修复方案：
1.apache配置文件，禁止.php.这样的文件执行，配置文件里面加入
（php3 是防止其他文件后缀名也被解析，这里用了 | 或符号，所以可以自行添加）

<Files ~ “.(php.|php3.)”>
        Order Allow,Deny
        Deny from all
</Files> 

2.用伪静态能解决这个问题，重写类似.php.*这类文件， 打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so
步骤如下：
把httpd.conf文件内下图中的 #号去掉—>重启apache—>在网站根目录下建立.htaccess文件：

1. 下面步骤是把httpd.conf #号去掉
   
2. 下面是.htaccess文件代码

   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteRule .(php.|php3.) /index.php
   RewriteRule .(pHp.|pHp3.) /index.php
   RewriteRule .(phP.|phP3.) /index.php
   RewriteRule .(Php.|Php3.) /index.php
   RewriteRule .(PHp.|PHp3.) /index.php
   RewriteRule .(PhP.|PhP3.) /index.php
   RewriteRule .(pHP.|pHP3.) /index.php
   RewriteRule .(PHP.|PHP3.) /index.php
   </IfModule>
   

---

3：黑名单绕过 .htaccess

漏洞原理：
黑名单绕过 .htaccess 和 文件名叠加特性绕过（分布式配置文件）
精确控制能被解析成php代码的文件，不容易被发现
只要文件名匹配到所定义的字符串，就会将该文件当作php解析

1 <FilesMatch "自定义.gif">
2 SetHandler application/x-httpd-php   #在当前目录下，如果匹配到自定义.gif文件，则被解析成PHP代码执行
3 AddHandler php5-script .gif          #在当前目录下，如果匹配到自定义.gif文件，则被解析成PHP代码执行
4 </FilesMatch>

影响版本：上传绕过，无关配置

---

4：\0A HTTPD换行解析漏洞(CVE-2017-15715)

漏洞说明说在前头：注意访问的时候需要添加上%0a，这一点很重要！

CVE-2017-15715的出现是由于apache 在修复第一个后缀名解析漏洞时，
使用 正则表达式匹配后缀，在解析php时xxx.php\x0A 将被php后缀进行解析，
导致绕过一些服务器的安全策略，影响版本Apache HTTPd 2.4.0~2.4.29。

漏洞原理
apache这次解析漏洞的根本原因为$，在正则表达式中，$用来匹配字符串结尾位置。但是如果在HTTPD的配置中设置了RegExp对象的Multiline属性，则 $ 也匹配 \n 或 \r 。要匹配$字符本身，请使用 \$ 。就导致如果在上传文件时，在文件名后面添加一个十六进制的换行符 \x0A ，比如 1.php\x0A ，也能被正常解析，并且能够绕过系统的黑名单检测。所以理论上只要使用正则来匹配文件后缀名，就有可能存在该漏洞。在影响版本中，默认的Apache配置即可利用。

总而言之：是因为apache正则匹配可以匹配回车或换行符，当我们加上\x0a的时候php\x0a不在黑名单内，就是绕过黑名单检测，绕过后因为apache又能够且正常解析，即能把.php\x0a当成php文件，因为\x0a是换行而不是后缀名中的最终解析成功了。
说白了就是.php\x0a根本不在黑名单后缀名内，但是apache又能正常解析，所以就导致了漏洞。

抓包通过修改文件名后十六进制加一个\x0A即可

注意访问的时候需要添加上%0a，这一点很重要！再提一遍！

影响版本：2.4.0~2.4.29

---

下面小小的总结一下以及贴出修复方案，apache上传木马文件思路就是：

1：先看看是否是2.2版本之前。从右往左解析到有能解析的后缀名就解析，比如：test.php.xxx

2：或许运维人员配置了 AddHandler php5-script .php尝试上传xx.php.jpg等等只要包含又.php即可解析 。

3：又或者多尝试几个后缀名jpg/png/php1/php2/php3等等，或许运维人员就AddType application/x-httpd-php .jpg添加了这些扩展名为解析文件。

4：可以尝试上传.htaccess文件看是否能够成功上传​。

以上就是apache常见的文件解析漏洞

---

Apache 2.4.49/2.4.50路径穿越（CVE-2021-41773/42013）

讲解之前一定要记住，穿越的前提是需要知道访问的目录是一个存在且可访问的目录。这就是为什么大多数人复现的时候都带上了/icons/和/cgi-bin/文件夹

• 漏洞原理
  ap_normalize_path函数在对路径参数进行url解码，然后判断第一个字符是否是.，如果是.的话就会继续判断后两个字符是否为./，即这两步骤就是否存在…/的路径穿越符。
  但！我们协商.%2e/的时候，进入第二次判断.后面两个字符是否是./的时候检测到时%2，而不是./，那么就成功绕过进行目录穿越了。

网上没看到有人讲为什么解码后不应该是…/然后进行判断的时候肯定是过不了的，为什么会造成这个漏洞？？？

---

注意：这里我提问了gpt，给出的解释是因为解码后的url路径和进行判断的url路径值不一致，也就说解码后的路径没有用来判断，否则解码后的肯定是…/，进行判断的而是.%2e/所以导致判断后两个字符的时候出现了漏洞。。。
GPT：解码后的路径可能并没有及时影响到路径检查的逻辑，导致原始的 %2e 和解码后的 . 在不同步骤中分别被处理，这正是导致漏洞的根本原因。

---

• 漏洞复现（直接无脑用payload就行了）

• icons目录
  /icons/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd
  
  实测%2e%2e也可以，因为还是老样子，后面判断./不成功就造成漏洞了
  

• cgi-bin目录（RCE）
  payload

  POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash HTTP/1.1
  Host: 192.168.29.140:8080
  Cache-Control: max-age=0
  Upgrade-Insecure-Requests: 1
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 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;