Atténuation des RCE Node.js : DevOps comme dernière ligne de défense

Ce projet démontre une vulnérabilité critique d'exécution de code à distance (RCE) dans une application Next.js (notamment via les Server Actions) et comment le renforcement de l'infrastructure neutralise efficacement l'attaque même lorsque la vulnérabilité du code persiste.

Il oppose un déploiement « Non sécurisé » standard à un déploiement « Sécurisé » durci utilisant des images Distroless et des systèmes de fichiers en lecture seule.

🛡️ Le concept : « Défense en profondeur »

Les vulnérabilités logicielles sont inévitables. Lorsque le code échoue, votre infrastructure doit empêcher l'attaquant d'étendre son emprise.

La vulnérabilité

Une RCE critique (CVE-2025-55182, alias React2Shell) existe dans l'implémentation des React Server Components (RSC) utilisée par Next.js.

• CVSS : 10.0 (Critique)
• Cause racine : La désérialisation non sécurisée du protocole « Flight » permet à un attaquant de manipuler des objets internes (via une pollution de prototype ou des mécanismes similaires) lors du traitement des Server Actions.
• Impact : Cela permet une exécution de code arbitraire (comme spawnSync) sans authentification.

Les vecteurs d'attaque

1. Living off the Land (LotL) : Utilisation d'outils déjà présents dans l'OS (curl, wget, ls, cat) pour voler des secrets ou télécharger des malwares.
   • Mécanisme : L'exploit utilise child_process.spawnSync() de Node.js. Cela exécute des binaires directement, sans nécessiter de shell (/bin/sh).
2. Bring Your Own Land (BYOL) : Si les outils standard sont absents, l'attaquant télécharge son propre binaire (par exemple, un exécutable Go compilé), le rend exécutable (chmod +x) et l'exécute.

🏗️ Comparaison d'architecture

📝 Analyse des logs de l'application

Les logs suivants montrent à quoi ressemblent les tentatives d'attaque du point de vue de l'application. Ce contraste met vivement en évidence l'efficacité des mesures de sécurité.

Logs de l'application sécurisée (logs/server.safe.log)

Les logs montrent des échecs répétés (ENOENT).

• Pourquoi ? spawnSync essaie d'exécuter ls, id, curl. L'image Distroless ne possède tout simplement pas ces binaires. Il ne s'agit pas seulement d'un shell manquant ; les outils eux-mêmes sont absents.

[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 de l'application non sécurisée (logs/server.unsafe.log)

Les logs confirment une exécution de commande réussie et une manipulation du système de fichiers.

[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}`'

(Remarque : Dans les logs non sécurisés, cat /app/.env échoue ci-dessus car le fichier est nommé .env à la racine, mais ls -la dans les logs complets révélerait la structure des répertoires.)

💥 Résultats du POC

1. RCE standard (Living off the Land)

Tentative d'exécution de commandes shell standard.

• Non sécurisé : ✅ Succès. L'attaquant peut exécuter id, ls, cat .env et accéder à des données sensibles.
• Sécurisé : ❌ Bloqué. spawnSync /bin/sh ENOENT. Il n'y a pas de shell pour exécuter des commandes.

2. Attaque avancée (Bring Your Own Land)

Tentative de contournement des « outils manquants » en téléchargeant un binaire personnalisé.

• Non sécurisé : ✅ Succès.
  1. L'attaquant fragmente un binaire (pour contourner les limites de charge utile).
  2. L'écrit dans /tmp/malware.
  3. Exécute chmod +x.
  4. Exécute le binaire.
• Sécurisé : ❌ Bloqué.
  • Écriture échouée : EROFS: read-only file system.
  • L'attaquant ne peut déposer de fichiers nulle part, neutralisant ainsi efficacement l'attaque BYOL.

3. Analyse de l'exécution « véritablement sans fichier »

Un attaquant peut-il charger un binaire dans une variable et l'exécuter directement depuis la mémoire ?

• Concept : Concaténer des fragments d'un binaire dans une variable JavaScript globale (par exemple, global.payload = "..."), puis l'exécuter.
• Réalité : Échec.
  • Les fonctions child_process de Node.js (spawn, exec) nécessitent un chemin de fichier. Elles ne peuvent pas exécuter directement un tampon ou une chaîne.
  • Pour contourner cela sous Linux, on a besoin de memfd_create (un appel système pour créer un fichier anonyme en RAM).
  • La barrière : Node.js n'expose pas memfd_create nativement. Y accéder nécessiterait un addon C++ (comme ffi-napi) préinstallé dans node_modules.
  • Impact Distroless : Puisque l'image manque de compilateurs (gcc, make), un attaquant ne peut pas construire cet addon à la volée.

🔐 Meilleures pratiques démontrées

1. Utiliser des images Distroless

Les images « Distroless » contiennent uniquement votre application et ses dépendances d'exécution. Elles ne contiennent pas de gestionnaires de paquets, de shells ou d'outils UNIX standard.

• Pourquoi ? Si un attaquant obtient une RCE, il ne peut pas fouiller (ls), télécharger des fichiers (curl) ou escalader les privilèges facilement.

2. Systèmes de fichiers en lecture seule

Configurez votre runtime de conteneur pour monter le système de fichiers racine en lecture seule.

• Pourquoi ? Cela empêche les attaquants de télécharger (BYOL) ou de modifier votre code d'application (persistance).
• Comment ? Dans docker-compose.yml :
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # CRITICAL: explicitly block execution!
  

  Observation : Avec cette configuration, notre POC montre que l'attaquant peut écrire le binaire dans /tmp (écriture réussie), mais l'exécution échoue avec EACCES (Permission refusée) à cause du drapeau noexec. Cela équilibre fonctionnalité (tmp inscriptible) et sécurité.

3. Variables d'environnement natives (l'espace « Export »)

N'incluez pas de fichiers .env dans vos images de conteneur. Si un attaquant peut lire des fichiers (par exemple, cat .env), vos secrets sont compromis.

• Approche sécurisée : Injectez les variables directement dans l'environnement du processus à l'exécution (par exemple, via Kubernetes Secrets, AWS Parameter Store, ou la clé environment de Docker).
• Pourquoi ? Cela rend beaucoup plus difficile pour un attaquant de déverser tous les secrets d'un coup par rapport à la lecture d'un seul fichier.

🚀 Comment exécuter

1. Démarrer l'environnement : Les applications sécurisée et non sécurisée sont définies dans un seul fichier docker-compose.yml.

   root@kitploit:~

   docker compose up --build -d
   

2. Exécuter les exploits : Vous pouvez exécuter les exploits sur les ports spécifiques pour voir la différence.

   • Cibler l'application non sécurisée (Port 3001) :

     root@kitploit:~

     # 1. Standard RCE (LotL) - SUCCEEDS
     python exploit/poc.py http://localhost:3001
     
     # 2. Advanced Attack (BYOL) - SUCCEEDS
     python exploit/poc_advanced.py http://localhost:3001
     

   • Cibler l'application sécurisée (Port 3000) :

     root@kitploit:~

     # 1. Standard RCE (LotL) - FAILS (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. Advanced Attack (BYOL) - FAILS (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. Nettoyer :

   root@kitploit:~

   docker compose down