对nRF52840片上系统的硬件调试与漏洞研究(part2) - 嘶吼 RoarTalk – 网络安全行业综合服务平台,4hou.com

对nRF52840片上系统的硬件调试与漏洞研究(part2)

h1apwn 技术 2020-07-23 10:20:00
561317
收藏

导语:在**第1部分描述了APPROTECT攻击之后**,这篇文章会介绍如下内容: - 利用基于nRF52840的真实产品提取固件并重新激活SWD。 - 重现对其他nRF52 SoC的攻击,以确认所有nRF52版本中的漏洞。

第1部分描述了APPROTECT攻击之后,这篇文章会介绍如下内容:

· 利用基于nRF52840的真实产品提取固件并重新激活SWD。

· 重现对其他nRF52 SoC的攻击,以确认所有nRF52版本中的漏洞。

0x01 对真实产品进行利用验证

让我们从一个经典的场景开始,在这个场景中,黑客需要访问产品的固件。如果此产品基于nRF52,则可能受到保护以避免固件读出,以防止进行逆向。

目标:Logitech G Pro

为了进行漏洞利用验证,我选择了手头的第一台设备。这是我基于nRF52840的Logitech G Pro鼠标。

注意:我的目标不是在此处攻击Logitech产品。

0x02 获得访问权限

我跳过了拆卸部分,拆卸设备可访问主板:

1.png

Logitech PRO G的前PCB,看一下HERO传感器。

SWD引脚(SWDCLK,SWDIO)经过丝网印刷,因此易于识别(红色框)。然后,焊接一些引脚接头,以将目标连接到Segger J-Link调试探针:

2.png

目标和JTAG探针之间的SWDCLK,SWDIO,VDD_NRF和GND跳线。由于未连接电池,USB电缆也已插入。

拒绝通过OpenOcd和GDB进行连接的任何尝试:

 $ openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -c "transport select swd" -f /usr/local/share/openocd/scripts/target/nrf52.cfg
 $ arm-none-eabi-gdb

3.png

启用了APPROTECT,并且与SWD的连接被拒绝。

此设备上启用了APPROTECT功能。

0x03 APPROTECT  Bypass 复现

设备准备

nRF52840位于PCB背面,并充当系统的主处理器。

PCB设计与nRF52840参考设计(在北欧数据表中找到)完全匹配,就像复制粘贴设计一样。

去耦电容器C5和C15被移除,毛刺输出连接到VDD_CPU(DEC1):

4.png

C5和C15被卸下(黑框),VDD_CPU_DEC1(红线)和GND(黑线)。

VDD_CPU(DEC1)通过SMA连接器连接到毛刺器,这是完整攻击设置的视图:

6.png

Logitech PRO G的快速设置

故障攻击

通过运行python脚本来启动故障攻击,该脚本负责在每次故障尝试后同步故障系统,示波器并重置设备。

此屏幕截图显示了正常的启动(设备的经典行为):

7.png



正常行为(无毛刺效应)。CH1 = UART,CH2 = VDD_nRF(示波器触发),CH3 = CPU电流消耗,CH4 = VDD_CPU。

然后,在成功的故障注入之后,这是想要获得的结果:

8.png

成功的攻击。CH1 = UART,CH2 = VDD_nRF(示波器触发),CH3 = CPU电流消耗,CH4 = VDD_CPU。

板上的VDD_nRF信号用作示波器触发参考。经过特定的延迟后,注入的故障正在破坏nRF52840的正常初始化。

从shell程序的角度来看,外部调试器现在可以连接到鼠标:

9.png

调试器连接到nRF52840

0x04 固件提取

连接后,下一步是转储固件和UICR:

 #openocd via telnet
 dump_image FLASH.bin 0x0 0x100000
 dump_image UICR.bin 0x10001000 0x1000
 #optional
 dump_image FICR.bin 0x10001000 0x1000

这是闪存中0xE5CD8处的引导加载程序版本和设备名称:

10.png

引导程序版本

然后可以执行静态代码分析,以发现漏洞(或只是为了了解漏洞的工作方式)。

11.png

调试激活

为了持久地重新激活调试接口,禁用了APPROTECT (请参阅第1部分),并使用提取的FLASH.bin和UICR.bin(当然将APPROTECT修补为0xFFFFFFFF)重新刷新了:

12.png

Logitech PRO-G鼠标返回开发模式…

鼠标又回到了“开发模式”,其中动态代码分析具有巨大的优势(尤其是在漏洞利用程序开发期间)。

0x05 权限获取

到目前为止,所有结果均已在nRF52840上获得。

nRF52 SoC共享Cortex-M4 CPU,相同的调试端口,相同的闪存(内存阵列除外)和相同的NVMC。在这种情况下,该漏洞可能是整个nRF52系列SoC系列所共有的。这是我对nRF52生态系统的看法:

13.png

查看现有的nRF52平台

经过这次简短的回顾之后,我决定专注于nRF52832和nRF52833,Nordic为这两个平台提供了开发工具包。

0x06 在nRF58232上的结果

在基于nRF52832的  nRF52-DK 上完成了测试。通过移除电容器和焊线来修改开发板:

14.png

nRF52832参考原理图

15.jpg


nRF52832细导线焊接至DEC1,红色导线焊接至DEC4。

注意:仅连接到DEC1的细线就足以实现攻击。

示波器用于识别有趣的图案。

我对监控DEC1线路上的功耗进行了一些改进,信号噪声比更高。

根据下面显示的功耗,Flash Controller初始化期间的行为是相同的:

15.png

启动过程中的CPU功耗分析。CH1 = UART TX,CH2 = DEC1功耗,CH3 =毛刺命令。

这是成功故障注入的一个示例:

16.png

成功故障注入。CH1 = UART TX,CH2 = DEC1功耗,CH3 =毛刺命令。

SWD调试已重新激活:

17.png

调试器已连接到nRF52832目标。

这些结果表明nRF52832容易受到APPROTECT攻击。

0x07 在nRF58233上的结果

再次,基于  nRF52833在nRF52833-DK上实现了类似的测试  。

原理图和PCB视图供参考:

18.png

nRF52833原理图

19.png

nRF52833细导线焊接至DEC1,红色导线焊接至DEC4。

在nRF52833上,闪存控制器的初始化与之前分析过的nRF52等效,在CPU电源线DEC1上执行故障注入:

111.png同样在这里,SWD被重新激活:

21.png

调试器连接到nRF52833目标。

nRF52833容易受到APPROTECT攻击。

经过这些测试,发现所有nRF52版本都容易受到攻击。

0x08 漏洞影响

CVSS分数是7.6(严重性=高)CVSS:3.0 / AV:P / AC:L / PR:N / UI:N / S:C / C:H / I:H / A:H。

以下nRF52版本容易受到攻击:

· nRF52810

· nRF52811

· nRF52820

· nRF52832

· nRF52833

· nRF52840

因此,基于nRF52的模块也容易受到攻击。

这些模块可以利用Nordic SoC硬件和软件架构的所有功能来制作“单个模块产品”,而无需额外的微控制器来运行您的应用程序。

Nordic 在此处提供了第三方模块的参考,例如:

· Fanstel Corp.

· Laird

· Minew

· Raytac

· Taio Yuden

· U-blox

· Wurth Elektronik

· Murata

· Dynastream

· Fujitsu

· …. and more

微信截图_20200708152826.png

0x09 研究总结

所述APPROTECT绕过漏洞已被证明在商业设备-罗技G鼠标上存在。

在nRF52832和nRF52833上还完成了其他测试。结果表明,这些平台也容易受到攻击,NordicSemiconductor确认其所有nRF52版本均容易受到攻击。

从基于nRF52的产品到第三方模块(使用nRF52平台),这现在正在影响现场的大量设备。

该漏洞位于Silicon中,不进行硬件更新,就无法修补。

本文翻译自:https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass-part-2/如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论

 
本站4hou.com,所使用的字体和图片文字等素材部分来源于原作者或互联网共享平台。如使用任何字体和图片文字有侵犯其版权所有方的,嘶吼将配合联系原作者核实,并做出删除处理。
©2022 北京嘶吼文化传媒有限公司 京ICP备16063439号-1 本站由 提供云计算服务