【Pwned Labs】Hunt for Secrets in Git Repos：寻找 Git Repos 中的秘密

0x00 场景介绍

在为客户评估威胁形势的过程中，你正在对一个不太知名的暗网论坛进行 OSINT（开源情报）调查。

你在一个讨论高价值目标的帖子中发现了线索。

在一堆混乱的链接和炫耀言论中，有个用户随口提到发现了一个属于你客户——国际物流巨头 Huge Logistics 的 GitHub 仓库。

一些地下研究者暗示他们发现了某些东西，但说得很含糊。你的直觉告诉你，这里面肯定还有更多信息等待揭示。

你的目标？深入分析这个仓库，追踪任何相关的基础设施，发现潜在漏洞——要抢在它成为明天新闻头条之前。

时间紧迫，你能否先敌一步，击败对手？

🎯 点击【阅读原文】，立即进入靶场环境！

0x01 前置知识

• 基本的 Linux 命令行知识

0x02 学习目标

• 使用 git-secrets 和 Trufflehog 进行敏感信息搜寻
• 理解如何预防凭证泄露及如何响应相关事件

0x03 难度等级

• 初学者（Beginner）

0x04 关注重点

• 红队（Red）

0x05 真实背景

Git 仓库中泄露凭证是一个非常普遍且真实存在的安全问题。

凭证被公开可能导致单个系统甚至整个公司网络和平台被攻破。

除了声誉受损外，还可能带来巨额的云资源账单；更严重的是，如果客户数据因此泄露，来自监管机构的罚款可能会高得惊人。

0x06 解题思路

6.1 初步探查

我们先访问 Github 仓库，它看起来像是一个物流网站，总共有 6 个提交。

将其克隆到本地，进行进一步检查：

git clone https://github.com/huge-logistics/cargo-logistics-dev

在浏览器中打开 index.html，显示如下所示：

6.2 git-secrets

git-secrets^[1]是由AWS 实验室团队 开发的一款工具，旨在防止将密码、API 密钥等敏感信息意外提交到 Git 仓库中。

它的工作原理是：扫描 Git 仓库的内容，使用预定义的正则表达式规则来识别常见的敏感信息（如 AWS 密钥、令牌等）。当其检测到匹配项时，会根据配置发出警告或直接阻止提交或推送。

安装方式如下所示：

git clone https://github.com/awslabs/git-secretscd git-secretsmake install

我们进入 Git 仓库，git-secrets 为该仓库安装 Git 钩子。执行以下命令后，该仓库中的提交和非快进合并操作将被阻止提交包含敏感信息的内容。

cd cargo-logistics-dev/git secrets --install

使用 --register-aws 选项，可将常见的 AWS 模式（即正则表达式规则）添加到 Git 配置中，以确保不会在任何提交中检测到 AWS 密钥和~/.aws/credentials 文件中的密钥。

git secrets --register-aws

接下来，我们可以对 Git 仓库进行扫描了：

1. 首先，我们使用 --scan 对仓库进行全盘扫描，但这次扫描并未返回所匹配到的敏感信息。
2. 然后，我们使用 --scan-history 对仓库的所有历史提交进行扫描。这次，我们扫描出在提交记录d8098af5fbf1aa35ae22e99b9493ffae5d97d58f的log-s3-test/log-upload.php 文件中存在敏感信息AKIAWHEOTHRFSGQITLIY

git secrets --scangit secrets --scan-history

我们执行以下命令，查看该提交记录中的文件log-upload.php，便可获取获取 AWS 的登录凭证

git show d8098af5fbf1aa35ae22e99b9493ffae5d97d58f:log-s3-test/log-upload.php

6.3 Trufflehog

Trufflehog^[2]是另一个用于自动发现 Git 仓库中凭证信息的优秀工具。它有两个版本，下面将分别展示它们的使用命令。

我们可以使用包管理器快速安装：

brew install trufflehog     # Macapt install trufflehog        # Debian

或者是从源码构建

git clone https://github.com/trufflesecurity/trufflehog/; cd trufflehoggo build

然后直接使用 trufflehog 对远程代码仓库进行扫描，只需要提供 URL 即可：

• --max-depth 2：设置扫描深度为 2。trufflehog 默认会对全部的历史记录进行扫描，该选项只分析前 2 次提交，可加快扫描速度。

trufflehog git https://github.com/huge-logistics/cargo-logistics-dev --max-depth 2

trufflehog 会显示暴露的 AWS 密钥和受影响的文件以及历史提交：

此外，我们还可以对本地 Git 文件夹进行扫描：

• --regex ：启用正则表达式扫描模式。使用内置或自定义的正则去匹配常见的凭证格式（如 AWS 密钥、Slack Token、API Key 等）。
• --no-entropy ：禁用熵值分析。TruffleHog 默认会用“熵”来判断一段字符串是否像密钥（随机性高），这个参数关闭该功能，只依赖正则来判断。

trufflehog git file://cargo-logistics-dev/ --regex --no-entropy

trufflehog 显示该 Git 文件夹存在多处敏感信息泄漏：

6.4 凭证滥用

使用获取的 AWS 凭证登录：

aws configureaws sts get-caller-identity

列出 s3 存储桶中数据，并递归下载存储桶中的所有内容：

aws s3 ls s3://huge-logistics-transactaws s3 cp s3://huge-logistics-transact . --recursive

查看 flag 和敏感数据，我们发现web_transactions.csv 包含了用户名、邮件和 IP 得知等个人信息。

0x07 总结

查看本次所提供的 Github 仓库的提交记录^[3]，我们发现，即使已经删除了 AWS 凭证，但更改永远的被记录起来了。

那么，我们还能发现更多的 secret 吗？虽然我们已经使用了一些自动化的扫描工具。但这些工具也有可能会遗漏一些常见字符，例如mysqli_connect。

亚马逊做得很不错的是，他们会对泄漏的 secret 进行监控，并且反应特别迅速，在事故发生后的 10 分钟内就可以做出响应了。

正如下方 AWS 邮件中所提到的，建议配置安全联系人。默认情况下，AWS 会尝试联系账户注册时填写的电子邮箱，但这个邮箱在很多情况下可能并不会被人监控。

这封邮件内容较长，但下面总结了关键点以及 AWS 所采取的措施来缓解泄露的影响。值得一提的是，另一个公司（GitGuardian）也指出了该问题。当然，也有许多其他实体（包括恶意攻击者）在 GitHub 上扫描泄露的凭证信息。

We have become aware that the AWS Access Key AKIAWHEOTHRFSGQITLIY , belonging to IAM User dev-test , along with the corresponding Secret Key is publicly available online at https://github.com/huge-logistics/cargo-logistics-dev/blob/8f53c36b3888da71f3f6ae3a13ca1fe26950793d/log-s3-test/log-upload.php.<SNIP>To protect your account from excessive charges and unauthorized activity, we have applied the "AWSCompromisedKeyQuarantineV2" AWS Managed Policy ("Quarantine Policy") to the IAM User listed above. The Quarantine Policy applied to the User protects your account by denying access to high risk actions like iam:CreateAccessKey and ec2:RunInstances.

当我们登录 AWS 控制台查看受影响的用户时，会看到该托管策略AWSCompromisedKeyQuarantineV2 已直接附加。该策略会禁止一系列高风险操作，比如创建和删除资源。

AWS 提供了一篇文章《如果你不小心泄露了 AWS Access Key 应该怎么做^[4]》，推荐阅读，内容包括以下步骤：

1. 确定这些凭证能够访问哪些资源
2. 使凭证失效，防止继续被使用
3. 考虑吊销通过该凭证生成的临时安全凭证
4. 恢复合适的访问权限
5. 全面审查你 AWS 账户的访问权限

最后值得一提的是，现在我们已经在仓库中安装了git-secrets，可以防止类似的错误再次发生。