[Информационная безопасность, Исследования и прогнозы в IT] Трудности перевода: уязвимости шлюзов промышленных протоколов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Языковой барьер существует не только между айтишниками и пользователями. «Умные» производства и компьютеры, управляющие ими, также не способны общаться между собой без переводчиков — специализированных шлюзов промышленных протоколов. В этом посте мы расскажем о слабых местах шлюзов протоколов и о том, как злоумышленники могут использовать их, чтобы нанести вред предприятиям.
Шлюз протоколов — небольшое устройство, обеспечивающее критически важную трансляцию команд между станками, датчиками, различными исполнительными механизмами и компьютерами, на которых работают заводы, плотины, электростанции и промышленные предприятия. Эти шлюзы напоминают домашние роутеры: они также имеют несколько интерфейсов, подключённых к разным сетям, и точно так же уязвимы для различных атак. Если такое устройство выйдет из строя, связь между системами управления и машинами прекращается. Операторы не будут видеть, что происходит. По сути, они даже не смогут определить, работают ли машины, турбины или генераторы в безопасном режиме. Даже если что-то явно не так, неисправность шлюза не позволит оператору отдать команду на запуск или остановку процессов.
Подобная ситуация имела быть в декабре 2015 года во время атаки на украинскую электросеть: злоумышленники получили доступ к центру управления электросетями и отключили шлюзы протоколов на подстанциях, загрузив на них повреждённую прошивку. Это заблокировало все попытки инженеров энергосистемы восстановить работу, поскольку команды от систем управления на замыкание автоматических выключателей не могли быть переданы.
В отчёте об инциденте, составленном SANS ICS (подразделение американской образовательной и исследовательской организации SANS Institute по изучению индустриальных систем управления) и Центром анализа и обмена информации в области электроснабжения (E-ISAC — структура, объединяющая участников рынка электроснабжения Северной Америки), повреждение прошивки шлюзов протоколов назвали «взрывом мостов». Это очень точно описывает произошедшее, поскольку злоумышленники уничтожили ключевое звено — трансляторы, которые как раз и выступают в роли моста между контроллерами и подстанциями.
Структура взаимодействия сети управления и сети исполнения. Источник (здесь и далее, если не указано иное): Trend Micro
Из-за своего расположения шлюз протокола может стать самым слабым звеном в цепочке устройств промышленного объекта, а злоумышленник может напасть на такие устройства по двум важным причинам:
1. Шлюзы вряд ли попадут под инвентаризацию критически важных активов, которые будут контролироваться агентом безопасности или системой регистрации. Следовательно, меньше вероятность того, что атака будет замечена.
2. Проблемы трансляции трудно диагностировать, поэтому ошибки в проектировании шлюзов протоколов позволяют продвинутым злоумышленникам проводить очень скрытые атаки.
Виды шлюзов
По режиму работы можно выделить два семейства шлюзов:
1) шлюзы реального времени (Real-time gateways) пересылают трафик по мере поступления — каждый входящий пакет сразу же оценивается, переводится и пересылается; представители: Nexcom NIO50, Schneider Link 150, Digi One IA;
2) станции передачи данных (Data Stations) — работают асинхронно, используя таблицу соответствия интерфейсов, — не ждут запроса на чтение для получения данных от подключённого ПЛК, а регулярно запрашивают у него ПЛК обновления состояний и хранят полученные данные во внутреннем кэше для выдачи по запросу.
Вторая важная характеристика шлюзов протоколов — тип протоколов, которые они поддерживают и преобразуют. По этому свойству устройства можно сгруппировать по трём категориям:
1) шлюзы, которые транслируют внутри одного протокола, например, Modbus TCP в Modbus RTU, — в терминах обычного перевода это подобно переводу разговорного английского языка на английский язык, записанный с помощью шрифта Брайля;
2) шлюзы, которые выполняют трансляцию между различными протоколами внутри одного физического уровня, например, Modbus RTU → Profibus, — оба протокола последовательные, это можно сравнить с переводом письменного текста с немецкого на английский язык;
3) шлюзы, транслирующие команды между разными протоколами и физическими уровнями, например, Modbus TCP → Profibus, — аналог перевода с английского устного на немецкий текст, записанный с помощью шрифта Брайля.
В исследовании Lost in Translation: When Industrial Protocol Translation Goes Wrongмы изучали уязвимости шлюзов первой группы. Для этого мы собрали тестовый стенд, состоящий из следующих компонентов:
• фаззер, который генерирует входящий трафик для тестируемого шлюза — например, при тестировании трансляции с Modbus TCP на Modbus RTU, fuzzer генерирует тестовые случаи Modbus TCP,
• шлюз — изучаемое устройство,
• симулятор — устройство, имитирующее приёмную станцию, например, ПЛК, реализующий Modbus RTU ведомого устройства, — он необходим, потому что некоторые шлюзы протоколов могут работать некорректно, если в цепочке нет ведомого устройства,
• сниффер, собирающий информацию об исходящем трафике, т. е. о транслируемом протоколе,
• анализатор входящего и исходящего трафика.
Структурная схема тестового стенда для изучения уязвимостей шлюзов протоколов
Реальный тестовый стенд
Для моделирования основного узла Modbus мы использовали открытое программное обеспечение QmodMaster, а для моделирования ведомого устройства — pyModSlave, адаптировав его для наших потребностей, таких как получение данных из /dev/ttyUSB0.
Для перехвата трафика мы использовали Wireshark для Modbus TCP и IONinja для Modbus RTU. Мы написали специальные парсеры для преобразования вывода этих двух программ в общий синтаксис, понятный нашему анализатору.
Фаззер мы реализовали на основе BooFuzz, добавив в него некоторые модули проекта Boofuzz-modbus, распространяемого под лицензией Apache. Мы сделали фаззер портируемым для различных протоколов ICS, и использовали его для тестирования нескольких реализаций Modbus.
Вот некоторые разновидности атак, которые мы обнаружили, изучая различные шлюзы протоколов:
• атака на транслятор протокола,
• повторное использование учётных данных и дешифровка конфигурации,
• амплификация трафика,
• эскалация привилегий.
Атака на транслятор протокола
Шлюзы реального времени транслируют пакеты из одного протокола в другой, заменяя заголовки исходного протокола на заголовки целевого протокола. Шлюзы разных производителей по-разному обрабатывают некорректные пакеты. Некоторые из них, например, при получении пакета с неверно указанной длиной, вместо корректировки длины или сброса транслируют его как есть. Эта особенность позволяет тщательно спроектировать пакет неправильной длины для Modbus TCP так, чтобы после трансляции в Modbus RTU он сохранил корректность. При этом если читать его как Modbus RTU пакет, он будет иметь совершенно другое значение по сравнению с Modbus TCP эквивалентом.
Атакующий пакет: в Modbus TCP он содержит команду чтения регистра, но в Modbus RTU это уже команда записи нескольких битовых ячеек
При разборе этого пакета с семантикой Modbus TCP, он интерпретируется как команда на чтение входного регистра (Function Code 04) из блока с ID=3. Но в семантике Modbus RTU, он интерпретируется как запись нескольких битовых ячеек (Function Code 15 и 0F) в блок с ID=1.
Данная уязвимость является критической, поскольку совершенно невинный запрос на чтение превращается в команду на запись из-за того, что шлюз протокола неправильно обрабатывает пакет. Продвинутый злоумышленник может использовать эту уязвимость для обхода специализированного межсетевого экрана для промышленных сетей, который блокирует команды на запись с IP-адресов, не входящих в белый список.
В результате всего одной команды достаточно, чтобы, например, отключить датчики контроля работоспособности и безопасности двигателя (датчик температуры и тахометр), оставив при этом двигатель включённым. Если инженеры и операторы не заметят этого, двигатель может уже перейти в критический режим и выйти из строя, однако никто об этом не узнает, поскольку термометр и тахометр были деактивированы.
Повторное использование учётных данных и дешифровка конфигурации
Шлюзы Moxa используют проприетарный протокол при общении с программой удалённого управления MGate Manager. При запуске MGate Manager инженеру предлагается ввести имя пользователя и пароль для доступа к шлюзу протокола, после чего McGate Manager автоматически сбрасывает конфигурацию, чтобы пользователь мог изменить настройки. Когда полевой инженер завершает настройку шлюза протоколов и нажимает кнопку «Выход», конфигурация сжимается, шифруется и загружается в шлюз.
Этапы настройки конфигурации шлюзов Moxa
В этой процедуре есть два недостатка в области безопасности, которыми можно злоупотреблять.
— Повторное использование
Когда инженер входит в систему, в MGate Manager передаётся ключ для хэширования пароля. Однако в исследованной прошивке механизм реализован таким образом, что хакер может перехватить зашифрованный пароль инженера для входа в систему, а затем с его помощью залогиниться с административными привилегиями, даже не зная пароля в виде текста.
— Дешифровка конфигурации
Зашифрованная конфигурация, передаваемая по сети, содержит ключ шифрования, что позволяет хакеру сделать дамп и расшифровать её.
Зашифрованная конфигурация содержит AES-ключ для её расшифровки. Очень удобно для взлома
Для расшифровки мы использовали проприетарную библиотеку расшифровки, извлечённую из прошивки устройства. Конфигурация содержит файлы настроек,, базы данных SQLite и ключ Secure Shell (SSH). Ниже приведён пример расшифрованной конфигурации нашего собственного протокольного шлюза, которую нам удалось перехватить.
Расшифрованные конфигурационные файлы шлюза Moxa MGate 5105
Амплификация трафика
Поскольку станции данных асинхронно транслируют между собой протоколы, можно объединить несколько запросов типа «запись одного бита» в один запрос, чтобы более эффективно использовать последовательную шину. Например, хакер может вызывать функцию 15 (запись нескольких битов), на станции данных она будет преобразована в 1 запись для ID=2, 1 на ID=4, 1 на ID=5, 1 на ID=6. Таким образом, одна запись на Modbus TCP превращается в четыре записи на Modbus RTU, вызывая небольшие перегрузки на последовательной шине.
Одна TCP-команда на запись ячейки превращается в четыре RTU-команды
Следует отметить, что такое усиление не вызовет отказ в обслуживании (DoS), однако перегруженная шина RS-485 все же может привести к аномальному поведению.
Эскалация привилегий
На шлюзе MGate 5105-MB-EIP мы обнаружили уязвимость эскалации привилегий CVE-2020-885, которая позволяет непривилегированному пользователю выполнять команды с повышенными привилегиями.
Источник проблемы — отсутствие фильтрации ввода пользователя в веб-интерфейсе утилиты Ping.
Интерфейс утилиты Ping шлюза Mgate
Обладая минимальными техническими знаниями, непривилегированный пользователь может запустить демон Telnet в контексте пользователя root с помощью простого HTTP GET-запроса и получить полный удалённый доступ с рутовым шеллом.
Наши рекомендации
Изучив особенности работы различных шлюзов промышленных протоколов, мы выработали ряд рекомендаций для поставщиков, установщиков или конечных пользователей.
1. Устройства разных производителей по-разному обрабатывают недействительные пакеты. Некоторые из них не обладают адекватными возможностями фильтрации пакетов или ведут себя непредсказуемо. В связи с этим при выборе продукта следует в обязательном порядке учитывать эти функциональные аспекты.
2. Используйте специализированный брандмауэр для промышленных протоколов — он обнаруживает пакеты, которые не соответствуют стандартам протокола, и обеспечивает административный доступ к шлюзам протокола только с авторизованных конечных точек. Наличие ICS-брандмауэра помогает обеспечить целостность трафика. В линейке продуктов Trend Micro есть соответствующее решение — TXOne Networks, обеспечивающее защиту в режиме реального времени для сетей OT и критически важных устройств.
3. Выделите достаточное количество времени на настройку и защиту шлюза, особенно это важно для станций обработки данных — слишком велика цена ошибки при настройке таблицы отображения ввода/вывода, которая может предоставить злоумышленнику платформу для проведения незаметных атак. Отключите ненужные сервисы и включите шифрование везде, где оно поддерживается, например, в облачной интеграции MQTT.
4. Рассматривайте шлюзы протоколов как критический актив OT и применяйте к ним соответствующие процедуры управления безопасности, включая аудит настроек и своевременную установку обновлений прошивок.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-эмиграция, Интерфейсы, Информационная безопасность, Хранение данных] Как плохо спроектированный UX у теста на коронавирус чуть не посадил нас на самоизоляцию, но дырка в безопасности спасла
- [Информационная безопасность] Битва за Фаервол: IT Battle производителей Next Generation Firewall
- [IT-инфраструктура, Информационная безопасность, Исследования и прогнозы в IT, Реверс-инжиниринг] Loki 1.8: досье на молодой и подающий надежды Data Stealer
- [Информационная безопасность, Программирование] Безопасность через неясность недооценивается (перевод)
- [IT-инфраструктура, Законодательство в IT, Информационная безопасность] IaaS 152-ФЗ: итак, вам нужна безопасность
- [Информационная безопасность] Molto-2 — a USB programmable multi-profile TOTP hardware token
- [Удалённая работа, Транспорт, Исследования и прогнозы в IT] Удаленная работа с начала коронавируса сэкономила американцам $91 млрд на транспорте, или около $2000 на человека (перевод)
- [CTF, Занимательные задачки, Информационная безопасность, Карьера в IT-индустрии] «Очная ставка» NeoQUEST-2020: максимальное погружение в кибербезопасность
- [Информационная безопасность, Софт] Регистратор доменов Subreg/Gransy подвергся атаке, большинство его сервисов не работают (перевод)
- [Информационная безопасность, DevOps] Трек DevSecOps — тест безопасности на DevOpsConf Live 2020
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_issledovanija_i_prognozy_v_it (Исследования и прогнозы в IT), #_trend_micro, #_shljuzy_protokolov (шлюзы протоколов), #_kiberbezopasnost (кибербезопасность), #_kiberugrozy (киберугрозы), #_blog_kompanii_trend_micro (
Блог компании Trend Micro
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_issledovanija_i_prognozy_v_it (
Исследования и прогнозы в IT
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:13
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Языковой барьер существует не только между айтишниками и пользователями. «Умные» производства и компьютеры, управляющие ими, также не способны общаться между собой без переводчиков — специализированных шлюзов промышленных протоколов. В этом посте мы расскажем о слабых местах шлюзов протоколов и о том, как злоумышленники могут использовать их, чтобы нанести вред предприятиям.  Шлюз протоколов — небольшое устройство, обеспечивающее критически важную трансляцию команд между станками, датчиками, различными исполнительными механизмами и компьютерами, на которых работают заводы, плотины, электростанции и промышленные предприятия. Эти шлюзы напоминают домашние роутеры: они также имеют несколько интерфейсов, подключённых к разным сетям, и точно так же уязвимы для различных атак. Если такое устройство выйдет из строя, связь между системами управления и машинами прекращается. Операторы не будут видеть, что происходит. По сути, они даже не смогут определить, работают ли машины, турбины или генераторы в безопасном режиме. Даже если что-то явно не так, неисправность шлюза не позволит оператору отдать команду на запуск или остановку процессов. Подобная ситуация имела быть в декабре 2015 года во время атаки на украинскую электросеть: злоумышленники получили доступ к центру управления электросетями и отключили шлюзы протоколов на подстанциях, загрузив на них повреждённую прошивку. Это заблокировало все попытки инженеров энергосистемы восстановить работу, поскольку команды от систем управления на замыкание автоматических выключателей не могли быть переданы. В отчёте об инциденте, составленном SANS ICS (подразделение американской образовательной и исследовательской организации SANS Institute по изучению индустриальных систем управления) и Центром анализа и обмена информации в области электроснабжения (E-ISAC — структура, объединяющая участников рынка электроснабжения Северной Америки), повреждение прошивки шлюзов протоколов назвали «взрывом мостов». Это очень точно описывает произошедшее, поскольку злоумышленники уничтожили ключевое звено — трансляторы, которые как раз и выступают в роли моста между контроллерами и подстанциями.  Структура взаимодействия сети управления и сети исполнения. Источник (здесь и далее, если не указано иное): Trend Micro Из-за своего расположения шлюз протокола может стать самым слабым звеном в цепочке устройств промышленного объекта, а злоумышленник может напасть на такие устройства по двум важным причинам: 1. Шлюзы вряд ли попадут под инвентаризацию критически важных активов, которые будут контролироваться агентом безопасности или системой регистрации. Следовательно, меньше вероятность того, что атака будет замечена. 2. Проблемы трансляции трудно диагностировать, поэтому ошибки в проектировании шлюзов протоколов позволяют продвинутым злоумышленникам проводить очень скрытые атаки. Виды шлюзов По режиму работы можно выделить два семейства шлюзов: 1) шлюзы реального времени (Real-time gateways) пересылают трафик по мере поступления — каждый входящий пакет сразу же оценивается, переводится и пересылается; представители: Nexcom NIO50, Schneider Link 150, Digi One IA; 2) станции передачи данных (Data Stations) — работают асинхронно, используя таблицу соответствия интерфейсов, — не ждут запроса на чтение для получения данных от подключённого ПЛК, а регулярно запрашивают у него ПЛК обновления состояний и хранят полученные данные во внутреннем кэше для выдачи по запросу. Вторая важная характеристика шлюзов протоколов — тип протоколов, которые они поддерживают и преобразуют. По этому свойству устройства можно сгруппировать по трём категориям: 1) шлюзы, которые транслируют внутри одного протокола, например, Modbus TCP в Modbus RTU, — в терминах обычного перевода это подобно переводу разговорного английского языка на английский язык, записанный с помощью шрифта Брайля; 2) шлюзы, которые выполняют трансляцию между различными протоколами внутри одного физического уровня, например, Modbus RTU → Profibus, — оба протокола последовательные, это можно сравнить с переводом письменного текста с немецкого на английский язык; 3) шлюзы, транслирующие команды между разными протоколами и физическими уровнями, например, Modbus TCP → Profibus, — аналог перевода с английского устного на немецкий текст, записанный с помощью шрифта Брайля. В исследовании Lost in Translation: When Industrial Protocol Translation Goes Wrongмы изучали уязвимости шлюзов первой группы. Для этого мы собрали тестовый стенд, состоящий из следующих компонентов: • фаззер, который генерирует входящий трафик для тестируемого шлюза — например, при тестировании трансляции с Modbus TCP на Modbus RTU, fuzzer генерирует тестовые случаи Modbus TCP, • шлюз — изучаемое устройство, • симулятор — устройство, имитирующее приёмную станцию, например, ПЛК, реализующий Modbus RTU ведомого устройства, — он необходим, потому что некоторые шлюзы протоколов могут работать некорректно, если в цепочке нет ведомого устройства, • сниффер, собирающий информацию об исходящем трафике, т. е. о транслируемом протоколе, • анализатор входящего и исходящего трафика.  Структурная схема тестового стенда для изучения уязвимостей шлюзов протоколов  Реальный тестовый стенд Для моделирования основного узла Modbus мы использовали открытое программное обеспечение QmodMaster, а для моделирования ведомого устройства — pyModSlave, адаптировав его для наших потребностей, таких как получение данных из /dev/ttyUSB0. Для перехвата трафика мы использовали Wireshark для Modbus TCP и IONinja для Modbus RTU. Мы написали специальные парсеры для преобразования вывода этих двух программ в общий синтаксис, понятный нашему анализатору. Фаззер мы реализовали на основе BooFuzz, добавив в него некоторые модули проекта Boofuzz-modbus, распространяемого под лицензией Apache. Мы сделали фаззер портируемым для различных протоколов ICS, и использовали его для тестирования нескольких реализаций Modbus. Вот некоторые разновидности атак, которые мы обнаружили, изучая различные шлюзы протоколов: • атака на транслятор протокола, • повторное использование учётных данных и дешифровка конфигурации, • амплификация трафика, • эскалация привилегий. Атака на транслятор протокола Шлюзы реального времени транслируют пакеты из одного протокола в другой, заменяя заголовки исходного протокола на заголовки целевого протокола. Шлюзы разных производителей по-разному обрабатывают некорректные пакеты. Некоторые из них, например, при получении пакета с неверно указанной длиной, вместо корректировки длины или сброса транслируют его как есть. Эта особенность позволяет тщательно спроектировать пакет неправильной длины для Modbus TCP так, чтобы после трансляции в Modbus RTU он сохранил корректность. При этом если читать его как Modbus RTU пакет, он будет иметь совершенно другое значение по сравнению с Modbus TCP эквивалентом.  Атакующий пакет: в Modbus TCP он содержит команду чтения регистра, но в Modbus RTU это уже команда записи нескольких битовых ячеек При разборе этого пакета с семантикой Modbus TCP, он интерпретируется как команда на чтение входного регистра (Function Code 04) из блока с ID=3. Но в семантике Modbus RTU, он интерпретируется как запись нескольких битовых ячеек (Function Code 15 и 0F) в блок с ID=1. Данная уязвимость является критической, поскольку совершенно невинный запрос на чтение превращается в команду на запись из-за того, что шлюз протокола неправильно обрабатывает пакет. Продвинутый злоумышленник может использовать эту уязвимость для обхода специализированного межсетевого экрана для промышленных сетей, который блокирует команды на запись с IP-адресов, не входящих в белый список. В результате всего одной команды достаточно, чтобы, например, отключить датчики контроля работоспособности и безопасности двигателя (датчик температуры и тахометр), оставив при этом двигатель включённым. Если инженеры и операторы не заметят этого, двигатель может уже перейти в критический режим и выйти из строя, однако никто об этом не узнает, поскольку термометр и тахометр были деактивированы. Повторное использование учётных данных и дешифровка конфигурации Шлюзы Moxa используют проприетарный протокол при общении с программой удалённого управления MGate Manager. При запуске MGate Manager инженеру предлагается ввести имя пользователя и пароль для доступа к шлюзу протокола, после чего McGate Manager автоматически сбрасывает конфигурацию, чтобы пользователь мог изменить настройки. Когда полевой инженер завершает настройку шлюза протоколов и нажимает кнопку «Выход», конфигурация сжимается, шифруется и загружается в шлюз.  Этапы настройки конфигурации шлюзов Moxa В этой процедуре есть два недостатка в области безопасности, которыми можно злоупотреблять. — Повторное использование Когда инженер входит в систему, в MGate Manager передаётся ключ для хэширования пароля. Однако в исследованной прошивке механизм реализован таким образом, что хакер может перехватить зашифрованный пароль инженера для входа в систему, а затем с его помощью залогиниться с административными привилегиями, даже не зная пароля в виде текста. — Дешифровка конфигурации Зашифрованная конфигурация, передаваемая по сети, содержит ключ шифрования, что позволяет хакеру сделать дамп и расшифровать её.  Зашифрованная конфигурация содержит AES-ключ для её расшифровки. Очень удобно для взлома Для расшифровки мы использовали проприетарную библиотеку расшифровки, извлечённую из прошивки устройства. Конфигурация содержит файлы настроек,, базы данных SQLite и ключ Secure Shell (SSH). Ниже приведён пример расшифрованной конфигурации нашего собственного протокольного шлюза, которую нам удалось перехватить.  Расшифрованные конфигурационные файлы шлюза Moxa MGate 5105 Амплификация трафика Поскольку станции данных асинхронно транслируют между собой протоколы, можно объединить несколько запросов типа «запись одного бита» в один запрос, чтобы более эффективно использовать последовательную шину. Например, хакер может вызывать функцию 15 (запись нескольких битов), на станции данных она будет преобразована в 1 запись для ID=2, 1 на ID=4, 1 на ID=5, 1 на ID=6. Таким образом, одна запись на Modbus TCP превращается в четыре записи на Modbus RTU, вызывая небольшие перегрузки на последовательной шине.  Одна TCP-команда на запись ячейки превращается в четыре RTU-команды Следует отметить, что такое усиление не вызовет отказ в обслуживании (DoS), однако перегруженная шина RS-485 все же может привести к аномальному поведению. Эскалация привилегий На шлюзе MGate 5105-MB-EIP мы обнаружили уязвимость эскалации привилегий CVE-2020-885, которая позволяет непривилегированному пользователю выполнять команды с повышенными привилегиями. Источник проблемы — отсутствие фильтрации ввода пользователя в веб-интерфейсе утилиты Ping.  Интерфейс утилиты Ping шлюза Mgate Обладая минимальными техническими знаниями, непривилегированный пользователь может запустить демон Telnet в контексте пользователя root с помощью простого HTTP GET-запроса и получить полный удалённый доступ с рутовым шеллом. Наши рекомендации Изучив особенности работы различных шлюзов промышленных протоколов, мы выработали ряд рекомендаций для поставщиков, установщиков или конечных пользователей. 1. Устройства разных производителей по-разному обрабатывают недействительные пакеты. Некоторые из них не обладают адекватными возможностями фильтрации пакетов или ведут себя непредсказуемо. В связи с этим при выборе продукта следует в обязательном порядке учитывать эти функциональные аспекты. 2. Используйте специализированный брандмауэр для промышленных протоколов — он обнаруживает пакеты, которые не соответствуют стандартам протокола, и обеспечивает административный доступ к шлюзам протокола только с авторизованных конечных точек. Наличие ICS-брандмауэра помогает обеспечить целостность трафика. В линейке продуктов Trend Micro есть соответствующее решение — TXOne Networks, обеспечивающее защиту в режиме реального времени для сетей OT и критически важных устройств. 3. Выделите достаточное количество времени на настройку и защиту шлюза, особенно это важно для станций обработки данных — слишком велика цена ошибки при настройке таблицы отображения ввода/вывода, которая может предоставить злоумышленнику платформу для проведения незаметных атак. Отключите ненужные сервисы и включите шифрование везде, где оно поддерживается, например, в облачной интеграции MQTT. 4. Рассматривайте шлюзы протоколов как критический актив OT и применяйте к ним соответствующие процедуры управления безопасности, включая аудит настроек и своевременную установку обновлений прошивок. =========== Источник: habr.com =========== Похожие новости:
Блог компании Trend Micro ), #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_issledovanija_i_prognozy_v_it ( Исследования и прогнозы в IT ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:13
Часовой пояс: UTC + 5