Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner EN flag

Articoli

Icona delle News




Debugger remoti come vettore di attacco

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.

Frutti bassi

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.

Attacchi ai debugger

Java (JVM) / JPDA

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 .

Banner

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.

PHP / XDebug

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. 

Python / pdb / remote_pdb

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.

Python / debugpy / ptvsd

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.

Ruby / ruby-debug-ide

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.

Node.js / 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.

Banner

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 / .

Node.js / Inspector

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 .

Golang / Delve

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

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.

 


Articoli su Sicurezza

Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft