Последние пару дней (и ночей) я изучал новую (чрезвычайно опасную) уязвимость в 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, это решает проблему более строго.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.16.0</version>
</dependency>Сделайте то же самое для всех транзитивных зависимостей (!).
Вариант 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
Свойство: com.sun.jndi.ldap.object.trustURLCodebase
Я видел в Интернете предложения, что «новые» версии 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/
Примечание переводчика. К сожалению встреча уже прошла. Но есть презентация ее организаторов и вероятно будет выложена запись.
Дальнейшее чтение:
Вот несколько ссылок для получения дополнительной информации:
