While conducting OSINT on a lesser-known dark web forum as part of assessing your client's threat landscape, you stumble upon a thread discussing high-value targets. Among the chaos of links and boasts, a user casually mentions discovering an intriguing GitHub repository belonging to your client, the international titan, Huge Logistics. A couple of underground researchers hint at having found something but remain cryptic. Your instincts tell you there's more to uncover. Your objective? Dive deep into this repository, trace any associated infrastructure, and uncover any vulnerabilities before they become tomorrow's headline. The clock is ticking. Will you outsmart the adversaries?
真实场景
Git仓库中泄露的凭证是一个普遍存在的安全问题，它可能对现实世界造成严重影响。一旦凭证被公开，可能会导致个人系统甚至整个公司的网络和平台遭到破坏。除了对公司声誉的损害之外，还可能产生高额的云服务费用。如果因为这种破坏导致客户数据泄露，公司可能面临监管机构的巨额罚款。
先把代码拉到本地
通过 git-secrets 扫描敏感信息，mac 可以直接 brew 装
使用
在历史 commit
d8098af5fbf1aa35ae22e99b9493ffae5d97d58f 中发现 log-s3-test/log-upload.php 泄漏 AK AKIAWHEOTHRFSGQITLIY通过 Trufflehog 扫描
使用，这个发现的更多点
这个工具还支持远程不下载扫（就是如果仓库大容易报错啥的）
max_depth 是 commit 的最大深度到仓库commit里看，
在 commit 上来后一天后就把它删了，桶名是：
huge-logistics-transact
此外，代码还泄漏的数据库连接信息
配置一下就能拿 flag 了
防御
亚马逊安全在10分钟后监测到这个问题并向作者发送了安全告警邮件，这一点还是做的很好的～
默认好像是会尝试向该拥有该 AK 的所有账户都发送安全告警邮件
并且会为该 AK 自动加上
AWSCompromisedKeyQuarantineV2 策略，防止 AKSK 被进一步滥用
这个策略的定义
What to Do If You Inadvertently Expose an AWS Access Key AWS 官方文章给出了 AKSK 泄漏的应急步骤
- 确定凭证的可访问范围
- 吊销该凭证
- 吊销通过该凭证产生的任何临时凭证
- 恢复业务
- 审查自己 AWS 账户的访问权限
我们上面运行的
git secrets -—install 会在那个仓库安装了 git-secrets 工具，后面如果还提交了 AKSK 会被拒绝
进一步阅读
- https://www.thestack.technology/infosys-leak-aws-key-exposed-on-pypi/ pypi 上的内部包泄漏，里面包含了 AWS 的 AKSK
- https://blog.pingsafe.com/shiba-inu-cloud-credentials-leaked-in-a-major-security-breach-394ad54382c1 网站凉了
- https://www.theregister.com/2017/11/14/dxc_github_aws_keys_leaked/ Github 公开仓库泄漏 AKSK