共享凭据如何为数据泄露大开方便之门
目录
前言
无论是银行登录门户、开源软件，还是操作系统本身，现代社会对技术的依赖让技术专业人员和大众已经离不开他人编写的代码。对一致性和实用性的需求催生了代码库之类的工具，毕竟从头编写所有代码不具有规模效益。
随着环境日益复杂，实现自动化和重用现有工具也变得愈发关键。
不过，开发人员利用这些预建库的代码作为自己开发代码的基础也引发了“信任问题”。这意味着需要某种程度的信任，但安全专业人士认为这种信任可能是有风险的。源代码中的漏洞隐藏得越深，就越难以被发现——这还是假设您一开始就知道如何在浩如烟海的代码中寻找那个特定的数字隐患。
我们在自己的开发过程中也遇到过这些所谓的信任问题。 一次看似平常的外部服务调用却揭示了多个严重攻击漏洞。将相关信息披露给供应商之后，我们发现的问题得到了解决。 在本博文中，我们将分享所发现的问题，详细介绍发现问题的过程，并且探讨攻击者可能会利用它来牟利的方式。
事件剖析
在例行的优化测试期间，我们的一位 DevOps 工程师为一个第三方测试工具创建了一个新的容器。他执行了非常熟悉的命令： apt get update && apt get install XXXX -y。
输入该命令之后，我们希望了解创建过程中我们的端点正在运行哪些进程。为此，我们在端点上运行了简单的列出进程命令 ps ，并且发现了下面这行非常有意思的内容：
我们能够使用已识别的凭据对包含数百个客户构建的站点进行身份验证。
发现明文密钥固然令人担忧，但可以通过适当的用户控制进行解释/控制；例如，让令牌仅对单次使用有效。这里的情况显然并非如此。所提供的用户名包含字符串“default”，而这从来都不是一个好兆头。
我们决定更进一步，尝试使用这些凭据对 API 进行身份验证，结果成功查询到了大量的潜在敏感信息。这证明“default”用户真的是人人可用的默认用户—— 该用户并非专门供 Akamai 使用，而是由该应用程序的整个客户群使用。
有了这个明文密钥，任何攻击者都可以使用它来检索该应用程序的客户中大多数人的敏感数据，例如内部测试运行结果、视频记录、屏幕截图和内部脚本执行流程（图 1）。
Fig. 1: Example of improperly accessed sensitive customer data
因此而暴露的数据量非常大，而漏洞的性质又显而易见，这让我们不禁想进一步研究他们的代码库，看看还能发现什么。
并非所有信息都适合共享
发现该应用程序存在严重滥用共享密钥的情况后，我们决定着手排查是否存在其他此类密钥。在该应用程序的源代码中进行几次精准搜索（以及大量的整理）后，我们发现了另外三个密钥：
- 一个 Coralogix 私钥
- 一个 Google API 密钥
- 一个 ngrok 令牌
我们来一起研究一下这些密钥及其被滥用的可能性。
Coralogix：一个（非常公开的）私钥
我们在应用程序的代码库中发现的其中一个密钥是一个私钥，这引起了我们的兴趣，于是我们搜索了可能与该私钥关联的任何用户名。我们成功地在该密钥下方的几行中找到了一个用户名，它属于日志记录功能的一部分。我们利用了所留下的其他线索，发现该私钥属于 Coralogix 日志框架。
这些凭据经过了硬编码，这意味着不同的客户也在使用它们。这可能表示存在另一个潜在的数据泄露问题，但幸运的是，此用户/攻击者的权限级别较低，只被允许将日志信息写入该框架中。
虽然功能并不如先前的原语强大，但写入原语仍然可以为供应商自身提供一些有趣的向量：攻击者可以在供应商的环境中插入伪造的日志消息，或者尝试注入恶意日志来实施跨站点脚本攻击 (XSS) 或结构化查询语言 (SQL) 注入等攻击。
Google API 密钥
OAuth 是 Google 在其所有业务运营中都使用的一种授权机制。应用程序和网站可以让用户使用支持 OAuth 的 Google 帐户登录其应用程序或网站。要通过代码启用此选项，开发人员需要用到几个可以从其 Google 帐户中获取的参数，也就是他们的 API 密钥（即他们的 google_name 和 google_secret）。
在浏览该代码时，我们发现了对 Google API 的引用。通常情况下，当我们看到一个“google api”密钥时，我们只会看到该密钥本身，但这次是个例外。这次我们不仅找到了“google api”密钥，还发现了 google_client 唯一标识符以及 google_secret 标识符（这是最令人费解之处）。有了这三者，攻击者便可以冒充该供应商，向 Google 请求身份验证链接。此链接可以用在网络钓鱼活动中，诱骗受害者将其 Google Workspace 的权限提供给攻击者。
潜在网络钓鱼攻击
攻击者可以创建一封 网络钓鱼 电子邮件，并将包含的链接指向与该供应商网站完全相同的一个网站，但其中一个关键的改变在于，使用 Google 帐户信息登录的链接是攻击者使用该供应商的 Google API 详细信息获取的链接（图 2）。
Fig. 2: Malicious Google login page appears to be legitimate
只要攻击者成功登录，受害者便向攻击者授予了对其整个 Google Workspace 帐户的权限。一旦掌握了 Google 身份这样的敏感信息，攻击者几乎可以为所欲为。成功利用该漏洞后，攻击者便完全掌控了受害者的 Google Workspace 帐户，可以进行包括电子邮件泄露、文件下载等在内的操作。在对企业进行社会工程攻击的过程中，这可能非常有用。
ngrok
网络隧道几乎是安全数据传输的通用解决方案，一旦遭到破坏，便会为攻击者提供一个充满恶意机会的藏宝箱。我们在被入侵应用程序的安装文件中发现了很多与隧道相关的参数，包括 ngrok 配置，这促使我们进行进一步的调查。有些功能不仅促进了开发人员更好地进行协作，它们还成为攻击者觊觎的目标。
Ngrok 服务专门用于提供通过服务器隧道传输信息的平台。借助 Ngrok，向互联网公开服务变得非常简单，这有助于实现更快速的调试和更高效的开发反馈循环。遗憾的是，如果攻击者夺取了隧道的控制权，这种简单性也能够为他们所用。
通过调用简单的 ps 命令，攻击者可以查看公司的唯一 ID 和身份验证令牌。该唯一 ID 不可更改；在其他端点上使用该应用程序时，它将保持不变。攻击者可以使用以下参数将该 ID 和令牌发送到供应商的在线服务器以接收该公司的 ngrok 详细信息（图 3）。
Fig. 3: Ngrok token received from the vendor’s server
这意味着，在初始访问后， 攻击者可以从受害者那里复制唯一 ID 和令牌，并使用它们来读取受害者的应用程序发送/接收的数据 （图 4）。
Fig. 4: Example of data being read from ngrok tunnel
结论
威胁并非全然来自外部；事实上，我们甚至会主动容忍某些内部威胁的存在。很多人认为开源软件是最大的危险，因为我们信任它，但对于公司来说，第三方工具构成的挑战可能比开源软件更大。
根据我们的发现，我们向受影响的供应商披露了本博文中强调的问题，并且这些问题已得到修复。尽管如此，新的安全漏洞总是层出不穷。
我们相信，在这种情况下以及很多其他情况下， 安全监督 与培养开发人员的安全观念同样重要。这两方面都有助于确保托管服务不会给公司带来任何问题。