log4jScanner

Цели

Этот инструмент позволяет сканировать внутренние (только) подсети на наличие уязвимых веб-сервисов log4j. Он будет пытаться отправить полезную нагрузку JNDI каждому обнаруженному веб-сервису (через методы, описанные ниже) на список общих портов HTTP/S. Для каждого полученного ответа он будет регистрировать IP-адрес отвечающего хоста, чтобы мы могли получить список уязвимых серверов.

Если есть «УСПЕХ», это означает, что какой-то веб-сервис получил запрос, был уязвим к эксплойту log4j и отправил запрос на наш TCP-сервер.

Инструмент не отправляет никаких эксплойтов на уязвимые хосты и разработан так, чтобы быть как можно более пассивным.

Последний выпуск

ChangeLog

версия 0.3.3

• добавлена опция сканирования пользовательского списка портов --ports=1555,3030,8000,8080,9003
• добавлен флаг --connect-timeout, чтобы контролировать время ожидания ответа от каждого порта при сканировании
• различные исправления ошибок

Пример

В этом примере мы запускаем инструмент против подсети 192.168.1.59/29 (которая содержит уязвимый сервер).

Инструмент делает следующее:

1. Открывает сервер по умолчанию (локальный IP-адрес на порту 5555).
2. Возможно, добавляет флаг --ports=top100, чтобы настроить сканирование для включения 100 лучших портов.
3. Инструмент затем пытается использовать все порты на каждом из IP-адресов в подсети. Если удалённый сервер отвечает на одном из портов, запрос отправляется ему.
4. Если сервер уязвим, делается обратный вызов на наш сервер (созданный на шаге 1) и регистрируется IP-адрес удалённого сервера.
5. После сканирования всех IP-адресов в подсети сервер ожидает в течение 10 секунд по умолчанию для любых сохраняющихся соединений и закрывается.
6. Инструменты отображают сводку выполненных подключений:
   1. Запросы, отправленные на ответные удалённые серверы (и код состояния, с которым они ответили).
   2. Любой обратный адрес, сделанный на наш сервер.

Важное примечание об предположениях

• Если произошёл обратный вызов, это означает, что существует уязвимый сервер, эксплойт сработал и он инициировал обратный вызов. Однако.
• Хорошее эмпирическое правило: если IP-адрес обратного вызова не находится в отсканированной подсети, уязвимый сервер находится за NAT (например, контейнер Docker отвечает своим собственным IP-адресом, а не хостом, на котором запущен Docker).
• Сетевой трафик, создаваемый инструментом, может быть классифицирован как вредоносный продуктами безопасности или вызвать большой шум для служб мониторинга.
• Сервер, созданный инструментом, предполагает, что он открыт для приёма входящего трафика. Это означает, что необходимо открыть правило FW для входящего трафика на хосте, на котором выполняется сканирование.

Базовое использование

Скачайте инструмент для вашей конкретной платформы (Windows, Linux или Mac), чтобы запустить инструмент, убедитесь, что порт 5555 на хосте доступен (или измените его через конфигурацию), и укажите подсеть для сканирования (можно настроить отдельный сервер: комбинацию портов с помощью флага --server):

log4jScanner.exe scan --cidr 192.168.7.0/24

Это проверит 10 лучших портов HTTP\S на хостах в подсети, выведет любые уязвимые хосты на экран и создаст журнал + сводную CSV в том же месте, где находится двоичный файл, включая все попытки. Уязвимые и неуязвимые хосты

Чтобы определить, какие хосты уязвимы, просто найдите слово «SUCCESS» в журнале. Вы можете использовать grep для поиска ключевого слова «SUCCESS», чтобы получить только результаты.

Кроме того, инструмент генерирует CSV-файл, содержащий все результаты. Отфильтруйте по «уязвимому», чтобы получить уязвимые хосты.

Дополнительные варианты использования

Вы можете использовать инструмент для проверки 100 самых популярных портов HTTP\S, вставить один пользовательский порт, диапазон портов или список пользовательских портов (ограничено до 1024 портов).

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=top100

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=9000

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=9000:9005

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=1555,3030,8000,8080,9003

Можно использовать нестандартную конфигурацию для сервера обратного вызова.

log4jscanner.exe scan --cidr 192.168.7.0/24 --server=192.168.1.100:5000

Если вы хотите отключить сервер обратного вызова, используйте --noserver.

Доступные флаги

• --nocolor — вывод без цвета;
• --ports — либо топ-10 (по умолчанию), топ-100 (список из 100 наиболее распространённых веб-портов), пользовательский одиночный порт, диапазон портов или список пользовательских портов;
• --noserver — только сканирование, не используйте локальный сервер обратного вызова;
• --timeout=10 — установите время ожидания выключения сервера на 10 секунд;
• --connect-timeout=2000 — установите тайм-аут ответа для каждого сканируемого порта на 2000 миллисекунд.

Используемые методы

В настоящее время инструмент использует следующие области для попытки отправки эксплойта:

• различные заголовки X-* (мы планируем расширить их в будущем);
• кодирование параметров URL;
• User-Agent.

Настройка тестирования

Для тестирования вашей среды вы можете использовать прилагаемые образы Docker для запуска уязвимых приложений.

Запустите docker compose здесь:

docker-compose up -d

Это предоставит вам контейнер, уязвимый для порта 8080 для HTTP и порта 8443 для HTTPS.

Также вы можете запустить это:

1. Уязвимая цель:
   1. docker run --rm --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
2. Запустите сервер для входящих запросов:
   1. log4jScanner scanip --cidr DOCKER-SUBNET
3. Отправьте запрос на целевую уязвимость с деталями сервера обратного вызова:
   1. Отправляет запрос на уязвимую цель с данными обратного вызова сервера.
   2. Как только получит обратный вызов, регистрирует IP вызывающего запроса.

Вклад

Мы приветствуем вклад, пожалуйста, отправьте PR или свяжитесь с нами через contact@profero.io.