Postman 大量企业生产数据泄露，可直接接管后台
总结
- TRIAD 团队利用 CloudSEK 的 XVigil，确定了不当使用 Postman 工作区（一种流行的基于云的 API 开发和测试平台）所产生的重大风险。
- 在本博客中，我们将介绍一些有趣但关键的事件，这些事件可能导致客户 PII 的大规模数据泄露、通过收购滥用组织拥有的合法服务、发起恶意活动等。
- 我们长达一年的调查发现，超过 30,000 个可公开访问的 Postman 工作区泄露了敏感信息。在大多数情况下，这些集合包括访问令牌、刷新令牌、第三方 API 密钥，甚至来自各种规模和不同行业的组织的测试或演示用户数据。尽管许多泄露的第三方 API 密钥和令牌实例可以追溯到 API 架构中的权限不足或限制，从而无法正确识别所有者，但最终来源通常仍然未知。
- 大多数已确定的事件都归因于相应的组织并负责任地报告。
Postman 中的敏感数据泄露：您需要了解的内容
在快节奏的 API 开发和测试世界中，Postman 已成为开发人员和组织的首选工具。它的易用性、多功能性和协作功能使其成为不可或缺的。然而，权力越大，责任也就越大，风险也随之而来。Postman 环境通常包含敏感数据，从 API 密钥和令牌到机密业务逻辑，如果处理不当，它可能会成为恶意行为者的潜在金矿。
API 密钥、文档、凭据和令牌等敏感信息通常最终会通过 Postman 集合暴露，从而造成严重的安全漏洞。使用 CloudSEK 的 XVigil，我们发现了多个敏感数据被意外泄露的实例，凸显了对更好的安全实践和意识的迫切需求。
案例研究：来自各种报告的事件
通过 Okta IAM API 泄露各种业务和内部数据
运动服装和鞋类行业的领先组织之一可能由于第三方供应商泄露了其中一个私人 Postman 工作区而受到损害。工作区中的请求将与有效凭证和访问令牌一起发送到组织的 Okta IAM。通过该访问权限，任何威胁行为者都可以访问 Postman Workspace 中提到的该品牌的其他内部 API。由于这些访问，恶意行为者可以泄露各种发票、贸易内容、属性、货运详细信息以及各种商业数据。
影响分析：
- 未经授权的用户访问公司内部 API 的影响将是深远而重大的。威胁行为者不仅可以操纵记录并采取未经授权的行动（对组织造成财务和声誉损害），还可以获得对机密数据的访问权限。在极端情况下，整个公司数据库都可能面临风险。
- 此外，除非有适当的跟踪和监控系统，否则可能很难识别未经授权的修改或操作。所有这些都将对公司、客户和员工的安全性和可靠性产生直接影响。
通过泄露的 Zendesk 凭据泄露各种医疗保健客户和内部数据
由于发现公共 Postman 工作区泄露了高度敏感的信息，包括有效的 ZenDesk 管理员凭据，一家大型医疗保健公司可能已经屈服于重大数据泄露，泄露了客户信息以及以完全管理员权限访问支持门户。这种风险是一颗定时炸弹，可能会为客户数据泄露和未经授权访问组织的 ZenDesk 支持门户打开大门，这些风险可能会严重影响声誉和财务。
暴露的 ZenDesk 凭据仍然处于活动状态，可能允许恶意行为者以完全管理员权限登录支持门户。这意味着他们可以执行关键操作，例如以组织的名义创建或修改社区文章，从而进一步放大潜在的损害。
泄露的 Razorpay API 凭据。
在我们的调查过程中，我们遇到了多个 Razorpay API 密钥在公开共享的 Postman 工作区中意外暴露的实例。这些密钥旨在实现与 Razorpay API 的安全通信，但未受到保护，因此容易受到未经授权的访问。
这种疏忽很容易让威胁行为者利用暴露的密钥，可能导致金融欺诈或滥用支付系统。它清楚地提醒了保护敏感凭证的重要性，尤其是在协作环境中。
泄露的 API 密钥可能会产生毁灭性的后果，包括导致财务损失的未经授权的交易、泄露敏感客户数据以及因信任和合规性受到打击而造成的重大声誉损害。企业还可能面临运营中断，因为在解决滥用后果的同时撤销和重新生成密钥可能会中断正常的工作流程。
使用会话密钥和 API 调用泄露的刷新令牌
我们在公共 Postman 工作区中发现了一次严重泄漏，其中暴露了主要 CRM 软件的刷新令牌和会话密钥。更糟糕的是，还包括用于生成访问令牌的 API 端点，允许未经授权的用户潜在地利用整个令牌生命周期。
刷新令牌和会话密钥的泄漏为严重风险打开了大门。攻击者可以使用它们生成有效的访问令牌，从而允许他们在未经授权的情况下访问敏感的 API。这不仅使数据处于风险之中，而且还允许会话劫持，用户会话可能被用于数据盗窃或服务滥用。更糟糕的是，如果其他详细信息也被泄露，攻击者可能会升级他们的访问权限，进一步破坏系统，甚至冒充合法用户，从而使影响更加严重。
泄露的 NewRelic API 凭据
工作区中的请求将向一家大型软件公司的 New Relic API（日志监控和分析软件）以及有效的 API 密钥发出。威胁行为者可以访问日志文件、微服务、内部终端节点和标头。这可能使他们能够访问系统和应用程序日志、产品使用数据、网络流量数据和用户凭证，从而提供有关您公司及其内部基础设施的大量信息。
出于 POC 目的，我们还重现了公开的 Postman 工作区中提到的查询。此查询将为给定仪表板页面实体 GUID 生成公共 URL。然后，可以在生成的公有 URL 中以静态快照的形式访问控制面板页面。
在浏览器中访问 URL 后，您将获得仪表板详细信息。
Postman Workspace 中泄露的 API 文档
在这种情况下，发现一个 Postman 工作区公开了 API 文档，包括有关终端节点、请求参数、身份验证方法和错误代码的详细信息。更糟糕的是，一个有效的代币也被泄露了。
这种暴露可能会产生严重后果：攻击者可能会使用详细的端点信息来利用漏洞或访问受限资源，从而显著增加针对性威胁（如 SQL 注入或拒绝服务攻击）的攻击面。此外，竞争对手或恶意行为者可能会深入了解专有业务逻辑，从而危及机密性并为他们提供不公平的优势。
在这种特殊情况下，API 用于代表组织使用其 whatsapp 帐户发送 whatsapp 消息。使用令牌，研究人员能够完全控制该帐户，并可以向用户发送任何类型的短信/消息，这很容易被用来网络钓鱼用户以安装恶意软件或获取他们的凭据。
Postman 中的敏感数据泄露是如何发生的
几种常见的场景和做法会导致 Postman 中的敏感数据泄露。这些通常缺乏访问控制不足、意外共享和不安全的存储做法。
Postman 集合是一组结构化的 API 请求，使用参数、标头和身份验证详细信息等相关数据进行组织，旨在简化测试和协作。
以下是数据泄露的一些典型原因：
- 无意中共享集合和环境
Postman 最强大的功能之一是其协作功能，允许团队成员共享集合和环境以实现高效开发。但是，如果敏感数据嵌入到共享集合中，这也可能导致意外暴露。当包含敏感变量的环境在团队之间或与外部协作者共享时，未经授权的用户可能会获得对机密信息的访问权限。
- 与可公开访问的存储库同步
在某些情况下，Postman 集合和环境文件会同步或导出并存储在 GitHub 等公共存储库中。如果在上传这些文件之前未屏蔽或清理敏感数据，则有权访问存储库的任何人都可以访问这些数据。这是一个常见的漏洞，因为开发人员可能会无意中发布令牌或机密，而没有意识到其影响。
- 配置错误的访问控制
Postman 允许用户设置不同级别的权限，但配置错误的访问控制可能会导致广泛的访问，而只应允许受限访问。如果敏感环境在组织范围内共享，甚至错误地公开，这可能会导致大量数据泄露。
- 以明文形式存储敏感数据
Postman 通常以纯文本格式保存环境变量和其他数据，任何有权访问 Postman 工作区或环境文件的用户都可以查看这些数据。由于缺乏对本地存储或共享的敏感信息的加密，因此很容易被泄露，尤其是在共享或受感染的设备上。
- 使用长寿命代币，无需轮换
在 API 测试中，通常使用令牌对请求进行身份验证。许多团队选择长期令牌以避免不断的重新身份验证。但是，如果这些令牌不经常轮换或硬编码到 Postman 中，则它们可能会成为高价值目标。如果暴露，这些令牌可能会提供对系统的长期未经授权的访问。
Postman 中敏感数据泄露的影响
Postman 中的敏感数据泄露可能会对单个开发人员和整个组织产生重大影响。例如，泄露的 API 密钥或访问令牌可以让攻击者直接访问关键系统和数据，从而可能导致：
- 数据泄露：攻击者可以利用暴露的密钥来访问和泄露敏感数据，从而导致经济损失、声誉损害和监管处罚。
- 未经授权的系统访问：如果攻击者获得了对令牌或凭证的控制权，他们就可以冒充合法用户或应用程序，授予他们对内部系统或服务的未经授权的访问权限。
- 网络钓鱼和社会工程攻击增加：攻击者可以使用泄露的凭据发起有针对性的攻击，例如网络钓鱼或社会工程，以进一步渗透到组织中。
Postman 工作区是一个协作环境，用户可以在其中组织 API 集合、环境和其他资源并与团队成员共享，以简化开发和测试。
该数据突出了令人担忧的发现，超过 30k Postman Public 集合在各种平台和服务中暴露了敏感的 API 密钥和凭据。以下是一些重要见解：
- 顶级 API 服务泄露：api.github.com（5,924 次）、slack.com（5,552 次泄漏）和 hooks.slack.com（4,961 次）等平台在榜单中占据主导地位，显示了大量暴露的秘密。
- 热门 API 服务泄露：salesforce.com （4,206）、login.microsoftonline.com （1,729） 和 graph.facebook.com （1,174） 等备受瞩目的服务凸显了此问题的广泛性质，影响了关键的云、社交媒体和商业生态系统。
- 各种 API 服务泄露：风险范围从以开发人员为中心的工具（如 api.twilio.com （283） 和 api.openai.com （262））到电子商务和支付系统（如 api.stripe.com （554） 和 api.razorpay.com （704）。
这些数据凸显了 API 安全实践中的重大差距，并强调了迫切需要对协作开发环境中 API 密钥和凭证的管理方式进行更严格的控制。可视化比例的饼图可以进一步突出泄漏在顶级服务中的集中度。
Postman 中存储的常见敏感数据类型
敏感信息通常在 Postman 中用于验证 API 和与 API 通信。这些数据通常包括：
- API 密钥和密钥：授予对 API 的访问权限的唯一标识符，通常存储在 Postman 中，以便在测试期间易于使用。
- 访问和刷新令牌：用于身份验证，尤其是在 OAuth2 流中，这些令牌通常具有长期有效期，如果泄露，可用于冒充合法用户。
- 用户名和密码：Postman 集合中有时使用基本身份验证，使凭据容易暴露。
- 客户端密钥和证书：对于加密通信至关重要，它们通常存储在 Postman 中以方便测试，但如果未经授权的用户访问，则可能高度敏感。
- 环境变量：
生产或暂存环境的配置设置，通常包括内部 URL 或敏感的操作数据。
个人身份信息 （PII）：如果处理不当，可能会导致隐私侵犯和合规性问题的客户或员工数据。
参考链接：https://www.cloudsek.com/blog/postman-data-leaks-the-hidden-risks-lurking-in-your-workspaces
