SCADA и мобильники

Данное исследование – попытка ответить на некоторые из этих вопросов. Его цель – не только найти ошибки безопасности в мобильных приложениях для АСУ ТП, но и попытаться экстраполировать риски компрометации этих приложений на риски компрометации всей инфраструктуры АСУ ТП. Этот подход отличается от привычного взгляда на оценку безопасности мобильных приложений: уязвимости с традиционно низким уровнем опасности могут подвергнуть АСУ ТП огромному риску, а уязвимости, которые обычно считаются критичными угрозами, наоборот, бывают опасны для АСУ ТП с очень низкой вероятностью.

По результатам исследования было выявлено 50 уязвимостей, среди которых: незащищенные или недостаточно защищенные методы передачи и хранения данных (включая некорректное использование SSL или "самодельные" криптоалгоритмы), удаленная атака на отказ в доступе на клиент и сервер, SQL-инъекции, использование недоверенных входных данных в качестве параметров настройки техпроцесса и др. Эксплуатация этих проблем безопасности потенциально позволяет реализовать ряд опасных атак как на приложение, так и на оператора. В последнем случае реально создать ложное представление о текущем состоянии техпроцесса, что может привести к принятию неверных решений с тяжелыми последствиями для предприятия.

Главное об АСУ ТП

Современные инфраструктуры АСУ ТП имеют сложную архитектуру, состоящую из таких общеизвестных элементов, как серверы, ПК, сетевые коммутаторы, технологии программного обеспечения (.Net, .DCOM, .XML и т.д.), и более сложных компонентов: программируемых контроллеров, передатчиков, силовых приводов, аналоговых контрольных сигналов и т.д. На рис. 1 приведена схема современной инфраструктуры АСУ ТП. Обратите внимание на три ее основных уровня.

1. Нижний уровень, где расположены полевые устройства. Как уже упоминалось выше, они подходят для "грязной" работы: например, они могут контролировать температуру и давление в реакторе, управлять такими операциями, как открытие и закрытие клапанов, включение и выключение насосов и пр. На этом уровне может использоваться множество устройств. Это могут быть низкоуровневые программируемые логические контроллеры (PLC, по определению из Википедии¹: специализированное устройство, используемое для автоматизации технологических процессов). Кроме того, на этом уровне могут находиться передатчики и приводы, управляемые удаленным терминальным устройством (RTU, электронное устройство под управлением микропроцессора, которое переводит физические объекты в сигналы, понятные распределенной системе управления или SCADA-системе, путем передачи телеметрических данных на ведущую систему и сообщений от ведущей диспетчерской системы к контролируемым объектам²). Этот уровень – царство низкоуровневых промышленных протоколов, таких как Modbus, Modbus TCP, HART, Wireless HART, Profibus DP или PA, Foundation Fieldbus H1. Инженеры нижнего уровня АСУ ТП, электрики, техники и другие специалисты работают на этом уровне АСУ ТП.

2. Средний уровень, где можно встретить высокоуровневые PLC, распределенные системы управления (DCS, система управления технологическим процессом, отличающаяся построением распределенной системы ввода-вывода и децентрализацией обработки данных³), системы диспетчерского контроля и сбора данных (Supervisory Control and Data Acquisition (SCADA), программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления⁴) и человеко-машинные интерфейсы (Human-Machine Interface (HMI)), а также такие серверы, как OPC (Open Platform Communications, ранее OLE for Process Control – OLE для управления процессами). Здесь осуществляется вся интеллектуальная деятельность. На основе данных с низших уровней операторы и автоматизированные системы принимают решения и отправляют команды на полевые устройства. Здесь проходит весь процесс автоматизации производства. Операторы, инженеры-технологи, инженеры АСУ ТП, программисты PLC и ПО работают с системами на этом уровне.

3. Верхний уровень осуществляет интеграцию бизнеса и промышленных процессов. Этот слой обеспечивает привязку к корпоративной сети и системам планирования ресурсов предприятия (ERP). На данном уровне расположены различные системы управления активами производства (PAS) и системы управления производственными процессами (MES, предоставляющие нужную информацию в нужное время и показывающие лицам, принимающим решения на производстве, как условия работы цеха могут быть оптимизированы для повышения производительности⁵). Здесь с АСУ ТП работают управленцы и инженерно-технический персонал высшего уровня.

Типы мобильных приложений АСУ ТП и связанные с ними риски

Мобильные приложения для АСУ ТП отличаются разнообразием. Поскольку классификации этих решений (пока) не существует, авторами данного исследования разработана собственная, основанная на отношении приложения к промышленному процессу и его расположении в архитектуре АСУ ТП. Выделено три типа мобильных решений для АСУ ТП (см. рис. 2):

• Пульт управления (1): непосредственно конфигурация/мониторинг/контроль производственного процесса и/или его компонентов. Роли в инфраструктуре АСУ ТП:
  • Конфигурация PLC. Настройка и/или контроль компонентов АСУ ТП: PLC, HMI, подключенных к PLC, RTU и прочего. Мобильное приложение подключается к компоненту АСУ ТП по промышленной сети (нижний и средний уровни инфраструктуры). Оно осуществляет контроль над состоянием компонента или его (пере)настройку. Можно считать его аналогом стандартного переносного терминала, спрятанным внутри Nexus или Xperia. Пример: Siemens LOGO! App.
  • Клиент для SCADA. Контроль над промышленным процессом с помощью SCADA-клиента или виртуального интерфейса для подключения к SCADA. Эти приложения позволяют инженерам-технологам подключаться с телефона или планшета к SCADA-приложению и при необходимости контролировать производственный процесс. Пример: ProficySCADA.
  • Мобильная HMI-панель. HMI-панель внутри мобильного устройства для контроля или управления несколькими промышленными компонентами. Позволяет инженеру формировать (и даже программировать!) HMI-панель и подключать ее компоненты собственно к PLC или другим устройствам через Modbus/TCP, OPC или иные протоколы и интерфейсы. Пример: ScadaTouch Basic (HMI-Modbus).

У всех этих приложений есть одна важная особенность: соединение между приложением и промышленным компонентом происходит в предположительно безопасной среде, где-то на нижних и средних уровнях АСУ ТП. Поэтому отсутствие криптографии, аутентификации и другие "привычные" проблемы не относятся к категории высокого риска. Другое дело, если серверная часть приложения (компонент АСУ ТП) не проверяет корректность вводимых данных (с точки зрения промышленного процесса) или, что еще хуже, имеет уязвимости, эксплуатация которых может привести к DoS или другим последствиям. Кроме того, если такие решения хранят данные в файловом хранилище Android, они не должны разрешать изменять их. Возможно также необычное вмешательство в промышленный процесс: допустим, мобильная HMI-панель сохраняет информацию о приборах, контролирующих те или иные компоненты, на SD-карту. Если злоумышленник сможет каким-то образом изменить эту информацию, например поменять местами компоненты, связанные с двумя разными датчиками, это может привести к ситуации, когда инженер думает, что смотрит на некий датчик температуры, но на самом деле видит состояние совершенно другой части инфраструктуры АСУ ТП.

• Клиент для OPC/MES или система архивации (2): приложения-архиваторы позволяют инженеру или владельцу процесса читать и интерпретировать некоторые сведения из среднего и высшего уровня компонентов АСУ ТП. Данные доступны только для чтения, причем у пользователя даже нет прямого доступа к PLC, HMI или SCADA – только возможность просмотра определенных переменных. В эту же категорию включены и мобильные клиенты для MES-приложений. Они, как правило, используются, чтобы читать данные с сервера архивации или агрегированные данные от MES-системы. Типичное приложение из этой категории – клиент (браузер) для OPC. Он подключается не непосредственно к компонентам АСУ ТП, а к серверу OPC. Соединение обычно происходит на высших уровнях инфраструктуры. Кроме того, подключение может быть выполнено дистанционно. Это значит, что в таком приложении должны быть внедрены механизмы шифрования и аутентификации. Хотя чтение агрегированных данных само по себе не представляет угрозы, эта информация может быть использована злоумышленником для понимания (обратной разработки) промышленного процесса и создания специализированного сценария атаки. Кроме того, если приложение применяется вне заводской сети, появляются новые угрозы, например компрометация телефона инженера или руководителя через уязвимость в приложении. Пример: OPC XML DA Explorer.

• Удаленное управление SCADA (3): приложения, позволяющие удаленно (за пределами заводской сети) отслеживать/контролировать производственный процесс. Хотя для этого пригодны и решения первой категории, разработчики не продвигают и даже не афишируют эту возможность. Для всех приложений этой группы нашлись снимки/схемы/архитектурные чертежи/документы от разработчика, где мобильный клиент используется для удаленного управления снаружи промышленной сети (высшего и низшего уровней). Потенциальные пользователи будут иногда (или всегда) подключаться к промышленному процессу из общедоступных сетей, ненадежных домашних сетей или с помощью сотовой связи. Также неясно, в какой среде такое приложение будет работать на Android и не будет ли там вредоносного ПО, рутованной системы и других факторов риска. Требования к безопасности и надежности для таких приложений самые строгие. Пример: Pro-face Remote HMI.

Пульт управления
1. Отсутствие на стороне сервера проверки данных с точки зрения промышленного процесса. Из-за того, что серверное приложение полностью доверяет данным, которые пришли от оператора, и корректность технологического процесса полностью зависит от действий и команд, которые он отправляет, какие-либо недостатки валидации данных могут привести к серьезным последствиям. При этом в мобильном приложении легче ошибиться в разряде числа или случайно задать отрицательное значение параметра. Неверная интерпретация значений также может привести к отказу в обслуживании как серверного, так и клиентского приложения.

2. Компрометация данных, хранящихся на SD-карте, – многие приложения хранят данные на SD-карте: логи, проекты HMI и другие данные. Соответственно, все они имеют доступ к общей информации. Приложение, установленное из сторонних источников (или поддельное из официального магазина), может читать или модифицировать данную информацию, например изменить интерфейс или функционал мобильного HMI-приложения.

Клиент для OPC/MES или система архивации
1. Возможна компрометация сервера и приложения с помощью перехвата данных, которые поступают от приложения к серверу, поскольку данные приложения находятся уже не в защищенном контуре и передаются по сетям общего назначения (Интернет). Злоумышленник может получить доступ к авторизационной информации, конфигурации конечного устройства, каким-либо сведениям о состоянии системы, а также подменять управляющие команды.

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

3. Отказ в обслуживании клиента и сервера системы может привести к задержкам в информировании.

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

Результаты тестирования

Все найденные ошибки можно разделить на несколько категорий. Ниже будут описаны некоторые из них.

Ошибки аутентификации и авторизации (A&A)
Более 40% всех рассматриваемых приложений имеют проблемы с A&A или контролем доступа.

Отсутствие каких-либо механизмов A&A
Около 30% протестированных приложений позволяют осуществлять чтение и запись данных (или выполнение команд) в системе SCADA без какой бы то ни было проверки подлинности. Как уже отмечалось выше, это может быть связано с низким уровнем риска для приложений пульта управления, но ни на каких других мобильных приложениях такого быть не должно, особенно на удаленных клиентах для SCADA. Тем не менее, эта проблема оказалась самой распространенной. Можно извлечь проекты HMI-панелей, узнать состояние элементов инфраструктуры, систем и процессов, получить сигналы тревоги и т.д. – все это без аутентификации. Такие данные очень полезны для злоумышленника, потому что ему может быть доступна информация о промышленном процессе и возможность его частичного обратного проектирования. И все, что для этого нужно, – знать IP-адрес целевой системы! Кроме того, в некоторых приложениях можно перезаписывать значения и даже выполнять команды! На рис. 3 показана доля приложений, позволяющих осуществлять чтение/запись без аутентификации (приложения для работы с PLC исключены из списка).

Передача учетных данных открытым текстом
Некоторые приложения не используют шифрование или хеширование в ходе процесса аутентификации, и учетные данные передаются открытым текстом. Это может позволить злоумышленнику (если он имеет доступ к каналу через открытую Wi-Fi-сеть, MitM-атаку на Wi-Fi-соединение или GSM-канал) подключиться к системе с полными правами без дополнительных усилий.

Слабые хеши
Одно приложение использует MD5-хеш без "соли", не особенно надежный с учетом современных инструментов брутфорса и скорости работы компьютеров. Разработчики другого решения попытались сделать все "по правилам" и изобрели собственный алгоритм хеширования, который основывается на нескольких символах, операциях и приведении типов. В итоге вариантов хеша было всего 225 (33 000 000). Вероятность конфликта хешей очень высока, и современные системы способны взломать такой хеш за считанные секунды. Как и в предыдущем случае, слабые хеши упрощают жизнь злоумышленнику. Если он перехватит трафик с аутентификационными данными, восстановление исходных данных займет от нескольких секунд (собственный алгоритм хеширования) до нескольких дней (MD5).

Ошибки, связанные с протоколом

Отсутствие криптографии
Все данные между клиентом и сервером передаются в виде открытого текста. Как было показано выше (см. "Передача учетных данных открытым текстом"), это может привести к появлению проблем в случае ненадежного канала. Если злоумышленник способен контролировать канал связи, ему могут быть доступны конфиденциальные данные о процессах и системах. Если он в состоянии подделать ответы от клиента или сервера (атака "человек посередине", MitM), то ему открываются следующие возможности:

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

Некорректное использование SSL/TLS
Одна из основных целей использования SSL – предотвращение атак MitM. Каждое SSL-соединение начинается с процедуры "рукопожатия", где сервер отправляет свой сертификат клиенту. Безопасность SSL/TLS-соединения зависит от правильности осуществления процедуры проверки сертификата. Самый распространенный источник ошибок – неправильная конфигурация этого функционала, например:

• отключение проверки сертификата;
• отсутствие сверки имени хоста с сертификатом;
• отсутствие привязки сертификата (SSL Pinning).

Благодаря этим ошибкам атакующий может скомпрометировать процедуру "рукопожатия" и внедриться в соединение.

Ненадежное хранение криптографических ключей
Как уже упоминалось, критичные данные должны передаваться и храниться в зашифрованном виде. Некоторые приложения имеют проблемы с хранением ключей шифрования. Если злоумышленник получит доступ к ключам, он легко сможет расшифровать трафик или сохраненные данные. 20% приложений с защищенными хранилищами данных используют ключи, жестко заданные во встроенных двоичных файлах или Java-файлах. Несколько примеров ключей: "ZXCVB...", "42@DSOTM#..." и т.д. Это равносильно хранению данных без шифрования.

Ошибки, связанные со SCADA

Недостаточные проверки корректности значений с точки зрения технологического процесса
В некоторых приложениях нет проверок корректности значения переменных с точки зрения технологического процесса на стороне сервера. Пример – возможность установить значение температуры, равное 32 000 или - 1000. Все проверки делаются на стороне клиента. В случае с приложениями класса "пульт управления", которые взаимодействуют с PLC через протокол Modbus, это не страшно. Это предусмотренное поведение, нормальное для Modbus: только оператор отвечает за неправильные значения. Однако есть вторая группа приложений – клиенты для удаленного управления SCADA. Они работают вне доверенной зоны, и, если злоумышленник сможет каким-то образом (с помощью MitM-атаки или несанкционированного подключения) подделать значение в запросе, это чревато серьезной опасностью – например, может привести к сигналу тревоги или технологической неисправности.

Другие ошибки

Незащищенное хранение данных и ошибки целостности данных
Если приложение сохраняет данные на SD-карте, это потенциально может привести к появлению уязвимости. В некоторых случаях другие приложения или вирусы способны получить доступ к данным или изменить их. Кроме того, эти сведения могут быть изменены, когда телефон подключен к ПК. В ходе тестирования мы обнаружили, что некоторые приложения сохраняют на SD-карту конфиденциальные данные, например журналы (которые могут содержать имена пользователей и IP-адреса серверов), настройки подключения или (в случае мобильных HMI) даже файлы проектов. В первых двух случаях злоумышленнику проще будет получить доступ к серверам; последний случай уже был рассмотрен в разделе классификации приложений. Мошенник может изменить конфигурацию проекта, и ничего не подозревающий инженер нанесет вред технологическому процессу, думая, что все делает правильно.

Отсутствие парольной защиты
Применяются ли в приложении механизмы парольной защиты? Если нет, злоумышленник, даже ненадолго получивший контроль над мобильным устройством (например, если инженер оставит разблокированный смартфон на столе на пару минут), сможет изменить конфигурацию PLC или SCADA, получить важную информацию о промышленном процессе или отправить в систему опасные команды. Наличие даже 4-значного пароля способно предотвратить реализацию подобного сценария. Более 70% рассмотренных приложений не имеет никакой парольной защиты.

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

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

Выводы

В ходе исследования было рассмотрено 20 приложений для Android, так или иначе взаимодействующих с инфраструктурой АСУ ТП. Изучены решения для управления PLC, OPC- и MES-клиенты, клиенты для удаленного управления SCADA. Следует отметить, что нами не было найдено ни одного приложения без недостатков и/или уязвимостей. Большинство из них продемонстрировали проблемы с аутентификацией и целостностью данных на локальном или сетевом уровне. Наиболее опасное последствие эксплуатации этих уязвимостей – "компрометация" оператора, которому внушается ложное понимание текущего состояния технологического процесса. Мы описали несколько атак, возможных благодаря таким проблемам безопасности.

SCADA и АСУ ТП пришли в мобильный мир недавно, но они принесли с собой старые подходы и проблемы. Хотелось бы надеяться, что стремительное развитие мобильного ПО будет способствовать скорейшему устранению всех этих проблем.