tadash10/exploiting-cve-2021-44228-log4shell-in-a-banking-environmentЦель: продемонстрировать эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в среде смоделированного банковского приложения.
Цель: продемонстрировать эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в смоделированной среде банковского приложения.
Область применения:
1: Настроить уязвимое банковское приложение с использованием Apache Log4j. 2:Создать полезную нагрузку для эксплуатации уязвимости с достижением удалённого выполнения кода. 3:Продемонстрировать методы пост-эксплуатации, такие как эксфильтрация данных и горизонтальное перемещение. 4:Внедрить и задокументировать стратегии обнаружения и смягчения последствий, включая установку обновлений и мониторинг сети. 5:Подробно описать процесс эксплуатации, включая используемые инструменты (например, JNDI Exploit Kit, Burp Suite).
Итак, давайте перейдём к созданию полезной нагрузки для эксплуатации уязвимости Log4Shell (CVE-2021-44228) и достижения удалённого выполнения кода в рамках вымышленного сценария упражнения на виртуальной машине.
Чтобы создать полезную нагрузку, необходимо понять природу уязвимости. Уязвимость Log4Shell позволяет злоумышленникам внедрять вредоносный код в файл конфигурации библиотеки Log4j, который затем выполняется затронутым приложением. Полезная нагрузка разрабатывается для запуска этой уязвимости и выполнения произвольного кода в целевой системе.
Ниже приведён базовый план шагов по созданию полезной нагрузки:
Определите файл конфигурации Log4j: установите расположение файла конфигурации Log4j в среде целевого банковского приложения. Обычно этот файл называется log4j2.xml или log4j.properties.
Разработайте эксплуатирующую полезную нагрузку: создайте вредоносную конфигурацию Log4j, которая включает обращение к Java Naming and Directory Interface (JNDI) для выполнения произвольного кода. Эту полезную нагрузку можно встроить в файл log4j2.xml.
xml
Замените «your-attacker-server» на IP-адрес или имя хоста вашей машины атакующего, прослушивающей порт 4444.
Разместите полезную нагрузку: настройте прослушиватель на машине атакующего для приёма соединения и выполнения произвольного кода.
Объявление XML:
xml
Стандартное объявление XML.
Элемент Configuration:
xml
Корневой элемент конфигурации Log4j.
Appenders:
xml
Определяет Socket-appender с именем «evil».
Атрибут host указывает сервер атакующего.
Атрибут port указывает порт на сервере атакующего.
SerializedLayout означает, что события журнала будут сериализованы и отправлены по сети, что может быть угрозой безопасности, поскольку способно привести к удалённому выполнению кода (RCE) через атаки на десериализацию.
Loggers:
xml
<Loggers>
<Root level="all">
<AppenderRef ref="evil" />
</Root>
</Loggers>
Определяет уровень журналирования all, то есть все сообщения журнала (debug, info, warn, error и т. д.) будут захватываться.
Элемент AppenderRef ссылается на ранее определённый appender «evil», то есть все сообщения журнала будут отправляться на сервер атакующего.
Замечания
Риски безопасности:
Удалённое выполнение кода (RCE): использование SerializedLayout с удалённым Socket-appender может позволить атакующему выполнить произвольный код в системе, если он контролирует сервер и отправляет вредоносную полезную нагрузку. Это критическая уязвимость безопасности.
Эксфильтрация данных: такая конфигурация может легко привести к отправке конфиденциальных данных на неавторизованный удалённый сервер, что ведёт к утечкам данных.
Неправильные методы ведения журнала:
Ведение журнала на ненадёжный удалённый сервер крайне небезопасно и противоречит лучшим практикам безопасного журналирования.
Журналирование на уровне all в производственной среде может привести к переполнению журнала, проблемам с производительностью и потенциальному раскрытию конфиденциальной информации.
Рекомендации по смягчению последствий:
Избегайте SerializedLayout: не используйте SerializedLayout ни в одной конфигурации журналирования, если это не абсолютно необходимо, и убедитесь, что принимающий сервер является доверенным и защищённым.
Проверяйте конечные точки журналирования: убедитесь, что все конечные точки журналирования находятся в доверенных и контролируемых средах.
Используйте безопасные макеты: используйте более безопасные макеты, такие как PatternLayout, которые не создают рисков сериализации.
Ограничивайте уровни журналирования: используйте подходящие уровни журналирования (например, info, warn, error) и избегайте all, за исключением случаев отладки в защищённой среде.
Пример более безопасной конфигурации
Вот пример более безопасной конфигурации Log4j:
xml
nc -nlvp 4444
Запуск уязвимости: разверните созданный файл конфигурации Log4j в целевой среде, заменив исходный файл конфигурации.
Выполнение эксплойта: после загрузки вредоносной конфигурации уязвимым экземпляром Log4j будет предпринята попытка установить соединение с сервером атакующего, что приведёт к удалённому выполнению кода.
Проверка выполнения: проверьте прослушиватель на машине атакующего, чтобы подтвердить, что полезная нагрузка была выполнена успешно.
Крайне важно отметить, что эта полезная нагрузка предназначена для образовательных и тестовых целей в контролируемой среде. В реальных сценариях эксплуатация таких уязвимостей, как Log4Shell, без авторизации незаконна и неэтична. Всегда убеждайтесь, что у вас есть явное разрешение и авторизация, прежде чем проводить любые мероприятия по тестированию безопасности или тестированию на проникновение.