漏洞复现之中间件解析漏洞
中间件解析漏洞
Apache httpd多后缀文件解析漏洞（CVE-2017-15715)
漏洞描述
Apache httpd允许一个文件可以有多个以点分割的后缀，Apache会从最右边开始识别其后缀名，如遇无法识别的后缀名则依次往左进行识别，如果运维人员给.php后缀的文件添加了处理程序 AddHandler application/x-httpd-php .php 那么在有多个后缀的情况下，只要文件含有.php后缀那么该文件就会被识别为PHP文件进行解析；如果添加了AddType application/x-httpd-php .html，那么凡是.html格式的都会以php方式执行。
形成原因
该漏洞和apache版本和php版本无关，属于用户配置不当造成的解析漏洞。
漏洞复现
1、打开Linux操作系统（比如Kali、Ubuntu等都可以，以下是用Kali实验的），利用vulhub进行漏洞复现，进入vulhub中该漏洞的目录下：
cd vulhub/httpd/apache_parsing_vulnerability
2、启动该漏洞环境，发现是一个可以文件上传的界面。
sudo docker-compose up -d
3、利用vim编辑器编写一个php脚本，将文件命名为11.php.jpg，进行上传，发现上传成功。
5、根据提示路径，访问上传的文件，发现php文件解析成功。其核心原因就是后缀jpg在白名单中，所以可以成功上传，但是由于Apache配置不当而产生的多后缀解析漏洞，导致只要后缀里有.php，就都按php解析执行，因此访问时php脚本执行成功。
Nginx配置文件错误导致的解析漏洞
漏洞描述
php中的参数开关cgi.fix_pathinfo用于修正路径，对于接收到的文件路径（如1.jpg/2.php），php会从后往前解析，如果后面的路径2.php不存在，那么就会向上找，如果上一级文件是存在的，就会按照刚才不存在的后缀来解析这个存在的文件，从而造成解析漏洞。之所以属于Nginx的漏洞是因为Nginx接收到文件路径时从后往前解析，如果发现最后一个后缀是php，就会直接交给php处理，并不会检查是否这个路径是否存在，所以属于Nginx的解析漏洞。
形成原因
该漏洞和nginx版本和php版本无关，属于用户配置不当造成的解析漏洞。
复现过程
制作一个图片马，进行上传，上传成功后的到路径，访问路径，在后面加上一个不存在的php文件，访问后会发现图片马会被成功解析。
修复方案
方案一：将php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,只要1.jpg不存在就会显示404页面。
方案二：php-fpm.conf中的security.limit_extensions后面的值设置为.php。意思是你只有后缀是.php，我才会承认你是一个php文件，按照php执行，如果你是.jpg，硬说自己是php，我无法按PHP执行。
Nginx文件名逻辑漏洞（CVE-2013-4547)
漏洞描述
Nginx在遇到%00空字节时与后端FastCGI处理不一致，导致可以在图片中嵌入PHP代码，然后通过访问XXX.jpg%00.php来执行其中的代码。
详细点：
该漏洞利用了Nginx错误的解析了URL地址，导致可以绕过服务端限制，从而解析PHP文件，造成命令执行的危害。
举个例子,比如,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.jpg0x20.PHP,这个URI可以匹配上正则.PHP$,可以进入这个Location块；但进入后,Nginx却错误地认为请求的文件是1.jpg[0x20]（相当于截断），那么就将1.jpg当作php来解析，这样如果1.jpg是个图片马，就可以成功被解析。
形成原因
Nginx在遇到%00空字节时与后端FastCGI处理不一致
影响版本
- Nginx 0.8.41~1.4.3
- Nginx 1.5.0~1.5.7
复现过程
1、打开靶场环境：
cd vulhub/nginx/CVE-2013-4547
sudo docker-compose up -d
2、上传图片马，将文件名改成611.jpg%20%00.php，然后将其进行URL解码（看成post型00截断）
3、上传成功后进行访问，但是发现路径中的%20空格会被忽略，所以抓包改为刚才修改的格式后在发送，进行访问。
4、访问成功，图片马被成功解析。
IIS解析漏洞（6.X版本)
影响版本
- IIS 6.X
基于文件名的解析漏洞
该版本的IIS在解析文件名时，如果遇到分号;会默认为结束，不会解析分号及后面的内容，因此对于*.asp;.jpg此种格式的文件名就会被当作asp解析。
611.asp;.jpg ——> 611.asp
基于文件夹名的解析漏洞
该版本的IIS默认会将*.asp/目录下的所有文件当成asp来解析。
127.0.0.1/test.asp/611.jpg ——> 611.jpg在asp/的目录下，所以被当做asp来解析
其他解析漏洞
IIS6.x除了会将扩展名为.asp的文件解析为asp之外，还默认会将扩展名为.asa，.cdx，.cer解析为asp。
修复方案
1、上传的文件进行随机数重命名。
2、限制上传目录的执行权限，不允许执行脚本。
IIS解析漏洞（7.X版本)
影响版本
- IIS 7.X
解析漏洞
IIS7.X版本在Fast-CGI运行模式下，对于文件名加上/.php的会按照php来解析。
611.jpg/.php ——> 611.jpg按照php来解析
修复方案
cgi.fix_pathinfo=1
浙公网安备 33010602011771号