[Перевод] Log4Shell/Leak4J — чрезвычайно опасная уязвимость в log4j216.12.2021 12:01

Последние пару дней (и ночей) я изучал новую (чрезвычайно опасную) уязвимость в log4j2 под названием Log4Shell.

Это касается всех версий log4j-core от 2.0-beta9 до 2.14.1, и это очень серьезная проблема.

Эта уязвимость позволяет злоумышленнику удаленно выполнить код в вашей системе с возможностью получить полный контроль над базовыми серверами.

Log4J долгое время был наиболее часто используемым фреймворком для ведения журналов в среде Java. Он чрезвычайно широко используется, и у этой атаки есть самый широкий триггер, который вы можете себе представить: ей нужно что-то зарегистрировать.

Вредоносный код может быть доставлен МНОГИМИ способами, если они попадают в оператор логирования. Через управляемые пользователем поля, HTTP-запросы, URL-адреса, ВСЕ что угодно.

Атака

После написания некоторого кода (вредоносный встроенный сервер LDAP) я смог воспроизвести атаку RCE («Удаленное выполнение кода») даже на самый простой проект.

Вот пример: простая конечная точка REST в стартовом проекте Spring Boot с единственной строкой регистрации.

Как видите, код загружает и выполняет файл классов, распечатывающего сообщение, который я загружаю с вредоносного сервера LDAP (работающего удаленно).

Я не буду делиться вредоносным кодом, он слишком прост в настройке и злоупотреблении. Есть лучшие и более простые способы проверить, уязвимо ли ваше программное обеспечение. Например, с помощью этого инструмента от Trend Micro.

Возможные риски

Риски этой уязвимости:

Потеря ВСЕХ данных
Программы-вымогатели
Бэкдоры
Ботнет
Потеря ключей / секретов AWS / Kubernetes
И этот список можно продолжать, продолжать и продолжать …

Исправление

Вариант 1. Если вы еще этого не сделали: обновите log4j-core до версии> = 2.16.0.

Используйте версию 2.16.0 вместо 2.15.0, это решает проблему более строго.


		org.apache.logging.log4j
    log4j-core
    2.16.0

Сделайте то же самое для всех транзитивных зависимостей (!).

Вариант 2. Другой вариант — запустить JRE с помощью.

-Dlog4j2.formatMsgNoLookups=true

Но будите ВНИМАТЕЛЬНЫ: этот флаг был реализован в log4j2 начиная с версии 2.10.0. Если у вас более старая версия, это не сработает.

Вариант 3. удалить JndiLookup.class

Также можно удалить org.apache.logging.log4j.core.lookup.JndiLookup из файлов JAR log4j. Я не рекомендую делать это, если вы хотите пойти по этому пути. Вероятно, проще просто перейти на>=2.16.0.

Не вариант:

Я видел в Интернете предложения, что «новые» версии Java не затронуты, но это не так. Даже с последними версиями Java и с установленным значением trustURLCodebase=false все равно можно украсть данные (например, переменные среды) и десериализовать объекты, уже известные загрузчику классов. Это упрощает запуск других десериализационных RCE.

Это может быть немного сложнее/безопаснее в более новой версии Java, но это определенно НЕ исправление.

Чтобы показать это, я взял последнюю версию Java 8 (1.8.311) и использую десериализацию log4j2 для создания чего-то, что открывает калькулятор на моем MacBook с использованием других классов, известных уязвимой цели:

Опять же: загружаемый объект все еще десериализуется в последней версии Java.

Вы были скомпрометированы

Отлично, вы обновили и устранили проблему. Однако: не останавливайтесь на достигнутом, это всего лишь первый шаг.

Эта утечка была известна и использовалась в течение долгого времени, вероятно, за несколько недель до того, как стала достоянием общественности. И если даже я смогу использовать его за пару минут с помощью собственного вредоносного кода: любой сможет.

Итак, вот что еще вам нужно сделать:

Шаг 1. Обновите и устраните утечку

Шаг 2: Предполагая, что все украдено: замените все ключи

Шаг 3: Войдите в вашу систему и проанализируйте записи в лог файлах

Шаг 4: Если вы настроили инфраструктуру как код: восстановите вашу среду

Шаг 4. Повторно разверните все свои приложения

Мы ДОЛЖНЫ отнестись к этому серьезно. Мне не хотелось бы услышать или прочитать через пару месяцев, что какая-то компания забыла исправить свое программное обеспечение.

Присоединяйтесь к нашей встрече

«Понимание Log4Shell: уязвимости, атаки и способы их устранения (прямая трансляция)»
Среда, 15 декабря 2021 г., 20:00 CET

https://www.meetup.com/OpenValue/events/282682468/

Примечание переводчика. К сожалению встреча уже прошла. Но есть презентация ее организаторов и вероятно будет выложена запись.

Дальнейшее чтение:

Вот несколько ссылок для получения дополнительной информации: