aflock-ai/supply-chain-attacks

# 供应链攻击 [](https://github.com/aflock-ai/supply-chain-attacks/actions/workflows/ci.yml) [](https://cilock.aflock.ai/tutorials/defending-against-supply-chain-attacks) [](LICENSE) [](https://github.com/aflock-ai/rookery) 本仓库中的每个条目都是**一次真实的攻击、其安全合成复现、捕获它的 [cilock](https://github.com/aflock-ai/rookery) 策略，以及在每次推送时证明该策略有效的 CI 工作流**。没有营销噱头——无论是绿色徽章还是红色徽章，都是可审计的。 ## 7 次攻击 | 日期 | 攻击 | 向量 | 受影响对象 | 检测层 | 状态 | |---|---|---|---|---|---| | **2026-05-19** | [Nx Console VS Code 扩展](2026-05-nx-vscode/) | IDE 扩展权限滥用 | `nrwl/nx-console`，220 万+ 次安装 | 内容（secretscan）+ 行为（trace） | 📋 已记录，实现待定 | | **2026-05-19** | [`actions-cool` 劫持](2026-05-actions-cool-hijack/) | 通过窃取的维护者凭据冒充提交，从 `/proc//mem` 抓取机密 | `actions-cool/*` Actions | 预防（源策略）+ 内容（secretscan，6 项发现）+ 行为（`/proc/*/mem` + `/proc/self/environ` + `/tmp/runner_collected_*`） | ✅ **实时检测** — 全部 3 层均为绿色 | | **2026-05-19** | [Shai-Hulud npm 蠕虫](2026-05-shai-hulud-npm-worm/) | 跨已发布 npm 包的自我复制恶意软件 | 数十个 npm 包 | 内容（针对安装脚本的 secretscan）+ 行为（`npm install` 模式） | 📋 已记录，实现待定 | | **2026-05-18** | [Microsoft `durabletask` PyPI 木马](2026-05-microsoft-durabletask-pypi/) | Microsoft 发布的 PyPI 包的木马化版本 | PyPI 上的 `durabletask` | 预防（证明策略要求上游证明）+ 内容（针对 `setup.py` / `.pth` 的 secretscan） | 📋 已记录，实现待定 | | **2026-05-18** | [GitHub 内部源码泄露](2026-05-github-source-disclosure/) | 数据暴露 / 违规，GitHub 自己的源代码 | GitHub 内部仓库 | 运行时不适用 — cilock 本可以从受影响的构建流水线中提供取证证明 | 📋 仅作文档记录 | | **2026-03-24** | [LiteLLM `.pth` 凭据窃取程序](2026-03-litellm-pth-stealer/) | Python `.pth` 文件在每次解释器启动时执行，扫描凭据 | PyPI 上的 `litellm==1.82.7` 和 `1.82.8` | 内容（带有递归 base64 解码的 secretscan）+ 行为（读取 `/proc/self/environ`） | 📖 查看深入分析演练 | | **2026-03-19** | [Trivy 标签重写](2026-03-trivy-tag-rewrite/) | `aquasecurity/trivy-action` 中 75/76 个版本标签被强制推送，凭据从 `/proc//mem` 中窃取 | 每个通过标签固定该 action 的流水线 | 预防（策略强制执行 SHA 固定）+ 内容 + 行为 | 📖 [在 `aflock-ai/attestor-compliance-examples/43-trivy-attack-detection` 中查看完整深入分析](https://github.com/aflock-ai/attestor-compliance-examples/tree/main/43-trivy-attack-detection) | ## 本仓库是什么 这是对每次供应链事件后每个开发者都会问的问题的有效解答：**“我的工具能捕获这个吗？”** 对于每个记录的攻击，本仓库提供： 1. **一份 README**，包含时间线、IOC、归因以及捕获它的 cilock 检测机制。 2. **一个安全的合成 payload**，它重现了攻击的系统调用 / 输出模式，而没有任何真实的数据外泄。没有真实的机密。没有网络信标。没有真实的恶意软件。 3. **一个签名的 cilock 策略**（[OPA Rego](https://www.openpolicyagent.org/docs/latest/policy-language/)），可在 cilock 的三个防御层中的一个或多个层检测到该攻击。 4. **一个实时的 CI 工作流**（`.github/workflows/detect-.yml`），它在每次推送时通过带有该策略的 cilock 运行 payload，并将徽章变为绿色或红色。如果它变红了，说明检测失效了，README 就在撒谎。 各种攻击的测试架构是相同的——相同的 `cilock run` + `cilock verify` 组合，相同的策略模块结构，相同的任务矩阵。只有 payload 和策略细节不同。这使得添加新攻击的成本很低，读者也极易比较不同攻击之间的检测情况。 ## 检测工作原理 Cilock 在三个独立的层捕获供应链攻击，因此攻击者必须绕过所有三层才能成功： | 层级 | 它的作用 | 本仓库中的检测示例 | |---|---|---| | **1. 预防** | 签名的 Rego 策略限制允许运行哪些 actions、包和 refs。强制执行 SHA 固定。不受信任的 refs 永远不会执行。 | `actions-cool-hijack/policy-source-restrict.rego` 拒绝未进行 SHA 固定的 `actions-cool/*` refs | | **2. 内容检测** | `secretscan` 证明器在 stdout 上运行 Gitleaks，并通过三层**递归解码** base64、hex 和 URL 编码的 payload。凭据模式将触发构建失败。 | LiteLLM `.pth` 窃取程序被捕获：嵌入在 `__pycache__` 中的 payload 在字节码内进行了 base64 编码；secretscan 的递归解码器将其解包 | | **3. 行为检测** | `--trace` 标志（仅限 Linux）对包装的进程进行 ptrace，并记录每个进程打开的每个文件。OPA Rego 策略匹配收集凭据的文件系统模式。 | `actions-cool-hijack/policy-trace-behavioral.rego` 拒绝任何读取 `/proc//mem` 或 `/proc/self/environ` 的进程——两者都是收集凭据的指纹 | **纵深防御才是关键。** 单层可以被绕过；三个独立的层实质性地提高了攻击者的成本。此处记录的每次攻击都标注了哪些层会触发，以便您查看什么绕过了什么。 ## 在本地重现任何检测 CI 工作流在 GitHub 托管的 runner 上直接运行。要在 Linux 上本地运行任何检测： ``` # 安装 cilock (其中之一)： curl -fsSL https://cilock.aflock.ai/install.sh | bash # 或 docker pull ghcr.io/aflock-ai/cilock:latest # 选择一个攻击，使用以下 policy 通过 cilock 运行其 payload： cd 2026-05-actions-cool-hijack cilock run \ --step detect-actions-cool \ --attestations secretscan git environment commandrun \ --trace \ --attestor-secretscan-fail-on-detection \ --signer-fulcio-url https://fulcio.sigstore.dev \ --signer-fulcio-oidc-issuer https://token.actions.githubusercontent.com \ --signer-fulcio-oidc-client-id sigstore \ --timestamp-servers https://timestamp.sigstore.dev/api/v1/timestamp \ --enable-archivista=false \ --outfile attestation.json \ -- bash payload.sh # 根据 policies 进行验证（捕获它的检测层）： cilock verify --policy policy-source-restrict.rego attestation.json cilock verify --policy policy-trace-behavioral.rego attestation.json ``` 如果策略检测到了攻击（应该会的），`cilock run` 将以非零状态退出，并且 `cilock verify` 将报告匹配的 `deny` 规则。这就是检测。 ## 如何将攻击添加到此目录中 每个子目录都是独立的。要添加新的攻击： ``` -/ ├── README.md # Timeline, IOCs, attribution, detection layer ├── payload.sh # Safe synthetic reproduction. NEVER include │ # real secrets or live exfil URLs. Echo synthetic │ # credential patterns + touch the same syscalls │ # the real attack hits. └── policy-.rego # One or more Rego policies that fire on the attack .github/workflows/detect-.yml # CI for this attack. Mirror the shape # of detect-2026-05-actions-cool-hijack.yml. # Lives at the repo root because GitHub # only discovers workflows there. ``` 提交一个 PR；顶层 CI 矩阵会自动提取新目录。README 的表格需要添加新的一行。 ## 伦理与安全 本仓库中的每个 payload 都是合成复现的。我们演练了真实攻击使用的相同系统调用和内容模式，但是： - **没有真实的凭据。** Payload 会输出形状类似于 AWS 密钥、GitHub PAT、RSA 私钥的字符串——但这些值不是真实的机密，且从未有效过。 - **没有实时的数据外泄。** Payload 不执行任何网络出站操作。没有 DNS 查询。没有 HTTP。行为层基于文件系统访问模式触发，而不是基于出站流量。 - **不重新分发恶意软件。** 我们不托管真实恶意软件的副本。IOC（文件路径、包名、版本号、哈希值）被记录用于取证参考；如果您有合法的研究理由，每个攻击的 README 中引用的原始来源是获取真实样本的地方。 本仓库是一个**防御性演示**，而不是攻击性工具包。 ## 相关内容 - **Cilock 本身：** [aflock-ai/rookery](https://github.com/aflock-ai/rookery) - **CI 集成：** [aflock-ai/cilock-action](https://github.com/aflock-ai/cilock-action) - **Trivy 深入分析（单一攻击）：** [43-trivy-attack-detection](https://github.com/aflock-ai/attestor-compliance-examples/tree/main/43-trivy-attack-detection) - **文档：** [cilock.aflock.ai](https://cilock.aflock.ai) — 三层模型、证明器目录、威胁演练 - **商业 / 托管：** [TestifySec 平台](https://testifysec.com/product) ## 许可证 Apache 2.0 — 请参阅 [LICENSE](LICENSE)。由 [TestifySec](https://testifysec.com) 构建和赞助。

标签：Cutter, IP 地址批量处理, StruQ, 威胁复现, 文档安全, 网络信息收集, 请求拦截, 软件供应链安全, 远程方法调用, 逆向工具