Una de las partes más importantes durante una revisión de seguridad, es la de reconocimiento del objetivo mediante la búsqueda de toda la información que sea posible.

Previamente, es interesante realizar un acercamiento al sistema a revisar de manera anónima y con un enfoque indirecto y no-agresivo (reconocimiento pasivo). Con ese objetivo, se pueden utilizar distintas fuentes públicas para encontrar información y todo tipo de datos que pueden resultar muy útiles para posteriores fases del análisis.

El presente artículo se centra en la herramienta SEAT (Search Engine Assesment Tool) por su potencial y simplicidad de uso para el rastreo de vulnerabilidades. SEAT realiza consultas en distintos buscadores según una base de datos interna de términos de búsqueda tales como CGIs vulnerables, google dorks, fallos de seguridad conocidos, etc. Dicha base de datos es fácilmente modificable y extendible.

SEAT tiene otras funcionalidades interesantes como cambiar de forma aleatoria el campo “USER-AGENT” en cada petición a realizar, servirse de PROXYs y optimizar la ejecución de las consultas según el número de threads a utilizar. Todas estas funciones se pueden modificar incluso en tiempo de ejecución.

SEAT está desarrollada en lenguaje Perl + Gtk por Peter Kacherginsky de Midnight Research Labs. Su objetivo es la búsqueda de potenciales vulnerabilidades a partir de información que se puede obtener de diversas fuentes públicas.

La lista de buscadores en la que se basa es fácilmente ampliable y modificable pero, por defecto, utiliza los siguientes:

•    Google
•    Yahoo
•    MSN
•    AltaVista
•    AllTheWeb
•    AOL
•    DMOZ
•    Wayback Machine
•    Netcraft

Para la búsqueda de vulnerabilidades, SEAT se nutre de una base de datos interna que contiene diferentes términos de búsqueda (campos inurl: con vulnerabilidades conocidas, listado de ficheros potencialmente peligrosos como CGIs  o directorios abiertos, etc.). La lista es muy extensa y también es fácilmente ampliable:

./seat/databases:

•    GHDB.xml: Google Hacking.
•    cgis.wmap: listado de CGIs potencialmente vulnerables.
•    dirs.wmap: directorios potencialmente vulnerables.
•    file.wmap: listado de diversos ficheros críticos.
•    filetype.gs: tipos de ficheros a buscar.
•    gdork.gs: Google Dorks.
•    indexof.gs: listado de directorios sensibles abiertos.
•    inurl.gs: inurl.
•    newdb.xml: contiene números de tarjetas de crédito.
•    scan_database.nikto: base de datos de vulnerabilidades del conocido programa nikto.
•    test.xml: fichero de pruebas.
•    url.urlchk: diversas rutas potencialmente sensibles.
•    vuln.nestea: más directorios sensibles.

En sus opciones más avanzadas permite la búsqueda de dominios y sub-dominios y el rastreo indirecto de rangos de direcciones IP. Cabe destacar la sencillez con la que se puede optimizar y personalizar la herramienta para adaptarla a necesidades más específicas.


CASO PRÁCTICO

1. Fase de Preparación

En esta primera fase, se define el objetivo u objetivos para los que hay que buscar información y posibles vulnerabilidades. En cuando a la definición de objetivo, es importante la variable _GLOBAL que usada como objetivo principal hará que la herramienta busque los términos seleccionados de manera indiscriminada, es decir, en vez de buscar errores a partir de un objetivo se busca un objetivo a partir de un listado de vulnerabilidades dado.
Para definir los términos de búsqueda se puede añadir manualmente la consulta que se utilizará o usar alguna o todas a la vez de las vulnerabilidades existentes en las bases de datos que SEAT trae por defecto. Si no se incluye ningún archivo o se utiliza la variable _BLANK se define una plantilla cuya utilidad es el rastreo de direcciones IP y dominios:

Fig 1. Definición del objetivo


Fig 2. Carga (Load queries list from a file) de los archivos de vulnerabilidades y términos que vienen por defecto

Una vez cargados se pueden modificar las consultas desde la misma interfaz:

Fig 3. Modificación de las consultas a realizar

Aquí finaliza la etapa de preparación donde se han definido los distintos parámetros de la búsqueda de vulnerabilidades.

Es recomendable repasar los ficheros que contienen los distintos términos de búsqueda para optimizar tanto la ejecución como el análisis, así como guardar las consultas modificadas en un nuevo fichero que se podrá utilizar posteriormente. Los nuevos términos de búsqueda se aplican a todos los buscadores de manera automática sin tener que modificar los ficheros que los definen.

Fig 4. Creación de un nuevo fichero de consultas personalizadas

2. Fase Ejecución

Una vez definidos los objetivos y los términos a utilizar, se pasa a la fase de ejecución, en la que se llevan a cabo las consultas en distintos buscadores.  Los gráficos de la parte inferior representan los distintos threads en ejecución (un máximo de 15) así como la evolución del análisis.

Fig 5. Número de threads utilizados (15)

Como se ha comentado anteriormente, una de las funcionalidades interesantes es la posibilidad de realizar  cambios en el modo de ejecución y consulta que se aplican en tiempo real.

Fig 6. Opciones a modificar en la consulta realizada

Los cambios que se pueden realizar son:

1. Search Depth: para definir la profundidad de la búsqueda, es decir, cuántas páginas de resultados de los buscadores se quieren tratar.
   
   
2. Use Mined Results: usar información relacionada, extraída a partir del objetivo original. Si se detectan nuevos dominios se utilizarán para aplicar en nuevas búsquedas. Las opciones son:
   
   • Never: no tratar nuevos dominios encontrados nunca, tampoco los añade a la lista de objetivos para su análisis posterior.
   • Save for Later: incluir los resultados encontrados en la lista de objetivos para su posterior tratamiento. Posteriormente, se podrá decidir cómo tratar nuevamente a estos resultados.
   • Immediately Request: utilizar los nuevos resultados encontrados en tiempo real, aplicando las búsquedas que se han decidido en la etapa anterior para el objetivo principal.
   
   
3. Sleep time between runs: el tiempo de espera entre dos búsquedas consecutivas en un mismo hilo (thread). Valores altos impedirán saturar el proxy en caso de utilizarlo y harán que los buscadores no penalicen las consultas desde con captchas o similares.
   
   Con valores bajos, se conseguirán resultados más rápidos pero se utilizan más recursos de red (ancho de banda) y también es posible que los buscadores bloqueen las peticiones realizadas por realizar demasiadas consultas.
   
   
4. Number of threads: el número de threads a usar. Dependerá de los recursos  que haya disponibles (capacidad de proceso, ancho de banda).
   
   
5. User-Agent: define la cabecera USER-AGENT que SEAT utilizará en las consultas. Destacar la opción Random-BOT o Random-Browser que habilitará la función de cambio automático de USER-AGENT en las consultas. SEAT contiene una lista predefinida de 13.400 USER-AGENTs diferentes que se pueden ampliar añadiéndolos en ./user-agents/browser_list.txt, en el mismo directorio también está el fichero robots.txt, que contiene un listado de 270 robots.
   
   
6. Proxy Server: configuración del servidor proxy a utilizar con el formato ip:puerto. Tal y como indica la documentación, en caso de recibir mensajes de error tipo “connection error” se deberá modificar las opciones utilizando menos threads y aumentando el tiempo de espera(sleep between runs) entre búsquedas para no saturar el proxy (ni los buscadores).
   
   

En esta fase es posible incluir  y modificar las definiciones de motores de búsqueda o se puede cambiar directamente el fichero seat/searchengines/default.xml:

Fig 7. Modificación de las definiciones de los motores de búsqueda

3. Fase Análisis

Una vez finalizada la búsqueda, en la etapa de análisis se puede consultar los resultados obtenidos y realizar un tratamiento a posteriori de la información recolectada. Dependiendo de la configuración de la opción Mine Results, se podrá escoger los nuevos objetivos (posibles sub-dominios)  para empezar una nueva etapa de ejecución.

Fig 8. Análisis de los resultados obtenidos

También se pueden seleccionar los resultados y hacer otro tipo de consultas a:

•    Visita directa del resultado.
•    Consulta sobre el resultado en Netcraft.
•    Consulta sobre el resultado en Archive.org.
•    Consulta sobre el resultado en Google Caché.

Fig 9. Ver los resultados según Netcraft, Archive.org o la caché de Google

Para finalizar, únicamente queda generar el informe mediante la opción Save results to file, que permite guardar en formato HTML un análisis detallado de todo el proceso y sus resultados.

Fig 10. Reporte obtenido