Mitigazione RCE in Node.js: il DevOps come ultima linea di difesa

Questo progetto dimostra una vulnerabilità critica di Remote Code Execution (RCE) in un'applicazione Next.js (in particolare tramite Server Actions) e come l'indurimento dell'infrastruttura neutralizzi efficacemente l'attacco anche quando la vulnerabilità nel codice rimane.

Mette a confronto un deployment "Non sicuro" standard con un deployment "Sicuro" indurito che utilizza immagini Distroless e file system in sola lettura.

🛡️ Il Concetto: "Difesa in Profondità"

Le vulnerabilità software sono inevitabili. Quando il codice fallisce, la tua infrastruttura deve impedire all'attaccante di espandere il proprio punto d'appoggio.

La Vulnerabilità

Una RCE Critica (CVE-2025-55182, nota anche come React2Shell) esiste nell'implementazione di React Server Components (RSC) utilizzata da Next.js.

• CVSS: 10.0 (Critico)
• Causa Radice: La deserializzazione non sicura del protocollo "Flight" consente a un attaccante di manipolare oggetti interni (tramite prototype pollution o meccanismi simili) durante l'elaborazione delle Server Actions.
• Impatto: Consente l'esecuzione arbitraria di codice (come spawnSync) senza autenticazione.

I Vettori di Attacco

1. Living off the Land (LotL): Utilizzare strumenti già presenti nel sistema operativo (curl, wget, ls, cat) per rubare segreti o scaricare malware.
   • Meccanismo: L'exploit usa child_process.spawnSync() di Node.js. Questo esegue i binari direttamente, senza bisogno di una shell (/bin/sh).
2. Bring Your Own Land (BYOL): Se gli strumenti standard mancano, l'attaccante carica il proprio binario (ad esempio, un eseguibile Go compilato), lo rende eseguibile (chmod +x) e lo esegue.

🏗️ Confronto dell'Architettura

📝 Analisi dei Log dell'Applicazione

I seguenti log mostrano come appaiono i tentativi di attacco dalla prospettiva dell'applicazione. Questo contrasto evidenzia chiaramente l'efficacia delle misure di sicurezza.

Log dell'App Sicura (logs/server.safe.log)

I log mostrano ripetuti errori (ENOENT).

• Perché? spawnSync tenta di eseguire ls, id, curl. L'immagine Distroless semplicemente non ha questi binari. Non si tratta solo dell'assenza di una shell; gli strumenti stessi non ci sono.

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

Log dell'App Non Sicura (logs/server.unsafe.log)

I log confermano l'esecuzione riuscita dei comandi e la manipolazione del file system.

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

(Nota: nei log non sicuri, cat /app/.env fallisce sopra perché il file si chiama .env nella root, ma ls -la nei log completi rivelerebbe la struttura delle directory.)

💥 Risultati del POC

1. RCE Standard (Living off the Land)

Tentativo di eseguire comandi shell standard.

• Non sicuro: ✅ Successo. L'attaccante può eseguire id, ls, cat .env e accedere a dati sensibili.
• Sicuro: ❌ Bloccato. spawnSync /bin/sh ENOENT. Non c'è alcuna shell per eseguire comandi.

2. Attacco Avanzato (Bring Your Own Land)

Tentativo di bypassare gli "strumenti mancanti" caricando un binario personalizzato.

• Non sicuro: ✅ Successo.
  1. L'attaccante suddivide un binario in chunk (per bypassare i limiti di payload).
  2. Lo scrive in /tmp/malware.
  3. Esegue chmod +x.
  4. Esegue il binario.
• Sicuro: ❌ Bloccato.
  • Scrittura Fallita: EROFS: read-only file system.
  • L'attaccante non può depositare file da nessuna parte, neutralizzando efficacemente l'attacco BYOL.

3. Analisi dell'Esecuzione "Veramente Fileless"

Può un attaccante caricare un binario in una variabile ed eseguirlo direttamente dalla memoria?

• Concetto: Concatenare chunk di un binario in una variabile JavaScript globale (ad esempio, global.payload = "..."), quindi eseguirlo.
• Realtà: Fallito.
  • Le funzioni child_process di Node.js (spawn, exec) richiedono un percorso file. Non possono eseguire direttamente un buffer o una stringa.
  • Per bypassare questo su Linux, serve memfd_create (una syscall per creare un file anonimo in RAM).
  • La Barriera: Node.js non espone memfd_create nativamente. Accedervi richiederebbe un addon C++ (come ffi-napi) preinstallato in node_modules.
  • Impatto di Distroless: Poiché l'immagine manca di compilatori (gcc, make), un attaccante non può compilare questo addon al volo.

🔐 Best Practice Dimostrate

1. Usare Immagini Distroless

Le immagini "Distroless" contengono solo la tua applicazione e le sue dipendenze runtime. Non contengono gestori di pacchetti, shell o strumenti UNIX standard.

• Perché? Se un attaccante ottiene RCE, non può guardarsi in giro (ls), scaricare file (curl) o escalare i privilegi facilmente.

2. File System in Sola Lettura

Configura il runtime del container per montare il file system root come sola lettura.

• Perché? Impedisce agli attaccanti di scaricare (BYOL) o modificare il codice della tua applicazione (persistenza).
• Come? In docker-compose.yml:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # CRITICO: blocca esplicitamente l'esecuzione!
  

  Osservazione: Con questa configurazione, il nostro POC mostra che l'attaccante può scrivere il binario in /tmp (scrittura riuscita), ma l'esecuzione fallisce con EACCES (Permesso Negato) a causa del flag noexec. Questo bilancia funzionalità (tmp scrivibile) e sicurezza.

3. Variabili d'Ambiente Native (lo Spazio "Export")

Non inserire file .env nelle immagini dei tuoi container. Se un attaccante può leggere file (ad esempio, cat .env), i tuoi segreti sono compromessi.

• Approccio Sicuro: Iniettare le variabili direttamente nell'ambiente di processo a runtime (ad esempio, tramite Kubernetes Secrets, AWS Parameter Store o la chiave environment di Docker).
• Perché? Rende molto più difficile per un attaccante scaricare tutti i segreti in una volta rispetto alla lettura di un singolo file.

🚀 Come Eseguire

1. Avvia l'Ambiente: Sia l'applicazione sicura che quella non sicura sono definite in un unico file docker-compose.yml.

   root@kitploit:~

   docker compose up --build -d
   

2. Esegui gli Exploit: Puoi eseguire gli exploit sulle porte specifiche per vedere la differenza.

   • Puntando all'App Non Sicura (Porta 3001):

     root@kitploit:~

     # 1. RCE Standard (LotL) - HA SUCCESSO
     python exploit/poc.py http://localhost:3001
     
     # 2. Attacco Avanzato (BYOL) - HA SUCCESSO
     python exploit/poc_advanced.py http://localhost:3001
     

   • Puntando all'App Sicura (Porta 3000):

     root@kitploit:~

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

3. Pulizia:

   root@kitploit:~

   docker compose down