黑客如何窃取你的密钥和秘密

它们在你的 JavaScript 文件中找到它们

他们回顾了 Wayback machine

他们使用 GitHub

他们使用谷歌

他们了解你的系统

总结

在搜寻安全漏洞之后，我意识到与我合作的客户对基本的“黑客”技术不够熟悉（甚至完全不熟悉）。API 密钥、密码、SSH 加密密钥和证书都是很好的保护机制，只要它们保密即可。一旦它们被公开，无论密码多么复杂，或者在其他地方使用什么哈希算法加密，都无关紧要。在这篇文章中，我将分享研究人员用于查找和利用秘密的概念、方法和工具。我还将列出一些易于实施的缓解措施。

值得一提的是，攻防“游戏”并非公平对决；攻击者只需一次成功尝试即可入侵，而防御者则必须100%成功。难点在于知道该如何寻找。一旦你能列出黑客入侵的虚拟“大门”，就能用相当简单的机制来保护它们。我认为，它们的简单性有时会掩盖其重要性，并因此被许多团队忽视。

因此，这里有一个快速而简单但不容忽视的 TL;DR：

• 在所有可能的地方——谷歌、GitHub、云服务提供商、VPN——都应强制执行 MFA。如果强制执行并非可选项，请重新考虑所使用的系统。
• 不断轮换密钥和密码，采用并执行轮换政策
• 定期扫描你的代码。最好将其作为发布流程的一部分
• 将登录配置文件和访问管理委托给您控制和监控的一个中央系统

这些是防止泄漏和访问控制漏洞的20% 措施，可实现 80% 的效果

进攻与防守“游戏”并不公平；攻击者只需一次成功尝试即可进入，而防守者则必须 100% 成功。

那么，黑客会做什么、用什么来查找密码和应用程​​序秘密呢？

它们在你的 JavaScript 文件中找到它们

API 密钥遍布互联网，暴露在外。这是事实。很多时候，这些密钥毫无意义。开发人员很容易忘记它们：

• 用于调试目的
• 为了当地发展
• 对于未来的维护者来说作为评论

类似这样的代码块在互联网上随处可见：

// DEBUG ONLY
// TODO: remove -->
API_KEY=t0psecr3tkey00237948

虽然很多黑客实际上会坐下来仔细阅读 JavaScript 文件，但绝大多数人会使用meg之类的工具自动扫描，然后扫描其中的模式。
他们是怎么做到的呢？使用“meg”之类的扫描器后，他们会扫描结果，寻找与不同模板匹配的字符串。另一个由同一作者开发的出色工具gf就是一个更好的例子grep。在这种情况下，使用truffleHog或trufflehog该工具中的选项gf可以找到大多数 API 密钥所对应的高熵字符串。对于搜索API_KEY多次出现结果的字符串，方法也是一样的。

很多时候，密钥出现在那里有充分的理由，但却没有受到保护以防止被外部使用。一个例子是我最近合作的一个客户，他们像许多其他平台一样，将地图作为第三方服务使用。为了获取并操作地图，他们会使用密钥调用 API，然后使用该密钥返回相关地图。但他们忘记配置地图提供程序，以限制带有该特定密钥的传入请求的来源。不难想象，一个简单的攻击就会耗尽他们的许可证配额，实际上会给他们造成巨额损失，或者“更好”一点（就攻击而言），导致他们面向地图的服务瘫痪。

JS 文件不仅会被黑客用来窃取机密信息。您的应用程序代码也暴露在任何窥探者的眼皮底下。聪明的黑客可能会仔细阅读代码，了解命名约定、API 路径，并找到有用的注释。之后，他们会将这些注释推断成一个单词和路径列表，并加载到自动扫描程序中。这就是所谓的智能自动扫描；攻击者会将自动化流程与收集到的组织特定信息结合起来。

目标首页上留下的真实评论，揭示了一组未受保护的 API 端点泄露数据。

/* Debug ->
domain.com/api/v3 not yet in production 
and therefore not using auth guards yet 
use only for debugging purposes until approved */

那你该怎么办？

• Minify / Uglify - 添加一层混淆和利用。虽然通常可逆，但它可以帮助躲避许多自动扫描器的雷达，从而减少攻击面。
• 只保留最低限度的密钥和权限——虽然有些是必需的，但大多数并非如此。只保留那些必须作为代码一部分的密钥
• 将密钥权限降至最低限度——就像地图服务示例一样，确保密钥只能在指定的地方执行其预期的操作。确保不留任何漏洞。
• 使用攻击者用来自动扫描 CI 构建代码的相同工具。尤其是那些运行速度快的字符串模式匹配工具。使用简单的greps 或 sgf来扫描模式。与测试类似，这些工具可以帮助确保开发人员不会留下可能被利用或用于破坏系统的漏洞。
• 进行代码审查，从另一个角度审视代码——世界上所有的扫描器都无法扫描和检测 100% 的用例。从另一个角度审视代码，无论对质量还是安全性来说，都是非常好的做法。

他们回顾了 Wayback machine

互联网档案馆（也称为“Wayback Machine”）保存着多年来互联网上各个网站的定期扫描记录。对于有目标的黑客来说，这是一个雷区。使用像waybackcurls（基于waybackcurls.py）这样的工具，可以扫描任何目标的旧文件。这意味着，即使你找到并删除了某个密钥，但没有对其进行轮换，黑客仍然可能在你网站的旧版本中找到它，并利用它来对付你。

发现钥匙放在了不该放的地方？

1. 创建替换密钥
2. 发布一个使用新密钥的版本，并删除提及
3. 删除旧版本或停用它

WaybackMachine不仅能帮你找到钥匙

旧代码向攻击者揭示了各种有趣的信息：

• 秘密 API 路径 - 您以为永远不会被发现的未受保护的 API 端点。虽然被发现的路径可能无法利用，但它们仍然有助于攻击者映射系统中的 API 结构和约定。当您的代码暴露在外时，您将无法控制它，这一点对于任何开发人员来说都是需要牢记并牢记在心的关键。
• Web 管理面板与 API 端点类似，出于各种目的而被保留，是黑客发现和利用的常见攻击媒介之一。这些面板主要存在于大型组织中，由 IT 团队安装。定期检查所有正在使用的管理面板及其访问权限管理是一个好主意。最近，一家汽车制造商的数据泄露事件就是通过s从https地址前缀中删除 而绕过的。没错：🤦。

他们使用 GitHub

GitHub 是黑客的金矿。只需简单搜索，了解在哪里查找就能找到有趣的结果。如果您的帐户未启用 MFA，那么组织中的每个用户都可能是一个活生生的安全漏洞。不难想象，组织中的某个合作者没有使用唯一密码，而且他的密码曾经通过其他系统泄露。以组织为目标的黑客可以轻松地自动执行此类扫描，甚至可以手动完成。
员工列表可以通过OSINT生成，例如在 Linkedin 或 GitHub 公共用户列表中搜索员工。

例如，如果你想探究特斯拉，这是一个很好的起点：

https://api.github.com/orgs/teslamotors/members

即使公司不使用 GitHub 作为 Git 提供商，通常也不会发现泄露事件。只要有一名员工使用 GitHub 进行个人项目，并且其中一个项目（或其 Git 历史记录）出现小规模泄露，就足以构成数据泄露。

Git 的本质是追踪每个项目的完整变更历史。从安全角度来看，这一点尤为重要。换句话说，任何拥有当前组织系统访问权限的用户编写（或删除）的每一行代码，都会危及公司安全。

为什么会发生这种情况？

• 公司不会自我检查是否存在泄漏
• 那些这样做的人通常不会考虑查看员工的个人（但公开的）账户
• 那些确实扫描员工的（估计不到 1%）很多时候会因为依赖自动化和跳过提交历史记录而失败（不是扫描整个 git 树，而只是扫描代码当前快照的表面）
• 最后，公司没有频繁轮换密钥或使用双重身份验证 (2FA)。这两项措施可以消除上述大部分漏洞。

呆子101

“Dorks” 是指利用搜索引擎不同功能的搜索词，通过有针对性的搜索字符串来精准定位结果。以下是一份来自漏洞数据库的有趣 Google 搜索列表。

在介绍要点之前，如果你想深入了解，我个人建议你这样做，这里有一位才华横溢的研究人员提供的宝贵一课。他讨论了如何扫描，如何使用 dork，在进行手动过程时要寻找什么以及在哪里寻找。

GitHub dorks 比 Google 简单，因为它不像 Google 那样复杂。不过，在正确的位置搜索正确的字符串可以创造奇迹。只需在 GitHub 上搜索以下列表中的一个字符串，你就会得到惊喜：

password
dbpassword
dbuser
access_key
secret_access_key
bucket_password
redis_password
root_password

如果您尝试将搜索目标锁定在感兴趣的文件（例如filename:.npmrc _auth，或）filename:.htpasswd，则可以筛选要查找的泄漏类型。继续阅读 SecurityTrails 的精彩文章。

减轻

• 作为任何 CI 流程的一部分，扫描泄漏，GitRob是一个很棒的工具
• 扫描员工账户；Gitrob 会为您执行此操作，除非使用-no-expand-orgs标志禁用
• 深入了解历史记录，Gitrob 默认为 500 次提交，你可以使用-commit-depth <#number>
• 强制执行 GitHub 双因素身份验证！
• 轮换每个系统的访问密钥、机密信息和密码。一个好的做法是通过一个系统（例如 GSuite 或 ActiveDirectory）使用联合访问，并确保它们采用密码轮换和复杂性策略。

读者@codemouse92和@corymcdonald发表了关于密码复杂性、轮换和物理设备辅助的重要评论：

每次需要登录时，都要使用独特且复杂的密码……但要明白，复杂并不意味着深奥。目前，长短语被认为是最佳策略。
……
关于密码管理器，我想补充一点：虽然你绝对应该使用，但最好还是使用基于短语的密码，这样人机也能合理地输入。——
Jason C.McDonald

--

在我的工作中……每个人都配备了基于硬件的 MFA。每个人都有 2 个 YubiKey……
此外，我们为每个团队配备了 1Password 和独立的密码库。当员工离职时，支持团队会轮换该员工访问过的每个密码库中的所有密码。
我个人就犯过一个该死的错误，把 AWS 的机密信息推送到 Github。建议每个人都在预提交工作流中添加git-secrets，
以防止推送任何类似机密信息的内容。—— Cory McDonald

他们使用谷歌

现在我们对 Dork 已经很熟悉了，把它们用到 Google 上，就能发现它全新的功能。Google 是一个强大的搜索引擎，它提供了字符串、文件格式、域名、URL 路径等的包含和排除功能。
考虑一下这条搜索语句：

"MySQL_ROOT_PASSWORD:" "docker-compose" ext:yml

这是针对特定文件格式（yml）和易受攻击的文件（ ）进行的攻击，开发人员通常会将不太唯一的docker-compose密码存储在这些文件中。继续运行此搜索行，您会看到意想不到的结果。

其他有趣的行可能包括 RSA 密钥或 AWS 凭证，下面是另一个示例：

"-----BEGIN RSA PRIVATE KEY-----" ext:key

选择无穷无尽，创造力水平和对不同系统的熟悉程度将决定研究结果的质量。如果你想尝试一下，这里有一个很长的“傻瓜”列表。

他们了解你的系统

当研究人员（或有志于成为黑客的人）“涉足”某个系统时，他会深入研究。他会了解它，包括 API 端点、命名约定、交互方式，以及系统的不同版本（如果这些都暴露出来的话）。

一种不太好的系统安全方法是在访问路径中引入复杂性和随机性，而不是真正的安全机制。安全研究人员试图找出易受攻击的路径和端点，会使用“模糊测试”工具。这些工具使用单词列表，将它们组合成系统路径，然后探测它们是否返回有效答案。这些扫描器永远无法找到完全随机的字符集，但它们非常擅长识别模式并提取您忘记或不知道存在的端点。

请记住，通过隐蔽性来实现安全性并不是一个好的做法（尽管不要完全忽视它）

这时，我们之前讨论过的 Github dork 就派上用场了；了解系统端点的命名约定，例如，api.mydomain.com/v1/payments/...会非常有帮助。搜索公司的 Github 仓库（以及他们的员工）的基本 API 字符串，很多时候都能找到那些随机的端点名称。

然而，在构建系统时随机字符串仍然有一席之地；它们始终是比增量资源 ID（如用户或订单）更好的选择。

这里有一个非常棒的字符串列表仓库，名为“SecLists”。几乎所有业内人士都在使用它。它通常会根据目标环境进行个性化调整和修改，是一个海量资源。另一个利用字符串列表的强大工具是FFuf，这是一款用 Go 编写的超快速模糊测试工具。

总结

初创公司往往忽视了安全性。开发人员和经理往往优先考虑速度和交付时间，而不是质量和安全性。将明文密钥字符串推送到代码仓库、在系统中反复使用相同的密钥、在有其他选项可用时使用访问密钥，这些做法有时似乎更快，但最终可能会造成损害。我曾尝试展示那些你认为通过存储在私有仓库中而受到保护的字符串，是如何轻易地进入公共 gist 的。或者员工无意中将 Git 克隆到公共仓库的。如果你为安全工作奠定基础，例如使用密码共享工具、中央密钥存储库、密码策略和多因素身份验证，你将能够继续快速进展，而不会完全牺牲安全性。

“快速行动，打破常规”并不是信息保护领域的最佳口号

了解黑客的运作方式通常是理解安全并将其应用于系统保护措施的良好开端。请考虑上述方法，并且要知道，这只是黑客入侵系统时所采用的有限路径列表。无论部署到系统的任何内容是面向客户还是内部的，都应该牢记其安全性。

管理安全有时会很麻烦，但请放心，只要处理好最基本的要素，就能避免混乱，保证您的安全和理智。

感谢您读到这里！希望我的分享能帮助一些人认识到那些我们常常忽略或忽视的风险。

如有任何反馈或问题，请随时联系我们，我们非常欢迎任何形式或形式的讨论！