«Примерно три десятилетия назад мы, специалисты по автоматизации производства, столкнулись с задачей, к которой были плохо готовы. Мы начали внедрять АСУ ТП с возможностью графического отображения хода процессов в реальном времени. Однако вначале экраны были пустыми, и нам надо было заполнить их информацией.У нас не было руководств, в которых можно было бы прочитать о том, что такое «хорошая» графика. Мы делали все что могли, вернее, все что знали – а знали мы немного. Итог был предсказуем – мы создали малоэффективную парадигму человеко-машинных интерфейсов (ЧМИ или англ.: HMI, humane machine interface), вернее того, как они должны выглядеть. Инерция мышления сделала все остальное. В основном ради удобства внедрения, мы решили изображать процессы в виде P&ID (от англ.: process & instrumentation diagram), функциональных схем, дополненных числовыми значениями. Мы придерживались этой парадигмы даже тогда, когда графические возможности систем DCS/SCADA улучшились, и просто мигрировали старые экраны на более новые системы.»
Билл Холлифилд (Bill Hollifield), для InTech.
Исторически так сложилось
Согласно исследованиям, ошибки операторов, наблюдающих и управляющими технологическими процессами, вызывают порядка 42% аварий. Это связано с развитием производства и увеличением автоматизации. При этом оператор, не находясь рядом с реальным оборудования, не имеет возможности оценить его физическое состояние в настоящий момент времени в текущих условиях эксплуатации. Сегодня в современном мире эту функцию выполняют SCADA-системы, основной составляющей которой является человеко-машинный интерфейс (HMI).
Исторически сложилось что под HMI (человеко-машинным интерфейсом) понимали стрелочные приборы, кнопки, переключатели, рубильники и на данный момент сохраняются требования, в соответствии с которыми кнопка аварийного отключения и лампа индикации аварии должны представлять собой реальные физические объекты. Современная панель оператора, состоит из виртуальных кнопок, графиков, аналоговых и цифровых показателей.
Отказаться от физических устройств полностью не представляется возможным по причине соблюдения стандартов безопасности. Потому что это позволяет организовывать физический разрыв в цепи управления и контролировать ситуацию, если виртуальный интерфейс вышел из строя.
Важно понимать, что панель оператора и человеко-машинный интерфейс (HMI) это не одно и тоже. Панель – это всего лишь интерфейс для упрощенного понимания технологии процесса. Большая часть ее современных возможностей и «интеллектуальных способностей» определяется программными средствами. Таким образом, эволюция HMI – это всегда параллельные процессы развития аппаратных средств и программного обеспечения (ПО).
Как показывает практика операторы и диспетчеры не участвуют в процессе создания человеко-машинного интерфейса SCADA-систем. Этот фактор влияет на эффективность работы операторов и количество допущенных им ошибок во время управления технологическим процессом на объектах.
Пассивный подход в области разработки HMI, обусловлен желанием проектировщиков создавать интерфейсы по уже используемым образцам. Эту проблему хорошо иллюстрирует факт использования в данный момент на территории РФ ГОСТа 21480-76 «Система «Человек-машина». Мнемосхемы. Общие эргономические требования», переизданного в ноябре 1986 г. Очевидно, что за последние 30 лет произошли радикальные изменения в уровне и объеме автоматизации технологических процессов, а также в возможностях SCADA-систем. Появились стандарты МЭК 60447-93 «Интерфейс человеко-машинный(ИЧМ), ГОСТ Р МЭК 60447-2000 «Интерфейс человеко-машинный. Принципы приведения в действие»», но они не отражают подход к оптимизации HMI.
Как итог, сегодня тысяч операторов контролируют производства стоимостью десятки миллиардов, разглядывая примитивные картинки, разработанные в то время, когда не имели представления о эффективности HMI.
Как можно улучшить HMI
Как добиться наибольшей отдачи от человека машиного интерфейса это предоставлять информацию, которая важна и в том виде, чтобы ее было интуитивно понятно. Высокоэффективные HMI отображают информацию – данные в определенном контексте, который делает их полезными. HMI должны не только отображать значение тех или иных процессных переменных, но и показывать, «хороши» или «плохи» эти значения. Ненормальные показатели должны четко выделяться. Предоставление информации в Графическом виде процессов позволяет максимизировать эффективность операторов. Процессы необходимо представлять в максимально информативном и способствующем немедленным действиям виде.
В 2009 г. Electric Power Research Institute или EPRI провел масштабное изучение HMI. В итоге исследования был создан отчет, получивший название «Operator Human Machine Interface Case Study: The Evaluation of Existing ‘Traditional’ Operator Graphics Versus High-Performance Graphics in a Coal-Fired Power Plant Simulator, ID 1017637».
На выбранной для проведения исследования ТЭС был специальный симулятор, который использовался более 10 лет. Во время теста несколько операторов обнаруживали и разрешали критические ситуации, используя как уже существующие, знакомые им экраны управления, так и новые, организованные с применением принципов высокоэффективных HMI. Последние существенно улучшили эффективность операторов по нескольким важным параметрам.
До этого теста никому не приходило в голову разработать специализированные экраны для таких сценариев, со всеми инструментами управления необходимыми для выполнения задания. Результаты же теста показали, что новый подход к организации HMI намного эффективнее. Сложные системы управления, как правило, обладают, неэффективными и проблематичными HMI, созданными людьми без специальных знаний. Эффективность операторов может быть очень существенно улучшена с применением HMI, созданных на основе правильных принципов. Высокоэффективные HMI очень практичны, их несложно внедрять, а их цена вполне доступна.
Современные тенденции и стремления HMI
Какой бы современной ни была система управления процессами производства принятия ключевых решений всегда остается за человеком. Удобство, надежность и функциональность во многом определяет успех всей работы АСУ ТП.
Другие требования предъявляемые к автоматизации связаны со сложностью самой технологии процесса в которой задействуется множество различных устройств от разных производителей. Для потребителей здесь на первое место выходит легкость интеграции HMI со всеми разнообразными устройствами, поддержка открытых протоколов связи(чаще всего Ethernet), а так же возможность передачи информации в систему белее высокого уровня и масштабируемость представленных решений.
Однако есть и общие требования к HMI, характерные и для машинной, и для процессной автоматизации. Во-первых, это легкость настройки и адаптации под нужды производства. Во-вторых, возможность создавать собственные, в том числе динамические, объекты и тиражировать их. В-третьих, четкое и ясное отображение информации, независимо от условий окружающей среды и других факторов. Наконец, в-четвертых, возможность быстро и четко управлять системой, независимо от ее текущего состояния, условий окружающей среды и других факторов.
В эпоху смартфонов и планшетов, любой экран воспринимается не только как устройство вывода информации, но и как устройство ввода.
Как уже отмечалось выше, многие инновационные возможности панелей оператора связаны с эволюцией программного обеспечения. Именно от характеристик софта зависят скорость разработки приложений, гибкость настройки.
Обычно аппаратные средства HMI не имеют выраженной отраслевой специфики и определяются наличием сертификатов различных классификационных обществ, таких как МЭК, UL, CSA, EAC, морские BV, GL, и ATEX.
Также адаптировать средства HMI к отраслевым задачам можно за счет использования готовых архитектур – TVDA (Technical validated documented architecture). Благодаря TVDA отпадает необходимость писать громоздкие программы, достаточно ввести параметры для уже готовых архитектур.
Существенно расширить возможности программного обеспечения для конфигурирования панелей можно за счет поддержки сценарного языка программирования JavaScript, который позволяет реализовать практически любую логику.
Один из ключевых трендов рынка средств HMI последних лет – возможность контролировать производственные процессы не только с помощью стационарных панелей, но и с помощью мобильных устройств. Эта функция востребована там, где есть необходимость контролировать удаленное оборудование.
Расширенный вариант позволяет техническому руководителю или инженеру-разработчику на своем мобильном устройстве создавать дополнительные экраны, не связанные с экраном панели оператора. С их помощью можно менять настройки, недоступные на обычных рабочих станциях.
Также современные панели оператора могут взаимодействовать с пользователем на расстоянии, отправляя ему SMS или электронные письма.
Промышленные компьютеры поставляются с установленными операционными системами Windows, SCADA-системами (системами диспетчерского управления и сбора данных) для установки приложений, либо системами HMI или web-интерфейса в зависимости от потребностей пользователя.
Средства HMI остаются неотъемлемой частью системы автоматизации, и должны легко интегрироваться с любыми ее компонентами, зачастую – и с системами верхнего уровня (ERP и MES).
Уязвимость и доступность
Казалось бы, сети на производстве как правило изолированы от сетей общего пользования и внутренних сетей предприятия, оборудование и ПО в них значительно отличаются от обычных сетей, — уж не говоря о том, что все процессы четко регламентированы и строго контролируются.
Рынок SCADA HMI очень активен, но часто не настолько безопасен, насколько это необходимо. Крупнейшими поставщиками HMI в этой отрасли являются Siemens, Advantech и GE, но есть также много мелких игроков во многих других странах. В некоторых случаях небольшая компания покупается до выхода патча его продукта, что затрудняет отслеживание состояния уязвимости в процессе раскрытия информации.
Кроме того, поставщики SCADA систем, как правило, сосредоточены на промышленном оборудование, а не на программном обеспечение, которое им управляет. Потому что они получают прибыль от продажи оборудования.
Когда дело доходит до фактических кодов, лежащих в основе систем SCADA, большинство не использует базовую защиту – in-depth такие как рандомизация размещения адресного пространства (ASLR), SafeSEH, или stack cookies. Это может быть связано с ошибочным убеждением, что эти решения будут работать в полностью изолированной среде.
Несмотря на очевидные риски получения несанкционированного доступа к критическим системам, отрасль развития SCADA-систем нацелена, на производство оборудования и меньше на программное обеспечения. Отсутствие глобальных стандартов для программного обеспечения HMI еще более усугубляет проблемы безопасности в этом поле.
В качестве основы для исследования была использована информация из общедоступных источников, таких как базы знаний уязвимостей (ICS-CERT, NVD, CVE, Siemens Product CERT, Positive Research Center, Trend Micro, Zero Day Iniciative (ZDI) ), уведомления производителей, сборники эксплойтов, доклады научных конференций, публикации на специализированных сайтах и в блогах.
В итоге выявлено 743 уязвимости в АСУ ТП, обнаруженные с 2005 г. по 2012 г., с 2009 по 2012 год количество обнаруженных уязвимостей АСУ ТП u выросло в 20 раз (с 9 до 192). В последние годы (2012—2015) количество обнаруживаемых ежегодно уязвимостей остается стабильным (около 200). По данным 2015 года, лишь 14% уязвимостей устранены в течение трех месяцев, 34% устранялись более трех месяцев, а оставшиеся 52% ошибок либо вовсе не исправлены, либо производитель не сообщает о времени устранения.
По состоянию на 2016 год обнаружено 158 087 компонентов АСУ ТП, доступных в сети Интернет. Наибольшее количество компонентов АСУ ТП доступно по протоколам HTTP, Modbus (RTU и TCP/IP) и Profibus / Profinet, BACnet, занимающие примерно по 33%, OPC (25%). Однако количество обнаруженных уязвимостей зависит от распространенности продукта и от того, придерживается ли производитель политики ответственного разглашения.
Наибольшее количество уязвимостей было выявлено в SCADA-компонентах, а также в компонентах человеко-машинных интерфейсов. Вместе с тем в настоящее время только для 5% известных уязвимостей имеются опубликованные эксплойты. Данный показатель значительно снизился по сравнению с 2012 годом: тогда можно было найти эксплойты для 35% уязвимостей.
Среди всех используемых с АСУ ТП операционных систем с большим отрывом лидирует Microsoft Windows. Чаще всего в глобальной сети присутствуют различные компоненты SCADA-систем (включая HMI). На их долю приходится 70% всех обнаруженных объектов.
Наличие в открытом доступе готового средства для эксплуатации уязвимости или информации о ней значительно повышает вероятность успешной атаки.
Как правило, количество опубликованных уязвимостей коррелируется с количеством опубликованных эксплойтов. В период с начала 2011 года по сентябрь 2012 года было опубликовано 50 эксплойтов — в шесть раз больше, чем за шесть лет с 2005-го по 2010 год.
Впрочем, отсутствие известного способа реализации атаки снижает вероятность нападения, но не исключает его полностью, поскольку кибератаки на промышленные объекты проводятся с привлечением опытных специалистов высокого уровня, которым зачастую попросту не нужны «эксплойт-паки» и прочие популярные инструменты.
Уязвимости, для которых уже есть эксплойт, но еще не выпущено исправление, представляют наибольшую опасность, так как для проникновения в систему злоумышленнику не нужны глубокие знания и длительная подготовка.
Уязвимости HMI отчет за 2016-год
Разработчики решений SCADA часто имеют мало опыта в отношении построения пользовательского интерфейса (UI). Это связано с тем, что разработчики не знают, какова будет конечная операционная среда для систем. Это заставляет разработчиков делать допущения, которые часто неверны. Без полного жизненного цикла разработки кода, программы содержат в себе уязвимости. Разработчики SCADA, продолжают делать те же самые ошибки, которые десять лет назад делали разработчики приложений и ОС.
Эксперты компании Trend Micro проанализировали предупреждения ICS-CERT за период с 2015 по 2016 годы, связанные с HMI уязвимостями, и пришли к неутешительным выводам.
В этом исследовании рассматривается текущее состояние безопасности SCADA HMI. Анализируя все публично раскрытые уязвимости в программном обеспечении SCADA, которые были исправлены с 2015 и 2016 годов, включая 250 уязвимостей, приобретенных в рамках программы Zero Day Initiative (ZDI). Почти треть уязвимостей (36%) связана с переполнением буфера (Buffer Overflow). Данная проблема безопасности позволяет злоумышленнику не только вызвать аварийное завершение или «зависание» программы, что ведет к отказу в обслуживании, но и выполнить произвольный код на целевой системе.
Если же сложить все типы уязвимостей, эксплуатация которых позволяет хакеру запустить выполнение кода (например, переполнение буфера, удаленное выполнение кода), то получится доля около 40% всех уязвимостей. Стоит отметить и большое количество проблем с аутентификацией и управлением ключами (Authentication / Key Management) — почти 23%.
Все эти ошибки можно предотвратить с помощью безопасных методов разработки программного кода. Наконец, мы наблюдаем среднее время между раскрытием ошибки поставщику SCADA и выпуском патча, оно достигает 150 дней, еще 30 дней, потребуется для развертывания программное обеспечение.
Это означает что в среднем пять месяцев до того, как уязвимости SCADA будут исправлены. У некоторых производителей это может занять лишь одну или две недели, пока у более крупных это занимает до 200 дней.
В подразделении Министерства национальной безопасности США, ICS-CERT, поручено снизить риски внутри всех важнейших секторах инфраструктуры путем сотрудничества с правоохранительными органами и разведкой и объединением усилий.
Существует такая интересная программа ZDI которая покупает у людей уязвимости, которые они нашли в различных продуктах. После покупки уязвимости они анализируют данную уязвимость со всеми схожими продуктами конкретной компании в чьем коде есть ошибки. После этого связываются с компанией и представляет уязвимость. По сути это превращается в бизнес. Когда программа ZDI приобретает уязвимости, которые влияют на SCADA, об этом сообщается ICS-CERT для разрешения этой проблемы. В 2015 году ICS-CERT ответило на 295 инцидентов и обработало 486 раскрытие уязвимостей.
Чтобы определить, какие уязвимости преобладают в HMI, рассмотрим результаты по выявлению ICS-CERT за 2015 и 2016 гг., и исправления в течение последних двух лет. Эти данные были объединены с более чем 250 уязвимостями нулевого дня, купленными программой ZDI. Эта информация была также сопоставлена с перечисленными уязвимостями CWE для определения общего числа.
Как выяснилось, 20% исследованных уязвимостей возникали по причине повреждения памяти (переполнение буфера, уязвимости чтения\записи за пределами поля (out-of-bounds read/write) и т.д.
23% уязвимостей возникали в связи с отсутствием механизмов авторизации, 19% проблем были связаны с учетными данными (вшитые пароли, скрытые учетные записи с полными правами, хранение паролей в открытом виде), 9% проблем позволяли внедрение кода.
Рисунок 1: Категории уязвимостей
Несмотря на то, что ожидались некоторые проблемы с межсайтовыми сценариями (XSS) и Cross-Site Request Forgery (CSRF) большинство проблем HMI – это проблемы с Windows, а не веб-приложениями. Некоторые ошибки XSS и CSRF существуют в категории «Другие», хотя их немного.
Проблемы с повреждением памяти
Проблемы с повреждением памяти составляют 20% выявленных уязвимостей. Слабые стороны этой категории представляют собой классические проблемы с защитой кода, такие как переполнение буфера стека и кучи за пределами границ чтения / записи. Повреждение памяти может происходить в HMI, когда содержимое ячейки памяти непреднамеренно изменены из-за ошибок где-то в коде.
Это также можно назвать нарушением безопасность памяти. Когда содержимое поврежденной памяти используется позже в этой программе, сбой или выполнение кода, который не предназначен для запуска.
Повреждение памяти 20.44%
Пример: Advantech WebAccess HMI Solution
В какой-то момент программа ZDI получила 100 отдельных отчетов с использованием продукта Advantech WebAccess HMI за один день. Большинство из этих случаев оказались переполнениями буфера, большинство из которых аналогичны примеру ниже.
Рисунок 2: Панель инструментов Advantech WebAccessОдин интересный момент, заключается в том, что, в настоящее время это решение SCADA, но оно также рекламируется как решение для Internet of Things (IoT). Решение содержит сервис webvrpcs.exe, который выполняется в контексте локального административного пользователя. Служба прослушивает протокол управления передачей (TCP) порт 4592 и может быть доступна по протоколу удаленного вызова процедур (RPC)-based protocol.
Служебные вызовы из приложения предназначены для того, чтобы напоминать Microsoft Windows DeviceIoControl функций. Каждый служебный вызов содержит значение ввода / вывода (IOCTL), которое позволяет использовать таблицы переходов для использования сотен типов услуг. В этом примере параметром является окно имени, которое копируется с помощью функции _sprintf в буфер стека, который равен 0x80 символов.
Областью, отмеченной желтым цветом, является код IOCTL, за которым следует длина буфера (в и из) — размером 0x8c байтов за которым следует завершающий нуль. Поскольку атака помещает 0x8c байтов данных в буфер длиной 0x80 байт, прогнозируемые результаты переполнения. Просмотр уязвимого кода показывает классический вызов _sprintf, который позволяет условия переполнения.
Проверка макета стека показывает, что для WindowName установлено значение -80 с 0 в качестве обратного адреса. С тех пор не был установлен во время этапа компиляции, нет stack cookies, установленных для защиты.
Отсутствие stack cookies, а также других защит, таких как ASLR и SafeSEH, вероятно, связано с тем что первоначальный код, был написан до существования этих методов кодирования. Однако использование запрещенных (API) и отсутствие глубинных мер защиты означает, что злоумышленникeу просто нужно переписать обратный адрес в начало атакующей обратной ссылки (ROP).
Без ASLR не требуется никаких сложностей для выполнения контролируемого злоумышленниками кода при повышенной привилегии. Анализ патча для этой уязвимости также показывает некоторые интересные варианты очистки кода старения баз. Первоначальная функция _sprintf была включена в список API-запрещенных Microsoft выпущенный в 2007 году. Исследователи ZDI ожидали, что Advantech будет внедрять список запрещенных API-интерфейсов и удалять известные плохие функции из его кода. Вместо этого патч для этой ошибки изменил функцию _sprintf на _snprintf функцию.
Однако _snprintf также находится в списке запрещенных API. Хотя _snprintf обеспечивает большую отказоустойчивость к переполнениям чем _sprintf, он не может завершать (нуль-символом) при наличии слишком большого количества символов.
Это означает, что когда стек не очищается ( редкая ситуация ), для злоумышленников становится возможным использование строковых манипуляций на этом WindowName, чтобы обмануть программу, считая буфер длиной 0x80 символов, когда в действительности, буфер длиннее, так как он не завершает нуль.
Из 75 исправлений, выпущенных Advantech, все были точечными исправлениями. Другими словами, поставщик исправил баг, но не устранил глобальные проблемные функции. Тысячи Функции _sprintf и _snprintf остаются в базе кода на сегодняшний день. Advantech не выпустил патчи для оставшихся 25 вопросов, о которых сообщили исследователи ZDI. Эти вопросы впоследствии были раскрыты общественности в соответствии с политикой программы ZDI.
Проблемы управления учетными данными
Проблемы управления учетными данными составляют 19% выявленных уязвимостей. Уязвимости в категории представляют такие случаи, как использование жестко закодированных паролей, сохранение паролей в восстанавливаемых формат (например, чистый текст) и недостаточная защита учетных данных.
Скрытая учетная запись GE MDS PulseNET
General Electric (GE) MDS PulseNET используется для мониторинга устройств и сетей промышленной связи развернутых в секторах энергетики, очистки воды и сточных вод во всем мире. Программа ZDI сообщает, что «затронутые продукты содержат жестко запрограммированную учетную запись с полными привилегиями». Полное расследование привело к раскрытию CVE-2015-6456 с общей оценкой уязвимости Системный (CVSS) рейтинг 9.0.
Взглянем на панель управления пользователя, в ней указывается на существование только двух учетных записей в системе(оператора и администратора). Однако, как отметил Andrea Micalizzi (который также известен под ником «rgod»), существует скрытая третья учетная запись с правами администратора.
Рисунок 3: Панель управления пользователя GE MDS PulseNET
Использование HeidiSQL для извлечения информации из базы данных предоставляет учетную запись «ge_support» с хэш пароля <
Рисунок 4: Панель управления пользователя GE MDS PulseNET после входа в систему
Даже после входа в систему с использованием учетной записи «ge_support» третье имя пользователя не отображается у пользователя панель управления.
Отсутствие аутентификации / авторизации и Небезопасные места по умолчанию
Эта категория представляет 23% уязвимостей SCADA. Она включает множество небезопасных дефолтов, чистый текст в передаче конфиденциальной информации, отсутствие шифрования и небезопасные элементы управления ActiveX, помеченные как безопасные.
Пример использования: Siemens SINEMA Server Небезопасные разрешения файлов
Уязвимость, связанная с привилегией доступа одна из самых часто встречающаяся в продуктах HMI, возникает она, когда компании решают создавать свои собственные списки контроля доступа (ACL) и каталоги верхнего уровня вместо использования стандартных Windows Program Files каталогов.
Вместо того, чтобы надлежащим образом защищать, эти каталоги верхнего уровня, они по умолчанию доступны для записи, и дерево каталогов включает служебные исходные файлы решений. Это позволяет любому локальному пользователю вкладывать новый двоичные файл, который будут выполняться как системная служба в каталоге. Эта проблема проявилась на сервере Siemens SINEMA и была рассмотрена с помощью CVE-2016-6486. Сам продукт установлен в дереве каталогов со слабым ACL. По умолчанию Microsoft устанавливает каталог-Program Files — как защищенный с списками ACL.
Рисунок 5: Командная строка, показывающая стандартные разрешения Program Files
Обратите внимание, что не только административные и специальные учетные записи имеют возможность записывать файлы в это дерево. Пользователи также имеют разрешение на чтение и выполнение. Вместо использования программных файлов или, по крайней мере, тех же разрешений, что и в Program Files, установщик Siemens создает собственное дерево верхнего уровня.
Рисунок 6: Свойства разрешений безопасности для Siemens SINEMA Server
Как видно выше, любой пользователь системы может добавлять и записывать данные в файлы, содержащиеся в этом каталоге. Пользователи также могут добавлять файлы и подкаталоги, что может привести к выполнению кода из-за локализации каталоги. Хуже того, если мы рассмотрим разрешения, в которых находятся программы, результаты подтвердят наше беспокойство.
Как отмечено выделенной строкой, Authenticated Users имеют полный контроль. Для присоединение к проверенной группе пользователей, пользователь должен только аутентифицироваться в домене Windows. По сути, это означает, что почти все в системе будут в группе «Аутентифицированные пользователи». Изучение исходного кода в этом каталоге показывает аналогичные результаты.
Важно отметить, что этот конкретный исходный файл запускает службу, которая выполняется на уровне локальной системы.
Конечный результат этой небезопасной установки по умолчанию позволяет любому аутентифицированному пользователю заменять исходный файл по желанию. Кроме того, этот новый управляемый злоумышленником двоичный файл выполняется в контексте локальной системы после следующей перезагрузке.
Пример: Advantech WebAccess
Advantech WebAccess обеспечивает кросс-платформенный, кросс-браузерный доступ к данным и пользовательский интерфейс основанный на технологии HTML5. Программа ZDI получила сообщение об ошибке, которая позволяла просматривать другие пароли при смене своего пароля.
Отчет ICS-CERT об этой ошибке «Правильно аутентифицированный администратор может просматривать пароли для других администраторов». Мы должны отметить, что это не означает системного администратора. Это относится к администратору SCADA систем. В рамках решения существует скрипт upAdmin.asp, который позволяет администратору SCADA обновлять его имя пользователя, пароль или описание. Сценарий Active Server Pages (ASP) может быть проэксплуатирован кем-либо с разрешения системы.
Рисунок 7: Панель настройки пользователя Advantech WebAccess
Чтобы злоумышленник воспользовался этой ошибкой, он должен сначала войти в известную учетную запись и нажать «Свойство пользователя проекта». Это приведет его к
URL-адресу http:///broadWeb/user/upAdminPg.asp?uname=known&return=bwproj
В этом примере — это IP-адрес системы, и известная учетная запись пользователя. Нападавший затем изменяет имя учетной записи в URL-адресе целевой учетной записи, как в
http:///broadWeb/user/upAdminPg.asp?uname=victim&return=bwproj
Хотя пароль для учетной записи жертвы сначала скрыт звездочками, но просто просматривая HTML-код исходника, на странице отобразится пароль целевого пользователя.
Эта ошибка позволяет аутентифицированному пользователю получить пароль любого другого пользователя, включая администратора SCADA решений.
Проблемы с вводом кода
Как и другие онлайн-сервисы, в области HMI существуют уязвимости, связанные с внедрением кода. Эти проблемы представляют собой 9% выявленных уязвимостей. В то время как обычные типы инъекций — SQL, команды, ОС, существуют инъекции в предметно-ориентированные языки программирования, которые также представляют риск для решений SCADA. Один из них предметно-ориентированные язык, подверженный инъекции — это Gamma, который используется в Cogent DataHub системе.
Что такое предметно-ориентированный язык Gamma?
Продукты Cogent DataHub используют собственный язык под названием Gamma для своего HMI решения. По словам производителя, Gamma является динамически типизированным интерпретированным языком программирования, специально предназначенный для быстрого развития контроля и приложений пользовательского интерфейса. Язык опирается на синтаксис, похожий на C и C ++, но с ряд встроенных функций, которые делают его гораздо лучшим языком для разработки сложных системы реального времени. Gamma также поставляется с полностью документированным API и доступен любому в Интернете.
Пример: Cogent DataHub
По словам производителя, Cogent DataHub представляет собой резидентную базу данных реального времени, которая действует как концентратор, обеспечивающий быструю и эффективную концентрацию и распределение данных для OLE для управления технологическими процессами (OPC) других приложений Windows.
Программа ZDI получила отчет об ошибке, которая позволяет атакующему, включить небезопасный режим обработки на веб-сервере. Это позволяет злоумышленнику отправлять произвольные сценарии на сервер и выполнять произвольный код.
Рисунок 8: Cogent DataHub WebView
Как видно выше, Cogent DataHub обеспечивает промежуточное программное обеспечение в режиме реального времени, которое добавляет визуализацию в комплекс SCADA систем. В этом случае злоумышленник использует недостаток в методе EvalExpression в Gamma для выполнения управляемого злоумышленником кода в целевой системе. Этот метод удаленного доступа через объект Ajax прослушивает TCP-порт 80.
Поскольку Gamma является языком, специфичным для домена, он содержит множество встроенных функций и функций для отрасли SCADA. Однако скрипт также содержит возможность доступа и выполнения системных команд. Именно эта способность может быть нарушена злоумышленником, как видно из уязвимого кода ниже.
Выделенная ошибка принимает выражение и проверяет один флаг, чтобы определить, разрешено ли системе выполнить выражение. Если эта проверка возвращает true, выражение выполняется независимо от того, что оно содержит. Злоумышленник все же должен обмануть систему. К счастью для злоумышленника, система позволяет это также. Чтобы завершить этот эксплойт, злоумышленник должен сначала отправить HTTP-запрос на любой сценарий Gamma, который загружает необходимые библиотеки.
Как уже упоминалось, в то время как разработчики предполагают, что эти системы будут работать на изолированном сети, это часто бывает не так. Злоумышленник использует запрос для вызова AJAXSupport.AllowExpressions и установливает allow_any_expression в значение True. Это позволяет злоумышленнику затем вызвать AJAXSupport.AllowExpressions и передать сценарий, который он хочет выполнить. Этот метод атаки очень надежный и повторяемый. Обзор патча показывает, как Cogent решил решить эту проблему. Слева на изображении ниже показан старый код, а справа — патч-код. Изменения подсвечены.
Рисунок 9: Различия в коде до и после исправления
В первой части патча полностью удалена AllowExpressions. Это предотвращает переключение этого флага в системе. Пока разработчик не удалил EvalExpressions полностью, он сделал комментарий, отметив, что использование метода представляет угрозу безопасности.
Cogent также прокомментировал код нарушения, чтобы он не был установлен по умолчанию. Чтобы включить код, разработчик должен войти и вручную разблокировать метод. Этот метод также делает его маловероятным для повторной ошибки в дальнейшем.
Раскрытие информации
Когда исследователи обнаруживают уязвимости в продуктах SCADA, количество времени, необходимое для исправления ошибки разниться. Это время часто называют окном уязвимости. Исследователи ZDI рассмотрели все уязвимости HMI, полученные через программу (более 250), и провели анализ, как долго они устраняются. Как видно из данных за последние четыре года, среднее время исправления не уменьшается.
С 2013 года среднее время между тем, когда исследователи раскрывают ошибку поставщику и время когда патч выпущен, составляет около 140 дней.
Рисунок 10: Среднее время для исправления уязвимостей с момента их раскрытия по годам
Качество выпущенного патча, также играет определенную роль во времени. Проблемное обновление, применяемое к системе, может привести к отказу в обслуживании (DoS) на критическом участке инфраструктуры. Из-за этих и других проблем, существует отставание между доступностью патча и установкой этого исправления в производственную систему.
Не все поставщики SCADA работают в одних и тех же временных рамках.
Некоторые поставщики реагируют гораздо быстрее чем другие. Например, ZDI проанализировал, что Cogent Real-Time Systems быстро среагировали на указанную уязвимость. У крупных поставщиков — ABB, GE, Indusoft и PTC- в среднем уходит более 200 дней для создания патча.
Рисунок 11: Среднее время для исправления уязвимостей с момента, когда они были раскрыты поставщиком
Сравнение по отраслям
Сравнение по времени отклика производителей SCADA с другими отраслями показывает, что время отклика мало чем отличается от других отраслей. Хотя широко распространенное программное обеспечение крупных поставщиков, таких как Microsoft, Apple, Oracle, Adobe и других имеют среднее время отклика менее чем 120 дней.
В SCADA-системах и безопасности систем автоматики в среднем около 150 дней. Индустрия программного обеспечения безопасности немного быстрее, но не значительно. К категории бизнес-программ относятся предприятий таких компаний, как HPE и IBM. Этим поставщикам требуется значительно больше времени для раскрытия информации об ошибках.
Рисунок 12: Среднее время для исправления уязвимостей с момента их раскрытия промышленностью
Вывод
Примечательно, что за последние четыре года оперативность устранения уязвимостей осталась практически на прежнем уровне — порядка 140 дней. Как отмечается, производители SCADA-систем основное внимание уделяют промышленному оборудованию, а не программному обеспечению, поскольку именно аппаратные средства приносят им большую прибыль.
Доклад также указывает на ошибки, которые совершают компании.К примеру, многие из них устраняют только определенные уязвимости (заменяют уязвимые API, отключают проблемные функции и т.д.), но не более того.
«Производителям HMI и SCADA-решений следует принять во внимание практики безопасности жизненного цикла, реализованные разработчиками ОС и приложений за последние десять лет. К тому же им стоит ожидать, что их продукты будут использоваться не по назначению, например, будут подключены к публичной сети. С учетом наихудших сценариев, разработчики могут реализовать комплексные меры по обеспечению безопасности»,- отмечается в отчете исследователей.
В рамках различных решений SCADA HMI представляет собой самую яркую и самую настоящую цель для нападавших. HMI выступает в качестве централизованного центра управления критичной инфраструктурой. Если атакующий успешно проэксплуатирует уязвимости HMI то он может сделать с самой инфраструктурой все что угодно, включая физическое повреждения оборудования.
Даже если злоумышленники решают не прерывать операции технологического процесса, они все равно могут использовать HMI для сбора информации о системе или отключения предупреждений и уведомлений, предназначенных для оповещения оператора о опасности для оборудования.
В исследовании мы рассмотрели, что большинство уязвимостей HMI делятся на четыре категории: повреждение памяти, управление учетными данными, отсутствие аутентификации / авторизации и небезопасные значения по умолчанию. Все эти ошибки можно предотвратить с помощью безопасных методов разработки программного кода.
Мы также заметили, что среднее время между тем, когда исследователи раскрывают ошибку поставщику SCADA и время, когда патч выпущен доходит до 150 дней, еще 30 дней, для таких поставщиков, как Microsoft или Adobe, но на 43 дня меньше, чем предложения предприятий от таких компаний, как HPE и IBM.
Принимая во внимание вектор атак на HMI, SCADA системы, где уязвимость является эффективной точкой входа в систему, надеемся, что владельцы SCADA и администраторы знают о обнародованных уязвимостях и соответственно пытаются блокировать угрозу. Разработчикам решений HMI и SCADA было бы полезно принять на вооружение безопасные методы жизненного цикла разработки программного кода, как это уже десятилетие делается разработчиками ОС и приложений.
Принимая простые шаги, такие как аудит для использования запрещенных API, поставщики могут сделать свои продукты более устойчивыми к атакам. SCADA разработчики также должны ожидать, что их продукты будут использоваться не в идеальных системах. Например, несмотря на то, что это считается плохой практикой в области безопасности, разработчики должны взять на себя ответственность за свою продукцию и решения и понимать, что их системы будут подключены к сети общего пользования.
Принимая такой подход, который предполагает худший сценарий использования продукта, разработчики должны внедрять более глубокие меры защиты. Вредоносные программы, специально предназначенные для АСУ ТП, существуют и активно нацелены на HMI.
Ошибки в системах SCADA, скорее всего, будут с нами еще много лет. Работая совместно, безопасность этих систем будет продолжать улучшаться. В то время как полностью безопасная система, вероятно, никогда не будет создана. Усиления исследования и разработки в области программного кода для HMI будет нашим лучшим шансом сдерживать атакующих до тех пор, пока это необходимо.