Вы находитесь на странице: 1из 36

Александр Большев, Глеб Чербов

Светлана Черкасова

Компоненты DTM:
тайные ключи к королевству АСУ ТП

Исследовательский центр Digital Security,


1 декабря 2014
Содержание

0. Введение: главное об АСУ ТП 4 5. Решение – FDT 2.0? 31


1. Введение в FDT/DTM 8 6. Выводы и планы на будущее 32
2. Область исследования 16 7. Благодарности 33
3. Инструменты и методы фаззинга 21 8. О компании 34
4. Найденные уязвимости и слабости 25

Краткое содержание исследования

Современные инфраструктуры АСУ ТП — это сложные При такой организации, проблемы конфигурирования и
многоуровневые системы, основанные на множестве тех- управления интеллектуальными полевыми устройствами
нологических решений и спецификаций. Одной из техно- всегда были весьма сложными.
логий, используемых в таких инфраструктурах, является
FDT/DTM. Разработанная FDT Group в начале 2000-х, FDT/ Решение, предлагаемое FDT Group в виде спецификации
DTM была призвана решить одну из проблем стандар- FDT/DTM, состоит из двух частей — FDT (программный
тизации, возникающую при работе с низкоуровневыми инструментарий настройки полевых устройств) и DTM
(полевыми) устройствами. Эти устройства — датчики, ак- (программное средство управления типом устройства).
туаторы, трансмиттеры — представляют собой нижний FDT позволяет компонентам DTM взаимодействовать друг
уровень инфраструктуры и отвечают за взаимодействие с с другом внутри контейнера, называемого FDT Frame.
окружением: измерение температуры и давления, управ- Создавая виртуальные иерархии DTM, можно через стан-
ление вентилями и другими физическими элементами дартизованный интерфейс FDT работать с любым устрой-
заводов, электростанций и иных предприятий. Эти око- ством в реальной инфраструктуре предприятия.
нечные устройства соединены с контроллерами и управ-
ляющими системами (SCADA, DCS) посредством низкоу- К сожалению, при создании спецификации были упущены
ровневых протоколов, включая Modbus, Profibus, HART и моменты, связанные с информационной безопасностью.
др. На одном блоке электростанции может быть несколь- Текущая спецификация (1.2.1) основана на технологии
ко тысяч интеллектуальных полевых устройств, и все они DCOM и обмене сообщениями на базе XML. Это создает
так или иначе соединяются с управляющими системами атакующему прекрасные возможности для получения
через иерархии низкоуровневых протоколов. Несколько контроля над всей иерархией посредством эксплуатации
уровней таких протоколов могут быть соединены посред- уязвимости лишь в одном компоненте.
ством контроллеров или шлюзов.

2
Цель исследования и основные результаты

Цель данного исследования – показать, насколько плохо Из данного списка особенно опасны выполнение произ-
или хорошо защищены инфраструктуры на базе FDT/DTM, вольного кода и XML-инъекция. Посредством первой уяз-
выявить архитектурные слабости спецификации и опре- вимости злоумышленник может захватить контроль над
делить спектр возможных уязвимостей в DTM-компо- приложением FDT Frame и, таким образом, возможность
нентах. Поскольку в официальном каталоге на сайте FDT получать данные, настраивать и даже отключать любые
Group содержится порядка 3000 компонентов для раз- устройства в иерархии FDT/DTM. Инъекция XML-кода мо-
личных устройств, была взята выборка в 114 компонентов жет помочь злоумышленнику в развитии атаки на другие
для 752 различных устройств, поддерживающих низкоу- системы, в том числе и на системы верхних уровней, на-
ровневый протокол HART. В число производителей ком- пример, ERP.
понентов выборки попали: ABB, Endress+Hauser, Emerson,
Schneider Electric, Vega, Honeywell и др. После этого при Полученные результаты свидетельствуют о невысоком
помощи специально разработанных программных и ап- качестве защищенности инфраструктур, основанных на
паратных средств был проведен фаззинг компонентов. спецификации FDT/DTM. Вместе с тем, все эти атаки воз-
Результат – обнаружение 29 уязвимостей в компонентах, можны не только из-за недостатков DTM, но и из-за слабой
поддерживающих порядка 500 устройств. Среди уяз- архитектуры АСУ ТП в целом. Подход к многоуровневым
вимостей: отказ в доступе, выполнение произвольного сетям АСУ ТП нуждается в полной переработке. Иначе уяз-
кода, состояние гонки, инъекция XML и др. вимости такого рода будут возникать снова и снова.

3
Введение: главное об АСУ ТП
0
АСУ ТП расшифровывается как «автоматизированная Как мы уже говорили ранее, современные АСУ ТП –
система управления технологическим процессом». сложные системы, где интегрированы многие техно-
Это общий термин, объединяющий программные и логии и архитектуры. Взглянем на примерный план
аппаратные комплексы, используемые в автоматиза- современной инфраструктуры АСУ ТП (см. рис. 1).
ции промышленности, в том числе распределенные Здесь изображены три основных уровня АСУ ТП.
системы управления (DCS), системы диспетчерского
контроля и сбора данных (SCADA) и другие систе-
мы, включая программируемые контроллеры (PLC),
человеко-машинные интерфейсы (HMI), системы
управления производством (MES) и т. д. Сегодня ин-
фраструктуры АСУ ТП можно найти на любом заводе Рисунок 1:
и даже в вашем собственном доме! Упрощенно гово- Примерный план
ря, АСУ ТП осуществляет сбор данных с удаленных современной
станций, обрабатывает их и использует автоматизи- инфраструктуры
рованные алгоритмы или управляемую оператором АСУ ТП.
программу-диспетчер для создания команд, кото-
рые затем отправляются на удаленные устройства
(или «полевые устройства»). Полевые устройства
выполняют всю грязную работу: контроль состоя-
ния, запуск и остановка механизмов, сбор данных с
датчиков и т. д.

Современные инфраструктуры АСУ ТП имеют слож-


ную архитектуру, состоящую из таких общеизвест-
ных элементов, как серверы, ПК, сетевые коммута-
торы, технологии программного обеспечения (.Net,
DCOM, XML и т. д.), и более сложных компонентов:
программируемых контроллеров, передатчиков,
силовых приводов, аналоговых контрольных сигна-
лов и т. д. Такое сочетание позволяет атаковать эти
MES PAS ERP
системы самыми разными способами. В этом отче-
те мы расскажем о том, как исследовали некоторые
звенья инфраструктуры АСУ ТП. О некоторых слабо-
стях среднего уровня АСУ ТП (уровня компонентов
SCADA и HMI), до которых можно добраться с нижне- HMI DCS/SCADA OPC
го уровня (уровня полевых устройств и соединений),
и таким образом вызвать другие слабости на верх-
нем уровне этой АСУ ТП (MES, PAS и другие системы).
Мы попадем в инфраструктуру АСУ ТП через черный PLC
ход и украдем ключи к «королевству».

4
0
1. Нижний уровень, где расположены полевые устрой- петчерского контроля и сбора данных (Supervisory
ства. Как уже упоминалось выше, они подходят для Control and Data Acquisition (SCADA), программ-
грязной работы: могут контролировать температу- ный пакет, предназначенный для разработки или
ру и давление в реакторе, управлять такими опе- обеспечения работы в реальном времени систем
рациями, как открытие и закрытие клапанов, вклю- сбора, обработки, отображения и архивирования
чение и выключение насосов и пр. На этом уровне информации об объекте мониторинга или управ-
используется множество устройств. Это могут быть ления4), человеко-машинные интерфейсы (Human-
низкоуровневые программируемые логические кон- Machine Interface (HMI)), а также такие серверы, как
троллеры (Programmable Logic Controller (PLC), по OPC (Open Platform Communications, ранее OLE for
данным Википедии1 : специализированное устрой- Process Control – OLE для управления процессами).
ство, используемое для автоматизации технологиче- На этом уровне осуществляется вся интеллектуаль-
ских процессов). Также это могут быть передатчики ная деятельность. Здесь на основе данных с низших
и приводы, управляемые удаленным терминальным уровней операторы и автоматизированные систе-
устройством (Remote Terminal Unit (RTU), электрон- мы решают, что делать, и отправляют команды на
ное устройство под управлением микропроцессора, полевые устройства. Здесь проходит весь процесс
которое переводит физические объекты в сигналы, автоматизации производства. Операторы, инжене-
понятные распределенной системе управления или ры-технологи, инженеры АСУ ТП, программисты PLC
SCADA-системе, путем передачи телеметрических и ПО работают с системами на этом уровне.
данных на ведущую систему и сообщений от веду-
щей диспетчерской системы к контролируемым 3. На верхнем уровне приосходит интеграция бизнеса
объектам2). Этот уровень – «царство» низкоуровне- и промышленных процессов, привязка к корпоратив-
вых промышленных протоколов, таких как Modbus, ной сети и системам планирования ресурсов пред-
Modbus TCP, HART, Wireless HART, Profibus DP или PA, приятия (Enterprise Resource Planning (ERP)). На этом
Foundation Fieldbus H1 и другие. Инженеры нижнего уровне расположены различные системы управле-
уровня АСУ ТП, электрики, техники и другие специа- ния активами производства (Plant Asset Management
листы работают с этим уровнем. (PAS)) и системы управления производственными
процессами (Manufacturing Execution Systems (MES),
2. Средний уровень, где можно встретить высокоуров- предоставляющие нужную информацию в нужное
невые PLC, распределенные системы управления время и показывающие лицам, принимающим реше-
(Distributed Control System (DCS), система управле- ния на производстве, как условия работы цеха могут
ния технологическим процессом, отличающаяся по- быть оптимизированы для повышения производи-
строением распределенной системы ввода-вывода и тельности5). Здесь с АСУ ТП работают управленцы и
децентрализацией обработки данных3), системы дис- инженерно-технический персонал высшего уровня.

1 3
https://ru.wikipedia.org/wiki/Программируемый_логический_ https://ru.wikipedia.org/wiki/Распределённая_система_управления
контроллер 4
https://ru.wikipedia.org/wiki/SCADA
2
Gordon R. Clarke, Deon Reynders, Edwin Wright (2004). Practical modern 5
SCADA protocols: DNP3, 60870.5 and related systems. Newnes, ISBN McClellan, Michael (1997). Applying Manufacturing Execution Systems.
0-7506-5799-5, стр. 19-21 Boca Raton, Fl: St. Lucie/APICS

5
Уверен, у вас уже возник вопрос: «Как такие разные К счастью, миновали времена 1990-х и 2000-х годов,
системы могут взаимодействовать друг с другом?» когда уровень защищенности инфраструктур АСУ ТП
Вот список наиболее часто используемых в АСУ ТП был близок к нулю. Отсутствие патчей, доступные
технологий: из Интернета веб-интерфейсы PLC и SCADA, сли-
яние сети АСУ ТП с корпоративной сетью, – почти
• Windows все это ушло в историю. Для старых инфраструктур,
• Linux которые невозможно быстро обновить, инженеры
• Ethernet АСУ ТП разработали промышленные брандмауэры,
• HTTP специальные SIEM-системы, диодные системы (Diode
• XML Interconnection Systems), особые конфигурации IDS/
• DCOM IPS. Однако теперь частая ошибка при настройке
• .NET безопасности инфраструктуры АСУ ТП – когда забы-
• SOAP вают о ее нижнем уровне.
• SQL
Даже в современной архитектуре АСУ ТП нижний
Знакомо, не так ли? Добавьте в список следующие уровень управляется устаревшими промышленны-
термины, специфичные для АСУ ТП: ми протоколами. У них слабые механизмы безопас-
ности или вовсе никаких. Речь о таких низкоуров-
• Промышленные протоколы (DNP3, Modbus/Modbus невых протоколах, как Modbus поверх RS-485, HART,
TCP, Profibus DP/PA, Foundation Fieldbus, HART, Profinet Profibus DP и PA, Foundation Fieldbus H1 и т. п. Эти
и т. д.) протоколы основаны не на Ethernet или современ-
• OPC и Ко ных беспроводных стеках, а на технологиях, изобре-
• FDT/DTM тенных в далеких 1970-х или 1980-х. Это может быть
• И многое другое... полезно на определенных промышленных объектах,
где сильные электромагнитные помехи способны
Ответ на вопрос выше очень прост: глубокая инте- привести к повреждению или нарушению работы
грация. В начале 2000-х годов поставщики решений современных технологий 1-го и 2-го уровня модели
для АСУ ТП наконец поняли, что они должны рабо- OSI. Но такие места – редкий случай, а большая часть
тать вместе. Были созданы различные стандарты остальной отрасли просто получила старые прото-
и спецификации, помогающие устройствам, про- колы в наследство от ушедшей эпохи.
граммному обеспечению и технологиям от раз-
личных производителей работать друг с другом. И Итак, если найти способ (используя некую особую
теперь у нас есть множество спецификаций от IEC, цифровую или аналоговую магию) подключиться
OPC Foundation, консорциума FDT/DTM. Кроме того, к линии низкоуровневого промышленного прото-
многие поставщики разрабатывают собственные кола и преодолеть его некоторые технологические
технологии и методики для интеграции с системами «особенности», можно прослушивать информацию,
других вендоров. Ясно, что глубокая интеграция не передаваемую по этой линии, и даже внедрять соб-
особенно эффективна без глубокого доверия. Само ственные пакеты. Иногда это просто, иногда сложно,
собой, такой подход создает определенные пробле- но всегда возможно. Однако соседние устройства
мы в сфере обеспечения информационной безопас- и приложения этого совсем не ожидают. Они могут
ности подобных инфраструктур. быть уязвимы к специально сформированным паке-

6
там и инструкциям, потому что из-за глубокой инте- уровень SCADA и OPC, а на слой MES и даже ERP! Это
грации и глубокого доверия их разработчики (иногда) еще одна очень интересная «функция», которую мож-
не думают о возможности получения некорректных но использовать для атаки не только на нижние уров-
пакетов (да, они разработали механизмы защиты от ни сети и промышленных процессов, но и на корпо-
поврежденных пакетов, а вот на пакеты с правильной ративные сети. Но первый шаг злоумышленника на
контрольной суммой и некорректным содержимым пути от точки входа (полевые устройства или линия
они не рассчитывали). Более того, некоторые данные, с низкоуровневым протоколом) – взломать приложе-
собранные на уровне полевых устройств, передают- ния среднего уровня. Рассмотрим, как спецификация
ся на более высокие уровни: не просто на средний FDT/DTM может нам помочь.

Источник: http://www2.emersonprocess.com/en-uk/news/
pr_uk/pages/1104-glaxosmithkline.aspx

7
Введение в FDT/DTM
1
Представьте себе современный промышленный средство управления типом устройства. Концепция
объект – электростанцию, например, – и подумайте, FDT описывает интерфейсы взаимодействия между
сколько различных полевых устройств в его инфра- программными компонентами конкретного устрой-
структуре. Только в одном цехе их может быть не- ства, предоставляемыми поставщиком этого устрой-
сколько тысяч. Эти устройства выпущены разными ства, и приборами, разработанными производите-
поставщиками, работают по разным низкоуровне- лем системы управления. Программный компонент
вым протоколам и организованы в сложные иерар- для работы с конкретными устройствами называет-
хические сети. Теперь вопрос: как их поддерживать? ся DTM (Device Type Manager – программное сред-
Просто дойти до каждого из них с портативным ство управления типом устройства)6, согласно созда-
коммуникатором – та еще задача. Другая проблема телям спецификации FDT/DTM. Вкратце:
возникает при создании распределенной системы
управления такими устройствами: разные произ- • FDT стандартизирует коммуникации и конфигура-
водители могут использовать один и тот же низко- ционный интерфейс, соединяющий все полевые
уровневый протокол с собственными командами, устройства и системы среднего уровня;
расширениями и т. д., то есть для разработки SCADA • DTM предоставляет единую структуру для доступа
необходимо разобраться во всех этих подробно- к параметрам устройств, настройки и эксплуата-
стях. Решение этих проблем существует: специфика- ции устройств и диагностики проблем.
ция FDT/DTM.
Обычно приложение-фрейм (FDT Frame) выступает
FDT Joint Interest Group была основана ABB, в качестве контейнера для всех компонентов DTM.
Endress+Hauser, Invensys, Siemens и Metso Automation Устройства можно настраивать, контролировать и
в начале 2003 года. Теперь эти компании составля- поддерживать из одной программной системы неза-
ют управляющий комитет FDT JIG. FDT Joint Interest висимо от конкретной модели, типа или промышлен-
Group была некоммерческим международным биз- ного протокола того или иного полевого устройства.
нес-партнерством в области промышленной авто- Приложение FDT Frame позволяет инженерам за-
матизации. С ростом числа участников управлять гружать и создавать иерархии драйверов устройств
FDT Joint Interest Group становилось все труднее, и и интерфейсов DTM. Приложение FDT Frame может
было решено перегруппировать ее как юридически играть роль PAS/AMS, DCS или просто инструмента
независимую организацию. Так в сентябре 2005 года конфигурации устройств. Системы управления акти-
была создана ассоциация FDT Group. вами производства (PAS или AMS) позволяют инже-
нерам настраивать и контролировать все полевые
FDT (Field Device Technology – технология настрой- устройства, а менеджерам – получать полный отчет
ки полевых устройств, ранее Field Device Tool) – это о состоянии инфраструктуры полевых устройств.
спецификация программного интерфейса. Этот PAS-системы решают сложные проблемы управле-
программный интерфейс описывает обмен данны- ния устройствами и интегрируются с такими высоко-
ми между полевыми устройствами и драйверами уровневыми системами, как MES и ERP.
с помощью единого фреймворка. Спецификация
FDT описывается стандартами IEC 62453 и ISA 103.
FDT/DTM состоит из двух частей: Field Device Tool –
программный инструментарий настройки полевых 6
FDT Group, http://fdtgroup.org
устройств, и Device Type Manager – программное

8
1
Одно из наиболее популярных приложений FDT компонент Condition Monitoring, который позволяет
Frame – Endress+Hauser FieldCare. Оно имеет мно- контролировать инфраструктуру полевых устройств
жество различных функций, включая интеграцию с при помощи веб-браузера. На рис. 2 можно увидеть
MES и ERP-системами, привязку к базам данных, об- главное окно интерфейса FieldCare.
мен данными с внешними приложениями, а также

Рисунок 2: Главное окно E+H FieldCare с иерархией нескольких DTM-компонентов.

9
Что касается компонентов DTM, то их можно создать Существуют различные версии FDT/DTM, но в нашем
несколькими способами: как FDT-интерфейс к име- исследовании мы будем придерживаться версии
ющемуся автономному инструменту, как общий ин- 1.2.1, которая сейчас наиболее популярна. Техноло-
терфейс к файлам языка описания устройств (Device гия FDT 1.2.1 основана на взаимодействии COM-ком-
Description Language (DDL)) или с нуля как DTM для понентов. Приложение FDT Frame и различные DTM
конкретного устройства (см. рис. 3). обмениваются XML-сообщениями.

FDT

PAS & DCS

DDs Generic DTM

Рисунок 3: Разные реализации DTM.

DTM-компоненты делятся на два основных типа: При помощи различных комбинаций компонентов
можно создавать сложные иерархические сети, где
• CommDTM, которые позволяют работать с опреде- один DTM действует в качестве CommDTM для низко-
ленным промышленным протоколом; уровневых DTM и одновременно как DeviceDTM для
• DeviceDTM, которые предоставляют функциональ- высокоуровневых DTM. На рисунке 4 можно увидеть
ные возможности для работы с конкретными по- простейшую иерархию компонентов CommDTM и
левыми устройствами. DeviceDTM.

10
На рисунке контейнер FDT Frame содержит в себе
PAS Frame Application всего два компонента. CommDTM отвечает за связь
COM Container с промышленной шиной через модем. DeviceDTM
предназначен для связи с передатчиками посред-
Device DTM ством CommDTM. Иерархия может быть и гораздо
сложнее, как показано на рис. 5.
CommDTM

Рисунок 4:
Схема иерархии DTM-компонентов.

DTM Ethernet
Fieldbus Ethernet
HART
DATA
DTM
Fieldbus
Fieldbus
HART
DTM DATA
HART

DTM

Рисунок 5: DTM-коммуникации в сложных сетях.

11
Frame application Device type manager (DTM)

FDT

DOM

XML-DATA

Рисунок 6: Схема иерархии DTM-компонентов. 7

На рисунке 6 показана упрощенная внутренняя архитектура FDT. Используя ее, рассмотрим упрощенный про-
цесс взаимодействия внутри FDT на простом примере иерархии из рисунка 4. На нашем предприятии есть не-
сколько полевых устройств на основе протокола HART, которые подключены к линии токовой петли. Сервер с
FDT Frame также подключен к токовой петле с помощью HART-USB-модема. Что произойдет, если инженер за-
хочет прочитать данные от конкретного полевого устройства и нажмет «Чтение данных с устройства» в меню
приложения Frame? DeviceDTM получит вызов DownloadRequest() от FDT Frame. Затем DeviceDTM с помощью
FDT API запросит у FDT Frame указатель к CommDTM и запустит настройку связи с ним. После нескольких вы-
зовов и ответов DeviceDTM пошлет запрос на соединение с CommDTM:

1 <?xml version=”1.0”?>
2 <FDT xmlns=”x-schema:FDTHARTCommunicationSchema.xml” xmlns:fdt=”x-schema:FDTDataTypesSchema.xml”>
3 <ConnectRequest fdt:tag=”AAAAAAAA”>
4 <ShortAddress shortAddress=”0”/>
5 </ConnectRequest>
6 </FDT>

CommDTM создаст HART-команду: отправит пакет на устройство с определенным идентификатором (Polling


ID). Пакет будет отправлен на устройство токовой петли с помощью HART-модема. Когда устройство отве-
тит и CommDTM получит его уникальный идентификатор HART (Unique ID), он с помощью обратного вызова
FdtCommunicationEvents.OnConnectResponse сообщит DeviceDTM, что все готово для передачи данных:

7
Рисунок является собственностью FDT Group и взят из их официальной спецификации, см. http://www.fdtgroup.org/technical-documents.

12
1 <FDT xmlns=”x-schema:FDTHARTCommunicationSchema.xml” xmlns:fdt=”x-schema:FDTDataTypesSchema.xml”>
2 <ConnectResponse fdt:tag=”AAAAAAAA” preambleCount=”0” primaryMaster=”1” communication-
3 Reference=”1B36D3D1-C4DD-4BAF-9A31-016F704E21F2”>
4 <ShortAddress shortAddress=”0”/>
5 </ConnectResponse>
6 </FDT>

Теперь DeviceDTM создаст TransactionRequest с точной командой (и, возможно, данными), которую нужно от-
править на устройство:

1 <?xml version=”1.0”?>
2 <FDT xmlns=”x-schema:FDTHARTCommunicationSchema.xml” xmlns:fdt=”x-schema:FDTDataTypesSchema.xml”>
3 <DataExchangeRequest commandNumber=”0” communicationReference=”1B36D3D1-C4DD-4BAF-9A31-
4 016F704E21F2”>
5 </DataExchangeRequest>
6 </FDT>

CommDTM обработает запрос, создаст HART-пакет с командой и инкапсулированными данными (если таковые
имеются) и отправит его на линию токовой петли. Полученный ответ от устройства будет проанализирован,
HART-заголовок и байт контрольной суммы будут удалены, и командные данные из пакета будут переданы
DeviceDTM с помощью обратного вызова IFdtCommunicationEvents.OnTransactionResponse:

1 <?xml version=”1.0”?>
2 <FDT xmlns=”x-schema:FDTHARTCommunicationSchema.xml” xmlns:fdt=”x-schema:FDTDataTypesSchema.xml”>
3 <DataExchangeResponse commandNumber=”0” communicationReference=”1B36D3D1-C4DD-4BAF-9A31-
4 016F704E21F2”>
5 <fdt:CommunicationData byteArray=”FE006209070201010110F01C070262000000C7000000”/>
6 <Status deviceStatus=”0”>
7 <CommandResponse value=”0”/>
8 </Status>
9 </DataExchangeResponse>
10 </FDT>

13
Два важных замечания: Последнее, чего мы коснемся в этой главе, – место
FDT и DTM в архитектуре АСУ ТП. Хорошая иллюстра-
1. Все данные будут переданы с помощью XML. Тэг ция (рис. 7)8 есть на сайте FDT Group.
устройства (FDT:tag) – это уникальный идентифика-
тор полевого устройства (и инстанции DeviceDTM) в Как видите, FDT охватывает все уровни промышлен-
иерархии FDT Frame. Тэг зависит от данных, полу- ного объекта. Компоненты DTM можно найти в:
ченных с этого полевого устройства (например,
для HART-устройств это может быть HART tag или • PAS/AMS-системах;
HART long tag); • HMI-системах;
• DCS-системах;
2. DeviceDTM не общается с устройствами непосред- • OPC-серверах.
ственно. Вместо этого он получает двоичный поток
XML c устройства, а CommDTM только удаляет из па- Данные с DTM-компонентов могут переходить на
кета начало и конец. верхний уровень, например, к MES- и даже ERP-си-
стемам.
У спецификации FDT/DTM есть и другие слабые ме-
ста: многие компоненты DTM были созданы для ран-
них версий этой спецификации или просто в каче-
стве интерфейсов для существующих библиотек или
программного обеспечения. В результате получает-
ся очень опасное и уязвимое смешение технологий:

• OLE32
• ActiveX
• Visual Basic 6.0
• .Net
• COM
• XML

Как видно, разные DTM могут использовать различ-


ные модели потока, разные версии .Net, XML-анали-
заторы, рабочие среды C++, и все это должно как-то
работать вместе. Поэтому слишком много исключе-
ний игнорируется и не поддерживается даже «ко-
стылями». А это означает множество отличных век-
торов для атак.

Источник: http://www.emersonprocessxperts.com/
2011/04/steam-injection-well-wireless-flow-
8 rate-measurement/#.VHXd1jGsWIg
Изображение с http://www.automatio nworld.com/fdt-group-
wants-your-input-yes-yours

14
CONTINUOUS DEVICE ACCESS

Ethernet

SCADA/DCS/PAS

industrial ethernet

field b us

sensor/a ct or bus

Рисунок 7: FDT и уровни АСУ ТП.

15
Область исследования
2
На официальном сайте FDT Group (http://www. Несколько слов о HART. Протокол HART (Highway
fdtgroup.org) имеется каталог FDT-компонентов . Там Addressable Remote Transducer – магистральный
есть DTM-компоненты для тысяч полевых устройств. адресуемый дистанционный преобразователь) яв-
Приступив к исследованию FDT, мы поняли, что не- ляется одной из первых реализаций протоколов
обходимо сформулировать конкретные задачи и полевой шины. Главное преимущество HART заклю-
задать некоторый диапазон, потому что весь объем чается в том, что он может взаимодействовать со
данных слишком велик для небольшой группы ис- стандартной токовой петлей 4–20 мА. В прошлом
следователей. И мы решили, что хотели бы ответить токовая петля 4–20 мА использовалась для получе-
на три вопроса в нашем исследовании: ния и отправки информации на удаленные передат-
чики или приводы с использованием аналогового
1. Каковы архитектурные слабости FDT/DTM? (токового) сигнала. Когда HART появился (в середине
2. Какие уязвимости в DTM-компонентах могут при- 1980-х), он давал возможность настройки удаленных
вести к компрометации инфраструктуры АСУ ТП? устройств через токовую петлю и получения/отправ-
3. Что можно сказать о безопасности FDT 2.0? ки дополнительной информации к ним, а не только
чтения (или записи) одной переменной.
Ответ на первый вопрос был частично дан в конце
предыдущей главы. Чтобы дать полный ответ, а так- HART основан на архитектуре master-slave (веду-
же ответить на второй вопрос, необходимо увидеть щий-ведомый). Полевые устройства (передатчики и
примеры реализации DTM. Таким образом, нам нуж- актуаторы) являются ведомыми сетевыми устрой-
но было сделать выборку, отражающую всю совокуп- ствами, а компьютеры с HART-модемами, HART-шлю-
ность DTM-компонентов, и выяснить, сколько из них зами и PLC с HART-модулями – ведущими. Как прави-
имеют недостатки и/или уязвимости. Выборка долж- ло, ведомое устройство не может отправлять пакеты
на быть не очень большой, но и не слишком малень- в сеть, помимо ответов ведущему устройству. Со-
кой, чтобы оставаться репрезентативной. Поэтому гласно спецификации HART, может быть только одно
мы решили изучить около 100 DTM. Наконец, какой основное ведущее устройство (PLC, шлюз или сер-
низкоуровневый протокол следует выбрать при ис- вер) и одно вторичное (ПК или HART-коммуникатор).
следовании DTM? Ответ был очевиден для нас: HART.
Итак, мы выбрали 114 DTM от 24 поставщиков для 752 HART использует две разные схемы адресации
HART-устройств. для полевых устройств: логический и аппаратный
адрес. У каждого полевого устройства уникальный
Почему только HART? По нескольким причинам: аппаратный адрес (Unique address). Он состоит из
Manufacture ID, Device ID и Unique Device ID. Это ана-
• Мы знакомы с этим протоколом; лог MAC-адреса. Кроме того, в многоточечном режи-
• У нас есть аппаратные средства для эксплуатации ме каждое полевое устройство имеет адрес Polling
HART-устройств и атак на них; ID – целое число в диапазоне 1–63.
• HART используется в важнейших отраслях промыш-
ленности, таких как электростанции, химические HART может работать в двух режимах: двухточечный
заводы, нефтегазовые предприятия и т. д. (point-to-point, analog/digital, режим передачи циф-
ровой информации одновременно с аналоговым
сигналом) и многоточечный (multidrop, только циф-
9
ровая передача). В двухточечном режиме цифровые
http://www.fdtgroup.org/product-catalog/certified-dtms

16
2
сигналы передаются по аналоговой токовой петле В случае HART FSK все данные передаются с помо-
4–20 мА. Основное ведущее устройство может полу- щью простой частотной модуляции, где ‘1’ закодиро-
чить значение переменной традиционно, с исполь- вана как один полный период частоты 1200 Гц, а ‘0’
зованием аналогового значения тока, или на основе – как два неполных периода 2200 Гц. Как это проис-
цифровых HART-пакетов. В этом режиме Polling ID ходит, показано на рис. 8 10.
(логический адрес) устройства всегда зафиксиро-
ван в значении 0. В многоточечном режиме на ли- Сейчас протокол HART поддерживается Hart
нии присутствует несколько устройств, и у каждого Communication Foundation (см. веб-сайт http://www.
устройства собственный Polling ID. Когда ведущее hartcomm.org/ для получения более подробной ин-
устройство начинает работу с ведомым, оно вызыва- формации по протоколу).
ет его по Polling ID, чтобы узнать уникальный адрес
полевого устройства. Затем, с помощью Unique ID, В таблице 1 представлены уровни связи по протоко-
ведущее устройство сможет общаться с ведомым лу HART в зависимости от уровней модели OSI.
непосредственно.

+0.5 mA
Аналоговый 0
HART сигнал
сигнал
-0.5 mA
1200 2200
20 mA Hz Hz
‘1’ ‘0’

C = Command
R = Response
4 mA

0 1 Время (сек.) 2
Рисунок 8: HART FSK.

10
Собственность Hart Communication Foundation, см. http://en.hartcomm.org/hcp/tech/aboutprotocol/aboutprotocol_how.html

17
В таблице 1 представлены уровни связи по протоко- Физический уровень обеспечивается HART FSK.
лу HART в зависимости от уровней модели OSI. Структура HART-пакетов на канальном уровне пока-
зана в таблице 2:

HART

Таблица 1: Уровни связи по HART.

Delimeter Address [Expand] Command Byte Count [Data] Check byte

Таблица 2: Структура HART-пакетов на канальном уровне.

На уровне приложений доступно множество На уровне приложений появляется дополнительная


HART-команд, которые можно разделить на три ка- схема адресации для HART-протокола – тэг и длин-
тегории: ный тэг. Тэг – это упакованная ASCII-строка, пред-
ставляющая собой идентификатор, который легко
• универсальные (universal: операции с ID, получение запомнить инженеру. Длина тэга не должна превы-
переменных, установка лимита и типа перемен- шать 8 символов (6 упакованных ASCII-байт). Когда
ных, операции с тэгами и т. д.); число полевых устройств на объекте растет, инже-
• распространенные (common usage: инженерные нерам нужны более удобные идентификаторы, по-
команды и специфичные для конкретных процес- этому появилась команда «длинный тэг». Длинный
сов); тэг позволяет сохранять на устройствах 32-байтовую
• специфичные (device family: команды, специфичные ASCII-строку и возвращать ее в ответ на запрос веду-
для семейства устройств и производителя). щего устройства. Как уже говорилось, тэги и длинные
тэги часто используются в PAS/AMS, OPC-серверах,
MES и других системах для идентификации полевых
устройств на промышленных объектах.

18
Еще одна причина выбора DTM на основе HART – про-
блемы физической безопасности HART и возможные
проблемы безопасности механизма инкапсуляции
(которые могут относиться к HART, к FDT или к прин-
ципам построения АСУ ТП в целом). Рассмотрим мо-
дели атак для HART/FDT-инфраструктур. Допустим,
что у нас есть уязвимый DTM. Эта уязвимость может
быть реализована с помощью вредоносных данных
внутри HART-пакета. Как поместить туда эти данные?

Существует несколько способов. Во-первых, низко-


уровневая инъекция, например, непосредственно
в линию токовой петли. С помощью определенных
методов можно успешно подделать ответы полевого Рисунок 9: Атака на уязвимый DTM через линию токовой
устройства в линии токовой петли11. Злоумышленник петли.
проводит атаку «человек посередине» на настоящий
передатчик, подделывает его и отвечает на запросы
DTM специально сформированными пакетами, как
на рис. 9.

Это проще, чем кажется. Длина линии токовой петли


HART может достигать 3 км, и иногда можно найти
HART-передатчики за пределами завода – например,
передатчики уровня давления и коррозии на трубо-
проводах.

Как мы уже упоминали, после HART-шлюза данные


могут отправиться в сети с другими протоколами:
обычный Ethernet, Wi-Fi, другой беспроводной ка-
нал и т. п. Для этого данные могут быть распакованы
в другой формат, такой как HART-IP – HART по про-
токолу TCP/IP. Это может увеличить область атаки:
например, в HART-IP длина пакета закодирована
двумя байтами (максимальное значение = 65535)
Рисунок 10: Атака на уязвимый DTM через высшие уровни
вместо одного в HART (максимальное значение =
(HART-IP).
255). DTM-компонент может удивиться такому ко-
личеству данных. Злоумышленник в данном случае
использует стандартные инструменты и принципы
проведения атаки «человек посередине» на хосты в
Ethernet-сети, затем подделывает пакеты от одного 11
См. презентации HART (in)security: how one transmitter can com-
шлюза к следующему, как показано на рис. 10. promise whole plant и HART as an attack vector: from current
loop to application layer.

19
3
Третий вариант – это атака на один из промышлен- Все DTM имели версию спецификации 1.2 или 1.2.1,
ных протоколов в цепи передачи пакетов. Например, большинство из них (83) были версии 1.2. Что инте-
можно атаковать протокол Modbus или Profibus-DP ресно, мы обнаружили DTM, созданные в течение по-
(см. рис. 11). следних 2–3 лет, но, согласно их внутренним данным,
поддерживающие спецификацию FDT 1.2, а не 1.2.1.
Существуют разработчики ПО, специализирующие-
ся на создании DTM-компонентов: M&M Software и
CodeWrights. У них есть специальные вспомогатель-
ные инструменты, фреймворки и даже автомати-
ческие генераторы для разработки DTM. На рис. 12
можно увидеть долю компонентов на основе таких
фреймворков в нашей выборке DTM.

Неизвестно/ dtmGenerator/
Рисунок 11: Атака на уязвимый DTM через высшие уровни Другие dtmManager
(Profibus DP). 35 (31%)

Прежде чем перейти к методам фаззинга, погово- 64 (56%)


рим об исследуемых компонентах. К сожалению,
политика ответственного разглашения не позволяет
15 (13%)
нам перечислить конкретные модели устройств или
точные названия компонентов. Но список поставщи- DTMStudio/
ков мы указать можем. Мы исследовали DTM-ком- DTMLibrary/CoDIA
поненты следующих производителей: ABB, Azbil
Corporation, Dresser Masoneilan, Emerson/Rosemount,
Endress+Hauser, Flexim, Flowserve, Foxboro Eckardt, GE Рисунок 12: Доля специальных фреймворков среди выбран-
Oil & Gas, General Monitors, Hans Turck GmbH & Co. KG, ных DTM.
Honeywell, ICS GmbH Ettlingen, Invesys/Foxboro, Klay
Instruments, KROHNE, MACTek Corporation, Magnetrol,
Metso, Pepperl+Fuchs, Samson AG, Schneider Electric
USA, StoneL, Vega.

20
3
Инструменты и методы фаззинга

Определив область исследования, мы столкнулись с Анализируемый DeviceDTM помещался в контейнер


новой проблемой: как фаззить 100 COM-компонен- FDT Frame, в нашем случае FieldCare PAS. Для запуска
тов? Эти компоненты могут быть написаны на раз- операции «Прочитать все с устройства» мы исполь-
ных языках и использовать разные рабочие среды, зовали специальные скрипты AutoIt13.
модели процесса разработки и т. д. Поэтому мы ис-
пользовали три разных метода фаззинга: Схема фаззинга с помощью первого метода показана
на рис. 13.
1. Эмулировать CommDTM и помещать анализируемые
данные протокола непосредственно в DeviceDTM
(самый быстрый способ);
PAS (FieldCare) HRTParser lib
2. Эмулировать устройство с помощью виртуального
последовательного порта;
3. Эмулировать устройство аппаратно (с помощью AutoIT
HRTshield, ICSCorsair и т. д.) (самый медленный спо- HART Emulator
Ruby
соб).
HART Fuzzer DTM
Если фаззинг того или иного компонента первым ме- Radamsa
тодом не получался, мы переходили ко второму и т. д.
Поговорим подробнее о наших методах.

Инфраструктура фаззинга во всех методах одина- UDP


ковая: мы использовали библиотеку HRTParser для
обработки и создания HART-пакетов, затем эмулятор
HART (написанный на Ruby) отслеживал состояние Рисунок 13: Фаззинг через эмуляцию CommDTM.
соединения между ведущим и ведомым устрой-
ством. Наконец, в 2/3 случаев внутренние данные
пакета прогонялись через Radamsa12.

12 13
https://code.google.com/p/ouspg/wiki/radamsa, «Radamsa – https://www.autoitscript.com/site/autoit/, «AutoIt v3 – это бес-
это генератор тестовых случаев для тестирования надежности, платный язык описания сценариев, похожий на BASIC, разра-
или фаззер. Его можно использовать для того, чтобы проверить, ботанный для автоматизации Windows GUI и других сценариев.
как программа справляется с искаженными и потенциально вре- Сочетает имитацию нажатия клавиш, движений мыши и мани-
доносными входными данными. Он работает на основе заданных пуляций окнами/кнопками для автоматизации задач, невыпол-
примеров входных данных и поэтому требует минимальных уси- нимых или выполняемых ненадежно с помощью других языков
лий для установки. Основные преимущества Radamsa в том, что (таких как VBScript и SendKeys). Еще AutoIt - компактный, автоном-
он прост в использовании, содержит много старых и новых алго- ный и будет работать на всех версиях Windows «из коробки», не
ритмов фаззинга, легко программируется из командной строки и требуя раздражающих тестовых прогонов!»
уже нашел множество уязвимостей в реально важных програм-
мах».

21
Мы не хотели тратить время на низкоуровневые У некоторых DTM разные модели потоков, ожидаемые
коммуникации. HART медленный (1200 бод), и мы временные параметры и специальные операции HART,
решили ускорить работу. Мы использовали простую так что создание идеальной симуляции CommDTM
схему: FDT Frame (FieldCare) + целевой DeviceDTM обошлось бы довольно дорого. Зато можно было
+ наш специальный CommDTM для фаззинга HART. использовать настоящий HART CommDTM (в нашем
HART Fuzzer CommDTM – это эмуляция реально- случае – CodeWrights HART CommDTM) и подключить
го CommDTM. Когда запущена операция «чтение с его к Ruby HART Emulator с помощью программы для
устройства», этот инструмент принимает запросы эмуляции виртуальных последовательных портов (в
транзакций от DeviceDTM, но вместо отправки на нашем случае – VSPE14 ). CommDTM получает запросы
HART-модем отправляет их в инфраструктуру фаз- транзакций от целевого DeviceDTM и перенаправ-
зинга. Скрипт Ruby HART Emulator получает запрос ляет их через виртуальный последовательный порт
от UDP-сервера и возвращает тело HART-пакета (без (думая, что это настоящий HART-модем, подключен-
заголовка). Это тело прогоняется через Radamsa в 2 ный к токовой петле). Эмулятор принимает пакет,
случаях из 3. AutoIt-скрипт заставляет FieldCare не- извлекает из него команду и с помощью HRTParser
прерывно повторять операцию «Чтение с устрой- создает ответ. В 2/3 случаев ответ прогоняется че-
ства». рез Radamsa. Затем он упаковывается в корректный
HART-пакет и отправляется обратно через виртуаль-
Второй способ – это использование эмуляции вирту- ный порт.
ального последовательного порта, как показано на
рис. 14.

PAS (FieldCare) HRTParser lib

AutoIT
HART Emulator
Ruby
HART CommDTM
(codeWrights)
Radamsa

14
http://www.eterlogic.com/products.vspe.html, «VSPE создан,
Virtual Serial чтобы помочь инженерам и разработчикам ПО создавать, от-
Port Emulator лаживать и тестировать приложения, использующие последо-
вательные порты. Он может создавать различные виртуальные
устройства для передачи/приема данных. В отличие от обыч-
Рисунок 14: Фаззинг с помощью эмуляции виртуального ных последовательных портов, виртуальные устройства имеют
специальные возможности: например, одно и то же устройство
последовательного порта.
может быть открыто несколько раз разными приложениями, что
может быть полезно во многих случаях. С VSPE вы можете предо-
ставить нескольким приложениям доступ к данным физического
последовательного порта, открыть доступ к последовательно-
му порту из локальной сети (по TCP-протоколу), создать парный
виртуальный последовательный порт и т. д.».

22
Но иногда DeviceDTM бывают довольно приверед-
ливыми и отказываются работать даже с эмуляцией PAS (FieldCare) HRTParser lib
виртуального последовательного порта. В таких слу-
чаях мы прибегали к «тяжелой артиллерии», исполь- AutoIT
зуя метод, показанный на рис. 15. Radamsa

CommDTM подключается к настоящему HART-мо- HART CommDTM


дему, а с другой стороны используется устройство (codeWrights) HART Emulator
HRTShield или ICSCorsair. Мы не могли воспользо- Ruby
ваться обычным HART-модемом на стороне фаззера,
поскольку некоторые входные данные для фаззинга
превышали нормальную длину HART-пакета – 255
байт. Обычный HART-модем, как правило, способен USB
получать такие пакеты и передавать их дальше, но
может отказаться их отправлять. ICSCorsair переклю-
чается в режим HART-модема и соединяется по USB
с ПК для фаззинга, а Ruby HART Emulator использует
HART Modem HART “Transmitter”
библиотеку serialport для работы с устройствами. (ICSCorsair)
Остальная инфраструктура не меняется. Этот метод
фаззинга воспроизводит реальную среду, но он мед-
ленный и неудобный.

В конце главы рассмотрим инструментальные сред- Рисунок 15: Фаззинг с помощью аппаратных средств.
ства, которые мы создали для фаззинга.

HRTParser – библиотека на Ruby для создания и ана- DTMSpy – небольшая утилита для прослушивания
лиза пакетов HART. Она поддерживает расширения транзакций между DTM-компонентами. Программа
для конкретных HART-устройств. Библиотеку можно разработана Светланой Черкасовой на C++.
скачать с http://github.com/Darkkey/HRTParser.
Ruby HART Emulator – набор сценариев на Ruby,
HART Fuzzer DTM – компонент CommDTM для фаз- использующий HRTParser для эмуляции HART-стека.
зинга DeviceDTM. Когда он получает запрос транзак- Он может поддерживать несколько устройств и ин-
ции (TransactionRequest), он подключается к удален- тегрируется с Radamsa.
ному UDP-серверу и запрашивает ответ на команду,
указанную в запросе. Компонент написан на C# и
скомпилирован под .NET 2.0 и .Net 4.

23
4
HRTShield – это аппаратное устройство: коммуника-
ционный щит HART для плат Arduino. Мы использова-
ли обычный HART-модем IC от Maxim Semiconductors
(DS8500) с пассивным фильтром входящих данных
и активным фильтром исходящих данных. На плате
имеется специальный усилитель выходного сигна-
ла. Схемы доступны на http://github.com/Darkkey/
HRTShield. HRTShield можно увидеть на рис. 16.

ICSCorsair15 – это многоцелевое открытое аппарат-


ное устройство для проведения аудита низкоуров-
невых протоколов АСУ ТП. Оно может взаимодей-
ствовать с различными системами по протоколам
HART FSK, Profibus и Modbus. ICSCorsair можно управ- Рисунок 16: HRTShield – высокомощный HART-модем.
лять через USB-кабель или удаленно через Wi-Fi,
Bluetooth или другое беспроводное соединение.
Схемы, прошивка и ПО доступны на http://github.
com/Darkkey/ICSCorsair. ICSCorsair можно увидеть на
рис. 17.

Рисунок 17: Плата ICSCorsair v. 0.03.1.

15
Для получения дополнительной информации об ICSCorsair см.
наше выступление на BlackHat USA 2014: ICSCorsair: How I will
PWN your ERP through 4–20 mA current loop.

24
4
Найденные уязвимости и слабые места

В итоге фаззинга мы обнаружили, что уязвимы 29


компонентов (из 114). Это примерно 25%, но если по-
смотреть на статистику по разным типам устройств,
то она выглядит намного мрачнее: 501 (из 752)
устройство имеет уязвимые DTM-компоненты. Срав-
нение показано на рис. 18.
501 (67%)

85 (75%) 251 (33%)

29 (25%)

Рисунок 18: Найденные уязвимости по компонентам и по устройствам.

25
Все найденные уязвимости были разделены на шесть групп:

Удаленное выполнение кода (RCE)


уязвимости, которые могут привести к выполнению произвольного кода в контек-
сте DTM-компонентов и приложений Frame. Это может быть переполнение буфера
или другие похожие уязвимости. Мы написали PoC-эксплойт для каждой уязвимо-
3
сти в этой группе;

Возможное удаленное выполнение кода (RCE)


уязвимости, которые потенциально могут привести к выполнению произвольного
кода в контексте DTM-компонентов и приложений Frame. Написание эксплойтов
для переполнения кучи и похожих уязвимостей заняло бы слишком много време-
ни, поэтому в эту категорию попали все уязвимости без стабильного эксплойта.
7
Это не означает, что такая уязвимость не наносит вреда системе — в лучшем слу-
чае она приводит к DoS, а в худшем к RCE;

Отказ в обслуживании (DoS);


6
Состояние гонки;
2
XML-инъекции
инъекция XML в поле длинного тэга (или другого тэга) может стать причиной за-
грузки внешней схемы или атаки SSRF (Server-Side Request Forgery – подделка за-
просов на стороне сервера);
2
Другое

9
сюда попали непонятные блокировки, случайные сбои, зависания на очень боль-
ших пакетах (>8 кБ: эти пакеты можно отправлять только через HART-IP, но не через
HART по токовой петле). Их либо сложнее эксплуатировать, либо они менее вред-
ны для целевой системы. К этой же категории отнесены курьезные и бесполезные
уязвимости (например, XSS в автоматически сформированном отчете).

26
Рассмотрим некоторые из классов подробнее:

Удаленное выполнение кода (RCE)

Уязвимости удаленного выполнения кода, связан- Это дает злоумышленнику полную свободу действий
ные с переполнением буфера, позволяют потенци- и может привести к компрометации всей системы.
альному злоумышленнику произвести инъекцию При этом само приложение остается работоспособ-
произвольного исполняемого кода, который будет ным, и факт вторжения и постэксплуатации легко
выполнен в контексте уязвимого приложения. Такой может быть незамеченным. С точки зрения атакую-
сценарий возможен в случае подключения к токо- щего, процесс эксплуатации подобных уязвимостей
вой петле и отправки специально сформированного в значительной мере упрощает отсутствие у атаку-
HART-пакета в ответ на опрос устройства. емых DTM-компонентов задействованных механиз-
мов защиты памяти.

Рисунок 19: Удаленное выполнение кода.

27
Отказ в обслуживании (DoS)

Уязвимости отказа в обслуживании могут быть след-


ствием множества факторов, среди которых ошибки
реализации алгоритмов разбора протокола, отсут-
ствие валидации полученных извне данных на пред-
мет соответствия стандартам, любые другие ошибки
реализации компонентов, проявляющиеся в услови-
ях, которые злоумышленник может сформировать
путем внешних воздействий.

Такие уязвимости могут как повлечь за собой ава-


рийное завершение работы (crash) компонента, в
котором произошла ошибка, так и привести к отказу
в обслуживании всей системы управления (ICS) или
даже операционной системы. В ряде случаев после
подобного завершения работы восстановление ра-
ботоспособности системы управления штатными
средствами не представляется возможным.

Состояние гонки (Race Condition)

Состояние гонки – ситуация, в которой внутренние


процессы приложения, работающие параллельно,
имеют доступ к некому разделяемому ресурсу (об-
ласти памяти, логическому объекту) и независимо
друг от друга могут производить операции с этим
общим неблокируемым ресурсом. В результате это
приводит к непредвиденному поведению програм- Рисунок 20: Отказ в обслуживании.
мы, выходящему за рамки заложенной в код логики,
что может стать причиной отказа в обслуживании
или предоставить атакующему возможность обхода
ряда программных проверок входных данных.

Уязвимости, приводящие внутренние процессы си-


стемы управления в состояние гонки, как правило,
являются следствием архитектурных ошибок, допу-
щенных при разработке многопоточных приложе- Рисунок 21: Состояние гонки.
ний и организации внутреннего межпроцессного
взаимодействия.

28
XML-инъекции

К уязвимостям XML-инъекции относятся случаи,


когда отсутствует либо некорректно производится
валидация и нормализация входных данных, под-
ставляющихся впоследствии в обрабатываемые
системой XML-документы. Атакующий, имея воз-
можность подключения к токовой петле, направ-
ляет специально сформированный пакет в ответ на
запрос системы, инъектируя в непроверяемые поля
XML-код, обрабатываемый впоследствии парсером.
Подобные уязвимости могут как привести к отказу в
обслуживании системы, так и дать атакующему воз-
можность проведения SSRF-атак на другие элементы
информационной инфраструктуры, доступные в вы-
числительной сети.

Полная статистика уязвимостей приведена в табли-


це 3.

RCE 3
7
DoS 6
2
2
9
Таблица 3: Статистика уязвимостей. Рисунок 22: XML-инъекция.

29
5
Распределение уязвимостей по производителям показано на рис. 23.

by DTM by device

Рисунок 23: Количество уязвимостей у разных производителей.

Интересно также наличие механизмов безопасности


в DTM-компонентах, например, stack cookie, DEP и
ASLR. К сожалению, все это используется лишь в не-
66 0 0 0 которых DTM. В таблице 4 есть подробная информа-
ция.
35 1 0 0

5 0 1 0

1 0 1 1

7 1 1 1

Таблица 4: Механизмы безопасности в DTM-компонентах.

30
5
Решение – FDT 2.0?

Недавно FDT Group наконец представила новую


версию спецификации FDT, v. 2.0. К сожалению, на
данный момент ее поддерживает лишь малая часть
устройств. Основные отличия от 1.2.1, которые могут
повлиять на безопасность:

• Интерфейсы на базе .Net;


• Переработанная архитектура классов;
• Отсутствие XML (взаимодействие между FDT-объ-
ектами основано на типах данных .NET вместо XML).

Эти изменения выглядят неплохо и, несомненно,


должны повысить общий уровень безопасности
FDT-технологий. Однако, определенные проблемы
до сих пор актуальны:

1. Новая версия непопулярна на практике: мы ни разу


не видели компонентов FDT 2.0 на реальных про-
мышленных объектах. Даже в официальном ката-
логе DTM-компонентов (на сайте FDT Group) нет
DTM для FDT 2.0!

2. FDT 2.0 обеспечивает обратную совместимость с FDT


1.2.1 (с помощью (де)сериализации обратно в XML
для работы с FDT 1.2.*). Это может привести к про-
блемам при небрежном использовании.

3. Управляемый код не решает проблему полностью,


если неуправляемый код также по-прежнему
используется. Например, в ходе наших исследо-
ваний мы видели компоненты FDT 1.2 с хорошо
защищенным FDT-фронтендом, но с уязвимым
управляемым кодом на C++ внутри.

К сожалению, мы не смогли найти настоящее устрой-


ство, поддерживаемое FDT 2.0, чтобы протестиро-
вать и его.

31
Выводы и планы на будущее
67
Мы планируем активно работать с производителя-
ми, чтобы исправить все обнаруженные проблемы.
Окончательная информация о найденных уязвимо-
стях выйдет (во всяком случае, мы на это надеемся)
летом/осенью 2015 года, после того, как вендоры
исправят большую часть уязвимостей. Мы не можем
опубликовать более подробные данные сейчас из-за
политики ответственного раскрытия информации.
Одновременно с информацией об уязвимостях мы
планируем опубликовать исходный код всех исполь-
зованных инструментов фаззинга.

В ходе данного исследования мы осуществили фаз-


зинг 114 компонентов и нашли 29 уязвимостей. Если
на вашем промышленном объекте используется
одно из 501 уязвимого HART-устройства, скорее все-
го, вы находитесь в зоне повышенного риска. Вместе
с тем, все эти атаки возможны не только из-за недо-
статков DTM, но и из-за слабой архитектуры АСУ ТП
в целом. Подход к многоуровневым сетям АСУ ТП
нуждается в полной переработке. Иначе уязвимости
такого рода будут возникать снова и снова.

32
67
Благодарности

Благодарим за помощь в подготовке данного иссле-


дования:

• Георгия Носенко
за «особую магию» и неоценимую помощь в обрат-
ной инженерии и разработке PoC-эксплойтов;

• Андрея Абакумова
за помощь в поиске XML-инъекций;

• Федора ‘Alouette’ Савельева


за идеи для фаззинга;

• Александра Попова
за визуальное оформление.

33
О Компании
8
Digital Security – одна из ведущих российских кон- и нерегулярно, в любительском формате. Открытие
салтинговых компаний в области информационной лаборатории Digital Security вывело эту деятель-
безопасности, основанная в 2003 году. Мы предо- ность на профессиональный уровень.
ставляем широкий спектр услуг в области оценки за-
щищенности, в том числе проведение аудитов ИБ и За все время работы лаборатории было обнаружено
тестов на проникновение, подготовку и сертифика- более 400 уязвимостей, что составляет около 0,8%
цию по PCI и PA-DSS, СТО БР ИББС, аудит защищенно- от всех уязвимостей, закрытых в мире, и превышает
сти систем ДБО, SCADA, ERP-систем, бизнес-прило- опыт всех остальных российских компаний в сово-
жений, веб-приложений и платформ виртуализации. купности.

Digital Security является официальным партнером За время работы исследовательского центра было
SAP SE, международным лидером по поиску и ана- проведено более 50 исследований, результатами
лизу уязвимостей в продуктах SAP, а также разра- которых стали различные статьи, отчеты и высту-
ботчиком ERPScan Security Monitoring Suite – ин- пления на конференциях. Так, с 2009 по 2011 год
новационного продукта по комплексной оценке экспертами Digital Security Research Group проводи-
защищенности и проверке соответствия стандартам лось масштабное исследование российских систем
для платформы SAP. Только в 2010 году из 58 уязви- дистанционного банковского обслуживания. В 2012
мостей в продуктах SAP, опубликованных исследо- году специалисты Digital Security Research Group
вателями со всего мира, 19 уязвимостей были об- опубликовали множественные уязвимости промыш-
наружены исследовательской лабораторией Digital ленных контроллеров и SCADA в поддержку проек-
Security. Всего к июню 2013 года лабораторией опу- та BaseCamp. В 2012 году проведено исследование
бликовано 100 уязвимостей в продуктах SAP. С 2010 «Безопасность SAP в цифрах» – первый в мире вы-
года специалисты Digital Security проводят тренинги сокоуровневый обзор актуальных проблем безопас-
по ИБ для SAP Product Security Response Team, с 2013 ности SAP-систем. В 2013 году опубликованы резуль-
оказывают корпорации услуги по повышению защи- таты исследования уязвимостей российских систем
щенности новых разработок SAP. для мобильного банкинга за 2012 год. В истории цен-
тра более 60 выступлений на крупных западных кон-
В 2007 году открылся исследовательский центр ференциях по практической безопасности, таких как
в области информационной безопасности Digital BlackHat, RSA, HackInTheBox и многих других. Кроме
Security Research Group, пользующийся международ- того, специалисты Digital Security Research Group
ным признанием и получивший множество офици- возглавляют проект EAS-SEC, посвященный безопас-
альных благодарностей от таких мировых лидеров ности бизнес-приложений.
индустрии информационных технологий, как Oracle,
SAP, Apache, SUN, IBM, Alcatel и др. Digital Security является членом Технического коми-
тета 362 ФСТЭК России и Технического комитета 122
ЦБ РФ и принимает активное участие в разработке
Исследовательский центр Digital Security стал уни- государственных стандартов защиты информации.
кальным явлением для российского рынка ИБ: ра- Digital Security имеет статус PCI QSA с 2007 года и PA
нее поиск уязвимостей осуществлялся бессистемно QSA с 2010 года.

34
8
В 2009 году компания Digital Security создала PCIDSS.
RU – открытое Сообщество профессионалов в обла-
сти стандарта безопасности данных индустрии пла-
тежных карт (PCI DSS), которое служит для аккуму-
лирования и обсуждения информации о стандарте и
способствует его внедрению и продвижению в сре-
де организаций, формирующих рынок платежных
услуг.

Начиная с 2010 года, Digital Security совместно с Ас-


социацией Российских Членов Европей при офици-
альной поддержке Visa, MasterCard и Совета PCI SSC
проводит единственную в России специализирован-
ную международную конференцию по безопасности
данных индустрии платежных карт PCI DSS Russia,
предназначенную для всестороннего взаимодей-
ствия Совета PCI, международных платежных систем,
консультантов в области PCI и участников индустрии
платежных карт – представителей банковского сек-
тора. С 2014 года конференцию организует партнер
Digital Security – компания «Авангард Центр».

С 2011 года Digital Security проводит ZeroNights –


международную конференцию, посвященную прак-
тическим аспектам информационной безопасности.
Данное мероприятие рассказывает о новых методах
атак и угрозах, показывает возможности для напа-
дения и защиты, предлагает нестандартные методы
решения задач ИБ, собирает экспертов, специали-
стов-практиков по ИБ, аналитиков и хакеров со все-
го мира.

Среди клиентов Digital Security такие компании,


как ОАО «Альфа-Банк», ОАО «АК БАРС» Банк, АО
«КазТрансОйл», холдинг «Металлоинвест», ОАО
«Пивоваренная компания Балтика», Mail.Ru Group,
Commerzbank, SAP SE и многие другие.

35
OOO «Диджитал Секьюрити»
Штаб-квартира
Россия, 115093
Москва, Партийный пер., д. 1, корп. 57, стр. 3
тел./факс: +7 (495) 223-07-86, +7 (499) 277-79-24

Центр R & D
Россия, 197183
Санкт-Петербург, ул. Сабировская, д. 37
тел./факс: +7 (812) 703-15-47, +7 (812) 430-91-30

Электронная почта
• Общие вопросы – info@dsec.ru
• Отдел продаж – sales@dsec.ru
• Отдел технической поддержки – support@dsec.ru
• Пресса – pr@dsec.ru

www.dsec.ru

36

Оценить