Примеры команд

Важные замечания

• ⚠️ Ошибки тайм-аута ОЖИДАЕМЫ — они указывают на успешное выполнение RCE
• Сервер зависает после выполнения команды, что вызывает тайм-аут HTTP
• Команды выполняются от имени пользователя nextjs (UID 1001) внутри контейнера
• Файлы создаются в файловой системе контейнера, а не на хосте

Docker-настройка

Этот репозиторий включает полную Docker-настройку для тестирования уязвимости:

• docker-compose.yml — конфигурация Docker Compose
• test-server/ — уязвимое приложение Next.js
• test-server/Dockerfile — продакшн Dockerfile
• test-server/Dockerfile.dev — Dockerfile для разработки (опционально)

Уязвимый сервер работает на Next.js 16.0.6 с простым Server Action, который можно эксплуатировать.

Файлы

• poc.py — скрипт proof of concept на Python (оригинал от msanft, с исправлением экранирования кавычек)
• exploit-docker.sh — автоматизированный скрипт эксплойта для Docker-среды
• DOCKER_SETUP.md — подробная документация по настройке Docker

Очистка

Оригинальный анализ уязвимости

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

Оригинальное исследование от msanft

Эта уязвимость позволяет выполнение произвольного кода (RCE) в React Server Functions, например, как они реализованы в Next.js, через небезопасные ссылки на прототипы.

Я не эксперт в React или Next.js, поэтому относитесь ко всей информации здесь с осторожностью. Кроме того, я всё ещё нахожусь в процессе анализа, так что то, что я описываю ниже как "уязвимость", может быть лишь маленькой частью полной цепочки.

Предыстория

React предлагает Server Functions¹, которые можно рассматривать как своего рода RPC через HTTP. Они могут использоваться для получения данных от соседних узлов для обеспечения низкой задержки или для выполнения аутентифицированных запросов, для которых у клиента нет учетных данных.

React использует так называемый React Flight Protocol² для сериализации значений, передаваемых Server Functions.

Клиент передаёт "чанки" (chunks) на сервер, например, через form data:

Как показано, они могут содержать ссылки друг на друга. Приведённая выше полезная нагрузка десериализуется на сервере в:

Формат сам по себе немного сложнее и позволяет более сложную сериализацию и десериализацию, но это даёт базовое понимание для реальной уязвимости.

Уязвимость

До этого коммита³ при обходе чанков для разрешения ссылок, например, при получении fruitName из чанка 2 в примере выше, React не проверял, установлен ли запрашиваемый ключ в объекте. Это позволяло получить прототип объекта⁴.

Это можно продемонстрировать такой полезной нагрузкой:

Которая десериализуется в конструктор функций⁵:

Когда чанк с ID 0 — не массив, а объект, мы можем установить ключ then в конструктор функций. Затем объект возвращается функцией decodeReplyFromBusboy и ожидается (awaited) Next.js:

Когда возвращается thenable, await в вызывающем коде вызовет его. Это и происходит с такой полезной нагрузкой:

Что приводит к ошибке:

Ошибка выглядит так, потому что V8 вызывает ожидаемую (awaited) функцию с внутренними функциями resolve и reject, которые, будучи приведёнными к строке (toString), сериализуются примерно так:

Эксплуатация

Поскольку мы можем тривиально получить конструктор Function, прямой путь — найти call-gadget, который вызывает конструктор с контролируемым пользователем значением (т.е., кодом функции в виде строки), а затем вызывает возвращённую функцию.

Есть несколько мест, которые могут вызвать конструктор функций, например, resolveServerReference, где id — контролируемый объект, lastIndexOf может быть переопределён для возврата контролируемой строки (например, через Array.prototype.join), а slice может быть переопределён на конструктор функций. Однако это место не работает, потому что второй вызов .slice() передаёт число в качестве первого аргумента, которое, насколько мне известно, никогда не может быть обработано конструктором функций.

Здесь приходит блестящая идея от maple3142⁶. Когда getChunk берёт чанк с ID 0 как корневую ссылку для начала разрешения цепочки ссылок, этот же самый чанк может разрешиться в поддельный "фейковый чанк".

Мы можем сослаться на поддельный чанк 0 в чанке 1 с помощью синтаксиса $@, который возвращает "сырой" чанк, а не его разрешённое значение:

Комбинируя это с нашей перезаписью then выше, мы можем создать нечто подобное:

Здесь чанк 0 перезаписывает свой собственный .then() на .then() своего собственного сырого представления чанка. Проще говоря, мы перезаписываем свой собственный .then() на Chunk.prototype.then, который существует, поскольку Chunk являются thenable:

С приведённой выше полезной нагрузкой Chunk.prototype.then в конечном итоге вызывается с поддельным чанком с ID 0.

Как показано выше, когда .status нашего фейкового чанка равен resolved_model:

Мы попадаем в initializeModelChunk. Здесь .value парсится как JSON, а затем на возвращённом объекте разрешаются ссылки, используя "внешний" контекст наших чанков с ID 0 и 1:

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

Существует call-gadget в обработке blob-данных с префиксом $B в flight protocol:

Используя специальное поле _response, мы контролируем свойство response поддельного чанка:

С этим мы можем создать объект с поддельными свойствами ._formData и ._prefix:

Свойство .reason нужно добавить, чтобы обойти сбой при вызове toString в initializeModelChunk:

Указывая ._formData на конструктор функций, а ._prefix на наш код, мы получаем вызов конструктора функций в десериализации blob:

Наша поддельная функция затем возвращается parseModelString как метод .then() поддельного чанка, который также ожидается (awaited), поскольку всё это происходит в одной цепочке разрешения промисов. Таким образом, возвращая thenable, наша поддельная функция вызывается. Это и есть требуемый call-gadget, упомянутый выше.

Собирая всё вместе с реальной полезной нагрузкой RCE, мы получаем нечто подобное:

Исправление

Использование ссылок на чанки для получения свойств прототипа исправлено следующей проверкой:

Открытые вопросы

• Почему в уведомлении React⁷ упоминается, что эта уязвимость может быть вызвана даже без активного объявления server functions? Существуют ли другие вещи, которые превращаются в server functions под капотом?