Informazioni

Questo è il posto dove pubblicherò analisi di exploit pubblici, o alcuni dei miei exploit 1day.

[ Analisi di exploit pubblici ]

• Personalmente penso che il modo migliore per imparare un exploit pubblico sia comprenderlo riga per riga finché non lo capisco appieno. Pubblicherò alcuni di questi exploit (eccessivamente commentati ;) ) così, si spera, altri possano imparare da essi, e come tentativo di restituire qualcosa alla comunità. Anche per scopi di documentazione, perché queste cose tendono a svanire dalla mia mente con il passare del tempo.

CVE-2016-8655

• Questa è un'analisi dettagliata dell'exploit di rebel.
• Grazie rebel per l'incredibile exploit! :D

CVE-2016-5342

versione mp3

• Questa è una versione commentata dell'exploit LPE Android di freener
• arm32
• Overflow dell'heap
• Questo exploit sovrascrive direttamente un puntatore a funzione di un altro oggetto.

versione tty

• Questa è una versione commentata dell'exploit LPE Android di freener
• arm32
• Overflow dell'heap
• Questo exploit sovrascrive un puntatore a oggetto in un altro oggetto. Usa l'attacco ret2dir per far puntare il puntatore corrotto a un indirizzo fisso prevedibile nel kernel che contiene il payload dell'exploit. Questa tecnica di exploit bypassa PXN e PAN.

CVE-2016-2434

• Questa è una versione commentata dell'exploit LPE Android di Jianqiang Zhao
• arm64
• Azzeramento di 16 byte a un indirizzo arbitrario
• Questo exploit azzera 16 byte di un utile oggetto globale, che si trova a un indirizzo fisso nel kernel.
• Un puntatore a oggetto corrotto all'interno dell'oggetto globale fa riferimento al payload dell'exploit proveniente dallo userland. Questo tipo di attacco non funziona su dispositivi/kernel con PAN (o emulazione PAN).

extra_recipe

• Il mio tentativo di comprendere il jailbreak extra_recipe
• Ero particolarmente interessato alla parte di bypass del KPP. Sebbene ci fossero un paio di slide sull'argomento da cui potevo intravedere un'immagine vaga del bypass, volevo davvero approfondire i dettagli più fini e vedere cosa succede realmente all'interno del codice.
• Volevo anche comprendere gli ingredienti finali per un jailbreak (installare Cydia, ecc.).

yalu102 (ViewController.m)

• Ho commentato la parte relativa al bug effettivo e a come è stato sfruttato.
• Il motivo per cui ho analizzato yalu102 invece dell'exploit originale è che la tecnica port-feng-shui sembrava più pulita e semplice da capire.
• L'analisi si ferma subito prima del bypass del KPP.

extra_recipe-master di xerub (jailbreak.c, unjail.m, patchfinder64.c, pte_stuff.h)

• Passo qui perché conteneva qualche informazione in più sui vari offset numerici.
• Inoltre, patchfinder.c è intatto, a differenza di yalu102 di cui esiste solo un file oggetto.
• La parte relativa a Cydia è piuttosto incompleta, quindi passo al ramo cydia dopo il kpp.

extra_recipe-cydia di xerub (unjail.m)

• Cerco di capire gli ingredienti per un jailbreak dopo tfp0 e la fase di post-exploitation.

empty_list (sploit.c)

• Un'analisi dettagliata dell'exploit del kernel empty_list di Ian Beer.
• Usa tecniche sorprendenti per partire da primitive davvero deboli, costruire un AAR più robusto e infine creare un task port completo. La magia dei port dietro il codice dell'exploit è incredibile. Tutto questo con un overflow dell'heap di 8 byte NULL. Semplicemente sbalorditivo.
• Ho annotato alcune idee ingenue per migliorare l'affidabilità. Spero che in futuro qualcuno rilasci una versione più affidabile dell'exploit. :)
• Grazie Ian Beer per l'incredibile exploit!

CVE-2018-4233

• Questa è una versione commentata dell'exploit WebKit per iOS di @niklas_b.
• Un enorme ringraziamento a kudima (@begger_dd) per il writeup molto chiaro, conciso e accuratamente annotato! :)
• Il writeup spiega il bug di type confusion nella JIT, alcune limitazioni sulle conversioni di boxing/unboxing (che potrebbero introdurre inaffidabilità), e una dettagliata panoramica su come vengono costruite le primitive AAR/AAW iniziali/finali. Fornisce inoltre approfondimenti sui cambiamenti nelle tecniche di exploitation dopo l'ultima serie di mitigazioni (index masking, avvelenamento del backing store di ArrayBuffer, alcune modifiche al meccanismo della JIT W^X, cambiamenti nella struttura di JSObject, ecc.)

jsc_ConcatMemcpy_infoleak

• Questa è una versione commentata dell'exploit di infoleak WebKit di kudima (corretto il 2018.8.27).
• Deriva da una correzione incompleta di uno dei bug segnalati da lokihardt. La patch della segnalazione di lokihardt ha corretto la primitiva di type confusion Double -> Object, ma non ha corretto il caso opposto: Object -> Double.
• Esegue lo spray dell'heap di WebKit con butterfly contenenti un singolo oggetto e un marker, quindi innesca il bug di concat e riempie gran parte di diversi array di double con dati di heap non inizializzati. Itera attraverso gli array di double non inizializzati prodotti dal concat difettoso finché non trova l'indirizzo dell'oggetto precedentemente spruzzato e lo rivela (leak).
• Ancora grazie a kudima (@begger_dd) per il bell'exploit e il writeup! :)

jsc_prop_enum_uaf

• Questo è un altro contributo di kudima. È una versione commentata dell'exploit di esecuzione di codice remoto WebKit di kudima (corretto in questo commit). È corretto in iOS 12.1 e funziona fino a iOS 12.0.1.
• Il problema è che durante l'esecuzione di codice nei loop forin compilati dalla baseline JIT, si può introdurre codice che libera l'oggetto StructureID che supporta l'oggetto JSOBject e innescare il garbage collector, ma il garbage collector non marca il membro "JSPropertyNameEnumerator->m_cachedStructureID", e l'oggetto StructureID a cui punta "JSPropertyNameEnumerator->m_cachedStructureID" viene liberato durante la fase di sweep, risultando in un puntatore pendente.
• Dopo che l'oggetto StructureID viene liberato con il GC, si può introdurre codice che crea un nuovo oggetto StructureID, il quale occupa lo slot del "StructureID object" precedentemente liberato.
• Liberando lo StructureID dell'oggetto A e poi facendo sì che l'oggetto B crei un nuovo StructureID che prende il suo posto, è possibile creare una situazione di type confusion perché "JSPropertyNameEnumerator->m_cachedInlineCapacity" è impostato alla dimensione delle proprietà inline dell'oggetto A, mentre "JSPropertyNameEnumerator->m_cachedStructureID" punta al nuovo oggetto Structure ID che rappresenta l'oggetto B. Questo fa superare un controllo in 'op_get_direct_pname' e permette all'oggetto B di accedere a proprietà inline al di fuori dei suoi limiti.
• Questo può essere abusato per costruire primitive più forti come AAR/AAW e successivamente usarle per eseguire codice arbitrario.
• Grazie a kudima (@begger_dd) per il figo exploit e il writeup molto dettagliato! :)

[ 1Day ]