УЦСБ планирует выпустить DATAPK

УЦСБ: За информационной безопасностью АСУ ТП никто не следит

УЦСБ

Екатеринбургская компания Уральский Центр Систем Безопасности (УЦСБ) провёл в Москве семинар под названием "Информационная безопасность промышленных систем автоматизации и управления", на котором были озвучены результаты проверки 30 промышленных объектов, на которых было развернуто 150 АСУ ТП. Обнаружилось, что на всех предприятиях были организационно-распорядительные документы, регламентирующие требования по информационной безопасности, однако ни в одном из них не было предусмотрено средства контроля за соблюдением требований этих документов

. "Ни на одном предприятии нам не удалось найти процедуру, которая бы позволяла в течении недели обнаружить нарушение требований безопасности собственных документов", - пояснил Антон Ёркин, руководитель направления УЦСБ.

Компания проводила аудит средств защиты промышленных предприятий - в основном металлургических и ТЭК - где проверялись три уровня защиты АСУ ТП: технологический, организационный и физический. Проблемы с документами - это уровень организационных мер, но и с техническими средствами защиты АСУ ТП не всё гладко. Из хорошего: исследователи обнаружили в 88% случаев, что компании предпринимали определённые меры обеспечения сетевой безопасности - отделяли операционную систему АСУ ТП от остальной корпоративной сети, или хотя бы настраивали межсетевой экран и контролировали доступ пользователей. Однако в 17% случаев был обнаружен удаленный доступ к операционной сети из общекорпоративной - это, как правило, администраторы ИТ организовывали канал для удаленного управления компьютерами АСУ ТП. Доступ к пользовательскому интерфейсу самих АСУ ТП часто был защищён паролем, по которому ограничивался набор пунктов меню системы управления. Однако базовые операционные системы были установлены в основном с настройками по умолчанию, а встроенные в PLC механизмы защиты были отключены. Антивирусное ПО было установлено на компьютеры АСУ ТП только в 25% случаев, но только в 11% - оно получало обновления. При этом сама система АСУ ТП обновлялась только в 8% случаев.

Физическая безопасность также была в целом на высоком уровне, однако системы контроля доступа и видеонаблюдения в основном были нацелены на выявление краж продукции и защиту самого объекта. Тем не менее были обнаружены случаи, когда операционный зал АСУ ТП находился за пределами охраняемого периметра.

Своё исследование защищённости решений для АСУ ТП представила на семинаре и компания Digital Security. Её специалисты изучили 20 мобильных приложений, которые разработаны для удаленного управления различными SCADA-системами. Обнаружилось, что нет ни одного приложения, которое было бы разработано с соблюдением требований безопасности. В частности, достаточно часто приложение просто хранило настройки на SD-карте мобильного устройства в незашифрованном виде, что позволяет другому приложению модифицировать эти настройки и нарушить работу основного приложения, а через него, возможно, и вмешаться в работу основной АСУ ТП. Также компания исследовала протокол взаимодействия с сервером и пыталась вмешаться в диалог между мобильным приложением и сервером. При этом обнаруживались такие ошибки проектирования как передача пароля от сервера в открытом виде и банальные SQL-инъекции на стороне сервера. Как уже было сказано, администраторы 17% систем настроили удаленный доступ к ним, вполне возможно, и с помощью мобильных приложений.

Собственно, чтобы контролировать соблюдение требований безопасности при управлении АСУ ТП компания УЦСБ разработала собственный продукт для мониторинга промышленных сетей под названием DATAPK. Он собирает информацию о функционировании промышленной сети и выдаёт сообщения в случае обнаружения несанкционированной активности. Сейчас компания проводит несколько пилотных проектов по тестированию своего решения. Пока разработка правил защиты требует достаточно сложной работы с клиентом, чтобы описать корректные режимы работы АСУ ТП и выяснить потенциально опасные ситуации. Впрочем, при внедрении аналогичных систем других производителей - Инженирингового центра МИФИ и "Лаборатории Касперского" - также требуются длительные консультации с клиентами и построение сложных правил контроля, которые не могут быть применены в других условиях. Впрочем, все компании-производители собираются заняться обучением своих партнёров, чтобы со временем передать им работу по настройке защиты АСУ ТП.

HTTP/2 Bomb: одна машина может положить сервер за считаные секунды

Эпоха ботнетов для организации мощных DDoS-атак получила ещё одного игрока. Исследователи рассказали о новой технике отказа в обслуживании под названием HTTP/2 Bomb, которая позволяет буквально положить крупный веб-сервер силами всего одной машины.

Самое неприятное — атака работает против стандартных конфигураций популярных серверов, включая NGINX, Apache HTTP Server, Microsoft IIS, Envoy и Cloudflare Pingora.

Метод обнаружили специалисты компании Calif при помощи ИИ-агента Codex от OpenAI. Фактически HTTP/2 Bomb — это комбинация двух известных приёмов: усиления через механизм сжатия заголовков HPACK и удержания ресурсов по схеме Slowloris с использованием особенностей управления потоком в HTTP/2.

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

По данным исследователей, обычный домашний компьютер с каналом 100 Мбит/с способен вывести из строя уязвимый сервер за считаные секунды. Например, Apache httpd и Envoy можно заставить выделить и удерживать 32 Гбайт оперативной памяти примерно за 20 секунд.

Во время испытаний результаты оказались впечатляющими:

  • Envoy 1.37.2 — 32 Гбайт RAM за 10 секунд;
  • Apache httpd 2.4.67 — 32 Гбайт за 18 секунд;
  • NGINX 1.29.7 — 32 Гбайт за 45 секунд;
  • Microsoft IIS на Windows Server 2025 — 64 Гбайт за 45 секунд.

Особую пикантность ситуации добавляет тот факт, что опубликованы уже не только технические детали, но и готовые эксплойты.

Исправления уже доступны для NGINX 1.29.8 и Apache mod_http2 2.0.41. Для Apache проблема зарегистрирована под идентификатором CVE-2026-49975. А вот пользователям IIS, Envoy и Pingora пока остаётся ждать патчей либо временно отключать HTTP/2 и использовать прокси-серверы или файрволы с жёсткими ограничениями на количество заголовков.

RSS: Новости на портале Anti-Malware.ru