domingo, 26 de julio de 2015

Fingerprinting en Joomla

¡Saludos!

<TL;DR;>

He hecho un script para sacar la versión de los Joomla, así como qué plugins con vulnerabilidades conocidas posee (y link al exploit). Ventajas frente a Joomscan, JoomlaScan, el escáner de Metasploit, etc.: está actualizado para hacer fingerprint a las versiones recientes de Joomla y la base de datos de componentes es mayor.

Kum0nga => https://github.com/0verl0ad/kum0nga

</TL;DR;>


Ahora vayamos al turrón.

Extraer la versión de Joomla

Prácticamente en todos los CMS el proceso de identificación de la versión que anda utilizando la página web objeto de la auditoría viene determinada por dos opciones:

  • Localizar ficheros donde explícitamente se indique la versión instalada
  • Detectar detalles que únicamente aparezcan en una determinada versión
El primer caso sería lo ideal, pero si el administrador de la web ha hecho bien sus deberes eliminará todos los puntos desde los cuales el auditor pueda extraer la información de forma directa.

En joomla podemos encontrar la versión, tal cual, en diferentes ficheros accesibles a través del navegador. Por ejemplo, un buen sitio donde mirar es en el archivo "joomla.xml" que queda alojado en la ruta /administrator/manifests/files/joomla.xml






Por otra parte los archivos XML generados en los packs de lenguajes también puede aportarnos información acerca de la versión, por ejemplo /language/en-GB/en-GB.xml






 En la imagen de arriba se observan también nombres de componentes, sobre eso hablaremos más tarde.

  Cuando estos archivos jugosos no se encuentran accesibles, o les han sido extirpados los datos relevantes, podemos recurrir a realizar un fingerprint de la plataforma. Para ello, lo ideal, es realizar un análisis a todas las versiones de Joomla para hallar diferencias que permitan acotar ante qué versión nos encontramos.

Para que nos entendamos, imaginemos que en la rama 2.X y 3.X en un archivo .JS aparece una determinada línea. Si comprobamos ese archivo en una web, y está sabremos que pertenece a la rama 2.X o a la 3.X (y si no lo está sabemos que no pertece a esas ramas). A continuación buscaríamos algo que sólo estuviese en una de esas ramas, y así continuamente, hasta dar con la versión instalada.

Por suerte para nosotros ya hay personas que han buscado estas diferencias y ya han hecho parte del trabajo (un buen punto de partida es este post https://www.gavick.com/blog/how-to-check-the-version-of-joomla . Esto que nos ahorramos.

Para ganar precisión (y actualizar a las nuevas versiones) procedí a descargarme todas las versiones de joomla publicadas y hacer diffing para encontrar diferencias. Fruto de ello es el script kum0nga que actualmente utilizo para la identificación de la versión. Todavía se podría llegar a afinar mucho más la versión (en muchos casos indico entre y qué versión puede estar, pero no la exacta), pero eso se lo dejo a la gente que quiera colaborar.

Cabe decir que a veces existen discrepancias entre las versiones extraídas directamente, ya que a veces al actualizar algunos ficheros no son cambiados y podemos encontrar que en archivo de lenguaje aparece una versión más antigua que en el joomla.xml, por ejemplo. Ante estos casos el fingerprint es la única salida para estar seguros.

Detectar componentes instalados

 Como vimos en la imagen anterior, a veces los plugins generan entradas en los archivos de lenguaje. Otras veces los ficheros que aparecen listados existen realmente pero no han sido linkeados al .xml, por lo que si accedemos (por ejemplo /language/en-GB.com_weblinks.ini) y vemos que existe el fichero, ese plugin estará instalado. 

  En el fondo, al igual que ocurre con el resto de los CMS, la detección de si un plugin se encuentra instalado o no se reduce al envío de peticiones HTTP a rutas de instalación, y comprobar la respuesta del servidor.

Las rutas habituales de instalación son /components/com_nombre del componete. Por ejemplo, si queremos saber si está instalado weblinks, mandaríamos una petición a url-falsa.com/components/com_weblinks.

En muchas ocasiones podemos llegar a determinar incluso la versión del componente instalado a través de ficheros .xml. Ficheros comunes son los manifest.xml, index.xml, y readme.xml. 

Kum0nga

Se trata de un pequeño script que he hecho para cuando me toca trabajar con Joomla. Básicamente realiza un fingerprint más acertado (aunque todavía queda mucho por mejorar) y actualizado que el resto de herramientas que se encuentran en internet (incluyendo el escaner de Metasploit). 

La lista de componentes que detecta está directamente extraída (scrapeada cutremente y que habría que añadir tropecientos plugins más vulnerables, pero eso lo iré haciendo poco a poco) de joomlaexploit.com. La idea es ir actualizando la base de datos cada dos semanas o mensualmente. 



Kum0nga => https://github.com/0verl0ad/kum0nga



 Espero que os sea de utilidad

Byt3z!

 

 
5 0verl0ad Labs: julio 2015 ¡Saludos! <TL;DR;> He hecho un script para sacar la versión de los Joomla, así como qué plugins con vulnerabilidades conocidas pos...

jueves, 16 de julio de 2015

Espiando a los vecinos pasivamente

¡Saludos!

  La semana pasada tras el Hack & Beers salimos a tomar un par de copazos. Hubo un momento durante la noche en la que me percaté que dos de las personas que allí estaban vivían en el mismo edificio y que una tercera vivía y tenía su oficina relativamente cerca a mi piso.

En ese momento mi mente empezó a cavilar algunas ideas que empezaría a poner en marcha ese mismo fin de semana. La premisa de la que partía era: ¿Qué información útil puedo obtener de forma no intrusiva de mis vecinos? La meta que me marqué era poder llegar averiguar las rutinas y horarios que mis vecinos tenían, es decir, cuando andaban en casa y cuando no.

Hoy en día todo el mundo tiene wifi en su casa, y dispositivos móviles que les acompañan en su día a día, por lo que si consigo asociar qué dispositivos corresponden a cada piso, podré saber cuando están en casa o no. Por lo tanto el problema lo podemos desglosar en dos puntos a completar:

1.- Averiguar cuando un dispositivo está conectado a la red, y mantener una trazabilidad en el tiempo.

2.- Averiguar qué red corresponde a cada piso.

Esto es algo muy viejo y que varias a veces ha salido a la luz por centros comerciales que utilizaban estas tácticas para trackear a los usuarios (además de con el Wifi, antiguamente con el bluetooth). Lo mío es una simple implementación de andar por casa.

Quien está conectado a que

Los dispositivos móviles emiten contínuamente paquetes Probe Request en modo broadcast, con el fin de mapear qué redes hay alrededor. Estos paquetes Probe Requests contienen la dirección MAC del dispositivo, por lo tanto ya tenemos un elemento que nos aporta la trazabilidad necesaria de los individuos (es muy difiicl que nos vayamos a encontrar dos macs identicas).

Dentro de los paquetes Probe Requests que vayamos pescando deberemos de diferenciar dos grupos: "itinerantes" y "vecinos". Los itinerantes son aquellas personas que simplemente pasean por la calle, y los vecinos son las personas que realmente nos interesan. Más adelante veremos cómo quedarnos sólo con la parte que nos interesa.

Para detectar las redes podemos basarnos en los paquetes Beacons y en los Probe Response. En caso de que la red esté oculta y haya alguien conectado podremos sacar el ESSID a través de los Probe Response; si no hay nadie conectado deberemos de bruteforcear el nombre, ya que de los paquetes podemos sacar el tamaño del ESSID.

Ya tenemos clientes y redes. Ahora toca averiguar quien está conectado a qué, y para ello necesitamos capturar algún paquete donde aparezcan ambos datos (cliente y AP). La respuesta son los paquetes RTS.


En estos paquetes vamos a tener la mac del dispositivo y la de AP, por lo que como previamente sabemos cuales son las macs de los AP, es trivial sacar quien está conectado a qué.

Toda esta parte ya la programé en un ñapa script en NodeJS hace un año (https://github.com/0verl0ad/wifi-scan-js ). Para nuestro propósito básicamente le he añadido la capacidad de volcar cada 20 minutos la información dentro de una base de datos SQLite, de esta forma podremos tener un histórico de cuando han estado conectados los clientes, y de esta forma poder trazar visualmente los horarios de las personas. Además, a través de las direcciones mac se pueden saber los fabricantes de las tarjetas de red y a partir de ahí identificar qué moviles / ordenadores usan esas personas.

Pero no es oro todo lo que reluce. Los dispositivos móviles cuando no están en movimiento, o no están en uso, disminuyen o dejan de enviar prácticamente Probe Request con el objetivo de ahorrar batería. Se entiende que al estar sin moverse en un mismo punto las redes wifi alrededor no van a modificarse, van a ser las mismas.

Esto puede ser un problema si no lo tenemos en cuenta a la hora de representar los datos obtenidos y obtener conclusiones. De los datos observados, es fácil determinar cuando esa persona entra o sale de su casa por la cantidad de paquetes y el vacío que hay cuando abandona el edificio.

Ya hemos completado la primera parte, vayamos al siguiente punto.


¿A qué piso corresponde cada red?

Hay muchas formas de poder responder a esta pregunta. En mi caso no quería parecer un bicho (aun más) raro, por lo que descarté ir por el edifico con el portátil y la antena haciendo mediciones.

Para pasar más desapercibido opté por utilizar una aplicación móvil que hiciera las mediciones. Me decanté por "Wifi Analyzer", que me permitía hacer capturas de la potencia de todas las redes y guardarlas con un nombre identificativo.

La idea es hacer mediciones de la intensidad de la señal cada 2 metros e ir guardando los datos ordenados en una matriz, y posteriormente analizar estos datos para establecer distancias relativas a los puntos de muestreo y así "dibujar" donde estarían los AP.

Los problemas con los que me encuentro en este caso es que la propia forma de la estructura del edificio, junto a las interferencias, hace que en ciertos puntos se falseen los datos porque la cantidad de señal que llega no es la que "debería" de llegar, aparentando que el AP se encuentra más lejos de lo que está en realidad.

Actualmente me encuentro atareado con esta última parte, pero confío en que con un tamaño muestral suficiente y utilizando el sentido común pueda llegar a buen puerto.


Espero haberos dado ideas para entreteneros este verano ;)

Byt3z!



5 0verl0ad Labs: julio 2015 ¡Saludos!   La semana pasada tras el Hack & Beers salimos a tomar un par de copazos. Hubo un momento durante la noche en la que me per...
< >