世界就是一个巨大的草台班子 https://fulcrumsec.vg/pingcap/
总窃取数据量 10.6 TB • 4,901,203 个文件 • 连续 88 次（每 6 小时一次）导出生产环境控制平面数据且未被察觉 • 约 50 个 GCP 存储桶 • 一个包含 5.338 亿行数据的 BigQuery 数据仓库 • 180,046 个租户组织 • 403,262 个独立电子邮箱 • 115,308 个明文客户 API 密钥（其中 42,612 个处于活跃状态） • 20,645,574 条客户 SQL 语句 • 102,003,766 次网关连接记录 • 5,036,738 个客户服务器 IP • 377,446 个 Jira 工单 • 433,928 个 CRM 联系人 • 92 GB 带有租户标签的 AWS 成本数据 • 413 个私有源代码仓库
今天，我们将 PingCAP 数据泄露事件公之于众。我们掌握了完整的 TiDB Cloud 控制平面、其账单与财务资产、GCP 存储资产、AWS 成本与账单资产、Jira、CRM、分析数据、源代码，以及长达四年的连接日志——记录了每一位客户从其应用服务器 IP 地址向该产品发起的每一次连接。
PingCAP 销售的 TiDB Cloud 是开源数据库 TiDB 的托管版本。银行、游戏工作室和电商平台将各自的生产环境工作负载交由其托管；PingCAP 在一个共享的多租户平台上运维这些集群，其整个商业模式都建立在“这样做既安全又可靠”的承诺之上。而本文接下来的内容将证明，它既不安全，也不可靠。
首先，他们对自己的云服务似乎毫无可见性（监控能力为零）。可悲的是，这在我们攻破的公司中已是司空见惯——他们愿意斥资数百万美元购买华而不实的 EDR（终端检测与响应系统），却任由五百个 S3 存储桶大摇大摆地被人搬空。但要知道，这可是一家云服务提供商。当他们旗下的每一项云服务（AWS、GCP、Atlassian / Jira、Azure）都遭到大规模、且毫不掩饰的入侵与数据窃取时，他们却似乎完全无力察觉，这种状况极其糟糕，且极度不负责任。在最初窃取了约 8 TB 数据后，我们在近两个月的时间里持续窃取并定期补充最新数据。我们甚至利用他们自己在代码仓库中提交的凭据（GCP 服务账号密钥和 Azure 服务主体），为他们自己的控制平面数据库搭建了一条数据复制流（replication feed），直接让他们的基础设施把数据源源不断地输送给我们。在此次行动的最后 22 天里（从 9 月 8 日到 9 月 30 日），这条数据管道每六个小时就会忠实地将 TiDB Cloud 运维核心中的每一张表——租户、用户、API 密钥、集群凭据、变更数据流（changefeeds）、迁移记录——重新导出并推送出来。连续 88 次导出，没有触发哪怕一次安全检测告警。最后一次导出运行于 9 月 30 日 06:02（UTC 时间）。它所携带的控制平面数据已包含在第一阶段公布的数据中。
heno 10-21 16:521楼