Stack Pivoting - EBP2Ret - EBP chaining
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)
Questa tecnica sfrutta la capacità di manipolare il Base Pointer (EBP) per concatenare l'esecuzione di più funzioni attraverso un uso attento del registro EBP e della sequenza di istruzioni leave; ret.
Come promemoria, leave significa fondamentalmente:
E come se l'EBP è nello stack prima dell'EIP, è possibile controllarlo controllando lo stack.
Questa tecnica è particolarmente utile quando puoi modificare il registro EBP ma non hai un modo diretto per cambiare il registro EIP. Sfrutta il comportamento delle funzioni quando terminano l'esecuzione.
Se, durante l'esecuzione di fvuln, riesci a iniettare un fake EBP nello stack che punta a un'area della memoria dove si trova l'indirizzo del tuo shellcode (più 4 byte per tenere conto dell'operazione pop), puoi controllare indirettamente l'EIP. Quando fvuln restituisce, l'ESP è impostato su questa posizione creata, e l'operazione pop successiva diminuisce l'ESP di 4, facendolo puntare effettivamente a un indirizzo memorizzato dall'attaccante lì.
Nota come devi conoscere 2 indirizzi: Quello dove andrà l'ESP, dove dovrai scrivere l'indirizzo a cui punta l'ESP.
Prima devi conoscere un indirizzo dove puoi scrivere dati / indirizzi arbitrari. L'ESP punterà qui e eseguirà il primo ret.
Poi, devi conoscere l'indirizzo utilizzato da ret che eseguirà codice arbitrario. Potresti usare:
Un indirizzo valido ONE_GADGET.
L'indirizzo di system() seguito da 4 byte spazzatura e l'indirizzo di "/bin/sh" (x86 bits).
L'indirizzo di un gadget jump esp; (ret2esp) seguito dal shellcode da eseguire.
Alcuna catena ROP
Ricorda che prima di qualsiasi di questi indirizzi nella parte controllata della memoria, devono esserci 4 byte a causa della parte pop dell'istruzione leave. Sarebbe possibile abusare di questi 4B per impostare un secondo fake EBP e continuare a controllare l'esecuzione.
C'è una variante specifica di questa tecnica nota come "Off-By-One Exploit". Viene utilizzata quando puoi modificare solo il byte meno significativo dell'EBP. In tal caso, la posizione di memoria che memorizza l'indirizzo a cui saltare con il ret deve condividere i primi tre byte con l'EBP, consentendo una manipolazione simile con condizioni più vincolate.
Di solito viene modificato il byte 0x00 per saltare il più lontano possibile.
Inoltre, è comune utilizzare un RET sled nello stack e mettere la vera catena ROP alla fine per rendere più probabile che il nuovo ESP punti all'interno del RET SLED e che la catena ROP finale venga eseguita.
Pertanto, mettendo un indirizzo controllato nell'entrata EBP dello stack e un indirizzo per leave; ret in EIP, è possibile spostare l'ESP all'indirizzo EBP controllato dallo stack.
Ora, l'ESP è controllato puntando a un indirizzo desiderato e la prossima istruzione da eseguire è un RET. Per abusare di questo, è possibile posizionare nel posto controllato dell'ESP questo:
&(next fake EBP) -> Carica il nuovo EBP a causa di pop ebp dall'istruzione leave
system() -> Chiamato da ret
&(leave;ret) -> Chiamato dopo la fine di system, sposterà l'ESP al fake EBP e ricomincerà
&("/bin/sh")-> Parametro per system
Fondamentalmente in questo modo è possibile concatenare diversi fake EBP per controllare il flusso del programma.
Questo è simile a un ret2lib, ma più complesso senza apparenti vantaggi ma potrebbe essere interessante in alcuni casi limite.
Inoltre, qui hai un esempio di una sfida che utilizza questa tecnica con un stack leak per chiamare una funzione vincente. Questo è il payload finale dalla pagina:
Come spiegato in questo post, se un binario è compilato con alcune ottimizzazioni, l'EBP non controlla mai l'ESP, quindi, qualsiasi exploit che funziona controllando l'EBP fallirà fondamentalmente perché non ha alcun effetto reale. Questo è dovuto al fatto che i prologhi e gli epiloghi cambiano se il binario è ottimizzato.
Non ottimizzato:
Ottimizzato:
pop rsp gadgetIn questa pagina puoi trovare un esempio che utilizza questa tecnica. Per questa sfida era necessario chiamare una funzione con 2 argomenti specifici, e c'era un gadget pop rsp e c'era una leak dallo stack:
Controlla la tecnica ret2esp qui:
Ret2esp / Ret2reg64 bit, sfruttamento off by one con una catena rop che inizia con un ret sled
64 bit, no relro, canary, nx e pie. Il programma concede una leak per stack o pie e un WWW di un qword. Prima ottieni la leak dello stack e usa il WWW per tornare e ottenere la leak del pie. Poi usa il WWW per creare un ciclo eterno abusando delle voci .fini_array + chiamando __libc_csu_fini (maggiori informazioni qui). Abusando di questo "eterno" write, viene scritta una catena ROP nella .bss e si finisce per chiamarla pivotando con RBP.
In ARM64, i prologhi e gli epiloghi delle funzioni non memorizzano e recuperano il registro SP nello stack. Inoltre, l'istruzione RET non restituisce all'indirizzo puntato da SP, ma all'indirizzo dentro x30.
Pertanto, per impostazione predefinita, abusando semplicemente dell'epilogo non sarai in grado di controllare il registro SP sovrascrivendo alcuni dati all'interno dello stack. E anche se riesci a controllare lo SP, avresti comunque bisogno di un modo per controllare il registro x30.
prologo
epilogo
Il modo per eseguire qualcosa di simile al pivoting dello stack in ARM64 sarebbe essere in grado di controllare lo SP (controllando qualche registro il cui valore viene passato a SP o perché per qualche motivo SP sta prendendo il suo indirizzo dallo stack e abbiamo un overflow) e poi abusare dell'epilogo per caricare il registro x30 da un SP controllato e RET a esso.
Inoltre, nella pagina seguente puoi vedere l'equivalente di Ret2esp in ARM64:
Ret2esp / Ret2regImpara 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)
