Apache文件解析漏洞复现

环境复现：

使用Docker搭建环境

首先拉取一个基础镜像

docker pull ubuntu:18.04

启动一个容器

docker run --name apachejs -itd -p 80:80 ubuntu:18.04

进入容器

docker exec -it apachejs bash

安装web环境

apt-get install apache2

apt-get install php7.0

apt-get install php-pear

apt-get install libapache2-mod-php

启动apache

service apache2 start

漏洞复现：

Apache解析文件的方法
一个重要文件 /etc/mime.types
这里记录了大量的文件后缀和mime类型,当客户端请求一个文件时,如果后缀在这个列表
里那么apache就返回对应的content-type给浏览器如果不在列表,apache不会返回content-type给浏览器，而直接文件内容,由浏览器自动处理。
Apache解析php的方法
cat /etc/mime.types | grep php

这里关于php的全部都被注释掉了
Apache解析php的方法
/etc/apache2/mods-enabled/php7.2.conf 

意思是如果请求的文件名匹配正则: .+.ph(p[3457]?|t|tml)$
也就是说(php|php3|php4|php5 lphp7|pht|phtml)是文件的最后一个后缀,则把文件交
给php处理器(php_ module)来处理,处理完之后结果返回给apache,再由apache发送给
浏览器。

漏洞原理：

Apache文件解析漏洞涉及到一个解析文件的特性:
Apache默认一个文件可以有多个以点分隔的后缀,当右边的后缀无法识别(不在
mime.types内)，则继续向左识别.
当我们请求这样-个文件：
shell.php.xxx.yyy
yyy ->无法识别向左
XXX ->无法识别,向左
php ->发现后缀是php，交给php处理这个文件
在web目录下创建一个1.php.yy.xx，然后访问该文件
 

echo "<?php phpinfo()?>" > /var/www/html/1.php.yy.xx

可以看到并没有解析成PHP，那为什么呢?
其实,apache本身根本不存在所谓的解析漏洞.我们回顾一下请求的过程:
当我们请求这样一个文件:shell.php.xxx.yyy
yyy ->无法识别,向左
xxx ->无法识别，向左
php ->发现后缀是php，交给php处理这个文件
最后一步虽然交给了php来处理这个文件，但是php也不认识.aaa的后缀啊，所以就直接输出了。
其实，解析漏洞的产生，是由于运维人员在配置服务器时，为了使apache服务器能解析php，而自己
添加一个handler,例如:AddHandler application/x-httpd-php .php
 

echo "AddHandler application/x-httpd-php .php" > /etc/apache2/sites-enabled/bbs.conf

它的作用也是为了让apache把php文件交给php_ module解析,但是注意到它与SetHandler:它的后缀不
是用正则去匹配的。所以,在文件名的任何位置匹配到php后缀,它都会让php_ module解析。
现在重启一下apache服务，重新加载一下配置

service apache2 restart

现在，访问1.php.xxx.yyy之后解析的流程是这样的:
yyy ->无法识别,向左
xxx->无法识别,向左
php->激活php处理器执行PHP代码解析漏洞就产生了。 

漏洞修复：

不要使用AddHandler,改用SetHandler,写好正则,就不会有解析问题，
删除掉之配置的AddHandler 

rm /etc/apache2/sites-enabled/bbs.conf

<FilesMatch ".+\.php$">
SetHandler application/x-httpd-php
</FilesMatch>

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

<FilesMatch ".+\.ph(p[3457]?|t|tml)\.">
Require all denied
</FilesMatch>