In che modo lo sfruttamento basato su SEH ignora DEP e ASLR?

Question

In che modo lo sfruttamento basato su SEH ignora DEP e ASLR?

#1 da (2 voti)
#2 da (1 voti)

4

Sono nuovo agli exploit basati sulla gestione di eccezioni strutturate.

Perché non inseriamo il nostro indirizzo di ritorno direttamente nel gestore SE per passare al nostro shellcode? (senza SEH sicuro)

Qualcuno può spiegare il motivo dell'utilizzo di pop-pop ret?

Ho letto qualcosa che diceva che SEH ignora ASLR e DEP, ma come?

Il nostro shellcode si troverà nello stack e poiché lo stack non sarà ancora eseguibile, come viene bypassato DEP?

exploit buffer-overflow aslr dep

posta Sani 12.09.2013 - 13:58

fonte

2 risposte

Leggi altre domande sui tag exploit buffer-overflow aslr dep

Come gestire l'Errcode 13 di MySQL quando si tenta di scrivere una shell Intercettazione e lettura del traffico SSL generato da Android

score 2 · Answer 1

link

L'utilizzo di SEH per ottenere exploitation sconfigge né DEP né ASLR.

In particolare, il DEP mitigherà l'esecuzione dello shellcode dalla pagina di memoria dello stack che, in definitiva, era ciò che un exploit basato su SEH sta cercando di ottenere.

Senza un modulo non ASLR nella spaziatura del processo usato per localizzare la chiave di exploit SEH POP POP RET , ASLR rimane per impedire ulteriormente lo sfruttamento.

Come suggerito da Van Jone nel suo commento, ROP (e una perdita di informazioni per la scoperta dell'indirizzo di base del modulo) sono necessari per la sconfitta di DEP e ASLR.

score 1 · Answer 2

Supponendo che lo shellcode sia nello stack, non inseriamo l'indirizzo dello shellcode nell'indirizzo del gestore delle eccezioni (quello che hai chiamato "indirizzo di ritorno") perché Windows ha un meccanismo di base di difesa che impedisce alle eccezioni di saltare agli indirizzi nello stack. SEH è stato abusato comunemente e ripetutamente, e quindi è stato creato. Oggi SafeSEH definisce gli indirizzi esatti che consentono alle eccezioni di passare a loro e quindi con SafeSEH l'attacco non funzionerà.
Usiamo pop, pop, ret perché possiamo facilmente trovare questo codice nel segmento di testo. Come ho spiegato sopra, non possiamo saltare all'indirizzo in pila ma possiamo passare al segmento Testo. pop, pop, ret salta all'indirizzo del prossimo record SEH poiché nel momento in cui il gestore delle eccezioni inizia a funzionare, ESP ne ha 8 byte. Si noti che controlliamo questo valore.

In winDBG:

0:000> !exchain
*0012ffb0*: seh_overflow!ILT+85(__except_handler4)+0 (0041105a)
0012ffe0: kernel32!ValidateLocale+2b0 (7c839ac0)
Invalid exception stack at ffffffff
0:000> g
(614.f68): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
:
0:000> dd esp L4
0012f6f8  7c9032a8 0012f7e0 *0012ffb0* 0012f7fc

A volte non riusciremo a bypassare DEP. Ma, se vediamo che c'è una DLL vulnerabile, possiamo sfruttare chiamando VirtualProtect per cambiare le protezioni di memoria dello stack per includere il bit eseguibile e poi passare allo shellcode.

Ho anche chiesto una domanda sull'argomento, potresti dare un'occhiata a it