Fractal ID 数据泄露事后分析

总结：

• 2024 年 7 月 14 日星期日，我们的监控系统检测到我们的一个后台办公室出现异常活动。此活动很快被识别为恶意账户的恶意攻击，并在不久后得到遏制。

• 一名运营商帐户访问凭证被盗，攻击者得以窃取我们约 0.5% 用户的数据。我们对所发生的事深表遗憾，我们将尽最大努力保护受影响的用户。

• 该操作员已与我们合作 3 年，拥有管理员权限。这使攻击者能够避开内部技术数据隐私系统，然而，系统监控发现了这一威胁，并让我们在 29 分钟后锁定了攻击者。  

• 操作员没有遵守我们的操作安全政策和培训。我们已采取技术措施，确保将来任何操作员都无法规避这些措施。这不是软件漏洞造成的。

• 我们在外部技术安全支持的帮助下确定了攻击的范围并对其进行了控制。

• 我们正在采取措施减轻此次攻击的影响，包括优先采取额外的安全措施，并与当局和网络安全服务部门合作，以限制数据泄露的影响。

事件和响应

2024 年 7 月 14 日星期日 07:00 UTC，我们的系统监控向值班的一名工程师发出了警报。此警报指出 Fractal ID 的一个后台办公室出现了异常活动：正在查询一个在正常操作过程中不经常使用的特定端点。这最初似乎是后台办公室前端代码的回归，但很快就清楚了，这其实是一次攻击的证据，因此他们于 07:29 UTC 关闭了这个后台办公室以阻止攻击。

这位工程师立即拉响了警报，团队开始深入调查情况。经过分析，我们得出结论，我们刚刚遭遇了数据泄露。后台的管理员帐户使用有效凭据登录系统，并利用他们的特权管理员访问权限，点击系统的 API 逐一窃取用户数据，大概是自己保留了这些数据的副本。由于他们在 Fractal ID 中的角色，这个帐户需要这个特权。只有极少数管理员操作员被授予此级别的访问权限。

在恢复此系统之前，我们禁用了该系统中的所有帐户，并将访问权限限制在少数 Fractal ID 高级核心员工的范围内。

管理员权限使攻击者能够绕过内部技术系统数据隐私保护方法，例如严格限制当前处理的用户（每次一个）的数据访问。此外，操作员没有遵循我们的操作安全政策和培训，这让攻击者得以窃取访问凭据。这是因为操作员重复使用了过去无关的黑客攻击所泄露的凭据并忽略了安全警告。

此后，我们已采取措施，从技术上确保任何操作员将来都无法绕过操作安全，并审查和限制了系统中的角色。

我们还立即采取措施减轻此次泄露的影响，并联系了相关数据保护机构和网络犯罪警察部门。此次泄露仅发生在我们的环境中，不会影响使用我们服务的任何客户系统或产品。我们将继续与相关数据保护机构合作，将数据泄露的影响降至最低。

后来，有人联系我们，声称对这次袭击负责。他们向我们索要赎金。我们没有参与，而是向当局举报了他们。

谁受到了影响以及哪些数据被泄露

该恶意账户可访问 6.3k 名用户的数据，约占我们数据库中用户的 0.5%。我们已直接联系受影响的用户，告知他们此次泄露事件。泄露的数据范围从仅进行身份证明检查到进行全面 KYC 检查不等，具体取决于用户在入职时需要提供的内容。这可能包括姓名、电子邮件地址或电话号码、钱包地址、实际地址、任何上传文件的图像和图片。

我们始终对客户负有义务，即在验证后将用户数据集中存储。这些数据在静止时是加密的，但由于它是由有效的运营商帐户访问的，因此我们的后端会解密数据以进行显示，就像在常规操作期间一样，以支持我们的客户。需要重申的是，并非所有运营商都可以访问这些数据，只有少数管理员可以访问。

我们正在采取哪些措施来避免将来再次发生类似的袭击

我们正在优先采取措施，使我们的登录系统更加强大，避免将来再次发生类似的攻击并减轻其后果：

• 请求限制：限制每个帐户在每个时间段内可以访问的用户数据量

• 更细粒度的授权：创建额外的账户类型，使我们能够为客户提供服务，而无需透露特定实例所需的任何信息

• 严格监控失败的身份验证尝试：防止试图通过字典攻击账户密码

• 更严格的 IP 控制：使用当前访问 IP 监控，在帐户未通过其常规 IP 进行身份验证时阻止访问

我们将采取什么措施保护客户

我们非常重视用户数据的安全和隐私。除了改进安全措施外，我们还与网络安全服务机构合作，以监控用户数据是否被添加到已知的数据泄露网站。我们将及时向用户通报最新情况，并尽最大努力阻止其传播。

我们还联系了相关数据保护机构，并向柏林警察网络犯罪部门提交了犯罪报告。

所访问的数据可能会被出售给第三方、被网上冒名顶替者使用或用于商业目的。我们建议用户对要求提供更多个人信息的未经请求的通信保持谨慎。

我们将向用户提供相关更新。如果您有任何疑问或我们可以提供任何帮助，请联系 [email protected]

前进之路

我们意识到这次数据泄露对受影响的用户来说确实很痛苦。这对我们来说也很痛苦，因为我们的任务是保护这些用户的数据安全。

我们立即分析并改进了我们的系统。然而，在中心化数据存储中，攻击者和像我们这样的防御者之间总是会有一场竞赛。我们的目标是将人们从 Fractal ID 的中心化服务器转移到一个自我托管的存储系统中，这早在这次事件发生之前就已提出。这不是为发生的事情找借口，而是一种坚定的信念，即我们需要使用去中心化系统来保证用户数据的安全。自 2017 年以来，我们一直为 web3 领域提供身份解决方案，并致力于构建一个更好的系统。

我们对所发生的事深感遗憾，我们将尽最大努力保护受影响的用户。我们将继续努力，最终建立一个不会发生此类违规行为的系统。

真挚地，

分形 ID

—

有关我们今天如何保护用户数据的更多详细信息

收集和储存

当用户将其身份信息输入我们的 Web 应用程序时，数据收集会在用户的浏览器上进行。所有传输中的数据均经过加密。我们实施 HSTS，并尽可能严格地遵守 CSP 规则。

我们将数据存储在爱尔兰地区的 Amazon Web Services (AWS) 中，所有静态数据都经过加密。

使用权

出于 BI 目的，一些员工可以读取某些数据，这些数据既不是个人身份信息 (PII)，也不是秘密数据（密码哈希、MFA 种子等）。只有经过良好培训的特定人员才被授予对数据库的 PII 读取访问权限，并根据需要进行。只有系统管理员才能访问秘密数据和完全读写直接数据库访问权限。

个人数据仅在验证后台可见。访问帐户必须手动创建，它们受密码保护，登录限制在预期的工作时间内，长时间不活动时会话会自动注销，我们会发送电子邮件登录通知等。

普通账户除了进行身份验证所需的信息外，不会显示任何其他用户信息，他们无法检索已查看过的个人资料或其他任意用户的个人资料，并且他们的所有操作都会被记录下来。搜索功能仅限于选定的管理员组。

基础设施

我们在 Amazon Web Services (AWS) 上运行我们的系统。我们大量使用其服务，以尽可能地利用它。值得注意的是，我们使用：

• 虚拟私有云 (VPC) 尽可能隔离我们的流量。所有入站和出站流量都经过加密，并限制在入站访问协议的最小子集内。

• AWS 证书管理器 (ACM) 委托我们所有的 TLS 证书管理。

• 应用程序负载均衡器 (ALB) 用于委托 HTTP 网络安全并提供增强的可用性。

• 关系数据库服务 (RDS) 具有多可用区部署、静态加密、强制 TLS 连接以及 35 天的每日备份保留期。

• 所有有效负载均已加密的简单队列服务 (SQS)。

• 具有服务器端加密的简单存储服务（S3）。

• 仅使用 Fargate 实例的弹性容器服务 (ECS)。

仅将 ECS 与 Fargate 实例结合使用会给我们带来一些有趣的好处。即：

• 我们需要关心的软件基线大大减少，因为没有主机系统需要管理，因为这已委托给 AWS。

• Web 工作实例仅公开其 HTTP 端口，而后台工作实例则根本不公开任何端口。这意味着没有系统管理员可以访问它们，从而消除了代码或配置漂移的可能性。

• 如果需要操作员干预，我们可以启动具有公共 IP 和 ssh 服务器的临时实例。这些实例在每次干预后启动，并在 30 分钟后没有 ssh 会话时自动关闭。

我们使用 CloudWatch 日志和警报。日志保留 7 天。所有系统都使用严格的阈值监控相关指标，以监控异常模式。我们使用 Sentry 收集所有错误。

访问我们的 AWS 生产账户需要 MFA。我们维护独立的生产和测试账户。只有一小部分训练有素的工程师才能访问生产账户。