Критическая дыра в ENIP-совместимых устройствах грозит взломом АСУ ТП

Критическая дыра в ENIP-совместимых устройствах грозит взломом АСУ ТП

Критическая дыра в ENIP-совместимых устройствах грозит взломом АСУ ТП

В прошивках десятка устройств, использующих комплект разработчика 499ES EtherNet/IP (ENIP) производства Real Time Automation (RTA), присутствует критическая уязвимость, позволяющая удаленно выполнить вредоносный код.

Разработчик SDK выпустил патч еще в 2012 году, однако многие продавцы оборудования для промышленной автоматизации приобрели право пользования проектом задолго до этого и продолжают привносить уязвимый код в свои реализации сетевого стека ENIP.

Согласно бюллетеню, выпущенному американской Группой реагирования на киберинциденты в сфере АСУ ТП (ICS-CERT), уязвимость, зарегистрированная под идентификатором CVE-2020-25159, относится к классу «переполнение буфера». Использование этой ошибки позволяет с помощью особого сетевого пакета, поданного на TCP-порт 44818, вызвать на устройстве состояние отказа в обслуживании, а при благоприятных условиях — даже выполнить произвольный код в системе.

Проблема была оценена в 9,8 балла из 10 возможных по шкале CVSS. Она присутствует во всех выпусках EtherNet/IP Adapter Source Code Stack, предшествующих пропатченному 2.28.

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

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

Операторам подобных устройств рекомендуется по возможности обновить прошивки. Снизить риск эксплуатации помогут превентивные меры, рекомендованные ICS-CERT США:

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

Российские провайдеры начали глушить защищённые DNS Google и Cloudflare

Пользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare. Под ударом оказались протоколы DNS over HTTPS (DoH) и DNS over TLS (DoT), которые шифруют DNS-запросы и не позволяют провайдеру запросто подсматривать, к какому домену обращается пользователь.

По данным телеграм-канала bypassblock, сбои затронули абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet.

Судя по результатам измерений, фильтрация работает хитрее обычного: TCP-соединение устанавливается, но защищённый туннель разваливается уже на следующем этапе.

При подключении к Cloudflare по адресам 1.1.1.1 и 1.0.0.1 через порт 853 TCP-рукопожатие проходит успешно, после чего соединение принудительно сбрасывается с ошибкой ECONNRESET — ещё до завершения TLS-аутентификации.


С Google Public DNS картина другая. Соединение с dns.google, 8.8.8.8 и 8.8.4.4 через порт 443 устанавливается, но после отправки TLS ClientHello ответы прекращаются.

Сессия либо висит до тайм-аута, либо завершается ошибкой unexpected eof while reading. Такое поведение может указывать на вмешательство промежуточного оборудования и фильтрацию по сигнатуре.

Симптомы различаются в зависимости от оператора и региона: у одних пользователей не работает только DoT, у других — DoH, а некоторым достался полный комплект. Техподдержка «Таттелекома» якобы прямо рекомендовала одному из абонентов отключить оба протокола для восстановления доступа.

Официального подтверждения централизованной блокировки пока нет. Однако совпадение сбоев у нескольких провайдеров и одновременные проблемы у Google и Cloudflare выглядят слишком сильно для обычной случайности.

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