我们的安全研究人员专家团队Kraken Security Labs发现了Safepal S1硬件钱包中的漏洞。尽管我们无法从钱包中窃取加密货币，但我们展示了某些弱点，这些弱点可能使将来的妥协成为可能。 在Kraken，我们试图在攻击发生之前就发现它们。发现后，我们于2020年11月18日向Safepal团队披露了这些漏洞的全部详细信息。 改善我们大家都喜欢的技术的安全性是发展数字资产行业的重要过程，并认为意识和教育是该使命的重要组成部分。 篡改检测无效 我们的测试发现，Safepal的篡改检测充其量是无效的。根据Safepal文档：“在S1内部嵌入了自毁和数据擦除机制。一旦多个传感器检测到任何软件或物理攻击，钱包将启动自防御机制，自毁机制将擦除私钥和所有钱包数据，从而使黑客无法获取敏感数据，从而避免资产错误的手。”我们发现拆开该设备后，它将停止引导，但可以通过重新连接单个引脚来重新启用该设备，并且该设备的内容不会被擦除。进一步的测试和与Safepal的通信表明，只有在以下情况下，钱包才会擦除数据：（a）开启设备电源；（b）断开前面提到的单个引脚的时间超过10秒。在盗窃中，有动机的攻击者不太可能触发此警报。违反开源许可 钱包包含GPLv2许可的U-Boot和Linux内核。这些GPL许可组件的使用要求Safepal分发其产品的源代码，以便用户可以检查和修改在用户设备上运行的代码。我们向Safepal请求了源代码，但他们拒绝提供，这意味着Safepal违反了GPL许可。此类违法行为已引起诉讼，我们敦促Safepal公开其源代码。 Safepal表示他们打算在2021年发布源代码。降级攻击 我们使用了闪存编程器来闪回以前的固件，但该固件未被设备检测到。防止攻击者将固件降级到较早版本对于确保安全性至关重要，因为它可以防止降级到例如固件的易受攻击版本。 Safepal表示，他们打算在2021年初通过固件更新来解决此问题。进一步的研究 此外，我们确定对U-Boot的高度修改版本进行了加密和模糊处理，该版本通常仅支持通过“ FIT映像”或SoC专有的安全启动过程进行安全启动。我们介绍了有关U-Boot的一些发现，但是由于混淆，我们限制了审查时间。根据我们的经验，与安全元素进行通信的应用处理器始终是加密货币硬件钱包中的薄弱环节，而SafePal S1也不例外。 Safepal似乎在其产品中开发或重复使用了重要的混淆技术，这有效地减缓了我们的研究速度，但是由于这种混淆以及GPL源代码缺乏透明度，因此尚不清楚，如果SafePal S1是否确实具有经过验证的安全启动链。技术细节 SafePal S1是一种加密货币硬件钱包，可运行嵌入式Linux和片上系统（SoC）。结果，此钱包的架构与最受欢迎的基于微控制器的钱包（例如Trezor和Ledger钱包）不同。保护任何基于Linux的嵌入式系统的挑战在于，如何保护启动过程的安全，因为大多数（但不是全部）具有Linux功能的微处理器需要外部闪存和外部RAM。此外，尽管Linux可能是使用最广泛的操作系统之一，但它并不是以安全状态发布的，这要求Safepal购买解决方案或自行进行加固。高级硬件分析 SafePal的硬件与Ledger Nano S / X或Trezor One / T等其他普通钱包有显着差异：两者均基于微控制器，但是SafePal基于运行Linux的完整系统级芯片。我们测试了S1P_Ver03硬件版本。 设备的主处理器标记为“ SafePal S1”，但是底层处理器很可能是Allwinner处理器。这是通过将Safepal S1的引脚排列（引脚排列）与Allwinner i3处理器（ https://dn.odroid.com/obsolete/Allwinner_i3_Datasheet_V1.0.pdf ）相匹配来确定的。最值得注意的是，该处理器没有任何集成闪存，而是由一个外部闪存芯片Zbit Semiconductor ZB25VQ64引导。此外，板上还有第二个SOIC-8芯片，该芯片被认为是安全元件。不幸的是，我们无法从芯片标记中找到供应商。 SafePal的处理器：SafePal S1 IDC80X1E – Allwinner芯片。 发现1：篡改检测旁路 根据Safepal文档：“在S1内部嵌入了自毁和数据擦除机制。一旦多个传感器检测到任何软件或物理攻击，钱包将启动自防御机制，自毁机制将擦除私钥和所有钱包数据，从而使黑客无法获取敏感数据，从而避免资产被盗错误的手。” 篡改检测系统分多个步骤进行了分析： - 开箱 首先，测试了使用破坏性和非破坏性方法打开SafePal钱包是否会造成篡改事件。打开S1的外壳并不会导致篡改事件或停止S1的工作。 - 去除射频屏蔽 SafePal处理器，闪存，安全元件和PMIC被RF罐屏蔽。使用围绕罐的多个夹子将RF罐固定在适当位置，并且不能完全焊接下来。使用小号平头螺丝刀可以非常轻松地进行无损清除。移除RF可能导致设备无法成功启动。通过执行测量，确定右上方的RF罐夹没有像其他夹一样接地。通过将夹子重新接地，使用.4毫米的电线将夹子连接到其旁边的裸露接地垫，可以将篡改事件静音，并且SafePal钱包可以再次工作。值得注意的是，没有重置设备，旧的凭证（PIN等）仍然有效。 找不到其他篡改检测措施。 带射频屏蔽的SafePal 移除射频屏蔽的SafePal。负责RF屏蔽去除检测的触点，通过一根细线桥接到地面。 旁路射频屏蔽检测的特写灌装 闪存芯片和安全元件均使用未知化合物封装。但是，用热风枪加热会使灌封料变脆。然后可以使用小型平头螺丝刀将混合物刮掉，而不会损坏设备的任何组件。这样可以直接访问SPI引脚以进行进一步的探测。 移除了射频屏蔽的SafePal，刮掉了闪存芯片上的封装。闪存转储 通过读取标记确定闪存芯片的类型后，尝试使用flashrom在系统中转储闪存。由于在撰写本文时，Flashrom不支持该芯片，因此必须在Flashrom中实现自定义支持。这样可以收集完整的闪存转储。 在进一步分析过程中，已确定使用闪存芯片的OTP安全功能将闪存的前0x8000左右字节设置为只读，而闪存芯片的其余字节均为可读可写。 Flash内容分析 从闪存的第5个字节开始，可以找到字符串“ eGON.BT0”。进一步的研究表明，这是基于Allwinner的设备上的早期Bootloader的通用标头： https ：//linux-sunxi.org/EGON 在SafePal固件中找到eGON.BT0字符串 调查结果2：违反GPL 从地址0x40000开始，找到了一个包含Linux内核的Android引导映像，表明该设备运行Linux。鉴于未发出或未发现GPL通知，则表明存在GPL违规行为。直接向SafePal的进一步请求没有产生任何结果。 在地址0x2A0000处，找到了一个SquashFS文件系统，并将其提取出来便显示出完整的Linux根文件系统，包括多个GPL许可工具。 在地址0x740000，标识了JFFS2文件系统，其中包含配置数据，包括sqlite3数据库内的事务地址。 此外，找到了JPEG引导徽标图像和关闭徽标JPEG图像。 Flash修改尝试 多次尝试修改闪存芯片的内容： - 确定Linux内核，SquashFS文件系统和引导徽标是可修改的。但是，修改导致设备拒绝启动。 - JFFS2文件系统和关闭徽标的内容是可以修改的，而不会导致设备无法启动，但是对关闭徽标的更改不会反映在实际关闭中。 - 由于闪存芯片中设置了上述安全位，因此无法修改第一阶段的引导加载程序。 Flash返工 通过更换主闪存芯片，有可能在设备上获得代码执行。由于内容保持相同，因此设备无法检测到。为了获得代码执行力，必须对多个检查进行反向工程和去混淆。在可能的情况下，这特别耗时，特别是考虑到U-Boot混淆链的复杂性，因此，没有将其作为此次审核的一部分。固件升级 wallet_update二进制文件中包含的固件升级过程已经过分析和反向工程。输入序列号后，可以从SafePal网站下载固件升级，但是确定对于相同的硬件修订版，固件更新是相同的，因此不会进行个性化升级。收到的所有设备的固件版本为v.1.0.17，这是当时的最新版本。固件升级可以在https://www.safepal.io/fw/S1F/v1.0.17/upgrade.bin中找到 还发现固件升级已加密，对固件二进制文件的修改导致升级过程失败。 在分析wallet_update二进制文件的过程中，发现使用许多XOR版本的数据对二进制文件进行了混淆。通过二进制修补wallet_update，可以在qemu-user模式下运行它，从而可以在常规系统上解密固件升级。 还发现，在成功解密之后，固件升级会执行对固件的ECDSA签名检查。该实现看起来与trezor-crypto非常相似，但是找不到确认（由trezor-crypto的许可证要求），因此无法完全验证。发现3：降级攻击 防止攻击者将固件降级到较早版本对于确保安全性至关重要，因为它可以防止降级到例如固件的易受攻击版本。 在此审核过程中，发布了SafePal固件v1.0.18。钱包已升级到该固件，已启动并经过测试。在确认固件升级成功之后，使用了闪存编程器来闪回以前的v1.0.17固件。此次降级使设备完全正常运行，固件未检测到降级，并且钱包保持正常运行，这表明容易遭受降级攻击。启动过程第一阶段引导程序 大多数Allwinner设备将U-Boot用作第二阶段引导加载程序，但是在闪存系统上找不到U-Boot。而是在闪存中找到了对“ XBOOT”和“ XTAB”的引用，尽管这与任何已知的引导加载程序（例如https://github.com/xboot/xboot）都不匹配。 鉴于该设备运行Linux，并且引导配置需要在某个地方进行，因此第一阶段的引导加载程序是使用Ghidra进行反向工程的。发现该第一级引导加载程序使用大量混淆处理来混淆字符串和密钥材料，最终发现第一级引导加载程序解密了第二级引导加载程序。为了了解此第二阶段自举程序的解密和验证，使用Unicorn Engine仿真器模拟了整个自举程序，从而可以对第二阶段自举程序进行完全解密。还发现第一阶段的引导程序可验证第二阶段的引导程序的ECDSA签名。 模拟第一阶段的引导程序，包括检查固件检查，允许测试修改后的固件以确定它是否可以通过检查第二状态自举程序 快速分析第二阶段的引导程序后，立即发现它是经过修改的U-Boot引导程序。鉴于U-Boot是根据GNU公共许可证获得许可的，并且找不到GPL通知或源代码，因此，这构成了违反GPL的行为。 发现U-Boot已通过某些混淆和解密方法进行了修改。应用分析 从提取的squashfs文件系统中恢复了两个二进制文件“ wallet”和“ wallet_update” 。钱包是主要的钱包应用程序，而wallet_update实现固件升级过程。 在钱包二进制文件的固件升级检查中发现了使用时间检查（TOCTTOU）问题。但是，wallet_update功能将执行无法绕过的第二项检查。同样，对每个引导执行第三次检查，即使绕过软件锁也失败。配置和数据库分析 在JFFS2文件系统上有两个配置文件：wallet.cfg和wallet.db。 Wallet.cfg包含配置项，例如是否已经设置了钱包以及钱包名称。发现可以自由更改此配置，从而使攻击者可以自由更改钱包名称之类的配置项。 wallet.db是基于sqlite3的数据库，其中包含有关交易，已配置硬币和钱包上地址的信息。修改数据库会导致电子钱包应用程序无法正常运行（SafePal将仅显示黑屏）。目前尚不清楚这是由于SQLite不兼容（从2012年开始在钱包中使用的版本是3.7.11）还是由于其他未知保护。数据库分析 由于数据库包含私人信息（地址和交易），因此尝试从设备中恢复地址。通过分析钱包二进制文件，发现使用AES对数据库中存储的地址进行了加密，密钥是从各种静态源以及假定为安全元素的输入派生的。 某些修改还会导致设备要求用户重新设置钱包，但是会使用未修改的闪存映像重新刷新设备，以恢复完整的钱包操作。这可能表明篡改检测和响应方法效率低下。 分享这个： - 推特 - Facebook - 像这样：喜欢加载...