6 jun 2012

Herramientas forense para ser un buen CSI. Parte VIII

Un caso forense sobre una intrusión web

Buenas a todos, hoy vamos a seguir con la cadena de posts sobre herramientas forense charlando sobre la herramienta notepad++, la herramienta más simple que nos podremos encontrar y una de las más útiles, y si no que se lo pregunten a programadores y analistas, por su genial soporte para multitud de lenguajes y por la posibilidad de incorporar plugins, como el famoso "compare" para comparar diferencias entre archivos. Pero hoy el potencial que querremos explotar de notepad++ no irá relacionado con la programación, si no con el ámbito forense.

Imaginaros que os llaman para realizar un análisis forense a un servidor web, debido a que han aparecido ciertos datos internos de la BBDD en pastebin o porque han desaparecido varias entradas en algunas de las tablas en la BBDD. Después de realizar todo el proceso forense que nos recomienda Juan Luis desde su genial cadena, Un forense llevado a Juicio, llegará la hora de ponernos manos a la obra y contestarnos las preguntas: ¿Qué ha pasado?, ¿Cuándo?, ¿Cómo? ¿Por qué? ¿Quién ha sido?

Para contestarnos a estas preguntas pediremos a los administradores del servidor los logs de acceso de los últimos días o meses (según nuestra intuición y las pruebas que hayamos recopilado en un primer vistazo, cómo metadatos, etc.), porque imaginamos que tendrán logs... ¿o no?, para el post de hoy supondremos que sí.

Para que os hagáis una idea del tamaño que pueden alcanzar estos logs, el log de un solo día de nuestra web www.flu-project.com alcanza las 80.000-100.000 líneas. A continuación os dejo una captura de un log que tenía a mano del pasado mes de Octubre:

¿Habéis probado a abrir un documento de este tamaño con el notepad de Windows?, lo más probable es que se os cuelgue la herramienta y no logréis vuestra misión, pero por el contrario a Notepad++ le basta con 1 segundo para abrirlo (me gusta Notepad++ se nota ¿no? :-) ).

Una vez que hayáis abierto el log, a mi personalmente me gusta aplicar a estos casos el formato del lenguaje SQL (aunque eso dependerá del gusto de cada uno), principalmente porque colorea los números de un color, lo que es útil para destacar las IPs y los estados de las peticiones (200, 404,...), y por otro lado, nos coloreará claramente las posibles inyecciones de tipo SQL, y que será una de las posibles maneras por las que han salido los datos de la BBDD de nuestro cliente.

Cuando se realiza una intrusión web, normalmente se peina el perímetro buscando las dimensiones de la aplicación/aplicaciones y del servidor y los posibles puntos débiles, para ello se suelen usar fuzzers, spiders, herramientas de fuerza bruta y escáneres de puertos, que suelen dejar mucha huella en los logs. Así que podremos echar un vistazo rápido a nuestro log y ver si encontramos muchas peticiones seguidas desde una misma IP, lo cuál destaparía en gran medida las intenciones de nuestro intruso.

Entre las peticiones seguidas que provengan desde una misma IP será útil fijarse en los "User-Agent", quizás os encontréis con algunos datos curiosos, como "Foca", nuestra amiga rosácea o el UA de algún que otro spider conocido. Esto nos dará ya una idea de que hay alguien aburriendose mucho, o de que después nos encontraremos con algunos cañonazos en nuestra muralla. Siguiendo con la búsqueda del User-Agent, puede ser útil buscar el de herramientas que automaticen ataques de inyecciones de tipo SQL, como por ejemplo "havij" y quizás os encontréis con algo como lo siguiente, un Windows XP (versión 5.1) lanzando un ataque automatizado (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij) sobre una petición parecida a la que os mostramos a continuación:

GET webDelCliente.com/aplicacion.asp?noticia=1.1+union+all+select+0xchorizo-- HTTP/1.1" 200

Ya tendríamos las respuestas a las preguntas:

  • ¿Qué ha pasado?: Le han robado a nuestro cliente los datos que sospechaba
  • ¿Cuándo?: La fecha nos la habrá proporcionado el log
  • ¿Cómo?: Han explotado una vulnerabilidad de tipo SQL Injection con una herramienta automatizada de una página asp que no validaba el contenido del parámetro "noticia"
  • ¿Por qué?: Por adivinar
  • ¿Quién ha sido?: Tenemos la IP

Tenemos la dirección IP señores, pero puede haberla camuflado con un proxy (o varios), aunque la experiencia nos dice que antes de camuflar la IP, se suelen realizar "algunas pruebas previas" que pueden servirnos para localizar previamente otros posibles ataques de menor embergadura con patrones similares (es lo que tiene encontrarse con una vulnerabilidad sin querer, y apresurarse a explotarla, o un descuido de principiante)

Otra información interesante a buscar es si desde esa IP se han realizado otro tipo de peticiones (sin ser ataques), para intentar buscar la respuesta a la pregunta ¿Por qué?. Quizás veamos artículos, páginas u archivos en los que haya mostrado nuestro intruso un gran interés.

Llevándolo al extremo, imaginaros que los clientes que os han contratado para realizar el análisis forense sospechan de un miembro de la organización (quizás no sea tan extremo), entonces podríamos seguir rascando los "User-Agent" de nuestra querida IP, y quizás veamos cosas como...

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5F136 Safari/525.20

Curioso, el atacante tiene un iPhone y sabemos la versión y es probable que un compañero de trabajo sepa el móvil que tiene otro compañero de trabajo ¿quizás un iPhone? ¿de eso se suele presumir delante de los compañeros no?

No solo de análisis de inyecciones vive el Analista Forense, será necesario lanzar mil hipótesis, contrastarlas, investigar los hábitos del atacante, sus motivaciones, hasta tenerle rodeado y entonces... dar tu veredicto.

Y ya queda en decisión de nuestro cliente si denunciar el hecho o resolver las cosas "en casa".

Saludos!

No hay comentarios:

Publicar un comentario