Come funziona lo sviluppo degli exploit per i penetration tester?

Question

Come funziona lo sviluppo degli exploit per i penetration tester?

#1 da (6 voti)
#2 da (3 voti)

4

Durante lo sviluppo di exploit, il processo si basa sempre sull'indirizzo di memoria della macchina della vittima.

Come sviluppatore di exploit, dovrai configurare un ambiente di macchine attacker \ victim e provarci. I principali lead per lo sviluppatore di exploit nel suo percorso verso l'acquisizione di una shell dall'app vulnerabile sono l'indirizzo di memoria (principalmente le posizioni dei buffer e delle DLL) che ottiene collegando l'app a un debugger (solitamente indicato dai registri della CPU come EIP, ESP, ecc.)

Questo è utile se l'obiettivo finale è quello di fornire una prova di codice concettuale per dimostrare che questa applicazione è vulnerabile. Tuttavia, per quanto ne so, questi indirizzi non sono permanenti e possono cambiare da macchina a macchina. Se stai facendo il Black Penetration Test per un'azienda, non sarai in grado di collegare un debugger alla loro applicazione per ottenere il giusto indirizzo a cui saltare. E lo stesso vale per gli exploit pubblici di exploit-db perché la maggior parte degli exploit in questo caso richiede un po 'di correzione per quanto riguarda gli indirizzi e gli offset.

Quindi la mia domanda è: in che modo un penetration tester può trarre vantaggio dalla scrittura di tali exploit (o dal scaricamento di uno da exploit-db) come tester di penetrazione e non come sviluppatore di exploit?

penetration-test exploit-development

posta HSN 05.03.2016 - 14:51

fonte

2 risposte

3

Ti stai chiedendo come lo shellcode possa sconfiggere la randomizzazione del layout dello spazio degli indirizzi, ma questo non è immediatamente chiaro dal modo in cui hai formulato la tua domanda. L'arte di "Return Oriented Programming" (ROP) si è evoluta per affrontare questa sfida. L'obiettivo di ROP è di assicurarsi che l'indirizzo di ritorno per qualsiasi esecuzione di codice sia in uno spazio di indirizzi che è stato pre-approvato per l'esecuzione perché risiede nello spazio degli indirizzi utilizzato da uno o più moduli (o "gadget" come vengono chiamati nel linguaggio ROP) che fa già parte del programma originale che è stato sfruttato o in una libreria che può essere legittimamente chiamata dal programma sfruttato. Se il programma iniziale e le librerie associate sono collocati in una posizione casuale, la posizione casuale dovrà essere scoperta. Qui, ad esempio, ci sono metodi per bypassare ALSR:

Moduli target non-ALSR. Alcuni software non sono compilati per obbedire ad ALSR e non lo rispetterò. Molti degli attacchi ai plugin di JRE6 browswer si basavano su questo. fonte
Trovare l'indirizzo iniziale dell'eseguibile e dedurre il resto. Ad esempio, questo exploit di Adobe Reader trova l'iniziale indirizzo e usa la capacità di manipolare i puntatori e quindi "leggere il vtable" per posizioni di memoria e così libero dalla memoria hardcoded posizioni. Cioè, può contare su posizioni di memoria relative una volta questo è fatto.

When doing exploit development, the process always relies on memory address from the victim's machine.

Questa affermazione iniziale è sbagliata. Non tutti gli exploit sviluppati per Metasploit o elencati in exploit-db dipendono dalla capacità di eseguire shellcode. Forse stavi solo chiedendo di questi tipi come hai menzionato un debugger, ma nel caso, considera il seguente exploit da exploitdb:

link nessun luogo di memoria coinvolto. Metasploit utilizzerà una funzione di caricamento di file non autenticato per caricare un file JSP a cui è possibile collegarsi e inviare comandi al sistema.

risposta data 05.03.2016 - 20:40

fonte

Leggi altre domande sui tag penetration-test exploit-development

Come potrebbe honeypot essere vulnerabile? qual è una sfida valida per l'autenticazione a 2 fattori?

score 6 · Accepted Answer

La modifica degli indirizzi su ogni avvio è denominata Address Space Layout Randomization (ASLR). Insieme a Data Execution Prevention (DEP), ASLR è uno dei più efficaci controlli di sicurezza contro gli exploit di corruzione della memoria. Leggi le risposte eccellenti su Come funzionano DEP e ASLR . Tuttavia, quando vengono creati exploit di overflow del buffer che puntano a qualcosa sopra Windows XP (praticamente tutto oggigiorno), l'ASLR viene bypassato usando alcune tecniche. Il più comune è il trasferimento dell'esecuzione del codice a un modulo non ASLR abilitato che viene caricato all'indirizzo fisso o previsto. La maggior parte degli exploit di IE target IE8 e IE9 utilizza uno dei due moduli (MSVCR71.dll e HXDS.dll) poiché entrambi sono non ASLR e vengono caricati nel processo IE (per impostazione predefinita o possono essere attivati facilmente) .

La maggior parte degli exploit flash utilizza una tecnica in cui la lunghezza dell'array vettoriale viene sovrascritta e vengono letti più dati del previsto. Quando l'autore dell'attacco è in grado di leggere dati di lunghezza arbitraria all'interno della memoria del processo sfruttato, può essere utilizzato per trovare gli indirizzi delle DLL comuni da cui è possibile creare i gadget ROP. Puoi trovare ulteriori dettagli nell'eccellente articolo di Haifei Lei qui . Se vuoi leggere del codice che è in grado di bypassare ASLR, dai un'occhiata al codice exploit utilizzato da Metasploit qui .

In breve, ASLR insieme a DEP è un'eccellente soluzione. Tuttavia, le tecniche sono lì per aggirarlo in certi casi per uno sfruttamento affidabile.