Node inspector/CEF debug abuse
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
From the docs: Quando avviato con l'opzione --inspect, un processo Node.js ascolta per un client di debug. Per default, ascolterà all'indirizzo host e alla porta 127.0.0.1:9229. Ogni processo è anche assegnato a un UUID unico.
I client dell'inspector devono conoscere e specificare l'indirizzo host, la porta e l'UUID per connettersi. Un URL completo apparirà simile a ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e.
Poiché il debugger ha accesso completo all'ambiente di esecuzione di Node.js, un attore malintenzionato in grado di connettersi a questa porta potrebbe essere in grado di eseguire codice arbitrario per conto del processo Node.js (potenziale escalation dei privilegi).
Ci sono diversi modi per avviare un inspector:
Quando avvii un processo ispezionato, apparirà qualcosa del genere:
I process basati su CEF (Chromium Embedded Framework) devono utilizzare il parametro: --remote-debugging-port=9222 per aprire il debugger (le protezioni SSRF rimangono molto simili). Tuttavia, invece di concedere una sessione di debug NodeJS, comunicheranno con il browser utilizzando il Chrome DevTools Protocol, che è un'interfaccia per controllare il browser, ma non c'è un RCE diretto.
Quando avvii un browser in debug, apparirà qualcosa del genere:
I siti web aperti in un browser possono effettuare richieste WebSocket e HTTP secondo il modello di sicurezza del browser. Una connessione HTTP iniziale è necessaria per ottenere un id di sessione del debugger unico. La politica di stessa origine impedisce ai siti web di poter effettuare questa connessione HTTP. Per ulteriore sicurezza contro gli attacchi di DNS rebinding, Node.js verifica che gli header 'Host' per la connessione specifichino un indirizzo IP o localhost o localhost6 precisamente.
Queste misure di sicurezza impediscono di sfruttare l'inspector per eseguire codice semplicemente inviando una richiesta HTTP (che potrebbe essere fatto sfruttando una vulnerabilità SSRF).
Puoi inviare il segnale SIGUSR1 a un processo nodejs in esecuzione per farlo avviare l'inspector nella porta predefinita. Tuttavia, nota che devi avere privilegi sufficienti, quindi questo potrebbe concederti accesso privilegiato alle informazioni all'interno del processo ma non un'escalation di privilegi diretta.
Questo è utile nei contenitori perché arrestare il processo e avviarne uno nuovo con --inspect non è un'opzione perché il contenitore verrà terminato insieme al processo.
Per connettersi a un browser basato su Chromium, è possibile accedere agli URL chrome://inspect o edge://inspect per Chrome o Edge, rispettivamente. Cliccando sul pulsante Configura, si dovrebbe assicurarsi che l'host e la porta di destinazione siano elencati correttamente. L'immagine mostra un esempio di Esecuzione Remota di Codice (RCE):
Utilizzando la linea di comando è possibile connettersi a un debugger/inspector con:
Lo strumento https://github.com/taviso/cefdebug consente di trovare gli ispettori in esecuzione localmente e iniettare codice in essi.
Nota che gli exploit RCE di NodeJS non funzioneranno se connessi a un browser tramite Chrome DevTools Protocol (devi controllare l'API per trovare cose interessanti da fare con essa).
Se sei arrivato qui cercando come ottenere RCE da un XSS in Electron, controlla questa pagina.
Alcuni modi comuni per ottenere RCE quando puoi connetterti a un inspector di Node sono utilizzare qualcosa come (sembra che questo non funzionerà in una connessione al protocollo Chrome DevTools):
Puoi controllare l'API qui: https://chromedevtools.github.io/devtools-protocol/ In questa sezione elencherò solo cose interessanti che ho trovato che le persone hanno usato per sfruttare questo protocollo.
Nel CVE-2021-38112 Rhino security ha scoperto che un'applicazione basata su CEF ha registrato un URI personalizzato nel sistema (workspaces://) che riceveva l'URI completo e poi lanciava l'applicazione basata su CEF con una configurazione che era parzialmente costruita da quell'URI.
È stato scoperto che i parametri URI venivano decodificati in URL e utilizzati per lanciare l'applicazione di base CEF, consentendo a un utente di iniettare il flag --gpu-launcher nella linea di comando ed eseguire cose arbitrarie.
Quindi, un payload come:
Eseguirà un calc.exe.
Cambia la cartella in cui i file scaricati verranno salvati e scarica un file per sovrascrivere il codice sorgente dell'applicazione utilizzato frequentemente con il tuo codice malevolo.
Secondo questo post: https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148 è possibile ottenere RCE e esfiltrare pagine interne da theriver.
In un ambiente reale e dopo aver compromesso un PC utente che utilizza un browser basato su Chrome/Chromium, potresti avviare un processo Chrome con il debugging attivato e inoltrare la porta di debugging in modo da poter accedervi. In questo modo sarai in grado di ispezionare tutto ciò che la vittima fa con Chrome e rubare informazioni sensibili.
Il modo furtivo è terminare ogni processo Chrome e poi chiamare qualcosa come
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
