CMS Fingerprinting – II

En el anterior post vimos cómo tratar de identificar un portal web y su versión, principalmente mediante análisis de contenido dinámico como metatags y cookies. En esta ocasión vamos a ver cómo funciona el fingerprinting web basado en contenido estático.

El fingerprinting web de contenido estático se basa en los directorios y ficheros estáticos, como imágenes, txt, html, JavaScript, etc, así como en sus hashes. ¿Qué es un hash? Un hash no es más que el resultado de una serie de operaciones matemáticas cuya finalidad es identificar de forma casi unívoca a un único documento, texto, etc. Se basan en que, para una única salida, no deberían existir dos entradas distintas. Esto quiere decir que, un hash dado, identifica únicamente a un fichero concreto.

Para poder identificar las distintas versiones de un sistema CMS primero es necesario realizar diversas acciones:

• Descargar las versiones de las que se desea realizar la tabla de fingerprinting
• Calcular los hashes de los ficheros estáticos, preferiblemente de aquellos que aparezcan de forma más específica y, por tanto, más significativa según la versión
• Intentar limpiar recursos no accesibles normalmente, como aquellos correspondientes a zonas de administración

Una vez se haya realizado dicha acción se tendrá algo parecido a lo siguiente (la imagen es de Patrick Thomas, autor de BlindElephant):

Disponiendo ya de la tabla de directorios, recursos y sus respectivos hashes, sólo queda intentar obtener los ficheros que sean necesarios para identificar correctamente la versión, tal y como se ve en la siguiente imagen:

Como ejemplo, vamos a utilizar blind elephant para tratar de identificar la versión de Wordpress utilizada por un sitio aleatorio.

Lo primero que haremos será listar los CMS que BlindElephant es capaz de detectar, para ello podremos ejecutar z0mbiehunt3r@ph0b0s:~/pentesting/www/blindelephant/$ ./BlindElephant.py -l y veremos dicha lista. 

Para intentar detectar la versión de Wordpress utilizada de la forma más exacta posible ejecutamos BlindElephant con el comando z0mbiehunt3r@ph0b0s:~/pentesting/www/blindelephant$ ./BlindElephant.py http://tastykitchen.com/ wordpress

Después de obtener unos pocos ficheros, 15 por defecto, comportamiento que podemos cambiar mediante el argumento -n , se nos muestran los resultados obtenidos mediante análisis de ficheros estáticos, tal y como vemos a continuación:

Como hemos visto, BlindElephant es una buena opción a la hora de tratar de identificar la versión de algunos gestores de contenido. Espero que os sirva.

CMS Fingerprinting – I

Durante las auditorías web es común necesitar identificar las tecnologías utilizadas así como cualquier posible sistema web y sus versiones, como pueda ser un sistema de foro, un CMS de blog, etc.

Según la metodología utilizada para ello disponemos de diversas herramientas, en este primer post vamos a ver cómo realizar la identificación del CMS utilizado gracias a un análisis de contenido dinámico.

Para ello, vamos a utilizar el programa WhatWeb, de la empresa morningstar IT security. WhatWeb utiliza, por defecto, una única petición HTTP y analiza las cabeceras de las mismas para intentar obtener información acerca de la solución software utilizada y su posible versión, veamos un ejemplo:

Sin indicarle ninguna opción, WhatWeb ha realizado una petición a la dirección indicada y ha analizado diversa información como cabeceras, metatags, cookies, etc, detectando un sistema de foros PHPBB versión 3.

Además de realizar un análisis de contenido dinámico, WhatWeb tiene la posibilidad de aumentar el intento de pruebas para obtener mayor información de la versión utilizada.

Pongamos un ejemplo, estamos realizando una auditoría web y hemos obtenido que la página web en cuestión utiliza Joomla, pues bien, con WhatWeb podremos intentar obtener información acerca de la versión utilizada de la siguiente manera:

Como podemos ver, ha acotado bastante la versión de Joomla utilizada, sólo ha hecho falta indicarle el plugin a utilizar para las pruebas (actualmente WhatWeb cuenta con casi 900 plugins...) y decirle el nivel de agresividad que queríamos utilizar.

En siguientes entradas veremos otros métodos de fingerprinting de página web.

Análisis estático de código con RATS

Durante el proceso de desarrollo, o mantenimiento, de software es necesario prestar atención a todos los aspectos relacionados con la seguridad del mismo y no únicamente al aspecto y/o funcionalidades del mismo.

Entre las acciones que se han de llevar a cabo para vigilar el nivel de calidad en cuanto a términos de seguridad se refiere, nos encontramos con la auditoría de seguridad de caja blanca de todo el código fuente. A pesar de que dicho proceso pueda realizarse manualmente revisando miles y miles de líneas de código es una tarea repetitiva y tediosa que puede automatizarse en gran medida.

Existe gran diversidad de software destinado a ayudar a la auditoría de código (semi)automatizada y, dependiendo del lenguaje auditado, de las necesidades de creación automatizada de informes, etc, necesitaremos usar uno u otro.

En este caso vamos a utilizar RATS (Rough Auditing Tool for Security), de la empresa Fortify y disponible como herramienta Open Source, para analizar de forma estática un programa en C y buscar de forma fácil vulnerabilidades en el mismo.

Para ello, vamos a utilizar el siguiente código:

int main(int argc, char *argv[]){

char buffer[10];

strcpy(buffer, argv[1]);

}

Es un código muy simple que, lo único que hace, es copiar el primer parámetro que se le proporcione en el array de char llamado buffer, sin realizar ningún tipo de comprobación previa. Ello, dependiendo de dicho parámetro, puede conducir a un stack buffer overflow, lo que podría provocar la ejecución de código arbitrario mediante la explotación de dicha vulnerabilidad. Es un ejemplo simple, pero nos servirá para la prueba de RATS.

Primero será necesario instalar RATS, o bien con un conocido ./configure, make, make install o bien directamente del repositorio según la distribución.

La forma más sencilla de ejecución de RATS es indicando únicamente el fichero, o directorio, que contiene el código fuente a auditar.

Como podemos ver en la imagen, RATS ha encontrado que se utiliza un buffer de tamaño fijo, así como la función strcpy, y nos avisa de que ambas acciones son peligrosas y pueden conllevar un desbordamiento de memoria.

Entre las distintas opciones disponibles, existe una que considero que puede resultar de gran utilidad, la opción --xml. Con ella, la salida de RATS se nos mostrará formateada en XML, por lo que podremos volcarlo a un fichero para su posterior tratamiento.

Un ejemplo de dicho tratamiento podría ser un script de entrada en un repositorio SVN para comprobar el número y gravedad de vulnerabilidades y, según los resultados, permitir o no hacer el commit (gracias Leo por la idea).

Esto es sólo un ejemplo muy sencillo pero que vale para demostrar la utilidad de herramientas como RATS que pueden ayudar en gran medida en los tediosos procesos de revisión de código, siempre sin olvidar que se realiza un contenido estático basado en las funciones utilizadas (en RATS dichas funciones peligrosas se declaran en ficheros XML, lo que permite una rápida modificación o expansión de las mismas) y que siempre será necesaria la revisión manual debido a posibles falsos positivos y/o falsos negativos.

Espero que a alguno de vosotros os sea de utilidad en algún momento, saludos.