Уязвимость Log4j: как она повлияла на 2022 год

9 декабря 2021 года была обнаружена уязвимость Log4j, которая стала серьезной проблемой для IT-специалистов со всего мира. В пиковые моменты число атак исчислялось десятками тысяч в час. В результате уязвимости был присвоен предельный уровень опасности по шкале CVSS – 10.

Уязвимость log4j: что это

Apache Log4j — это среда ведения журналов Java. Он поддерживается Apache Software Foundation, кооперативом с открытым исходным кодом. Его главное преимущество – это простота и универсальность. Поэтому он применяется в самых разных проектах: от LinkedIn до Steam.

В декабре 2021 года среда была скомпрометирована: поочередно выявили сразу три уязвимости, первая из которых получила название Log4Shell (CVE-2021-45105). Масштабные атаки начались девятого декабря, когда эксплойт Log4Shell был публично опубликован с помощью POC.

Уязвимость позволила злоумышленникам проводить удаленное выполнение кода. Вредоносные команды регистрировались как легитимные. Это позволяло делать практически что угодно: красть данные, распространять вредоносные URL, фактически контролировать целые серверы.

Позднее были выявлены еще две, менее критичные, уязвимости Apache log4j:

• 14 декабря – (CVE 2021-45046);
• 17 декабря – (CVE-2021-45105).

Основная сложность для команд IT-безопасности состоит в том, что исправления нужно вносить отдельно для каждой службы, которая работает на Log4j. Это трудоемкий процесс, который требует вдумчивого анализа. Само исправление стало возможно только после выхода серии патчей.

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

Патчи: как происходило устранение уязвимости

Чтобы понять, касается ли данная уязвимость конкретно вашего случая, нужно узнать версию log4j. Скомпрометированными оказались все версии, от 2.0-beta9 до 2.14.1 включительно. Первую информацию об уязвимости Apache получили от команды Alibaba Cloud уже 24 ноября, что позволило компании быстро выпустить обновление.

9 декабря был так называемый 0-day, то есть день, когда данные об изъяне в библиотеках Log4j были обнародованы. Следом было выпущено несколько патчей:

• 2.15.0 – частично решил проблему;
• 2.16.0 – гораздо надежнее, но имеет небольшую DoS уязвимость;
• 2.17.0 – безопасный продукт.

Везде, где используется apache log4j до версии 2.17.0, сохраняется риск для всей архитектуры. Но обновление ПО – это сложная задача для любого большого проекта, требующая больших аналитических ресурсов и времени. Поэтому многие команды пошли и идут по другому пути – вместо обновления уязвимых баз они самостоятельно «затыкают дыры» в коде и используют средства обнаружения.

Александр Герасимов
Директор по информационной безопасности и сооснователь Awillix

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

Бывает, что специалисты знают об этой проблеме, но все равно не обновляют свои сервисы. Как, например, с Windows, который без обновлений может работать в банках, в том числе в различных критических инфраструктурах, просто потому, что после обновления какое-то другое важное ПО перестанет работать. Поэтому оставляют как есть. В каждом втором нашем проекте по анализу защищенности есть уязвимость в Windows, которая за один шаг дает выполнение кода. Люди знают про эту проблему, но мало кто реально заботится об ее устранении.

Эффективность средств обнаружения в большей степени зависит от используемых метрик. Есть как простые решения, которые позволяют выявить вредоносное воздействие «постфактум», так и более продвинутые.

Актуальная ситуация

На момент написания статьи актуальная версия ПО – 2.17.1. Она достаточно надежна, это уже не экстренный патч, а полноценное обновление, которое сделано вдумчиво и основательно, с купированием ситуации вокруг ошибки log4j.

Те, кто не обновляют софт по тем или иным причинам, «отключают Log4j» вручную. Эксперт прокомментировал, какие сложности возникают при ручной фильтрации и поиске уязвимости Log4j.

Алексей Антонов
Управляющий партнёр Swordfish Security, эксперт в области кибербезопасности

Проблема намного шире, чем может показаться на первый взгляд.

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

Второй проблемой является то, что библиотека может напрямую не использоваться в продукте, а являться зависимостью на любом из уровней (то есть, когда одна библиотека использует другую для своей работы). И простым поиском по исходному коду такую библиотеку будет найти невозможно.

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

Единственный способ быстро и правильно отреагировать на появление подобных проблем – правильно выстроенный процесс работы с анализом Open-Source компонент в компании.

Актуальность проблемы в будущем

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

Вместе с тем, эта ситуация показывает, насколько велика роль сотрудничества и обратной связи. Команда Alibaba предупредила Apache о Log4jShell за 15 дней до того, как эти данные попали в публичный доступ.