Смягчение RCE в Node.js: DevOps как последняя линия обороны

Этот проект демонстрирует критическую уязвимость удаленного выполнения кода (RCE) в приложении Next.js (конкретно через Server Actions) и то, как усиление инфраструктуры эффективно нейтрализует атаку, даже если кодовая уязвимость остается.

В нем сравнивается стандартное «Небезопасное» развертывание с усиленным «Безопасным» развертыванием с использованием образов Distroless и файловых систем только для чтения.

🛡️ Концепция: «Глубокоэшелонированная защита»

Уязвимости ПО неизбежны. Когда код дает сбой, ваша инфраструктура должна помешать атакующему расширить свое присутствие.

Уязвимость

Критическая RCE (CVE-2025-55182, также известная как React2Shell) существует в реализации React Server Components (RSC), используемой Next.js.

• CVSS: 10.0 (Критическая)
• Коренная причина: Небезопасная десериализация протокола «Flight» позволяет атакующему манипулировать внутренними объектами (через загрязнение прототипа или аналогичные механизмы) во время обработки Server Action.
• Влияние: Это позволяет выполнять произвольный код (например, spawnSync) без аутентификации.

Векторы атак

1. Использование встроенных средств ОС (LotL - Living off the Land): Использование уже присутствующих в ОС инструментов (curl, wget, ls, cat) для кражи секретов или загрузки вредоносного ПО.
   • Механизм: Эксплойт использует child_process.spawnSync() из Node.js. Он выполняет бинарные файлы напрямую, без необходимости в оболочке (/bin/sh).
2. Принеси своё (BYOL - Bring Your Own Land): Если стандартные инструменты отсутствуют, атакующий загружает свой бинарный файл (например, скомпилированный Go-исполняемый файл), делает его исполняемым (chmod +x) и запускает.

🏗️ Сравнение архитектур

📝 Анализ логов приложения

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

Логи безопасного приложения (logs/server.safe.log)

Логи показывают повторяющиеся ошибки (ENOENT).

• Почему? spawnSync пытается запустить ls, id, curl. В образе Distroless этих бинарных файлов просто нет. Дело не только в отсутствии оболочки; сами инструменты отсутствуют.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.safe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"2. Verify Binary was Written","verification":{...},"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"","stderr":"","error_obj":{"message":"spawnSync /tmp/hello_test EACCES","code":"EACCES"},"success":true}`'

Логи небезопасного приложения (logs/server.unsafe.log)

Логи подтверждают успешное выполнение команд и манипуляции с файловой системой.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.unsafe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"Hello from Go binary!\\n","stderr":"","error_obj":null,"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"id","args":[],"stdout":"uid=0(root) gid=0(root) ...","stderr":"","status":0,"signal":null}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"cat","args":["/app/.env"],"stdout":"","stderr":"cat: can\'t open \'/app/.env\': No such file or directory\n","status":1,"signal":null}`'

(Примечание: в небезопасных логах cat /app/.env завершается ошибкой выше, потому что файл назван .env в корне, но ls -la в полных логах раскрыл бы структуру каталогов.)

💥 Результаты POC

1. Стандартное RCE (использование встроенных средств ОС - Living off the Land)

Попытка выполнить стандартные команды оболочки.

• Небезопасное: ✅ Успешно. Атакующий может выполнить id, ls, cat .env и получить доступ к конфиденциальным данным.
• Безопасное: ❌ Заблокировано. spawnSync /bin/sh ENOENT. Нет оболочки для выполнения команд.

2. Продвинутая атака (принеси своё - Bring Your Own Land)

Попытка обойти «отсутствие инструментов» путем загрузки собственного бинарного файла.

• Небезопасное: ✅ Успешно.
  1. Атакующий разбивает бинарный файл на части (чтобы обойти ограничения полезной нагрузки).
  2. Записывает его в /tmp/malware.
  3. Выполняет chmod +x.
  4. Запускает бинарный файл.
• Безопасное: ❌ Заблокировано.
  • Запись не удалась: EROFS: read-only file system.
  • Атакующий не может поместить файлы никуда, что эффективно нейтрализует атаку BYOL.

3. Анализ «полностью бесфайлового» выполнения

Может ли атакующий загрузить бинарный файл в переменную и выполнить его напрямую из памяти?

• Концепция: Склеить части бинарного файла в глобальную переменную JavaScript (например, global.payload = "..."), затем выполнить её.
• Реальность: Не удалось.
  • Функции child_process в Node.js (spawn, exec) требуют путь к файлу. Они не могут выполнить буфер или строку напрямую.
  • Чтобы обойти это в Linux, требуется memfd_create (системный вызов для создания анонимного файла в ОЗУ).
  • Препятствие: Node.js не предоставляет memfd_create нативно. Доступ к нему потребовал бы C++-аддон (например, ffi-napi), предустановленный в node_modules.
  • Влияние Distroless: Поскольку в образе отсутствуют компиляторы (gcc, make), атакующий не может собрать этот аддон на лету.

🔐 Продемонстрированные лучшие практики

1. Использование образов Distroless

Образы «Distroless» содержат только ваше приложение и его зависимости времени выполнения. Они не содержат менеджеров пакетов, оболочек или стандартных инструментов UNIX.

• Почему? Если атакующий получает RCE, он не может осмотреться (ls), скачать файлы (curl) или легко повысить привилегии.

2. Файловые системы только для чтения

Настройте среду выполнения контейнера так, чтобы корневая файловая система была смонтирована только для чтения.

• Почему? Это предотвращает загрузку (BYOL) или изменение кода приложения (постоянство) со стороны атакующего.
• Как? В docker-compose.yml:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # КРИТИЧЕСКИ ВАЖНО: явно заблокировать выполнение!
  

  Наблюдение: с такой настройкой наш POC показывает, что атакующий может записать бинарный файл в /tmp (запись успешна), но выполнение завершается ошибкой EACCES (отказано в доступе) из-за флага noexec. Это балансирует функциональность (записываемый tmp) и безопасность.

3. Нативные переменные окружения (пространство «Export»)

Не помещайте файлы .env в образы контейнеров. Если атакующий может читать файлы (например, cat .env), ваши секреты скомпрометированы.

• Безопасный подход: Внедряйте переменные непосредственно в среду процесса во время выполнения (например, через Kubernetes Secrets, AWS Parameter Store или ключ environment Docker).
• Почему? Это значительно усложняет атакующему дамп всех секретов за один раз по сравнению с чтением одного файла.

🚀 Как запустить

1. Запустите окружение: И безопасное, и небезопасное приложения определены в одном файле docker-compose.yml.

   root@kitploit:~

   docker compose up --build -d
   

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

   • Нацеливание на небезопасное приложение (порт 3001):

     root@kitploit:~

     # 1. Стандартное RCE (LotL) - УСПЕХ
     python exploit/poc.py http://localhost:3001
     
     # 2. Продвинутая атака (BYOL) - УСПЕХ
     python exploit/poc_advanced.py http://localhost:3001
     

   • Нацеливание на безопасное приложение (порт 3000):

     root@kitploit:~

     # 1. Стандартное RCE (LotL) - НЕ УДАЕТСЯ (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. Продвинутая атака (BYOL) - НЕ УДАЕТСЯ (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. Очистка:

   root@kitploit:~

   docker compose down