Web漏洞分析-文件解析及上传（中）

      随着互联网的迅速发展，网络安全问题变得日益复杂，而文件解析及上传漏洞成为攻击者们频繁攻击的热点之一。本文将深入研究文件解析及上传漏洞，通过对文件上传、Web容器IIS、命令执行、Nginx文件解析漏洞以及公猫任意文件上传等方面的细致分析，揭示这些漏洞背后的本质和攻击方式。
       文件上传漏洞一直是攻击者们渗透系统的首选方式。通过构造巧妙的上传文件，攻击者能够实施多种恶意行为，如上传包含恶意脚本的文件，从而实现远程代码执行。本文将深入探讨文件上传漏洞的工作原理、攻击场景，并通过实际案例为读者提供更直观的理解，帮助其更好地认识这一类型漏洞的威胁性。
       在网络攻击的舞台上，Web容器扮演着至关重要的角色。特别是在Windows操作系统下，IIS作为最为常见的Web服务器，存在着多种可能的文件解析和上传漏洞。本文将详细探讨这些潜在的漏洞，揭示攻击者如何善用这些漏洞渗透系统，以帮助读者更全面地了解并防范这一类威胁。

三、IIS命令执行及apache文件解析漏洞

1、IIS6.0命令执行漏洞

（1）、漏洞介绍

IIS6.0命令执行漏洞编号是CVE-2017-7269，在开启WebDav服务的情况下存在可远程执行漏洞。

漏洞原理是在IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候引发栈溢出，该漏洞可以导致远程代码执行。

（2）、关于栈溢出

（3）、关于栈溢出

栈溢出是缓冲区溢出中的一种，缓冲区溢出就好比一个杯子倒太多的水，洒出来这叫溢出。

有一些函数对用户的输入不作任何检查，分配的内存空间是有限的，如果输入超长的字符串，必然会导致溢出。

缓冲区溢出中，最为危险的是堆栈溢出，因为入侵者可以利用堆栈溢出，在函数返回时改变返回程序的地址，让其跳转到任意地址，带来的危害一种是程序崩溃导致拒绝服务，另外一种就是跳转并且执行一段恶意代码，比如得到系统权限然后为所欲为。

IIS6.0命令执行的简单原理就是这样

（4）、环境

IIS6.0漏洞触发的前提条件是WebDav开启

如果默认情况下是不开启的，需要使用以下方法开启

（5）、攻击方法

Github上的一个开源exp:

GitHub - zcgonvh/cve-2017-7269: fixed msf module for cve-2017-7269

将exp中的ip地址改为虚拟机 (目标) 的IP地址

（6）、攻击结果

这个exp的结果是弹出计算器，验证漏洞可以执行代码。

ScStoragePathFromUrl函数存在缓存区溢出漏洞，攻击者通过一个以“If:<http://”开始的较长header头的PROPFIND请求执行任意代码:

2、Apache 文件解析介绍

（1）、环境简介

Apache文件解析漏洞与用户的配置有密切关系严格来说属于用户配置问题，这里要讲解配置出错的原因以及修复方法所以需要自备环境。

使用ubuntu的docker。然后运行以下命令即可

apt-get install apache2

apt-get install php7.0

apt-get install libapache2-mod-php7.0

（2）、Apache和php三种结合方法

CGI: 通常翻译为共同网关接口，是HTTP服务器与机器上的其他程序进行通信的一个接口，让Web服务器必要时启动额外的程序处理动态内容。FastCGI: CGI解释器的更快实现，可以提供良好的性能、伸缩性、Fail-Over特性等等。

Module: 把php编译为apache的模块，也是用的最多的一种方法我们这里要讲的这个Apache文件解析漏洞就发生在Module结合方法上也就是我们之前配置apt-get install libapache2-mod-php7.0

查看Apache和php的结合方法:

（3）、Apache解析文件的方法

一个重要文件/etc/mime.types

这里记录了大量的文件后缀和mime类型,当客户端请求一个文件时,如果后缀在这个列表里,那么apache就返回对应的content-type给浏览器.如果不在列表,apache不会返回content-type给浏览器,而直接文件内容,由浏览器自动外理。

（4）、Apache解析php的方法

①、Cat /etc/mime.types  grep php

这里关于php的全部都被注释掉了

②、etc/apache2/mods-enabled/php7.2.conf

意思是如果请求的文件名匹配正则:.+ .ph(p[3457]?ltltml)$也就是说

(phplphp3lphp4lphp5lphp7lphtlphtml)

是文件的最后一个后缀则把文件交给php处理器 (php_module) 来处理,处理完之后结果返回给apache,再由apache发送给浏览器。

3、Apache 文件解析漏洞

（1）、漏洞原理

①、Apache文件解析漏洞涉及到一个解析文件的特性:Apache默认一个文件可以有多个以点分隔的后缀,当右边的后缀无法识别不在mime.types内),则继续向左识别.

当我们请求这样一个文件:shell.php.xxx.yyy

yyy -> 无法识别,向左

xxx -> 无法识别,向左

php -> 发现后缀是php，交给php处理这个文件

在web目录下创建一个1.php.aaa，然后访问该文件

②、可以看到并没有解析成PHP，那为什么呢?其实,apache本身根本不存在所谓的解析漏洞我们回顾一下请求的过程:

当我们请求这样一个文件:shell.php.xxx.yyy

yyy -> 无法识别,向左

xxx -> 无法识别,向左

SEO网线

php -> 发现后缀是php，交给php处理这个文件

最后一步虽然交给了php来处理这个文件，但是php也不认识.aaa的后缀啊，所以就直接输出了。

③、其实，解析漏洞的产生,是由于运维人员在配置服务器时，为了使apache服务器能解析php，而自己添加一个handler，例如:AddHandler application/x-httpd-php .php

它的作用也是为了让apache把php文件交给php_module解析,但是注意到它与SetHandler:它的后缀不是用正则去匹配的。所以,在文件名的任何位置匹配到php后缀,它都会让php_module解析。

④、现在，访问1.php.xxx.yyy之后解析的流程是这样的

yyy -> 无法识别,向左

xxx -> 无法识别,向左

php - > 激活php处理器,执行PHP代码

解析漏洞就产生了

现在，访问1.php.aaa，可以看到解析成功

（2）、修复方法

不要使用AddHandler,改用SetHandler,写好正则,就不会有解析问题

<FilesMatch".+ .php$">

SetHandler application/x-httpd-php

</FilesMatch>

禁止.php.这样的文件执行

<FilesMatch ".+ .ph(p[3457]?ltltml)\.">

Require all denied

</FilesMatch>

四、Nginx文件解析漏洞

1、Nginx配置

（1）、平台

操作平台: ubuntu14

docker pull ubuntu:14.04.5

（2）、配置方法

①、使用docker run -d -it -p 本机端口:80 ubuntu:14.04.5 启动镜像

使用docker exec -it [容器ID] /bin/bash 进入容器

然后使用以下语句安装相关环境:

apt-get update # 更新源

apt-get install vim # 安装vim

apt-get install nginx # 安装nginx

service nginx start # 启动nginx服务

apt-get install php5-fpm # 安装php5-fpm

②、刚安装好的Nginx是不能解析php的，:需要修改配置文件

etc/nginx/sites-available/default

③、Nginx的两种启动方式第五行如果打开，就是使用tcp方式启动,php-fpm将会本地监听9000端口如果倒数第三行打开，则是使用套接字方式启动

④、现在使用/etc/init.d/php5-fpm start启动web服务。

然后到web目录中写一个测试的php文件，重启nginx服务

尝试访问，如果可以解析，则环境配置成功

（3）、相关目录

usr/share/nginx/html # 默认web目录

/etc/nginx/# 配置文件目录

etc/php5/fpm # php配置文件目录

var/log/nginx/access.log # 访问日志

var/log/nginx/error.log # 错误日志

2、Nginx目录遍历

（1）、原理

Nginx的目录遍历与apache的一样，属于配置方面的问题错误的配置可能导致目录遍历与源码泄露。构造一个的目录，来模拟器的web目录

（2）、修改配置文件

①、Nginx默认是不会开启目录遍历的，这里我们需要修改配置文件vim /etc/nginx/sites-available/default 在location这里加上autoindexon; 重启nginx

②、访问目录，就可以看到这样的效果 apache是否也存在这样的问题?

3、Nginx文件解析漏洞

（1）、原理

①、(1)、对任意文件名，在后面添加/任意文件名.php的解析漏洞，比如原本文件名是test.jpg，可以添加为test.jpg/x.php 进行解析攻击。(2)、对低版本的Nginx 可以在任意文件名后面添加%00.php 进行解析攻击。

②、Nginx下,请求文件/shell.gif时在后面加个*.php,即/shell.gif/1.php,可能会被当作PHP代码执行

和Apache一样，Nginx也是通过mime.types识别文件文件

在/etc/nginx/mime.types

③、创建一个1.jpg，然后访问1.jpg/1.php显示:“Access denied."原因

Nginx拿到文件路径/1.jpg/1.php后，一看后缀是.php，便认为该文件是php文件，转交给php去处理。php一看/1.jpg/1.php不存在，便删去最后的/1.php，又看/1.jpg存在，便把/1.jpg当成要执行的文件了，又因为后缀为.jpg，php认为这不是php文件，于是返回“Access denied.”

④、cgi.fix_pathinfo，该值默认为1，表示开启。

用途:对文件路径进行“修理

当php遇到文件路径“/aaa.xxx/bbb.yyy/ccc.zzz”时，若“/aaa.xxxbbb.yyy/ccc.zzz”不存在，则会去掉最后的“/ccc.zzz”，然后判断“aaa.xxx/bbb.yyy”是否存在，若存在，则把“/aaa.xxx/bbb.yyy”当做文件“/aaa.xxx/bbb.yyy/ccc.zzz”，若“/aaa.xxx/bbb.yyy”仍不存在，则继续去掉“/bbb.yyy”，以此类推

（2）、配置

①、cgi.fix_pathinfo这个配置在php.ini 中可以修改，默认是开启的/etc/php5/fpm/php.ini

默认是1，不需要修改

②、配置/etc/php5/fpm/pool.d/www.conf中security.limit_extensions允许解析其他格式文件为PHP

（3）、测试

再次访问1.jpg/1.php

（4）、目录遍历修复方法

将/etc/nginx/sites-available/default配置文件修改:

autoindex on修改成autoindex off

（5）、文件解析漏洞修复方法

①、将php.ini文件中的cgi.fix_pathinfo的值设为0。这样php在解析1.jpg/1.php这样的目录时，只要1.php不存在就会显示404.

②、将/etc/php5/fpm/pool.d/www.conf中security.limit_extensions后面的值设为.php。