本帖最后由 Grav1ty 于 2022-4-30 00:57 编辑
解析漏洞总结
文件解析漏洞概述
文件解析漏洞,是指Web容器（Apache、Nginx、IIS等）将一些特殊文件解析成脚本文件格式，导致攻击者可以利用该漏洞实现非法文件的解析。 解析漏洞的分类常见的解析漏洞分为 IIS解析漏洞，Apache解析漏洞和Nginx解析漏洞
IIS解析漏洞IIS(Internet Information Services)是微软出品的灵活、安全、易于管理的Web服务器。
IIS 6.0 解析漏洞
漏洞简介IIS 6.0 在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。这一漏洞有两种完全不同的利用方式：
/test.asp/test.jpg 目录解析 会将 test.jpg 解析为 asp 文件
test.asp;.jpg 文件解析 ， 此类文件在Windows下不允许存在，:.jpg默认不解析，剩下/xx.asp
iis把asa，cdx，cer解析成asp文件的原因：这四种扩展名都是用的同一个asp.dll文件来执行。
环境一般为 IIS/6.0 搭配 windows 2003
修复方法阻止创建.asp类型的文件夹
阻止上传 xx.asp;.jpg 类型的文件名 阻止上传.asa, .cer,.cdx 后缀的文件
环境搭建和复现记得 连接 windows2003 的CD
[color=rgba(0, 0, 0, 0.75)] 
IIS 7.0/7.5 CGI解析漏洞
漏洞简介IIS7/7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7/7.5本身的漏洞。
漏洞条件php.ini 里的 cgi.cgi_pathinfo=1
IIS7 在fast-cgi 运行模式下 测试（这个漏洞我会在nginx详细叙述 大家往下看）
修复方法1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,只要1.jpg不存在就会显示404页面
2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php
环境搭建和复现搭建IIS7.0
Apache 解析漏洞
多后缀解析漏洞
漏洞描述 Apache 解析⽂件的规则是从右到左开始判断解析,如果后缀名为不可识别⽂件解析,就再往左解析，直到碰到认识的扩展名为⽌，如果都不认识，则会暴露其源代码。这种⽅法可以绕过基于⿊名单的检查。
比如：test.php.x1.x2.x3 ，Apache将从右至左开始判断后缀，若x3非可识别后缀，再判断x2，直到找到可识别后缀为止，然后将该可识别后缀进解析 test.php.x1.x2.x3 则会被解析为php 我们可以完全上传⼀个 xxx.php.abc 这样名字的 webshell ，Apache仍然会当做PHP来解析。 Apache 能够识别的文件在mime.types文件里。
影响版本
Apache 2.0.x <= 2.0.59 Apache 2.2.x <= 2.2.17 Apache 2.2.2 <= 2.2.8
修复方法 ：
后缀验证尽量使用白名单的方式，这样即使使用不存在的后缀名，也无法绕过。 Apache配置问题<FilesMatch "shell.jpg">
SetHandler application/x-httpd-php
这时只要文件名是shell.jpg，会以php 来执行。 Apache提供了一种很方便的、可作用于当前目录及其子目录的配置文件——.htaccess(分布式配置文件) 将Apache的/etc/apache2/sites-available/default里AllowOverride None改为AllowOverride All AllowOverride All
开启rewrite_mod a2enmod rewrite
这样.htaccess文件就会生效。 在win 下 必须先开启mod_rewrite功能 先开启httpd.conf 将下面这个行的注解拿掉 #LoadModule rewrite_module modules/mod_rewrite.so AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # Options FileInfo AuthConfig Limit #将
AllowOverride None修改为AllowOverride All ****
测试 方法1：
SetHandler application/x-httpd-php
方法2：
AddHandler php5-script .php
方法3：
AddType application/x-httpd-php .jpg方法2 ：上传 webshell.php.jpg 方法1和方法3： 上传 webshell.jpg
修复方法
1.apache配置文件，禁止.php.这样的文件执行，配置文件里面加入
Order Allow,Deny
Deny from all
2.关闭重写 a2dismod rewrite
Apache HTTPD 换行解析漏洞
漏洞简介
Apache HTTPD是美国阿帕奇（Apache）软件基金会的一款专为现代操作系统开发和维护的开源HTTP服务器；Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。在解析PHP时，xx.php\x0A将被按照PHP后缀进行解析，导致可以绕过一些服务器的安全策略。
条件
1、获取文件名时不能用$_FILES['file']['name'],因为它会自动把换行去掉。 2、Apache版本为2.4.0到2.4.29 3、服务器必须是linux系统，因为windows环境下不支持后缀名带有换行符\x0a
影响版本
HTTPD ：2.4.0~2.4.29 漏洞原理 看完上面的源代码我们很容易就能知道我们上传xx.php%0a和xx.php是不一样的，我们上传xx.php%0a就可以对文件上传的黑名单进行了绕过
SetHandler application/x-httpd-php
只要满足这么一个正则匹配，就会告知Apache将这个满足匹配的文件按PHP文件来解析 但是不巧的是这里还有一个东西就是$这个东西，它是用来匹配字符串结尾位置的，而且如果设置了RegExp 对象(正则表达式)的 Multiline(/m) 属性，则 $ 也匹配 ‘\n’ 或 ‘\r’。 所以如果我们设置了RegExp 对象的 Multiline 属性(\m)的条件下，$还会匹配到字符串结尾的换行符（也就是%0a),于是也就产生了这么一个换行解析漏洞 测试 上传一个后缀末尾包含换行符的文件，绕过 FilesMatch 1.php\x0a => 1.php apache通过mod_php来运行脚本，其2.4.0-2.4.29中存在apache换行解析漏洞，在解析php时xxx.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。该漏洞属于用户配置不当产生的漏洞，与具体中间件版本无关。
在1.php后面插入一个\x0A(注意，不能是\x0D\x0A，只能是一个\x0A)，不再拦截： 社区版Burp点击1.php后面的一个字节，然后右键->Insert byte。再将插入的00修改为0a。 访问刚才上传的/1.php%0a，发现能够成功解析，但是这个文件的后缀不是php后缀，说明目标存在解析漏洞
漏洞修复
1.升级到最新版本 2.将上传的文件重命名为时间戳+随机数+.jpg的格式并禁用上传文件目录执行脚本权限
Nginx 解析漏洞
Nginx PHP CGI 解析漏洞(fix_pathinfo)
影响版本 ： 漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞
漏洞原理vim /etc/nginx/conf.d/default.conf
Nginx 默认是以CGI的方式支持php解析的，普遍的做法是Nginx 配置文件中，通过正则匹配配置SCRIPT_NAME 当访问  /.php 时， $fastcgi_script_name 会被设置为webshell.jpg/.php 传递给PHP CGI fix_pathinfo 默认为1 ，如果开启了，php 会认为 script_name 是 webshell.jpg ,.php 为path_info, 所以 webshell.jpg 会被当做php 来解析 由于nginx的特性，只要url中存在.php 就会被以php文件处理 注：新版本php引入了security.limit_extensions，限制了可执行文件的后缀，默认只允许执行.php文件 使得该漏洞难以被成功利用
利用条件# php.ini
cgi.fix_pathinfo=1
# php-fpm.conf
security.limit_extensions = .php .jpg
测试/1.jpg/1.php
/1.jpg/.php
/1.jpg%00.php php 版本<5.3.4
/1.jpg/%20\0.php
但是fastcgi在处理.php文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置用于修复路径,如果当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了’/test.png’。 3、最重要的一点是php-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型(即指定什么类型的文件当做代码解析),此项设置为空的时候才允许fastcgi将’.png’等文件当做代码解析。
环境搭建和测试 windows 搭起来有问题，利用vluhub 靶场 搭建
修复建议1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0(慎用);
若实在将cgi.fix_pathinfo的值设置为0，就将php-fpm.conf中的security.limit_extensions后面的值设置为.php 2.在Nginx配置文件中添加以下代码： if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}代码的意思：当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。 3.使用Apache服务器的，在相应目录下放一个 .htaccess 文件，内容为： <FilesMatch "(?i:\.php)$">
Deny from all
4.不提供上传的原文件访问，对文件输出经过程序处理。 5.图片单独放一个服务器上，与业务代码数据进行隔离。
空字节代码执行漏洞
漏洞简介
Ngnix在遇到%00空字节时与后端FastCGI处理不一致，导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码
影响版本Nginx 0.5.x
Nginx 0.6.x Nginx 0.7-0.7.65 Nginx 0.8-0.8.37
测试
漏洞太老，基本不存在 1.上传一个qwzf.jpg图片文件 3.就会将qwzf.jpg作为PHP文件进行解析 修复方法 1.升级nginx 2.禁止在上传文件目录下执行php文件 3.在nginx配置或者fcgi.conf配置添加下面内容： if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
nginx 文件名逻辑漏洞（CVE-2013-4547）
漏洞描述 错误地解析了请求的URL,错误地获取到用户请求的文件名,导致出现权限绕过、代码执行的连带影响。
漏洞原理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;
}（1）在关闭fix_pathinfo的情况下(即cgi.fix_pathinfo=0)，只有.php后缀的文件才会被发送给fastcgi解析 （2）存在CVE-2013-4547时，请求qwzf.jpg[0x20][0x00].php，这个URI可匹配到正则\.php$，进入到Location块； （3）进入后，Nginx错误地认为请求的文件是qwzf.jpg[0x20]，然后设置其为SCRIPT_FILENAME的值发送给fastcgi。 （4）fastcgi根据SCRIPT_FILENAME的值，将qwzf.jpg[0x20]以php文件的形式进行解析，从而造成了解析漏洞。 也就是说，我们只需要上传一个空格结尾的文件，即可用PHP进行解析。
影响版本Nginx 0.8.41-1.4.3
Nginx 1.5 -1.5.7 测试 上传jpg文件 ，文件名为 webshell.jpg ,文件内容为(或者上传图片马)： GIF89a <?php phpinfo(); ?> 在上传时 使用burp 添加空格 访问上传的文件， webshell.jpg /.php添加两个空格，修改第二个空格为 00
windows解析问题
windows 环境与中间件处理不一致解析
在windows环境下，xx.jpg[空格] 或xx.jpg. 这两类文件都是不允许存在的，若这样命名，windows会默认除去空格或点，这也是可以被利用的！ IIS 6.0/7.0/7.5、Nginx、Apache 等 Web Service 解析漏洞总结 在向一台windows主机上传数据时，你可以抓包修改文件名，在后面加个空格或点，试图绕过黑名单，若上传成功，最后的点或空格都会被消除，这样就可得到shell。
参考链接 https://www.anquanke.com/post/id/219107 https://blog.csdn.net/u014270687/article/details/45805953 https://blog.csdn.net/weixin_45728976/article/details/104359582
| 
发表于 2022-4-30 00:56:20
