Log4Shell: что это и чем опасно год спустя | Блог Касперского

Что такое уязвимость Log4Shell, чем она опасна и почему о ней не стоит забывать в 2022 году.

Год назад, в декабре 2021 года, Log4Shell — уязвимость CVE-2021-44228 в библиотеке Apache Log4j, наделала много шума. К весне она вроде бы ушла с первых полос IT-изданий, но в ноябре 2022 года вновь появилась в новостях о том, что злоумышленники проэксплуатировали эту уязвимость при атаке на федеральное агентство США и установили на его системы криптомайнер. Это повод рассказать, что это за уязвимость, почему ее рано списывать со счетов и как защитить от свою инфраструктуру от эксплойта Log4Shell.

Что такое библиотека Apache Log4j

Изначально Java SDK не поддерживал логирование, поэтому разработчики были вынуждены писать собственные решения, и к тому времени, как появился официальный Java Logging API, их существовало уже несколько. Одно из них — Apache Log4j, популярная Java-библиотека с открытым исходным кодом, разрабатываемая еще с 2001 года. Это далеко не единственное решение для логирования в Java, но явно одно из самых популярных. Многие альтернативные решения по сути представляют собой ответвления или «переосмысления» того же Log4j, появившиеся на разных этапах развития библиотеки.

Что собой представляет уязвимость Log4Shell

Библиотека Log4j 2 логирует любые системные события в автоматическом режиме. В своей работе она использует стандартный набор интерфейсов для доступа к данным Java Naming and Directory Interface (JNDI). Как выяснилось в ноябре 2021 года, в процессе логирования она могла запустить команды JNDI, переданные ей событием, например, в поле Header запроса, в сообщении из чата или описания ошибки 404 на чужой веб-странице.

Уязвимость создает широкие возможности для злоумышленников — теоретически с ее помощью они могут делать в системе жертвы что угодно (если не сработает дополнительная защита). Чаще всего злоумышленники применяли Log4Shell для установки нелегальных майнеров и атак при помощи шифровальщиков-вымогателей. Но были и более экзотические варианты ее использования, включая целевые атаки, распространения ботнета Mirai и даже «рикроллинг» — проигрывание легендарной (но достаточно привязчивой) песни Never Gonna Give You Up в исполнении Рика Астли.

Почему уязвимость Log4Shell столь опасна и все еще эксплуатируется

Java — один из основных языков программирования, и бэкенды многих систем, от небольших корпоративных серверов до систем промышленной автоматизации и оборудования Интернета вещей, пишутся именно на нем. В большинстве этих систем так или иначе реализован процесс логирования. Долгие годы самым простым способом вести логи было использование библиотеки Log4J. Когда уязвимость в ней была обнародована в декабре 2021 года, эксперты объявили ее огромной проблемой на многие годы. И вот почему.

• Log4j используется в огромном количестве Java-приложений. На момент обнаружения уязвимость присутствовала более чем в 35 тыс. пакетов (артефактов) в Maven (крупнейшем репозитории программ на Java), что составляло 8% от их общего числа. По оценкам специалистов, около 40% сетей в мире были уязвимы для Log4Shell.
• Кроме обычных компьютеров и серверов, Java используется также в промышленном, медицинском и ином специализированном оборудовании (OT, Operational Technology). Там тоже не исключено использование библиотеки Log4j.
• Конечные пользователи решений с Log4J внутри вообще могут не задумываться о том, что в их ПО находится уязвимость, а следовательно, не спешить обновлять его.
• Разработчики решений, в которых используется библиотека Log4j, могли давно разориться, уйти с рынка или по иным причинам прекратить поддержку своих программ. Даже если конечные пользователи и хотели бы обновиться, у них больше нет такой возможности. А перейти на другое ПО может быть не так-то и просто.
• Log4j — библиотека с открытым кодом, а значит, программисты могли его копировать, модифицировать и применять в своих проектах. К сожалению, не все разработчики строго следуют лицензиям и не всегда указывают авторство используемого кода. Так что в теории та же самая уязвимость может находиться и в стороннем проекте, где официально нет никакой Log4j.
• Log4Shell была уязвимостью «нулевого дня», то есть использовалась злоумышленниками до того, как информация о ней была опубликована. Есть свидетельства, злоумышленники начали пробовать ее в деле еще за девять дней до обнародования.
• Среди уязвимых программ были продукты VMware, в частности популярное решение для организации инфраструктуры виртуальных рабочих столов VMware Horizon. Многие зафиксированные атаки проникали в систему именно через него.
• Обновление программ не решит всех проблем в том случае, если злоумышленники уже проникли в систему. Далеко не всегда атака начинается сразу после проникновения — вполне возможно, что во многих системах до сих пор сидят «закладки».

Практический вред от Log4Shell

Справедливости ради стоит признать, что катастрофически серьезных последствий использования Log4Shell до сих пор зафиксировано не было. Ну или широкой общественности пока о таковых неизвестно. Тем не менее уязвимость доставила немало хлопот разработчикам и специалистам по безопасности. Включая испорченные рождественские праздники для тысяч айтишников по всему миру. Компании, которые серьезно относятся к безопасности (как своей, так и своих клиентов), были вынуждены потратить немалые средства на поиск уязвимости в своих системах и разработках и ее устранение.

Из наиболее примечательных случаев использования Log4Shell на практике можно отметить следующие.

• 20 декабря 2021 года атаку на свою инфраструктуру с использованием уязвимости подтвердило бельгийское Министерство обороны. Подробности по понятным причинам не разглашались.
• 29 декабря 2021 года в СМИ появились сообщения о том, что атаке через Log4Shell подверглось некое научное учреждение в США. По мнению исследователей из CrowdStrike, незапатченной уязвимостью в ПО VMware Horizon воспользовалась APT-группировка Aquatic Panda. Подозрительную активность удалось вовремя остановить, но сам факт свидетельствует о том, что уязвимость взяли на вооружение серьезные хакерские группы.
• В том же декабре 2021 года стало известно об эксплуатации уязвимости на серверах Minecraft: Java Edition, хостящихся не у издателей игры (Microsoft). Компания подтвердила реальность проблемы и обратила внимание на простоту реализации атаки: преступники передавали зловредный код в обычном внутриигровом чате — этого было достаточно, чтобы исполнить вредоносный код как на стороне сервера, так и на стороне уязвимого клиента. Этот случай интересен не столько с точки зрения жертв, сколько с точки зрения технической реализации атаки: получается, что при определенных условиях атаку можно провернуть просто через внутренний чат. А ведь чаты сейчас встраивают далеко не только в игры: многие компании предпочитают общаться с клиентами по внутрипрограммным каналам. Например, во многих финтехприложениях именно так организована поддержка клиентов.
• В июне 2022 года Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Киберкомандование береговой охраны США (CGCYBER) выпустили предупреждение о том, что уязвимость все еще активно эксплуатируют. В сообщении говорилось, что преступники использовали лазейку в том же VMware Horizon и проникли во внутренние сети двух неназванных государственных организаций. Помимо всего прочего в предупреждении сказано, что злоумышленники получили доступ к 130 Гб конфиденциальных данных, связанных с правоохранительной деятельностью
• В ноябре 2022 года CISA и ФБР выпустили еще один бюллетень об атаке с использованием Log4Shell на государственное учреждение. Злоумышленники проникли в систему еще в феврале, были обнаружены в апреле и активно действовали в июне — июле. За это время они завели учетную запись с правами администратора, поменяли пароль легитимного администратора и загрузили на сервер ПО для майнинга. Предполагается, что за атакой стояли государственные хакеры из Ирана, поэтому некоторые специалисты считают, что майнинг был лишь дымовой завесой, призванной скрыть реальные мотивы преступников.

Как защитить свою инфраструктуру

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

• Если в ваших разработках применяется Log4j — используйте последнюю версию библиотеки, доступную на странице проекта.
• Изучите официальные инструкции от Apache Logging Services и следуйте им там, где это необходимо.
• Если Log4j используется в сторонних продуктах — обновите уязвимое программное обеспечение.
• Используйте надежные решения , способные выявлять попытки эксплуатации уязвимостей на серверах и рабочих станциях.
• Отслеживайте подозрительную активность внутри корпоративного периметра при помощи решений класса EDR или внешних сервисов типа managed detection and response. Это позволит выявлять и останавливать атаки на ранних стадиях.

09.12.2022