Diventa Autore per CoreTech | Scopri di più
28/05/21 CoreTech Blog
Il debug e i componenti / pannelli hanno spesso configurazioni errate, che possono portare alla divulgazione di informazioni sensibili o persino all'esecuzione di comandi remoti (iniezione di codice).
Alcune applicazioni espongono una porta speciale per il debug remoto, ad esempio le applicazioni Java aziendali espongono una porta JDWP (Java Debug Wire Protocol), che avrebbe facilmente consentito a un utente malintenzionato di ottenere il pieno controllo dell'applicazione.
Ogni sviluppatore utilizza una sorta di strumento di debug, ma il debug remoto è meno comune. Si utilizza il debug remoto quando non è possibile indagare su un problema a livello locale. Ad esempio, lo si utilizza quando è necessario eseguire il debug di un'applicazione Java aziendale che è troppo grande per essere sviluppata localmente e che ha forti connessioni con l'ambiente o con i dati elaborati. Un altro scenario tipico per il debug remoto è il debug di un contenitore Docker.
Un debugger è un obiettivo molto prezioso per un utente malintenzionato. Lo scopo di un debugger è fornire al programmatore le massime capacità. Ciò significa che, in quasi tutti i casi, l'attaccante può ottenere molto facilmente l'esecuzione di codice in modalità remota una volta che accede al debugger remoto.
Inoltre, il debug remoto di solito avviene in un ambiente affidabile. Pertanto, molti debugger non forniscono funzionalità di sicurezza e utilizzano protocolli di testo normale senza autenticazione o alcun tipo di restrizione. D'altra parte, alcuni debugger rendono l'attacco più difficile: forniscono l'autenticazione o le restrizioni IP del client. Alcuni vanno anche oltre e non aprono una porta ma avviano invece le connessioni all'IDE. Ci sono anche casi in cui il programmatore passa una connessione remota al debugger tramite SSH.
Di seguito puoi trovare esempi di attacchi RCE su vari debugger. Ho provato a coprire tutti i linguaggi comuni, ma mi sono concentrato solo sui debugger più popolari e su quelli che sono più comunemente configurati in modo errato.
JPDA è un'architettura per il debug di applicazioni Java. Usa JDWP, il che significa che puoi facilmente rilevare la sua porta usando Nmap. La porta, tuttavia, non è sempre la stessa, in genere dipende dal server delle applicazioni. Ad esempio, Tomcat utilizza 8000, ColdFusion utilizza 5005.
Per ottenere l'accesso a una shell tramite un attacco RCE riuscito, ho utilizzato un exploit di Metasploit: exploit / multi / misc / java_jdwp_debugger .
Si noti inoltre che tutti gli altri linguaggi basati su JVM (Scala, Kotlin, ecc.) Utilizzano anche JPDA, quindi questo presenta un attaccante con una vasta gamma di potenziali bersagli.
XDebug è diverso da tutti gli altri debugger descritti in questo articolo. Non avvia il proprio server come tutti gli altri debugger. Invece, si riconnette all'IDE. L'IP e la porta dell'IDE vengono memorizzati in un file di configurazione.
A causa della natura di XDebug, non è possibile rilevarlo e attaccarlo utilizzando una scansione delle porte. Tuttavia, con una certa configurazione di XDebug, puoi attaccarlo inviando un parametro speciale all'applicazione web, che lo fa connettere al nostro IDE invece che all'IDE legittimo.
Acunetix include un controllo per una configurazione così vulnerabile.
pdb è un comune debugger Python e il pacchetto remote_pdb (e altri pacchetti simili) consente l'accesso remoto a pdb. La porta predefinita è 4444. Dopo esserti connesso usando ncat, hai pieno accesso a pdb e puoi eseguire codice Python arbitrario.
debugpy è un debugger comune per Python, fornito da Microsoft. Esiste anche una versione deprecata di questo debugger chiamata ptvsd.
debugpy utilizza un protocollo di debug sviluppato da Microsoft - DAP (Debug Adapter Protocol). Si tratta di un protocollo universale che può essere utilizzato anche per debugger per altre lingue. Il protocollo è simile ai messaggi JSON con un'intestazione Content-Length precedente . La porta predefinita è 5678.
Microsoft utilizza questo protocollo in VSCode, quindi il modo più semplice per comunicare utilizzando questo protocollo è utilizzare VSCode. Se hai VSCode con un'estensione Python predefinita installata, tutto ciò che devi fare è aprire una cartella arbitraria in VSCode, fare clic sulla scheda Esegui e debug , fare clic su Crea un file launch.json , scegliere Python → Collegamento remoto e inserire una destinazione IP e porta. VSCode genererà un file launch.json nella directory .vscode / . Quindi fare clic su Esegui → Avvia debug e quando ti connetti, puoi inserire qualsiasi codice Python nella console di debug sottostante, che verrà eseguito sulla tua destinazione.
La gem ruby-debug-ide ( rdebug-ide ) utilizza un protocollo di testo personalizzato ma semplice. Questo debugger utilizza in genere la porta 1234.
Per eseguire codice arbitrario, puoi usare VSCode e seguire gli stessi passaggi di Python. Nota che se vuoi disconnetterti da un debugger remoto, VSCode invia quit invece di detach (come farebbe RubyMine), quindi VSCode arresta completamente il debugger.
Le versioni di Node.js precedenti alla v7 utilizzano il debugger di Node.js. Questo debugger utilizza il protocollo V8 Debugger (che assomiglia a intestazioni HTTP con un corpo JSON). La porta predefinita è 5858.
Il debugger Node.js consente di eseguire codice JS arbitrario. Tutto quello che devi fare è usare Metasploit con il modulo exploit / multi / misc / nodejs_v8_debugger / .
Le versioni più recenti di Node.js utilizzano Node.js Inspector. Dal punto di vista dell'aggressore, la differenza principale è che ora viene utilizzato il protocollo di trasporto WebSocket e la porta predefinita è ora 9229.
È possibile utilizzare diversi metodi per interagire con questo debugger. Di seguito puoi vedere come farlo direttamente da Chrome, utilizzando chrome: // inspect .
Delve è un debugger per Go. Per il debug remoto, Delve utilizza il protocollo JSON-RPC, tipicamente sulla porta 2345. Il protocollo è piuttosto complesso, quindi è assolutamente necessario utilizzare, almeno, approfondire se stesso ( dlv connect server: port ).
Go è un linguaggio compilato e non sono riuscito a trovare un modo diretto per ottenere RCE come con altri linguaggi. Pertanto, ti consiglio di utilizzare un IDE appropriato (ad esempio, Goland) perché dovrai eseguire un po 'di debug da solo per poter ottenere RCE. Nota che il codice sorgente non è necessario ma è utile.
Di seguito è riportato un esempio di connessione a Delve utilizzando Goland.
Approfondire fornisce un modo per richiamare le funzioni importate in un'applicazione. Tuttavia, questa funzionalità è ancora in fase di beta testing e non consente di passare stringhe statiche come argomenti di funzione.
La buona notizia è che possiamo modificare i valori delle variabili locali e passarli a una funzione. Pertanto, dobbiamo mettere in pausa un'applicazione in un thread non runtime all'interno di un ambito che ci interessa. Possiamo usare le librerie standard per questo.
Di seguito puoi vedere come mettere in pausa un'applicazione su una libreria HTTP standard e invocare la funzione os.Environ () , che restituisce l' env dell'applicazione (eventualmente contenente dati sensibili). Se si desidera eseguire comandi del sistema operativo arbitrari, è necessario eseguire exec.Command (cmd, args) .Run () . Tuttavia, in tal caso, è necessario trovare e fermarsi in una posizione con variabili di tipo String e [] String .
Gdbserver ti consente di eseguire il debug delle app in remoto con gdb. Non ha funzioni di sicurezza. Per la comunicazione, utilizza uno speciale protocollo di testo normale: il GDB Remote Serial Protocol (RSP).
Il modo più conveniente per interagire con questo debugger è usare gdb stesso: target extended-remote target.ip: port . Notare che gdb fornisce comandi molto convenienti get remote e remote put (ad esempio, remote get remote_path local_path ), che consentono di scaricare / caricare file arbitrari.