该 Nuclei 模板旨在检测存在 CVE-2024-38473 漏洞的 Apache 服务器。它首先识别运行 Apache < 2.4.60 且使用默认 PHP-FPM 配置的服务器。然后，它会模糊测试可能受 ACL 保护的 PHP 文件，这些文件可能因该漏洞而被绕过。
要使用此 Nuclei 模板，您需要克隆仓库。您可以通过运行以下命令来完成此操作：
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
导航到克隆的仓库目录：
cd CVE-2024-38473-Nuclei-Template
对单个主机运行 nuclei 模板：
nuclei -t CVE-2024-38473.yaml -u http://example.com
对主机列表运行 nuclei 模板：
nuclei -t CVE-2024-38473.yaml -l hosts.txt
对单个主机运行 nuclei 模板并指定一个有效的 .html 或 .php 文件：
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
以这种方式运行 Nuclei 可能会获得更高的检测率。您也可以在 hosts 文件中包含此格式的 URL，以便针对该列表运行模板。
为了轻松测试 CVE-2024-38473 漏洞，您可以使用 Docker 搭建一个存在漏洞的环境。请按照以下步骤快速验证 Nuclei 模板的有效性：
确保 Docker 守护进程正在运行：请确保 Docker 守护进程已在您的系统上运行。如果尚未运行，可以使用以下命令启动它：
sudo systemctl start docker
运行 Docker 容器：在仓库目录中，使用以下 Docker 命令启动一个包含存在漏洞的 Apache 和 PHP-FPM 配置的容器：
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
测试漏洞：
手动测试：打开您的网络浏览器，访问 http://localhost:8787 与 Docker 容器中运行的 Apache 服务器进行交互。访问 http://localhost:8787/info.php 来测试漏洞。该文件受 ACL 保护，如果 ACL 绕过成功，您将看到 phpinfo() 的输出：
使用 Nuclei 模板：运行以下 Nuclei 命令以使用该模板测试服务器：
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
2024 年 8 月 8 日，安全研究员 Orange Tsai 在 Black Hat USA 2024 上发表了题为 混淆攻击：利用 Apache HTTP 服务器中隐藏的语义歧义！ 的演讲。在此演讲中，他报告了影响 Apache HTTP 服务器的多个漏洞。他解释说，Apache 具有高度模块化的架构，由数百个模块组成，每个模块执行其功能，同时读取和写入一个名为 request_rec 的共享结构，该结构包含近 100 个字段。
安全研究员报告的漏洞根本原因在于不同 Apache 模块处理共享结构各个字段的方式不一致。例如，mod_authz_core 将 r->filename 字段视为文件，而 mod_proxy 则将其视为 URL，这种差异导致了一系列漏洞的产生。
在他的演讲中，Orange Tsai 定义了一种称为“文件名混淆”的攻击类型。尽管这种攻击的攻击面多种多样，但本模板涵盖的 CVE-2024-38473 指的是如何应用“文件名混淆”攻击来绕过 Apache ACL 并访问受限文件。
问题出现在 Apache 的身份验证模块 mod_authz_core 将 r->filename 属性视为文件，而 mod_proxy 则将其视为 URL 时。因此，采用默认配置的 PHP-FPM 的 Apache 安装会受到此漏洞的影响。假设一台运行 Apache 和 PHP-FPM 的服务器配置了如下 ACL 来保护对 admin.php 文件的访问：
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
由于该漏洞，可以绕过像上面这样保护单个文件的 ACL。实际上，只需发送以下请求即可轻松实现：http://server/admin.php%3fooo.php。
为了深入理解这一点，重要的是要考虑当 Apache 处理上述请求时，mod_authz_core 模块从共享结构的 r->filename 字段读取值 admin.php?fooo.php。它将该值视为所请求文件的名称，并在与 ACL 进行比较时，由于 admin.php?fooo.php 与 admin.php 不同，因此不匹配。
然后，由于 admin.php?fooo.php 以 .php 结尾，该请求由 PHP-FPM 处理。PHP-FPM 在从 Apache 接收到的文件名中删除 ? 之后的所有内容，然后进行处理，将其视为 URL 而不是文件。因此，PHP-FPM 将直接处理 admin.php。由于之前已经通过了 ACL 检查，攻击者可以在无需身份验证的情况下访问 admin.php。
当前的 Nuclei 模板不仅旨在通过暴力破解发现受保护的文件，还包含逻辑来识别服务器何时具有存在漏洞的 Apache < 2.4.60 配置与 PHP-FPM，即使未检测到受 ACL 保护的文件。在基本流程中，它首先尝试识别服务器是否具有存在漏洞的配置，然后，如果结果为阳性，则尝试识别可能受 ACL 保护的常见文件。
检测存在漏洞的 Apache < 2.4.60 与 PHP-FPM 配置的思路基于两个基本前提：
在存在漏洞的配置中，如果 file.php 存在于服务器上，那么对 http://server/file.php%3fooo.php 的请求将返回与对 http://server/file.php 的请求相同的 200 状态码和相同的响应体长度（因为 PHP-FPM 移除 %3fooo.php 后，请求的文件将是相同的）。
在存在漏洞的配置中，如果 file.html 存在于服务器上，那么对 http://server/file.html%3fooo.php 的请求将返回 403 Access Denied。这是因为 PHP-FPM 将尝试加载具有 .html 扩展名的文件而不是 .php，而默认情况下是不允许加载 .html 文件的。
该模板流程由 7 组请求组成。它们需要按顺序执行，并且必须满足各自的匹配条件才能继续执行下一组请求。这有助于在已知条件不满足时，最大程度地减少徒劳发送的请求数量。
模板向 index.phpooo.php%3fooo.php 发送一个请求，该文件不存在。其目的是过滤掉在 index.php%3fooo.php 返回 200 状态码且与 index.php 的响应体相同，但实际并未配置 PHP-FPM 情况下的误报。例如，当存在将任何请求的文件或以“index”开头的文件重写到 index.php 的规则时，就可能发生这种情况，例如：
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
如果服务器存在上述规则，此请求应返回 200 状态码；在通常可能配置了 PHP-FPM 的情况下，此请求应返回 404 状态码。如果此请求未返回 404 状态码，模板将停止对此主机的处理。
模板向 foo.phpooo.php%3fooo.php 发送一个请求，该文件不存在。其目的是过滤掉在 index.html%3fooo.php 返回 403 状态码，但实际并未配置 PHP-FPM 情况下的误报。例如，当存在禁止 URL 中出现 %3f 字符或限制访问以 .php 结尾的文件的规则时，就可能发生这种情况。此类规则的示例包括：
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
如果服务器存在上述规则，此请求应返回 403 状态码；在通常可能配置了 PHP-FPM 的情况下，此请求应返回 404 状态码。如果此请求未返回 404 状态码，模板将停止对此主机的处理。
模板发送请求以识别服务器上的一些可用文件。首先，它尝试识别 index.php 是否可用。然后，检查 index.html 和 index.htm。最后，如果用户提供的 URL 中存在文件，则对其进行测试。如果运行 Nuclei 时在 URL 中指定了一个有效文件，则在经典索引文件不存在的情况下，这可以提高检测效果。
模板向一个不存在的文件发送请求，以过滤掉最后的误报情况，即 index.php%3fooo.php 返回 200 状态码并且与 index.php 的响应体长度相同，但实际并未配置 PHP-FPM 的情况。某些 Web 服务器（尤其是非 Apache 服务器）会忽略 %3f 之后的所有内容。因此，如果我们发送 index.php%3fooo.php，服务器会将其视为 index.php。为了过滤这些情况，模板会向 index.php%3fooo.html（如果在服务器上找到了 index.php）或 index.html%3fooo.html（如果在服务器上找到了 index.html）发送请求。由于它以 .html 结尾，在通常可能配置了 PHP-FPM 的情况下，它不会被 PHP-FPM 处理，而是被当作一个逻辑上不存在的静态文件处理，从而返回 404 状态码。然而，在我们要过滤的情况下（%3f 之后的所有内容都被忽略），它会返回 200 状态码。如果此请求未返回 404 状态码，模板将停止对此主机的处理。
模板发送请求以识别存在漏洞的配置。有两种情况，必须满足其中至少一个匹配条件：
情况 1：在 请求 #3 中，找到了 index.php。在这种情况下，如果 Apache < 2.4.60 并且 PHP-FPM 使用默认配置启用，它应该去除 %3fooo.php 部分并加载 index.php，从而返回 200 响应，长度与请求 #3 中获得的相同。如果使用 mod_php 或其他处理程序，它会将 index.php%3fooo.php 视为完整的文件名并返回 404。要使此情况匹配，请求必须返回 200 并且响应体长度与 请求 #3 的响应长度相同。
情况 2：在 请求 #3 中，找到了 index.html。在这种情况下，如果 Apache < 2.4.60 并且 PHP-FPM 使用默认配置启用，它应该去除 %3fooo.php 部分并尝试加载 index.html，这将返回 403 Access Denied，因为 PHP-FPM 正在尝试加载具有不允许扩展名的文件。如果使用 mod_php 或其他处理程序，它会将 index.php%3fooo.php 视为完整的文件名并返回 404。要使此情况匹配，请求必须返回 404。
如果模板已到达此点，则表示服务器具有存在漏洞的配置。因此，模板发送请求以模糊测试可能受保护的文件，这些文件返回 403 状态码或需要身份验证并返回 401 状态码。默认情况下，它仅尝试识别少数最常见且可能受保护的文件名。但是，您可以取消注释一行以使用包含 350 个可能 PHP 文件名的自定义单词列表。
模板发送一个请求，以验证在 请求 #6 中识别出的受保护文件在使用绕过方法后是否返回 200 状态码。
如果 请求 #5 中的任何匹配条件得到满足，则表示服务器正在运行 Apache < 2.4.60 并采用默认的 PHP-FPM 设置。这意味着，如果存在保护单个文件的 ACL，则它可能被绕过。然而，很多时候可以在不识别任何受保护文件的情况下检测到这些存在漏洞的配置。默认情况下，模板使用单词列表 wordlists/potential_protected_php_files_10.php 来模糊测试受保护的文件。该列表包含最有可能受 ACL 保护的前 10 个 PHP 文件名。另外，还有一个包含 350 个条目的更大单词列表：wordlists/potential_protected_php_files_350.php。要切换到更大的列表，请在模板的 请求 #6 的 YAML 部分中注释掉 10 条目的单词列表，并取消注释 350 条目的列表，如下所示：
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
使用更大的单词列表可以增加找到受保护 PHP 文件的机会。但是，potential_protected_php_files_350.txt 单词列表可能包含不常见的 PHP 文件名，并且可能缺少更常见但受 ACL 保护的 PHP 文件名。因此，欢迎对单词列表进行任何改进或补充。此外，还可以使用更大的自定义单词列表进行进一步探索。
请注意，可绕过的 ACL 可能配置在不同的虚拟主机中，或配置在应用程序任何目录的 .htaccess 文件中，而不仅仅是根目录。因此，为了最大限度地提高识别受 ACL 保护的文件的几率，建议对目录和子域名进行彻底侦察，并针对所有已识别的具有不同子域名和目录的 URL 运行模板。
目前，请求 #6 的流程在识别出第一个受 ACL 保护的文件后停止。然而，可能还有更多文件未被发现。这是因为我没有找到一种方法来让 Nuclei 模糊测试多个文件、存储结果，然后在后续请求中使用这些结果来验证绕过方法是否确实授予了对受保护文件的访问权限。因此，也欢迎提供关于如何修改模板以识别多个受保护文件并验证它们确实可被绕过的任何建议。
报告漏洞并进行出色研究的所有功劳归于 Orange Tsai。他对 Apache HTTP 服务器漏洞（包括 CVE-2024-38473）的广泛研究极大地促进了安全意识的提升。我，Juan Schallibaum，仅负责创建此 Nuclei 模板，以方便测试和检测 CVE-2024-38473。
在未事先获得双方同意的情况下，使用此 Nuclei 模板攻击目标是违法的。最终用户有责任遵守所有适用的地方、州和联邦法律。开发者不对因使用此模板而产生的任何误用、损害或法律后果承担任何责任。在进行任何安全测试之前，请务必确保您拥有明确许可。