2023年8月21日，安全安全研究人员兼HackerOne顾问委员会成员Corben Leo在社交媒体上宣布，研究他侵入了一家汽车公司，人员入汽随后发布了一则帖子 ，何通划侵解释如何获得了数百个代码库的过漏访问权限。

图1

Corben参加了由这家汽车制造商发起的洞悬漏洞悬赏计划。漏洞悬赏是赏计司众多行业一种非常普遍的做法，旨在奖励道德黑客发现问题并以负责任的安全方式报告问题 ，这种做法久经时间的研究考验 ，为许多公司带来了显著的人员入汽效果。模板下载与此同时，何通划侵有报道称与其他行业相比，过漏汽车制造商支付的洞悬漏洞赏金往往少得多 。

就本文这个案例而言
，赏计司这家汽车公司给出了合理的安全奖励，Corben也有合理的动机去发现和报告这个可能引发危机的漏洞 
。Corben在帖子中阐述了其攻击方法。简而言之，通过反复试错 ，他找到了所谓的入站控制器，这其实是服务器租用用于Kubernetes环境的负载均衡器 ，通过蛮力攻击 ，操纵主机报头
，他发现了一个错误配置的Spring Boot Actuator（Sprint Boot框架的子项目） ，该Actuator使用HTTP端点来公开运行应用程序方面的操作信息，他发现的端点是 /env 和 /heapdump 端点。这时候凭据登场亮相了。

图2

/env 端点拥有经过适当编辑处理的密码，这意味着进入了死胡同，源码库然而， /heapdump端点含有存储在内存中的应用程序对象的快照，暴露了明文格式的凭据。在搜索关键字仅仅几分钟后，他就找到了oauth2凭据，他利用这些凭据访问了一个之前发现的config-server实例；同样由于另一个错误配置的Spring Boot Actuator ，他找到了另一组 /env 和 /heapdump 端点 。

不过这一回，/env端点没有编辑凭据。Corben现在有了GitHub代码库管理员的私钥和密码 ，亿华云这个管理员可以访问30多个GitHub组织，并对数百个代码库拥有读写访问权。

图3

如果不道德的黑客先发现了这个漏洞 ，这家汽车公司可能会泄露其所有的私有代码库或遭到勒索，正如我们所看到的 ，不是所有的公司都这么幸运  ，包括三星 、英伟达 、微软和优步。

这个场景涉及多个问题：错误配置
、暴露的免费模板明文密码和范围确定
。

虽然我们不能确定这家汽车公司的DevOps团队是如何部署其基础设施的 ，但很有可能他们会使用基础设施即代码（IaC），比如Terraform
、Crossplane或CloudFormation 。IaC有一些重大的优点，因为配置可以快速地进行版本控制和审查，使整个环境具有极大的可扩展性。然而，建站模板最大的缺点之一是代码中的错误配置可能意味着相同的问题推广到整个环境中的每个实例 ，这可能就是相同的错误配置出现在多台服务器上的原因 。

在流程的早期测试错误配置 ，是确保它们不会出现在生产环境中的最佳方法
，GitGuardian的客户使用gghield用于IaC扫描已有很长一段时间了。现在 ，我们通过新的基础设施代码安全模块将相同的这项扫描功能添加到GitGuardian平台，客户可以在仪表板上看到100多次自动扫描的结果，并协调修复过程。

无论你如何部署基础设施（手动部署还是通过IaC部署） ，都要确保添加了审查过程来覆盖常见的场景，我们还鼓励IaC方面刚入手的读者了解《WASP云原生应用程序十大安全漏洞》，知道测试时应该留意什么漏洞
。

到目前为止，我们希望每个人都知道以明文形式存储密码是个坏主意，然而我们也知道
，进入到公共GitHub代码库的暴露密码数量每年都在增长  。在本文，我们确实看到了为确保机密（secrets）安全而花费心思的证据，因为Corben遇到的初始 /env 端点确实拥有经过编辑的凭据，然而，他们忽略了 heapdump 端点中的日志文件  。

检查任何地方的机密至关重要，不仅仅是所编写的代码中的机密，还有代码生成的任何文件（包括日志）中的机密，这就是ggshield（GitGuardian CLI）可以扫描任意文件或路径查找机密的原因之一 。手动审查日志的代码可能会发现明文凭据的存在，但是始终使用工具进行测试的团队更容易及早发现问题 ，如果他们清理了那个端点上的日志，这将是内容全然不同的社交媒体帖子
 。

Corben发现的GitHub凭据不仅授予对单个私有代码库的访问权 ，甚至还授予对单个私有组织的访问权，他报告自己获得了对30多个组织和数百个代码库的访问权限，需要这种级别的跨组织协作可能有其合理的理由 。然而，这感觉像是有人使用根用户凭据来处理所有事情
，安全界的共识是始终致力于实现零信任架构，并运用最小特权原则。

Mackenzie Jackson在其文章《管理和存储包括API密钥和其他凭据在内的机密的最佳实践》中讨论了最小权限的这个原则，所有凭据都应该严格限定在其预期目的范围内，只授予完成特定任务所需的最小权限，创建一个只能访问非常特定的代码库的新用户可能是一条更好的途径，这意味着Corben将拥有一些访问权限，但无法访问密钥。

实际上，互联网上的每个应用程序都在不断地接受安全测试。问题就在于谁在测试 ，以及测试的目的是什么，我们一直在与攻击者玩猫捉老鼠的游戏，总是试图比对方领先一步。参与漏洞悬赏计划、雇用渗透测试人员来发现和利用应用程序和环境中的漏洞，这些都是确保你在攻击者之前发现问题的好方法
。

外头有很多道德黑客等着与你合作，帮助你确保安全，如果你正在寻找有关漏洞悬赏平台方面的更多信息 
，请查看HackerOne、Bugcrowd或Open Bug Bounty，这是三个最受欢迎的平台 。你也可以看看Jason Haddix最近的安全代码库播客 ，他畅谈了自己作为漏洞赏金猎人和育碧（UbiSoft）CIO的经历
，保证你的应用程序和客户的安全是一个过程。

我们可以从这个例子及其他例子中汲取很多教训。本文提醒我们在确定凭据的范围时应遵循最小特权原则
，不要添加明文形式的密码，并进行测试，以确保我们的基础设施即代码没有错误配置，无论你在通往更安全的道路上处于哪个阶段 ，我们都鼓励你不断学习
，努力保持安全 。