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.
