«Это Log4Shell, Джим, но не в том виде, в каком мы его знаем» — так никогда не говорил Commander Spock.

Это краткий обзор ошибки CVE-2021-42392, дыры в системе безопасности, о которой недавно сообщили исследователи из компании по управлению цепочками поставок программного обеспечения Jfrog.

На этот раз ошибка находится не в осажденном наборе инструментов Apache Log4j, а в популярном Java SQL сервере под названием H2 Database Engine.

H2 не похож на традиционную SQL систему, такую ​​как MySQL или Microsoft SQL server.

Хотя вы можете запускать H2 как отдельный сервер для подключения других приложений, он главным образом известен из-за его скромных размеров и автономном характере работы.

В результате вы можете встраивать код H2 SQL базы данных прямо в свои собственные Java-приложения и запускать свои базы данных полностью в памяти без необходимости в отдельных серверных процессах.

Как и в случае с Log4j, это означает, что в вашей организации могут быть неявно запущенные экземпляры кода H2 Database Engine, если вы используете какие-либо приложения или компоненты разработки, которые сами по себе незаметно включают его.

JNDI снова в центре внимания

Как и уязвимость Log4Shell, эта зависит от злоупотребления интерфейсом именования и каталогов Java, более известным как JNDI, который является неотъемлемой частью каждой стандартной установки Java.

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

Как бы опасно это ни звучало, важно помнить, что подобная функциональность может быть закодирована в любом программном обеспечении (скомпилированном или интерпретированном, скриптовом или бинарном), которое имеет доступ к сети, может загружать произвольные данные и может превращать эти данные в исполняемый код какой-либо программы. JNDI просто значительно упрощает создание распределенных приложений, которые находят и загружают удаленные компоненты. Подобное удобство программирования иногда повышает безопасность, потому что часто проще проверять и проверять код, если он следует хорошо задокументированному пути. Но иногда это снижает безопасность, потому что упрощает случайное появление неожиданных побочных эффектов. Мы видели это в Log4j, где «запись текстовой строки для логирования данных, отправленных удаленным пользователем», может непреднамеренно превратиться в «загрузить и запустить ненадежную программу, указанную удаленным пользователем».

К счастью, в отличие от Log4Shell, ошибка CVE-2021-42392 не может быть вызвана простым внедрением текста ловушки в запросы, которые отправляются в механизм базы данных H2.

Хотя Jfrog задокументировал несколько способов, которыми киберпреступники теоретически могут обманом заставить H2 запустить произвольный удаленный код, наиболее вероятный путь атаки включает:

• Активная веб консоль H2. Это встроенный веб-сервер, который обычно прослушивает TCP-порт 8082 и позволяет разработчикам взаимодействовать с серверной частью H2 SQL во время ее работы. Если этот порт заблокирован или консоль неактивна, то этот способ атаки не сработает.

• Консоль H2 прослушивает внешний сетевой интерфейс. По умолчанию консоль принимает подключения только от компьютера, на котором она запущена (localhost, обычно это IP-адрес 127.0.0.1 в IPv4 сети). Даже если это значение по умолчанию не изменено, злоумышленникам потребуется локальный доступ, прежде чем они смогут получить доступ к консоли H2.

Согласно документации к H2, приложения, которые встраивают движок H2 непосредственно в свой код, «не подвергаются внешнему воздействию», но, насколько мы можем видеть, это примечание относится только к самому движку базы данных, когда он не работает как SQL сервер, а не к компоненту веб консоли.

К сожалению, Jfrog отмечает:

Мы заметили, что некоторые сторонние инструменты, использующие базу данных H2, по умолчанию запускают консоль H2, доступную для удаленных клиентов. Например, инфраструктура JHipster также предоставляет консоль H2 и по умолчанию задает для свойства webAllowOthers значение true.

Настройка webAllowOthers— это свойство Java, используемое H2 для принятия решения о том, принимать ли подключения от внешних сетевых интерфейсов.

Страница входа в веб консоль по умолчанию включает форму, позволяющую пользователям указать способ подключения к базе данных.

Злоумышленник может использовать эту форму для запроса JNDI-поиска через LDAP, как и при атаке Log4Shell, чтобы обманом заставить H2 получить и запустить удаленный  Java файл .class (скомпилированную программу Java).

Хотя URL-адрес, используемый для запуска атаки, будет отправлен в той же форме входа, которая запрашивает имя пользователя и пароль, Jfrog обнаружил, что поиск JNDI происходит до проверки имени пользователя и пароля.

Это означает, что злоумышленнику не нужны реальные учетные данные для использования уязвимости, поэтому ошибка открывает так называемую дыру удаленного выполнения кода без проверки подлинности (RCE), наиболее опасную разновидность.

УЗНАЙТЕ, КАК ОБЪЕДИНЯЮТСЯ JNDI И LDAP ДЛЯ УДАЛЕННОГО ВЫПОЛНЕНИЯ КОДА

Для демонстрации того, как JNDI может быть злонамеренно объединен с поиском JDAP для загрузки и запуска ненадежного удаленного кода, посмотрите это видео:

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

Что делать?

• Если у вас есть приложения, использующие ядро базы данных H2, обновите H2 до версии 2.0.206.

На момент написания 2.0.206 (выпущенная 04.01.2022) указана как последняя версия, хотя в журнале изменений H2 2.0.206 по-прежнему указана как «невыпущенная» и не документирует CVE-2021-42392 как одну из исправленных проблем.

Jfrog, однако, заявляет, что 2.0.206 включает изменение кода, аналогичное тому, которое Apache использовал в обновлении Log4j 2.17.0: H2 больше не позволяет использовать JNDI с любыми удаленными ссылками.

Теоретически это означает, что злоумышленники больше не могут проделывать трюк, говоря: «выполните поиск, но используйте сетевой запрос, который приведет вас к ненадежному внешнему местоположению, чтобы мы могли манипулировать результатами».

Насколько мы видим, обновленный движок базы данных H2 теперь использует JNDI только для того, что по сути является локальными вызовами функций Java, так что удаленное выполнение кода как неожиданный побочный эффект использования JNDI больше невозможно ни случайно, ни намеренно.

• Чтобы найти экземпляры кода H2 в вашей сети, вы можете искать файлы с именами h2-*.jar.

Шаблон текста, обозначенный, * имеет вид X.Y.Z, представляющий номер используемой версии H2 — все, что ниже 2.0.206, должно быть заменено последней версией.