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

Иван Юшкевич, Александр Большев

Введение

Сегодня мобильные технологии – неотъемлемая часть нашей жизни, и иногда проникают туда, где их не следовало бы использовать. Удобство часто оказывается важнее безопасности. Сейчас можно отслеживать состояние АСУ ТП (автоматизированной системы управления технологическим процессом) или даже управлять ей с новенького смартфона на Android или iOS. Поищите "HMI" (человеко-машинный интерфейс), "SCADA" (система диспетчерского контроля и сбора данных) или "PLC" (программируемый логический контроллер) в магазине Google Play, и вы удивитесь количеству результатов. Более того, многие из этих приложений разработаны серьезными производителями: Siemens, GE, Omron и т. д., и обеспечивают доступ, контроль и управление HMI, PLC, DCS (распределенная система управления) и SCADA-системами в инфраструктуре АСУ ТП. Безопасны ли они? Может ли злоумышленник нанести вред, получив доступ к планшету инженера-технолога? Какие уязвимости существуют в этих приложениях? Какие векторы атак возможны?

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

В ходе исследования, мы протестировали 20 приложений для смартфонов на базе Android. В наш список попали продукты Siemens, GE, Schnieder Electric, Movicon, Autobase и др. Приложения мы разделили на три группы: работающие внутри безопасного периметра (мобильные HMI, клиенты SCADA-систем, приложения для конфигурации PLC); взаимодействующие с агрегированными данными о состоянии системы АСУ ТП (клиенты MES, OPC или журналирующих сервисов) и решения для удаленного доступа (remote endpoint). Как ни парадоксально, приложений последней группы довольно много в Google Play Store. Для всех решений такого типа вендоры предлагают (в виде примеров использования, типовых архитектур и решений и.т.п.) использовать удаленное соединение смартфона со SCADA-системой через незащищенные (e.g. Internet) каналы связи.

Рекомендуем почитать:

Xakep #304. IP-камеры на пентестах

• Содержание выпуска
• Подписка на «Хакер»-60%

К каждой из трех групп мы предъявляли разные требования безопасности. Очевидно, что риск использования приложения с уязвимостями в защищенном периметре меньше, чем риск применения уязвимого SCADA-клиента через Internet. Мы оценили защищенность решений с точки зрения OWASP Top 10 Mobile Risks, добавив проверки на DoS и защищенность интерфейса паролем. Еще один парадоксальный результат заключается в том, что в приложениях удаленного доступа было найдено больше уязвимостей и слабостей, чем в сумме по двум остальным группам. Это недопустимо для приложений, работающих через незащищенные каналы связи.

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

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

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

Прежде чем перейти к описанию мобильных приложений для АСУ ТП и связанных с ними угроз, необходимо сделать краткое введение в современные инфраструктуры АСУ ТП. Это общий термин, объединяющий программные и аппаратные комплексы, используемые в автоматизации промышленности, включая распределенные системы управления (DCS), системы диспетчерского контроля и сбора данных (SCADA), программируемые контроллеры (PLC), человеко-машинные интерфейсы (HMI), системы управления производством (MES) и т. д. Сегодня каждая фабрика, завод, бизнес-центр и даже жилые дома контролируются АСУ ТП в том или ином виде. Согласно общему определению, АСУ ТП осуществляет сбор данных с удаленных станций, обрабатывает их и использует автоматизированные алгоритмы или управляемую оператором программу-диспетчер для создания команд, которые затем отправляются на удаленные устройства (или «полевые устройства»). Первые инфраструктуры АСУ ТП появились в 1970–1980 годах. Для таких систем характерны редкие обновления и замедленный технологический прогресс. Однако в последнее десятилетие современные технологии, включая XML, .Net, JSON и т. д., стали использоваться в АСУ ТП все чаще. Конечно, мобильные приложения тоже не остались в стороне.

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

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

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

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

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-карту. Если злоумышленник сможет каким-то образом изменить эту информацию, например, поменять местами компоненты, связанные с двумя разными датчиками, это может привести к ситуации, когда инженер думает, что смотрит на некий датчик температуры, но на самом деле видит состояние совершенно другой части инфраструктуры АСУ ТП.

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

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

Пульт управления

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

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

Клиент для OPC/MES или система архивации

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

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

Удаленное управление SCADA

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

3. Методика тестирования

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

Наш контрольный список:

1. Аутентификация
   • Есть ли в приложении аутентификация или оно позволяет общаться с сервером/PLC/и т. д. без учетной записи и пароля?
   • Какой информацией в ходе аутентификации обмениваются мобильное приложение и сервер/PLC/и т. д.? Как организован процесс аутентификации? Какой протокол используется, есть ли какие-либо механизмы шифрования?
2. Защищено ли приложение паролем (который так или иначе ограничивает доступ к его функционалу)? Например, если пользователь потеряет свой смартфон (или он будет украден) с установленным мобильным клиентом для SCADA и им завладеет злоумышленник, что могло бы помешать ему сразу же подключиться к SCADA/PLC/и т. д.? Если защита паролем не установлена по умолчанию, можно ли ее включить?
3. Где и как хранятся пароли/строки подключения?
   • В shared_preferences или на SD-карте?
   • Есть ли какое-либо шифрование/хеширование/другие криптографические примитивы? Допустим, злоумышленник получил полный доступ к смартфону или к файлам конфигурации (например, с помощью вируса или утечки данных через другие каналы, такие как иное приложение или уязвимость платформы) – как быстро он доберется до критичных данных?
4. Какие разрешения необходимы приложению? При установке того или иного приложения запрашивается разрешение на доступ к конкретным возможностям или информации на устройстве. Например, доступ к данным на SD-карте, беспроводный доступ в Интернет, доступ к SMS-сообщениям и звонкам и т. д. Эта опция может быть полезна, если приложение удастся скомпрометировать. Каковы будут последствия для других клиентов на устройстве? Кроме того, анализ этих прав доступа может подсказать, собирает ли приложение дополнительные сведения с телефона (ненужные для работы).
5. Содержат ли приложение нативный код? В отличие от Java, нативный код потенциально опасен такими проблемами, как переполнение буфера, использование освобожденной памяти и другие уязвимости.
6. Есть ли в приложении веб-компоненты? Неправильное использование таких элементов может привести к появлению веб-уязвимостей. Таким образом, следует провести специальные веб-проверки для этих приложений.
7. Каково основное назначение приложения и какие протоколы используются – SCADA/HMI/PLC/OPC/и т. д.?
8. Есть ли cookie/токены и т. д.? Есть ли в запросах от приложения те или иные идентификаторы? Где именно происходит аутентификация – на сервере или в самом приложении?
9. Использует ли приложение SSL? Необходимо проверить конфигурацию SSL. Например, проверяет ли приложение корректность сертификата, использует ли привязку сертификата (SSL Pinning)? Это позволит понять, можно ли выстроить атаку конкретно на SSL (например, если SSL-протокол настроен с ошибками, можно ли использовать их для атаки MitM?).
10. Использует ли приложение XML?
    • Какой парсер используется для обработки XML-данных?
    • Как он сконфигурирован? Эта информация позволяет определить, возможно ли реализовать атаки, связанные с XML.
11. Какие данные хранит приложение? Строки подключения к серверу, файлы HMI-проектов, журналы и другие данные, которые могут быть интересны злоумышленнику. Какой формат используется для хранения информации? Шифруются ли данные? Легко ли получить к ним доступ?
12. Какие серверные API доступны приложению? Другими словами, какие функции и возможности доступны для приложения, когда оно взаимодействует с сервером?

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

Фаззинг: в некоторых случаях, если приложение использовало двоичный протокол, сложный для обратного проектирования или понимания, мы искали уязвимости с помощью мутационного фаззинга. На рис. 3 изображена фаззинговая архитектура, которую мы использовали. Приложение подключается к серверу (PLC, SCADA, MES, OPC и т. д.) через прозрачный прокси-сервер (transparent socket proxy). Проходящие через него данные периодически мутируют. Например, данные, передающиеся от клиента к серверу, мутируют с вероятностью 5 % или 25 %. Так мутационные фаззинговые проверки встраиваются в нормальный поток данных, и это позволяет нам проверить, как случайные участки протокола анализируются обеими сторонами.

Поскольку мы имеем дело с мобильной средой, автоматизированный фаззинг клиентских приложений затрудняется. Есть еще одна проблема: некоторые из исследуемых приложений имеют встроенные компоненты интерфейса. Из-за этого бывает невозможно использовать автоматизированные инструменты тестирования UI, чтобы эмулировать нажатия на кнопки управления в приложении для отправки/приема данных с сервера. Для решения этой проблемы мы разработали специальный инструмент – AndroidNUITst (Android Native UI TeSTer). Он состоит из двух компонентов: Java-приложение, которое использует adb и библиотеку Android UIAutomator, чтобы эмулировать нажатия на экран и захватывать снимки экрана; и Erlang-служба, которая применяет тестовый сценарий для запуска тех или иных функций приложений и обнаружения сбоев.

В таблице ниже перечислены все протестированные мобильные приложения.

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

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

Ошибки аутентификации и авторизации (A&A)

Более 40% всех рассматриваемых приложений имеют проблемы с A&A или контролем доступа.

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

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

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

Другие ошибки аутентификации. Кроме того, мы нашли ряд других ошибок аутентификации: например, один клиент для удаленного управления SCADA требует для аутентификации имя пользователя (а пароль в ходе сессии не передается вовсе).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сводная таблица по всем уязвимостям:

5. Примеры уязвимостей и атак

В этом разделе представлены некоторые примеры уязвимостей и возможных атак на их основе. Конечно, мы не можем раскрывать слишком много подробностей, так как ряд разработчиков еще работает над исправлениями. Некоторые детали мы скроем, но опишем эти ошибки в общем виде.

Атака 1: эксплуатация недостаточных проверок параметров технологического процесса на стороне сервера

Для использования этого вектора злоумышленник должен:

• Подключиться к сети, где расположен целевой клиент/сервер (в случае приложений класса «пульт управления»);
• Знать конечную точку удаленного управления SCADA (адрес сервера) и иметь действительные учетные данные для входа в систему.

Для перехвата трафика от клиента к серверу злоумышленник может организовать ARP-спуфинг в публичной сети, к которой подключен клиент, с целью перенаправления трафика через свой хост. Если это частная Wi-Fi-сеть, можно скомпрометировать ее (подобрав ключ или воспользовавшись каким-либо другими уязвимостями, например, если сеть защищена WEP) и перехватывать трафик пользователя. Также можно создать поддельную точку доступа или реализовать атаку типа Karma, заставив пользователя подсоединиться к этой точке доступа с целью перехвата данных.

Для атак, связанных с WI-Fi, могут применяться различные технические средства и ПО – начиная от специализированных устройств (рис. 5) и заканчивая обычными модемами под управлением ПО.

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

Пример: потенциальная жертва подключается через смартфон к общедоступной Wi-Fi-сети (в ресторане или в торговом центре). Если шифрования нет (или оно слабое и уязвимое), злоумышленник может осуществить MitM-атаку и внедриться в соединение с сервером (с помощью, например, ARP-спуфинга). Когда легитимный запрос отправится к системе, злоумышленник сможет изменить его. Результат наверняка удивит (см. рис. 6).

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

GET /scgi/?c8785. <removed>=26999& HTTP/1.1
Cookie: sessionid=98aec9bc19d2bed32d3cc9a1140920e2
Host: <removed>
Proxy-Connection: close
Connection: close

Атака 2: Компрометация базы данных HMI

К данным, которые хранятся на SD-карте, можно получить доступ следующим образом:

• Через приложение, которое имеет доступ к SD-карте;
• Благодаря вирусу на устройстве;
• Любая уязвимость платформы или стороннего приложения. То есть, скомпрометировав стороннее приложение, которое не имеет отношения к целевому мобильному приложению, можно также получить доступ к SD-карте и модифицировать данные (см. рис. 7).

Как мы упоминали ранее, ряд приложений сохраняет базу данных HMI (электрические цепи, интерфейсы, параметры соединения, HMI-проекты) на SD-карте. На рис. 8 показано, как это может выглядеть на смартфоне.

На рисунке видно, как выглядит реальный HMI-проект. Это приложение перемещает некоторую жидкость из одной емкости в другую. Для контроля процесса предназначены кнопки Start/Stop и датчик потока (рис. 9).

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

Теперь ОБЕ кнопки запускают технологический процесс. Конечно, можно надеяться, что физические или низкоуровневые регуляторы предотвратят опасность, но атака по крайней мере приведет к сигналу тревоги или даже к технологической неисправности.

Пример уязвимости 1: слабая функция хеширования пароля

Мы уже обсудили слабые функции хеширования в мобильных приложениях. Вот образец:

Максимальное результирующее значение такой функции – 2₂₅sub> значений. Потенциальный злоумышленник может взломать такой хеш «грубой силой» без особых трудностей.

Пример уязвимости 2: отказ в обслуживании

В ходе анализа мы обнаружили несколько уязвимостей, способных привести к реализации атаки на отказ в обслуживании. В одном из приложений потенциальный злоумышленник может вывести из строя мобильный бэкенд и не позволить оператору получать доступ к данным о технологическом процессе и управлять им (рис. 11):

Другая уязвимость типа «отказ в обслуживании» связана с мобильным приложением. Если оно используется для периодического запроса/получения уведомлений о статусе процесса, то злоумышленник, вызвав отказ в обслуживании, может лишить оператора важного источника информации. Оператор, привыкший получать сообщения в случае состояния тревоги или отказа, может не заметить проблемы, что приведет к тяжелым последствиям. Пример отказа в обслуживании мобильного приложения приведен на рис. 12.

Пример уязвимости 3: Хранение и передача данных в открытом виде.

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

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

6. Выводы

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

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

7. Благодарности

Это исследование не вышло бы без помощи многих людей, и мы хотели бы упомянуть о них. Спасибо:

• Дмитрию 'D1g1' Евдокимову за «особую двоичную магию» и неоценимую помощь в обратной инженерии нативного ARM-кода;
• Марине Кротофил за идеи угроз и рецензирование работы;
• и Александру Попову за отличную фоновую картинку для презентации.