是时候物联网医疗设备下手了:对心脏起搏器生态系统安全性研究(part1)
2020-08-02 10:30:00 Author: www.4hou.com(查看原文) 阅读量:486 收藏

导语:这是我有关起搏器生态系统安全性研究的系列文章中的第一篇,此研究包括在Marie Moe于2015年在SINTEF发起的一个内部项目。 第一篇文章为下一篇文章奠定了基础,并提供了有关我们将要研究的BIOTRONIK起搏器生态系统的基本说明,以及用于研究的方法。

这是我有关起搏器生态系统安全性研究的系列文章中的第一篇,此研究包括在Marie Moe于2015年在SINTEF发起的一个内部项目。

第一篇文章为下一篇文章奠定了基础,并提供了有关我们将要研究的BIOTRONIK起搏器生态系统的基本说明,以及用于研究的方法。

0x01 漏洞披露

这些研究结果以漏洞报告的形式与BIOTRONIK做了共享。BIOTRONIK根据协调的漏洞披露流程进行了合作,并分析和验证了我们的报告。然后,他们分享了对每个报告的漏洞的响应,我们详细讨论了每个要点。在这些讨论中,BIOTRONIK提供了足够的信息,以确认由漏洞引起的患者伤害的可能性是极小的。

BIOTRONIK建议医疗保健提供者和患者继续按使用说明继续使用设备并遵循设备说明。

CISA漏洞咨询可在此处获得

https://www.us-cert.gov/ics/advisories/icsma-20-170-05

协调披露的时间表:

· 2019年10月:漏洞报告已发送至BIOTRONIK

· 2019年11月:SINTEF与FDA进行了讨论

· 2020年4月:SINTEF收到BIOTRONIK的回复

· 2020年4月/ 5月:BIOTRONIK,BSI,CISA和SINTEF之间进行了讨论

· 2020年6月18日:CISA发布漏洞披露。

0x02 心脏起搏器的生态系统

什么是心脏起搏器?

首先,让我们定义什么是起搏器或ICD。植入式心脏复律除颤器(ICD)是一种植入到患者体内的医疗设备,通常在心律不齐的情况下控制患者的心跳。ICD用于患有严重心律不齐的患者,即那些状况可能导致他们昏厥甚至心脏骤停的患者。该设备监视患者的心律,并在检测到异常时发送电脉冲。

image.png

图1:SINTEF实验室中的起搏器图片

图1中显示了一个ICD。该设备只有信用卡的大小,并具有一根,两根或三根称为引线的电线。正如德州心脏研究所所解释的,植入物内部装有脉冲发生器以及其他电子电路和电池。起搏器与ICD的区别在于,ICD可以发出电击,而起搏器只能通过小的电刺激来校正心脏的节律。患者可以感觉到ICD发出的电击,通常医生会要求他报告一次或多次。从现在开始,我们将仅使用术语“起搏器”来指代“起搏器”和“ ICD”。

每次事件发生时都必须报告然后去看医生,这会使病人很烦恼。这就是起搏器制造商以无线方式连接设备的原因。这样,患者可以在夜间使用外部设备从起搏器收集数据,并将其自动发送到服务器,由专科医生看诊。这样可以在出现问题的情况下更快地通知医生,并防止患者不必要的拜访。

生态系统

如前所述,起搏器不是安装在患者体内并在体内与外界保持任何互动状态的独立设备。它依赖于整个生态系统才能正确有效地工作。该生态系统由多个设备组成。图2显示了我们一直在研究的供应商的生态系统,但这是很通用的。

image.png

图2:供应商的起搏器生态系统图

这是对生态系统不同组成部分的描述:

· 起搏器:植入患者体内,这是生态系统的主要设备。它会产生电脉冲,有助于调节心率。可编程的起搏器使医生可以为每个患者选择合适的起搏器。

· 编程器:编程器是医院的从业人员用来对起搏器进行编程的外部计算机。该设备需要与起搏器接近,通信仍然是无线通信。

· 家庭监控单元:HMU是一种旨在通过防止患者过于频繁地拜访医生来减轻患者生命的设备。确实,该设备放置在患者家中,负责从起搏器下载数据,并将其发送到供应商的服务器,以便从业者远程访问它们。

· 运营商网络:HMU需要一种访问Internet的方式,以便与供应商的服务器进行通信。根据HMU(参见下文)的不同,可以使用移动网络(例如GSM或3G)访问互联网,也可以使用常规电话线访问Internet。

· 供应商的服务器:这些是HMU连接到的服务器,以导出患者的数据。这是通过运营商网络实现的。从业人员可以通过在线平台访问这些服务器。

研究范围

我的项目只关注起搏器生态系统的一个要素,即家庭监控单元。即使不是强制性的,该设备也很安全,因为它可以与起搏器和供应商的服务器直接交互。它还处理患者的数据。最重要的是,以前的研究人员已经表明,通过使用某些HMU消耗起搏器的电池,可以将它们转变成“武器”,并威胁到患者的生命。图3突出显示了我研究成果中使用的范围:

1. HMU与供应商服务器之间的接口。

2. HMU本身是独立的嵌入式设备。

3. HMU和起搏器之间的接口。

image.png

图3:HMU的范围

我最终将重点放在范围2上,在范围1上有一些重叠。主要是因为在实验室中没有可用的起搏器,所以将范围3留在了一边。来自NTNU的另一位学生Anniken Wium Lie专注于范围1,特别是移动网络接口。尽管我们的范围是不同的,但是在我们的项目之间进行了许多合作。的确,我对HMU硬件以及Anniken所建立的Fake Base Station的发现使我们能够与该设备进行更多的交互并更好地理解它。

0x03 黑盒测试方法

为了进行研究,我一直在使用“黑盒测试方法”。我不会过多介绍该方法的细节,但基本上,这是一种从外部评估软件,设备或系统的方法,对内部的了解很少。攻击者正在分析通过发送一些输入或仅通过被动侦听获得的黑盒的输出,然后试图推断出目标的内部系统。做出一些猜测之后,攻击者可以调整其输入以确认其想法或利用目标(请参见图4)。

image.png

图4:黑盒测试方法图

与可用于评估系统的其他方法相比,该方法具有多个优点。确实,这里的目标是在真实条件下进行测试,以适应实际情况。这意味着这样的测试将包括在系统部署过程中可能发生的实际错误,例如默认密码,总体上的错误配置,甚至是缺乏对员工的培训(例如,弱密码)。它还具有较低的误报率,因为攻击者可以评估与漏洞相关的风险,即,给定的漏洞是否真正可利用。另一方面,白盒测试中,攻击者可以完全访问源代码和实现细节,可能会导致不相关的漏洞(至少没有达到Black Box Security测试的目标),因为这些漏洞永远不会在实际场景中触发。但是,黑盒测试方法也有一些缺点。根据定义,攻击者几乎没有有关目标的信息,并且可能会错过一些可能由代码和/或配置检查发现的漏洞。显然,黑盒测试不应该是唯一执行的安全性测试,即使它是在真实条件下评估设备的绝佳方法。

我的项目集中在一个专有的生态系统上,除了供应商为患者提供的信息外,我几乎没有任何信息,这实际上是模糊且非技术性的。此外,我的目标是在现实情况下评估与该生态系统相关的安全风险。然后,黑盒测试方法论很好地适应了我的限制和目标,这就是为什么我决定使用它的原因。

0x04 寻找调试接口

对家庭监控单元的硬件测试

当我刚开始从事该项目时,我对硬件安全性和总体硬件知之甚少。但是,致力于这个主题是一个挑战,在此过程中我学到了很多东西。目标是德国公司BIOTRONIK制造的Cardio Messenger IIS家庭监视单元。我没有比较好的方法,但是寻找调试端口似乎是必经之路。因此,下面将重点介绍如何定位调试端口以及从HMU中提取固件。

组件识别

首先,我打开设备以查看硬件类型。此阶段的目标是确定板上的主要组件,并利用它们之间的相互作用构建一个简单的原理图。图1显示了电话线版本的CardioMessenger II-S。与GSM版本非常相似,仅调制解调器有所更改。这就是为什么,此帖子将主要使用T-Line的图片,因为它是我执行初始测试的设备。但是,所有发现也随后在GSM版本上得到了验证。

cmiis_tline_inside_annotated.JPG

图5:CardioMessenger II-S T线内部

我首先从网上查找PCB上不同部分的数据表。有趣的是,PCB可以分为三个不同的部分:

1. 主PCB

2. 左上角的“微控制器PCB”

3. 调制解调器(已插入主PCB,可以在T-LINE版本上卸下)

在微控制器PCB上,有:

· 微控制器,Atmel的AT91RM9200(现为微芯片)

· 4Mb 闪存

· 外部RAM

查看PCB上剩余的内容,有数字信号处理器(图1的左下角)和调制解调器,我们可以绘制图2所示的非常简单的示意图。

图2:HMU原理图

图6:HMU原理图

有了这个原理图,很清楚我们可以在哪里进行测试。在这个项目中,我主要在调试端口(UART / JTAG)以及MCU与Modem之间的通信上进行了测试。但是,如果有适当的设备,也可以尝试直接进行交互。

在开始CardioMessenger II-S的工作之前,我分析了其他已知存在漏洞的医疗设备,例如St Jude Medical的Merlin @ Home或Medtronic的旧HMU。Merlin @ Home是一个嵌入式Linux系统,访问非常简单:通过UART(标记为UART)连接到设备后,系统会提示你登录。但是,如果中断引导,则会出现一个终端在Blob Bootloader中,带有一些可用命令。带有适当boot init=/bin/sh参数的命令会给你一个shell作为root用户。

然后,我想知道我是否会遇到与CardioMessenger II-S类似的问题,但是在查看组件时,即使它可行,我也很难相信它可能是在HMU上运行的嵌入式Linux系统。 因此假设它是一些基于著名的实时OS(例如Free RTOS)构建的自定义OS。

因此,下一步是在板子上寻找调试端口。我们从MCU的数据表中了解到JTAG / SWD和UART是可用的。仔细观察微控制器周围的PCB部分,我们可以确定几个兴趣点,它们在图3中以红色显示。

图3:板上可能的调试端口

图7:板上可能的调试端口

寻找UART

UART

引脚未在设备上标记,因此我要弄清楚与UART相对应的步骤是:

1. 使用万用表和已知的接地参考来确定接地引脚(如果没有更好的设备,则设备的金属部件可以解决问题)。在这里可以使用连续性测试功能。

2. 为了防止将计算机连接到随机的几个引脚上并使计算机正常工作,我随后使用示波器监视了启动过程中不同引脚上的情况。可以在TX上检测到活动。

3. 最后,我们需要使用的波特率。一种解决方案可能是简单地连接计算机并尝试使用其他计算机,直到获得有意义的东西为止。但是,更好的方法是使用示波器(或逻辑分析仪)确定位周期,然后取其倒数来获得波特率。

回到HMU,图3中以青色突出显示的引脚下面的3个引脚与UART相对应。当查看启动期间TX引脚上发送的内容时,我得到以下输出:

Bootloader TELEX4:

但仅此而已。我尝试在线查找此字符串,但没有得到任何相关信息,我确实找到了UART,但似乎也没有调试信息发送给它。

然后,我尝试查看是否可以与之交互,并发送了诸如“ ENTER ”,“ CTRL + C ”,“ ESC ”等键,但没有任何交互,也没有回显任何文本。

微控制器与调制解调器之间的通信

从图2所示的原理图中可以看出,UART不仅用于输出调试信息,而且还用于在两个组件之间进行通信。这里,调制解调器和微控制器使用UART进行通信。在网上寻找调制解调器的数据表时,我们很容易找到调制解调器的UART引脚。我们暂时不想在这里发送任何东西,只是窃听通信。为此,我们可以将调制解调器的TX引脚(对应于doc的“输入”,对应于doc的“输入”)连接到USB-to-TLL的RX引脚,以实现从微控制器到调制解调器的通信。我们可以通过连接到另一个USB到TTL的RX引脚的RX进行相同的操作,以实现从调制解调器到微控制器的通信。从那里我们可以观察到发生了有趣的数据通信:

[2019-03-30 11:43:24] at
atii5#vversion 
AT#MCOUNTRY?
at
AT+WOPEN=1
AT#DIALSELECT=1
AT#AUTHENT=PAP
at#atcmd=0,"-STE=7"
at#atcmd=1,"+A8E=6,5,0,1,0,0"
at#atcmd=2,"X3"
at
AT#DIALN1="T9W[REDACTED]"
AT#ISPUN="[REDACTED]@cm3-homemonitoring.de"
AT#ISPPW="[REDACTED]"
at#atcmd=0,"-STE=7"
[2019-03-30 11:43:26] AT#CONNECTIONSTART
[2019-03-30 11:43:28] at#connectionstop

可以看出,微控制器正在使用AT命令配置调制解调器。通过查看“ 具有IP连接的GSM / GPRS无线调制解调器的AT命令”,我们了解到微控制器命令调制解调器连接到接入点名称(APN),该名称是移动网络与另一个网络(通常是Internet)之间的网关。

https://www.embeddedarm.com/documentation/third-party/ts-modem2_developerguide-gsm-gprs-ip-commands-s000333b.pdf

首先,它使用WOPEN命令启动TCP / IP堆栈,然后选择与DIALSELECT命令一起使用的主拨号号码。然后将身份验证方法设置为密码身份验证协议(PAP)。最后,设置拨号号码,以及连接到APN所需的用户名和密码(ISPUN和ISPPW命令)。用户名和密码以明文形式发送。另外,我们注意到用户名与设备的序列号相对应,该序列号印在设备下方的标签上。在本系列的最后一篇文章中,我将回到这些凭据上,以及它们在完整攻击场景中扮演的角色。

寻找JTAG

攻击物联网设备的另一种常见方法是使用JTAG接口。在CardioMessenger II-S的情况下,JTAG引脚也没有标记,并且有几种候选:图2中用青色表示的14个引脚。但是,JTAG仅需要5个引脚。我没有合适的设备来同时探测所有14个引脚,并且感谢NTNU电子部门的工程师(再次感谢Ingulf,如果你读过这篇文章的话),我们能够在这些引脚上添加合适的连接器。图4显示了已添加的连接器以及在板上进行的焊接。

图4:添加到板上的连接器的详细信息

图8:添加到板上的连接器的详细信息

JTAG引脚的识别

为了确定JTAG接口的引脚排列,我们使用了一种称为“ JTAGulator ” 的特殊硬件工具。正如JTAGulator的发行商Grand Idea Studio所解释的那样,它是一种“ 开源硬件工具,可帮助从测试点识别OCD连接,或在目标设备上元件。”基本上,它可以通过尝试所有可能的排列猜JTAG接口的引脚分配。该JTAGulator是一种价格合适的商用设备,在图5呈现。

http://www.grandideastudio.com/jtagulator/

图5:Grand Idea Studio的JTAGulator

图9:Grand Idea Studio的JTAGulator

该设备易于使用。首先,我们需要将开发板上有趣的引脚连接到JTAGulator(如图6所示)。然后,JTAGulator通过USB连接到计算机,并且可以通过screen例如USB与计算机进行交互。波特率是115200 Bd / s。

图6:连接到设备的JTAGulator

图10:连接到设备的JTAGulator

连接设备后,步骤如下:

1. 调整JTAGulator的电压(对于CardioMessenger II-S,为3.3V)

2. 启动IDCODE扫描以确定TDO,TMS,TCK,TRST

JTAG> i
Enter starting channel [0]:
Enter ending channel [0]: 12
Possible permutations: 1716
Bring channels LOW between each permutation? [y/N]: y
Enter length of time for channels to remain LOW (in ms, 1 - 1000) [100]:
Enter length of time after channels return HIGH before proceeding (in ms, 1 - 1000) [100]:
Press spacebar to begin (any other key to abort)... 
JTAGulating! Press any key to abort...
-------------------------------------------
TDI: N/A
TDO: 11
TCK: 4
TMS: 12
Device ID #1: 0000 0101101100000010 00000011111 1 (0x05B0203F)
TRST #: 3
TRST #: 10
-------------------------------------------
IDCODE scan complete.

1. 启动BYPASS扫描以获取TDI

JTAG> b
Enter starting channel [0]:
Enter ending channel [12]:
Are any pins already known? [Y/n]: y
Enter X for any unknown pin. Enter TDI pin [0]: x
Enter TDO pin [11]:
Enter TCK pin [4]:
Enter TMS pin [12]:
Possible permutations: 10
Bring channels LOW between each permutation? [Y/n]: y
Enter length of time for channels to remain LOW (in ms, 1 - 1000) [100]:
Enter length of time after channels return HIGH before proceeding (in ms, 1 - 1000) [100]:
Press spacebar to begin (any other key to abort)...
JTAGulating! Press any key to abort...
----
TDI: 5
TDO: 11
TCK: 4
TMS: 12
TRST #:
TRST #:
Number of devices detected: 1 
------
BYPASS scan complete.

1. 读取设备ID以确认引脚排列

JTAG> d
TDI not needed to retrieve Device ID.
Enter TDO pin [11]:
Enter TCK pin [4]:
Enter TMS pin [12]:
Device ID #1: 0000 0101101100000010 00000011111 1 (0 x05B0203F)
-> Manufacturer ID: 0x01F -> Part Number: 0x5B02
-> Version: 0x0
IDCODE listing complete.

然后,JTAG引脚为:

图7:CardioMessenger II-S上的JTAG引脚

图11:CardioMessenger II-S上的JTAG引脚

0x05 固件提取

现在有了JTAG引脚,我们可以连接JTAG适配器并开始与微控制器进行交互,以获取我们真正寻找的东西:固件。就我而言,我使用了如图8所示的Raspberry Pi Zero。我的目标是仅使用COTS设备和开源软件,以尽可能降低成本。

与OpenOCD建立连接

如Dominic Rath在其博士论文中所述,OpenOCD(开放式芯片调试器)旨在为嵌入式目标设备提供调试,系统内编程和边界扫描测试。与一个为用户提供所需电信号的小型适配器一起使用,我们可以执行片上调试或编程,而无需外部且通常很昂贵的编程器。如上所述,它可以与Raspberry Pi Zero搭配使用,价格约为10美元。Raspberry Pi Zero的另一个廉价替代品是Shikra由Xipiter开发。使用OpenOCD的缺点是它可能不稳定或存在错误。此外,第一次使用时不一定要直接了解。尽管如此,一旦解决了配置问题,它就会成为非常强大的工具。我非常喜欢为OpenOCD编写配置的功能,几乎可以像“脚本”一样使用它。

图8:使用Raspberry Pi Zero作为JTAG适配器

图12:使用Raspberry Pi Zero作为JTAG适配器

连接到设备后,我们可以简单地SSH到RasperryPi并测试连接。首先,我们需要启动OpenOCD,执行sudo openocd -f your_config.cfg,然后nc 127.0.0.1 4444连接,然后scan_chain命令来检测存在哪些设备。

图9:通过JTAG与HMU交互

图13:通过JTAG与HMU交互

固件转储

OpenOCD为我们提供了一条dump_image读取内存的命令。通过使用图10中所示的微控制器的内存映射,可以轻松转储特定的内存块。感兴趣的部分包括引导加载程序,闪存和外部闪存的内容。相应的地址和大小可以从数据表的存储器映射中检索到(参见图10)。

图10:AT91RM9200内存图

图14:AT91RM9200内存图

为了转储我感兴趣的内存部分,我使用了以下OpenOCD配置文件:

# INTERFACE
interface bcm2835gpio 
bcm2835gpio_peripheral_base 0x20000000 
bcm2835gpio_speed_coeffs 113714 28 
bcm2835gpio_jtag_nums 11 25 10 9 
bcm2835gpio_srst_num 24
reset_config srst_only srst_push_pull 
adapter_khz 500

# TRANSPORT
transport select jtag

# TARGET
set WORKAREASIZE 0
set CHIPNAME at91rm9200
source [find target/at91rm9200.cfg]
reset_config srst_only srst_nogate 
adapter_nsrst_delay 100 
adapter_nsrst_assert_width 100

# EXEC 
init 
targets 
halt

echo "Dumping bootloader..."
dump_image bootloader.img 0x00000000 1048576
echo "Done!"

echo "Dumping SRAM..."
dump_image sram.img 0x00200000 104576
echo "Done!"

echo "Dumping Flash content..." 
dump_image flash.img 0x10000000 4194304
echo "Done!"

echo "Dumping RAM..."
dump_image sdram.img 0x20000000 2097152
echo "Done!"

连接到设备后,我们可以启动“脚本”,大约5分钟后,我们获得了四个内存转储!

0x06 分析总结

这部分分析中,我们将设备拆开,弄清楚主要组件是什么以及它们的功能是什么。然后,我们使用该信息来确定调试端口。最后,我们使用JTAG访问转储了设备的内存,并获得了HMU的固件。在下一篇文章中,我们将看到如何利用设备与后端服务器之间缺乏相互身份验证来提取数据。在第三篇文章中,我们将看到如何使用获得的固件对HMU与后端服务器进行通信的专有协议进行逆向。

本文翻译自:https://guillaumebour.fr/articles/security_testing_pacemaker_ecosystem/part_1_introduction_context_methodology/ https://guillaumebour.fr/articles/security_testing_pacemaker_ecosystem/part_2_hardware-_testing_home_monitoring_unit/如若转载,请注明原文地址


文章来源: https://www.4hou.com/posts/RwrO
如有侵权请联系:admin#unsafe.sh