Slope钱包Sentry漏洞——数字取证与事件响应报告

本文是对2022年8月2日Solana钱包被攻击事件的调查报告,重点关注了Slope钱包的Sentry漏洞。报告指出,尽管Slope钱包的Sentry应用监控存在收集敏感信息且未加密存储在中心服务器上的漏洞,但没有确凿证据表明服务器上的数据被泄露或在客户端-服务器传输过程中被拦截。审计结果未能明确将此漏洞与攻击事件关联。

Slope 钱包 Sentry 漏洞 — 数字取证和事件响应报告

前言

以下声明旨在概述 2022 年 8 月 2 日 Solana 钱包被黑事件的初步根本原因分析中发现的 Slope 钱包漏洞。本情况说明书中的每个描述都已得到至少一家审计公司的确认,或者可以通过链上数据等公开信息进行验证。如有疑问或需要验证以下详细信息,请联系 exploit@slope.group。

概要

Slope 钱包应用程序监控日志记录漏洞无法最终解释 2022 年 8 月 2 日的钱包攻击事件。

Slope Sentry 漏洞构成了一项严重的安全漏洞,因为它收集敏感信息并将这些数据以未加密的形式存储在中央服务器上。在两家领先的加密审计公司 OtterSec 和 SlowMist 进行了为期 12 天的密集代码和服务器审计(包括文件、系统、内存、网络和日志取证)之后,没有确凿的证据表明服务器上的数据曾被泄露,或者数据在客户端-服务器管道中被拦截。

Slope 将继续领导帮助受影响用户追回被盗资产的工作。

1. 2022 年 8 月 2 日 Solana 黑客事件响应概要:

在 2022 年 8 月 2 日星期二深夜,共有 9229 个钱包遭到攻击。攻击持续了 7 个小时(UTC 时间 22:37 至 05:50),并提取了用户资产,当时价值总计约 400 万 USDC。黑客在将资产转移到黑客控制的 4 个钱包时拥有钱包所有者权限,这意味着某种私钥泄露。

黑客攻击开始三小时后,8 月 3 日 UTC 时间 01:20,Solana 基金会组建了一个钱包耗尽事件响应小组。来自各种项目和领先安全公司的 100 多人共同分析可能的攻击向量。这项广泛的调查持续了 12 个多小时,不幸的是,来自两个钱包提供商的一些敏感数据在网上泄露,并且对调查进展情况发表了一些过早和/或具有误导性的公开声明。

由于大多数用户的报告都报告了使用 Phantom 和 Slope 移动钱包的黑客攻击,并怀疑供应链攻击是最可能的攻击向量,因此启动了 Phantom 和 Slope 移动应用程序之间的交叉依赖性检查。这两个应用程序都使用了 Sentry 提供的应用程序监控服务。

UTC 时间 11:30 发现,Slope 特定于 Sentry 的实现(包含在 Android 和 iOS 上的 Slope 钱包移动应用程序中)正尝试将敏感钱包数据发送到中央服务器。此数据通过 HTTPS TLS 加密,并通过 TLS 证书锁定进一步保护,并且对 Slope 在 AliCloud 上托管的服务器的访问受到控制。UTC 时间 11:45,Slope Finance 关闭了应用程序监控服务器,从而在首次报告该漏洞后 15 分钟关闭了该漏洞。

由于已发现的漏洞可能造成的严重影响,在漏洞的潜在规模和漏洞被确认为黑客攻击的根本原因之前,UTC 时间 18:45,Slope 的官方 Twitter 帐户正式建议所有 Slope 钱包用户放弃其钱包地址,并尽快将所有资产转移到新创建的钱包中。

在确定了第一个可靠的漏洞后,Solana 事件响应小组于 UTC 时间 21:28 放弃了对可能的攻击向量的任何其他假设的追查,但没有确凿的证据表明已发现的漏洞可以解释黑客攻击的全部范围。

UTC 时间 8 月 4 日 03:15,聘请审计公司 OtterSec (www.osec.io) 对 Slope 进行广泛的服务器和代码审计。网络安全和服务器审计公司 SlowMist (www.slowmist.com) 在 UTC 时间 06:45 提供了额外支持。UTC 时间 16:45,聘请数字资产合规和风险管理公司 TRM (www.trmlabs.com) 来支持资产追回工作。

UTC 时间 8 月 5 日 07:20,Slope 钱包移动应用程序从 Android 和 iOS 商店中撤下。

  1. Slope 钱包移动应用 Sentry 漏洞:

1.1. 简单英语概要

钱包应用程序需要使用钱包的私钥来解锁钱包和签署交易。为了能够做到这一点,私钥会临时加载到内存中,然后从内存中主动删除。

Sentry 应用程序监控 (www.sentry.io) 是一种领先的第三方插件,用于调试应用程序。它通过自动收集保存在内存中的各种数据并将这些数据发送到中央服务器(开发团队可以在其中评估这些数据)来帮助开发人员修复应用程序中的错误。此类服务已在行业中广泛使用,包括在 Phantom 钱包和 Trust 钱包中。Slope 采用了应用程序监控服务的本地实例来调试其移动应用程序。应用程序监控从未部署在 Slope Chrome 浏览器扩展程序上。

Sentry 提供了多种方法来防止在开发人员不知情的情况下记录(关键)敏感数据(例如私钥)。它会在黑名单的基础上提供自动关键字过滤器,以避免意外收集敏感数据。此外,记录的数据在传输到服务器的过程中会被加密,并存储在经过加密且访问受控的安全数据库中,以避免不必要的访问。这些代表了四个安全层(收集、传输、加密和访问)。

领先的审计公司 OtterSec (www.osec.io) 和 SlowMist (www.slowmist.com) 在 8 月 3 日至 8 月 11 日期间进行了广泛的代码和服务器审计。Ottersec 专注于服务器端数据取证,而 SlowMist 专注于完整的客户端到服务器管道以及被盗资金的链上跟踪。可以在此处找到其最终调查结果的链接:https://osec.io/reports/slope-investigation-report.pdf 和此处:https://slowmist.medium.com/analysis-of-a-large-scale-attack-on-solana-part-2-ee105d907c12 分别。

两家审计公司都发现,由于日常功能开发中的两个不相关的错误,Slope 移动钱包中的四个安全层中的两个(收集和加密)在客户端总共受到影响 41 天,在服务器端受到影响 7 天。在此期间,5,367 个钱包私钥存储在访问安全的数据库中。其中,只有 1,444 个是被黑客耗尽的钱包。没有证据表明黑客攻击影响的其余 7,785 个钱包曾存储在 Slope 服务器上。

两家审计公司都得出结论,没有证据表明在漏洞存在期间存在对服务器的未经授权的访问,即使对服务器的访问受到威胁,攻击者也不可能通过直接访问日志服务器来获得被盗钱包的完整范围。SlowMist 此外得出结论,没有证据表明导致数据库(传输)的数据传输受到威胁。

因此,审计结果仍然没有定论;没有发现将应用程序监控漏洞与 2022 年 8 月 2 日的攻击联系起来的确凿证据。

1.2.时间线

以下时间线描述了与 Slope 使用 Sentry 应用程序监控有关的一系列事件:

2021/10/11: 客户端: Sentry SDK 在 Slope 钱包版本 1.3 中发布。它将数据日志发送到 Sentry 托管的服务器。这些导出不包括(即客户端过滤掉了)钱包私钥。

2022/12/03: 服务器端: 由于性能要求提高,Sentry 服务器在 Slope 钱包版本 1.4.2 中迁移到 Slope 托管的解决方案。

2022/01/19: 服务器端: Sentry 服务器迁移完成,激活 Sentry 数据日志记录。

2022/05/06: 服务器端: 由于数据管道中的错误(Kafka 中的错误),Sentry 数据库日志记录停止。由于即将进行的计划维护和数据分析管道升级,日志记录没有立即重新启动。

2022/06/24: 客户端: 在 Slope 钱包版本 2.2 中添加了 toString() 方法,该方法无意中绕过了 Sentry 黑名单对敏感参数的过滤。所有日志数据均以密文加密。

2022/07/04: 服务器端: 负载均衡器更新,以提高 TLS 解码性能。

2022/07/18: 客户端: 在 Slope 钱包版本 2.2.1 中删除了密文 Sentry 日志记录。

2022/07/28: 服务器端: 重启 Kafka,从而重启整个 Sentry 数据日志记录管道(即漏洞开始)。

2022/08/03: 服务器端: 关闭 Sentry 服务器(即漏洞结束)。

2. Slope 安全审计结果:

2.1.总体范围

  • Slope 拥有超过 100 万 (1,214,191) 个自 2021 年 10 月以来导入到 Slope 钱包移动应用程序中的不同钱包地址的不完整日志。在 9,229 个被盗钱包中,只有 5,033 个(受影响钱包的 54%)可以追溯到曾经与 Slope 交互过。
  • Sentry 漏洞的范围可以限制为仅移动应用程序 (APP) 用户,并且时间可以限制为 7 天(2022 年 7 月 28 日至 8 月 2 日)的窗口。
  • 下图描述了 Slope 钱包应用程序的容器设置:

图 1:Slope 钱包 Kubernetes 概述

  • 下图说明了 Sentry 数据管道的组件:

图 2:Slope 移动 Sentry 数据管道

2.2.数据库(Postgres 和 Sentry-Service)取证

  • 两家审计公司都完成了对所有数据库日志和 sentry 服务配置的审查。
  • 在 Sentry 数据库中找到了总共 6,811 个唯一钱包(移动设备上 Slope 用户群的 0.4%)的私钥。其中,只有 1,444 个属于受影响的 9,229 个 Solana 钱包(15%)。
  • 数据取证没有发现任何证据表明黑客攻击期间被盗的其余 7,785 个钱包曾存储在 Sentry 数据库中。
  • 没有迹象表明发生过任何日志删除或篡改。所有 Redis 脉冲消息都表明该服务在整个期间都处于运行状态,而 Postgres 和 Clickhouse 日志由于计划中的分析管道更新而暂停。

图 3:Slope Sentry 服务器的 Redis 和 Postgres 日志

图 3:Slope Sentry 服务器的 Redis 和 Postgres 日志

图 4:基于 Sentry(事件)日期遭到入侵的钱包的分布

  • 通过 Sentry 服务器日志记录可能暴露的 5,367 个钱包(79%)的资产在攻击期间没有被耗尽。截至攻击时,这些未受影响的钱包持有价值超过 50,000 USDC 的资产。黑客忽略了这些资产,同时耗尽了 300 多个包含资产在攻击时价值低于 20 USDC 的钱包。

2.3. K8s 容器(Nginx、Sentry-Relay、Kafka)取证

  • SlowMist 完成了对所有 K8s 容器日志的审查。
  • 未检索到其他日志。
  • 没有恶意活动的证据。

2.4. Alicloud (Aliyun) 网络取证

  • Alicloud Container Service for Kubernetes (ACK) 的所有安全系统都是名义上的,未检测到任何异常。

♢ 仅允许 HTTPs 请求

♢ Istio ingress controller 和负载均衡器正常

♢ Kubernetes 虚拟私有网络正常

♢ PodSecurityPolicy 正常

♢ 身份管理正常

♢ 运行时监控和警报正常,没有关于以下方面的警报

✦ 恶意镜像

✦ 病毒和恶意程序

✦ 内部入侵

✦ 容器逃逸

  • 服务器访问受到 3 因素身份验证的保护,所有历史登录记录均被记录,未检测到任何异常。
  • 分析了所有 SSH 远程登录程序,在漏洞存在期间没有异常。
  • 没有中间人攻击的迹象:

♢ TLS 证书绑定已到位。

♢ 已通过解析从 htttps://dns.console.aliyun.com/ 上的 AliCloud 查询的日志,排除了 DNS 劫持(以及其他形式的基于 DNS 的攻击)。

♢ X.509 证书井然有序。

  • 未发现恶意软件的迹象。

2.5.源代码审计

  • Sentry 设置为仅接收错误级别事件。采用了自定义参数过滤器。此过滤器设置为过滤掉所有敏感数据。由于在 Slope 钱包版本 2.2.0 中引入的参数连接命令,该过滤器无法捕获所有敏感数据。
  • 完成了 Slope 内部代码审计。没有检测到任何其他漏洞的迹象。

2.6.内部调查

  • 对所有有权访问应用程序监控服务器的 Slope 员工的硬件设备进行了法证分析,未检测到任何可疑活动。

2.7.正在进行的调查

  • 正在聘请其他代码审计公司对 Slope 钱包源代码进行代码审计。
  • 调查 2022 年 6 月 24 日之前任何异常的 SSH 请求。
  • 对从未在移动设备上使用过 Slope 钱包的潜在受影响用户进行用户访谈。
  • 对受到攻击耗尽的用户进行用户访谈,他们的钱包公钥未出现在 Slope Sentry 条目中。

附录 A:问答:

1. 将 Sentry 切换到自托管服务器的目的是什么?

答:托管的 SaaS Sentry 存在局限性。

一开始,我们购买了 Sentry 的 SaaS 产品。每月可以报告的日志数量有限。随着业务规模的扩大,很快就达到了该限制,无法继续收集错误。报告的日志包括两部分:生产环境的日志和开发环境的日志。考虑到大量的报告日志数据和 Sentry 的 SaaS 产品的高服务成本,我们安排了运营、托管和维护,以便在 AliCloud 上自行部署该服务。

2. 添加 toString() 的目的是什么

答:为了使调试更方便。

toString() 命令用于导出所有局部变量,以便在钱包选择中更方便地进行调试。代码审查没有发现此命令会导出钱包的私钥并绕过现有的安全过滤器。

3. 将密文转换为明文的目的是什么?

答:为了提高端到端加密消息传递的解密性能。

随着钱包到钱包加密消息传递的引入,在应用程序中引入了两层解密。为了方便和防止异常错误,开发人员决定统一处理所有内存中的明文参数。

4. 为什么私钥会记录一段时间?

答:移动终端周围的数据管道传输缓存的数据。

在 2022 年 7 月 28 日之后的每一天,都有少量旧日志。Kafka 本身不会长时间缓存数据(默认 7 天)。在这种情况下,移动终端在服务恢复后开启了几天,然后将错误发送到服务器。

图 5:按 Nodestore 时间戳分发的 Sentry 时间戳

  • 原文链接: slope-finance.medium.com...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
slope-finance
slope-finance
江湖只有他的大名,没有他的介绍。