Log4Shell на промышленных предприятиях

Что такое Log4Shell?

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

• При этом уязвимое приложение вовсе не обязано получать данные напрямую от злоумышленника (т.е. речь идёт не только о смотрящих в интернет сервисах, таких как веб сервер Apache). Оно запросто может оказаться работающим внутри сети бизнес- или технологическим приложением, которое как-то — например, посредством передачи через цепочку других приложений или хранилищ данных — получает строку, пришедшую изначально из недоверенного источника.  
• В этом случае всё, что нужно для того, чтобы уязвимое приложение было доступно для атаки — наличие у самого приложения доступа к контролируемому злоумышленником серверу. Этот сервер может быть расположен как в интернете (наиболее частый сценарий), так и на скомпрометированном хосте внутри атакованной сети (например, в случае целевой атаки).

Как это работает?

Java — мощный инструмент, созданный, чтобы сократить время разработки приложений и повысить её эффективность. Однако его очевидные достоинства могут скрывать его недостатки. Иногда ценой за дополнительные удобства разработки и универсальность может стать потеря контроля качества и безопасности.

Log4j дает возможность разработчику разрешить пользователю определять не только что записывается в лог, но и как (в каком формате), и, главное, откуда брать логируемые данные. Источником информации при этом может быть java-класс, который хранится на удалённом сервере. Для поиска такого java-класса может использоваться JNDI (Java Naming And Directory Interface) — унифицированный интерфейс работы с сервисами каталогов, такими как LDAP (Lightweight Directory Access Protocol), DNS (Domain Name System), RMI (Remote Method Invocation) и другие. 

В результате злоумышленник может передать (как уже говорилось выше, неважно, каким способом) уязвимому приложению созданную им строку в специальном формате запросов Log4j к JNDI, которая будет содержать путь к вредоносному классу, размещённому на контролируемом злоумышленником сервере. По сути, это всё, что нужно, чтобы вредоносный код был скачан с сервера и выполнен в контексте уязвимого приложения.

Что же на самом деле происходит?

Ситуация — очень серьёзная.

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

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

Третья проблема в том, что речь идёт об уязвимости не в отдельном продукте и даже не в каком-то законченном общем технологическом компоненте, который применяется в разных продуктах одинаковыми или очень схожими способами (как, например, сервис лицензирования). Уязвимой оказалась распространённая технология разработки, которая по-разному используется в огромном количестве различных приложений, что делает их по-разному уязвимыми и множит возможные сценарии атак.

Ну и наконец, исправить уязвимости в самой технологии оказалось не так уж просто — через пару дней после выхода исправлений от разработчика был найден новый вектор атаки, работающий в ряде случаев, когда для форматирования логов используются параметры, сохранённые в Thread Context Map, которые удалось задать злоумышленнику (примерно таким же способом, как и в пред. варианте атаки). Несколько новых векторов было найдено в последующие дни, к счастью менее критичных. Один из них касался уже Log4j1 (более ранних версий фреймворка, считавшихся до этого неуязвимыми к Log4Shell).  Для эксплуатации уязвимости атакующему необходимо иметь доступ на запись к файлу конфигурации Log4j. Самая последняя находка исследователей, касающаяся Log4j2, также связана с его конфигурацией. Дело в том, что в добавок ко всем своим прочим возможностям, Log4j позволяет пользователям сконфигурировать запись лога не в файл, а в реляционную базу данных — через интерфейс JDBC (для этого используется технология JDBCAppender). Log4j при этом не проверяет корректность задания пути к источнику данных JDBC (хранящему параметры подключения к БД), и позволяет злоумышленнику задать вместо него ссылку на вредоносный класс  на контролируемом злоумышленником сервере — и загрузить его тем самым на выполнение всё тем же механизмом JNDI, что и для первых вариантов атаки.  Для реализации атаки злоумышленнику нужен доступ на запись к файлу конфигурации или возможность организовать MITM (файл конфигурации может быть расположен удалённо).

И, кто знает, может, история на этом ещё не закончилась.

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

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

Текущей проблемой для средств сетевой защиты является тот факт, что синтаксис передачи по сети данных (которые попадают в логируемые параметры уязвимых приложений) может быть очень вариативным, и сложно написать простые правила детектирования, покрывающие всё многообразие вариантов. Что же касается защиты конечных узлов, то многие из уязвимых приложений (особенно из числа «критически важных» и работающих под большой нагрузкой) могут попросту быть её лишены — например, ввиду предубеждений IT- и (особенно часто) OT-специалистов, обычно «обосновываемых» соображениями производительности и совместимости.

Более «продвинутые» злоумышленники будут использовать сценарии атак, специально подобранные для конкретной организации и её систем.  Защита от таких угроз — дело непростое и часто балансирует на грани искусства.

Насколько проблема затрагивает промышленные предприятия?

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

К сожалению, системы технологической сети оказались почти в такой же степени уязвимы, как и IT-системы — об этом свидетельствуют многие недавно опубликованные оповещения об уязвимостях от разработчиков продуктов для АСУ.  Среди уязвимых продуктов многие — широко распространены в электроэнергетике, в частности:

• распределенные системы управления (DCS) для объектов генерации
• продукты для мониторинга состояния полевого оборудования (трансформаторов)
• продукты для Asset Management
• продукты для управления станциями зарядки электромобилей
• различные продукты для системных операторов
• другие вспомогательные продукты, многие из которых имеют возможности интеграции со SCADA

Также проблема в большой степени затрагивает компьютеры и организации, занятые в сфере инжиниринга — уязвимыми оказались многие приложения для моделирования, симуляции и колабарации команд разработчиков, активно применяемые в разработке новых продуктов промышленных предприятий, и приложения PLM (Product lifecycle Management) и CAD/CAM-системы, используемые, не только для проектирования и разработки новых промышленных продуктов, но и непосредственно в процессе их производства — например,  для программирования станков с ЧПУ. В значительной мере уязвимость затронула системы управления зданиями, включая системы физической безопасности.

Много АСУ по всей видимости, оказались уязвимыми из-за использования популярных общих компонентов, таких как популярное ПО для управления лицензиями, встречающееся во множестве решений для АСУ (к сожалению, вендоры продуктов пока не выпустили патчей и оповещений безопасности, и мы не можем писать об этом подробнее из соображений responsible disclosure). Также уязвимыми оказались некоторые реализации стека протоколов OPC UA на Java 

В общей сложности, по оценкам, полученным на основе анализа данных нашей телеметрии, не менее 10% всех АСУ в мире могут быть уязвимы к Log4Shell из-за использования уязвимого специфического ПО.

Другие зоны риска для технологических систем, которые пока сложно оценить, связаны с использованием:

• содержащего уязвимость нецелевого ПО (которое часто может быть установлено вопреки политикам ИБ);
• приложений для промышленного интернета вещей и Smart Energy, многие из которых, как оказалось, разработаны с использованием уязвимой технологии.

Пока сложно сказать, в какой мере уязвимые системы АСУ доступны для атаки потенциальным злоумышленникам, однако, мы надеемся, что, в отличии от IT-инфраструктур, большинство уязвимых OT-систем не имеют возможности принимать на вход данные, пришедшие из недоверенных источников, что лишает злоумышленников простых векторов атаки.

Что мы можем порекомендовать для защиты от этой угрозы?

• Идентифицируйте по возможности все системы, содержащие уязвимую технологию.
• Удалите всё нецелевое программное обеспечение и внедрите регламенты и технические меры, препятствующие его использованию и установке.
• Обновите по возможности всё, что можно обновить, или хотя бы примените компенсационные меры, рекомендованные производителем. По согласованию с производителем уязвимой системы или под свою ответственность можете самостоятельно применить меры, рекомендованные разработчиком Log4j.
• Сегментируйте по возможности сеть.
• Убедитесь, что доступ к ресурсам интернета есть только у тех систем, которые действительно в нём нуждаются.
• Защитите, всё, что можно защитить, при помощи современных (лучше специализированных) средств защиты конечных узлов. Убедитесь, что средства защиты правильно сконфигурированы: базы поддерживаются в максимально актуальном состоянии, отсутствуют области, исключённые из защиты, работают все защитные компоненты и попавший в систему злоумышленник не имеет возможности их отключить.
• Убедитесь, что средства сетевой безопасности способны защитить от атак распространённых паттернов (получите доступ к хорошему источнику Threat Intelligence, чтобы быть уверенными, что знаете, как это проверить).
• Средства Threat Intelligence также помогут вам понять, от каких векторов продвинутых атак стоит защищаться, и дадут вам подсказку в выборе конкретных способов зашиты.