Статья Взлом медицинского оборудования: от fingerprinting до lateral movement через DICOM

Из 200 000 инфузионных насосов, проанализированных командой Unit 42 (Palo Alto Networks), 75% содержали хотя бы одну известную уязвимость - и 52% были подвержены двум CVE с рейтингом CVSS 9.8 (Critical), раскрытым ещё в 2019 году. Шесть лет назад. На стенде картина подтверждается один в один: четыре модели помп, которые я разбирал за последние пару лет, показали одно и то же - открытый текст в канале связи, дефолтные пароли на веб-интерфейсе, прошивки без обновлений. Инфузионные насосы - это примерно 38% всех IoT-устройств в типичной больнице, и с остальным медицинским оборудованием ситуация не лучше.

Место медицинского IoT в kill chain​

Атака на медицинское оборудование раскладывается на конкретные этапы с привязкой к MITRE ATT&CK. Таблица ниже - не абстракция, а маршрут, который я использую при планировании пентеста больничной инфраструктуры.

Этап kill chain	MITRE ATT&CK	Контекст в медицинской сети
Разведка	Network Service Discovery (T1046, Discovery)	Сканирование портов 104 (DICOM), 2575 (HL7), 443/80 (веб-интерфейсы помп)
Initial access	Exploit Public-Facing Application (T1190, Initial Access), Default Accounts (T1078.001, Initial Access)	Эксплуатация веб-интерфейса насоса с дефолтными credentials; уязвимость в TCP/IP-стеке
Credential access	Password Guessing (T1110.001, Credential Access), ARP Cache Poisoning (T1557.002, Credential Access)	Перехват трафика между помпой и drug library server через MitM в плоской сети
Lateral movement	Exploitation of Remote Services (T1210, Lateral Movement)	Переход от скомпрометированного насоса к DICOM-серверу или МРТ через общий VLAN
Impact	Transmitted Data Manipulation (T1565.002, Impact), Data Encrypted for Impact (T1486, Impact)	Изменение параметров дозировки; шифрование данных PACS ransomware

Главное отличие от пентеста корпоративной AD-среды: lateral movement в медицинской сети часто тривиален из-за отсутствия сегментации, но импакт затрагивает не данные, а здоровье пациентов. Это сдвигает модель рисков и меняет приоритеты при составлении отчёта.

Чем медицинская сеть отличается от корпоративной IT-инфраструктуры​

Пентестерам, привыкшим к Windows-домену и Kerberos, медицинские сети кажутся другой реальностью. И они правы - это другая реальность. Конкретные отличия, влияющие на выбор вектора:

Параметр	Корпоративная IT	Медицинская IoT-сеть
Протоколы	HTTP/S, SMB, RDP, Kerberos	DICOM (порт 104), HL7 v2 (порт 2575), FHIR (REST API)
Аутентификация	AD/LDAP, MFA	Часто отсутствует - DICOM не требует аутентификации по дизайну
Патчинг	Регулярные циклы через WSUS/SCCM	Жизненный цикл устройства 8-10 лет, обновление требует сертификации FDA
ОС	Windows 10/11, Server 2019+	Windows XP Embedded, VxWorks, проприетарные RTOS
Сетевая сегментация	Обычно реализована (VLAN, firewall)	Часто отсутствует - плоская сеть
Мониторинг	EDR-агенты, SIEM, NTA	Практически отсутствует - агенты несовместимы с embedded ОС

Протокол DICOM проектировался для передачи медицинских изображений между модальностями (МРТ, КТ, рентген) и PACS-серверами. Аутентификация в базовой спецификации не предусмотрена. Любой хост в сети, способный отправить C-FIND или C-STORE запрос на порт 104, получает доступ к снимкам и данным пациентов. Это Insecure Design (A04:2021 по OWASP) в чистом виде - не баг реализации, а архитектурное решение тридцатилетней давности.

HL7 v2 передаёт клинические данные (результаты анализов, назначения, ADT-сообщения) текстом без шифрования. Перехват через ARP Cache Poisoning (T1557.002) в плоской медицинской сети - задача на несколько минут.

Выбор вектора: decision tree для медицинского IoT-пентеста​

Перед тем как копать конкретные уязвимости, определяем вектор по условиям доступа:

• Внешний пентест → Shodan/Censys recon → поиск экспонированных DICOM (порт 104), HL7 (порт 2575), веб-интерфейсов → проверка дефолтных credentials (T1078.001)
• Внутренний пентест, плоская сеть → ARP poisoning + перехват трафика → идентификация cleartext-протоколов → MitM на DICOM/HL7 → pivot через legacy OS
• Внутренний пентест, сегментированная сеть → тестирование правил firewall между медицинским VLAN и остальной инфраструктурой → поиск misconfiguration в ACL
• Red team с физическим доступом → извлечение прошивки через JTAG/UART/flash dump → анализ в Binwalk/Ghidra → извлечение незашифрованных credentials из flash-памяти (CVE-2016-9355, CVE-2016-8375 - требуют физического доступа, публичных эксплойтов нет)

Fingerprinting медицинского оборудования в сети​

Внешний recon: Shodan и Censys​

Медицинских устройств, торчащих в интернет, стабильно много. По данным исследования Сергея Ложкина (Kaspersky), представленного на Security Analyst Summit, через Shodan обнаруживаются тысячи медицинских устройств с открытым доступом - МРТ-сканеры, кардиологическое оборудование, рентгеновские аппараты. Многие работают под Windows XP с десятками непатченных уязвимостей. Дорки для поиска DICOM-серверов:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Инфузионные насосы общаются с drug library server через проприетарные протоколы на нестандартных портах. Модель и версию прошивки часто можно вытащить по HTTP-заголовкам веб-интерфейса или через SNMP - community string public работает чаще, чем хотелось бы. Типичный случай Security Misconfiguration (A05:2021 по OWASP) и Identification and Authentication Failures (A07:2021).

Уязвимости инфузионных насосов: разбор CVE​

По данным Unit 42, среди проанализированных 200 000+ устройств семи производителей было выявлено свыше 40 CVE и более 70 типов уведомлений безопасности. Разберём те, на которые есть верифицированные данные из NVD.

Baxter Sigma Spectrum - открытый канал передачи данных​

CVE-2020-12040 затрагивает Baxter Sigma Spectrum Infusion System v6.x (модель 35700BAX) и Baxter Spectrum Infusion System v8.x (модель 35700BAX2). Устройство шлёт и принимает статусную и операционную информацию по неаутентифицированному каналу открытым текстом.

• CVSS: 9.8 (Critical)
• Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• CWE: CWE-319 (Cleartext Transmission of Sensitive Information)
• EPSS: 0.0020, percentile 0.42 - вероятность эксплуатации ниже медианы, но CVSS-вектор говорит сам за себя: атака по сети (AV:N), не требует сложных условий (AC:L), привилегий (PR:N) и действий пользователя (UI:N)

Практический сценарий: атакующий с доступом в больничную сеть (через Wi-Fi, скомпрометированный хост или гостевой VLAN) делает ARP Cache Poisoning (T1557.002) и перехватывает весь обмен между помпой и сервером. Данные идут открытым текстом - можно читать статусную и операционную информацию, а при MitM-позиции - модифицировать передаваемые данные (Transmitted Data Manipulation, T1565.002). Публичных эксплойтов для CVE-2020-12040 в Exploit-DB и других открытых базах нет; эксплуатация основана на перехвате незашифрованного канала.

Применимость: внутренний пентест при наличии доступа в сетевой сегмент с инфузионными насосами Baxter Sigma Spectrum v6.x/v8.x. Для внешнего пентеста нужен предварительный initial access.

BD Alaris 8015 PC unit - извлечение credentials из flash (CVE-2016-9355, CVE-2016-8375)​

CVE-2016-9355 и CVE-2016-8375 затрагивают BD Alaris 8015 PC unit (Version 9.5 и ранее, а также Version 9.7). Оба связаны с CWE-255 (Credentials Management Errors); оценка CVSS v3 в NVD не указана. При физическом доступе к устройству можно вскрыть корпус, прочитать flash-чип и достать оттуда незашифрованные учётные данные беспроводной сети и другую техническую информацию.

Оба вектора требуют физического доступа, что ограничивает применимость: red team с проникновением в помещение или анализ списанного оборудования. Билли Райос, один из ведущих исследователей IoT-безопасности, именно так и работал - покупал подержанные медицинские устройства на eBay и препарировал их в лаборатории.

Извлечение прошивки через flash dump с последующим анализом в Binwalk и Ghidra - стандартная процедура. Hardcoded credentials в конфигурационных файлах встречаются систематически.

VxWorks TCP/IP стек - CVE-2019-12255​

CVE-2019-12255 - Buffer Overflow в TCP-компоненте Wind River VxWorks (из группы уязвимостей URGENT/11). Integer underflow при обработке TCP Urgent Pointer = 0.

• CVSS: 9.8 (Critical)
• Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• CWE: CWE-120 (Buffer Copy without Checking Size of Input)
• EPSS: 0.8023, percentile 0.9914 - Top 1%, экстремально высокая вероятность эксплуатации
• Публичный эксплойт: EDB-47233, автор Zhou Yu, опубликован 2019-08-12, тип DoS (публичный эксплойт - только DoS; RCE-вектор теоретически возможен по CVSS, но публичного RCE-PoC нет)

Уязвимость не в самом насосе, а в TCP/IP стеке IPNet, который сидит в RTOS VxWorks - ОС, на которой работает масса медицинских устройств (по данным Armis, затронуты BD Alaris PCA, Spacelabs patient monitors и др.). Это Vulnerable and Outdated Components (A06:2021 по OWASP) в чистом виде: дыра в сторонней cross-platform библиотеке, которая прилетает в устройство через компонент ОС.

EPSS 0.80 (Top 1%) при наличии публичного эксплойта - ожидаемый показатель. По данным Unit 42, 52% проанализированных насосов были уязвимы к CVE-2019-12255 и связанному CVE. Шесть лет после раскрытия - устройства всё ещё работают без патчей. Вдумайтесь.

Применимость: любой сценарий с сетевым доступом к устройству на VxWorks. Не требует привилегий, аутентификации и действий пользователя.

Lateral movement через DICOM и атаки на МРТ оборудование​

Получив foothold на одном медицинском устройстве, атакующий переходит к движению по сети. В больничной инфраструктуре это проще, чем в корпоративной среде - и вот почему.

Плоская сеть. Медицинские устройства часто стоят в одном VLAN с рабочими станциями врачей, PACS-серверами и административными системами. Сегментация - скорее исключение.

DICOM без аутентификации. Протокол позволяет слать C-FIND (поиск), C-STORE (сохранение), C-MOVE (перемещение) запросы к любому DICOM-серверу в сети. Чтобы получить доступ к МРТ-снимкам, достаточно знать AE Title целевого узла - а его можно определить через C-ECHO или Nmap-баннер.

Доверенная зона. Как показал эксперимент Ложкина (Securelist/Kaspersky), производители закрывают внешний доступ, но считают локальную сеть доверенной. Подключившись к МРТ-аппарату из локалки, он получил доступ к интерфейсу управления, файловой системе и данным пациентов - через командную оболочку, встроенную в интерфейс устройства. Зачем разработчики засунули shell во врачебный интерфейс - вопрос без ответа.

Legacy OS как pivot. Windows XP Embedded на МРТ или КТ-сканере - не редкость, а норма. Десятки непатченных уязвимостей превращают такое устройство в трамплин для дальнейшего lateral movement через Exploitation of Remote Services (T1210).

Типичная цепочка при внутреннем пентесте: Wi-Fi со слабым паролем или скомпрометированная рабочая станция → ARP poisoning в медицинском VLAN → перехват DICOM/HL7 трафика → доступ к PACS-серверу → pivot через legacy OS к административным системам.

Где детекция работает и где слепые зоны в медицинских сетях​

Стандартные средства мониторинга в медицинских сетях упираются в фундаментальные ограничения:

Средство защиты	Что покрывает	Слепая зона
EDR (CrowdStrike Falcon, Kaspersky EDR Expert, Elastic Agent)	Рабочие станции врачей, серверы	Не ставится на насосы, МРТ, КТ - несовместимая ОС (VxWorks, RTOS)
SIEM (MaxPatrol SIEM, KUMA, Splunk)	Логи Windows-хостов, сетевого оборудования	Медицинские устройства не генерируют syslog; DICOM/HL7 не парсится стандартными коннекторами
NTA/NDR (PT NAD, Suricata)	Аномалии сетевого трафика на IP-уровне	Baseline для DICOM/HL7 не настроен; трафик на порту 104 воспринимается как нормальный
Сетевой firewall	Фильтрация между сегментами	При плоской сети - бесполезен; порт 104 должен быть открыт по функциональным требованиям

Что реально помогает закрыть слепые зоны:

Сетевая сегментация - выделение медицинских устройств в отдельный VLAN с минимальными ACL. Инфузионные насосы общаются только с drug library server, DICOM-модальности - только с PACS. Всё остальное - deny.

Пассивный мониторинг IoMT - решения класса Armis, Claroty, Medigate пассивно анализируют трафик и строят профили устройств без установки агентов. В России этот класс представлен слабо.

SBOM (Software Bill of Materials) - реестр компонентов каждого устройства, включая версии open-source библиотек. FDA давит на производителей по части SBOM: зная, что насос использует VxWorks 6.8, сразу проверяем CVE-2019-12255. По данным «Информзащиты», число инцидентов проникновения в сети медучреждений через оборудование выросло на 42% за первые девять месяцев 2025 года.

Чеклист пентеста медицинской IoT-сети​

Требования к окружению​

• Сценарий: внутренний пентест (grey/white box), доступ в сетевой сегмент с медицинским оборудованием
• ОС: Kali Linux 2024.x+, минимум 8 ГБ RAM
• Инструменты: Nmap 7.94+, Wireshark 4.x, dcm4che toolkit (для DICOM-запросов), Binwalk 2.3+ (для прошивок), Ghidra 11.x (для реверса)
• Сеть: доступ в VLAN с медоборудованием; offline-режим для анализа прошивок

Порядок действий​

1. Определить сетевую топологию: медицинские устройства в отдельном VLAN или в общей сети?
2. Сканирование медицинских портов: 104 (DICOM), 2575 (HL7), 8042/4242 (Orthanc), 80/443 (веб-интерфейсы)
3. Fingerprinting обнаруженных устройств: модель, версия прошивки, ОС - через HTTP-заголовки, SNMP, баннеры
4. Проверка дефолтных credentials (T1078.001) на веб-интерфейсах - мануалы вендоров с паролями валяются в открытом доступе
5. Отправка DICOM C-ECHO на обнаруженные серверы: отвечает ли без аутентификации?
6. Перехват трафика через ARP poisoning: передаются ли данные открытым текстом?
7. Проверка применимости CVE для VxWorks (CVE-2019-12255) на embedded-устройствах
8. Оценка lateral movement: доступны ли PACS, EHR, административные системы из медицинского сегмента?
9. Документирование находок с привязкой к MITRE ATT&CK и рекомендациями по сегментации

Производители медицинского оборудования за последние годы начали относиться к безопасности серьёзнее - FDA давит, SBOM внедряется, coordinated disclosure перестал быть экзотикой. Но парк установленных устройств - это сотни тысяч помп, сканеров и мониторов с прошивками, которые никто не обновит до конца жизненного цикла. Через три-четыре года ситуация с новыми устройствами улучшится. А вот следующие три-четыре года старые помпы будут работать в тех же плоских сетях, с тем же VxWorks 6.8 и тем же DICOM без аутентификации. Исследование PMC/OCDS, охватившее 92 миллиона закупочных записей по 36 странам, показало среднее окно экспозиции 3.2 года - от момента покупки устройства до публикации CVE. Даже при идеальном патчинге (которого нет) устройство три года работает с уязвимостью, о которой ещё никто не знает. Вопрос не в том, обнаружит ли кто-то эти слабости - они давно каталогизированы. Вопрос в том, кто окажется в сети первым: пентестер на плановом аудите или атакующий, который зашёл через скомпрометированный VPN-шлюз соседнего подрядчика.