24 septiembre 2008

Como detectar peligro REAL con HoneyTokens

Siguiendo la estela de mi anterior post, hoy hablaré de HoneyTokens, un concepto que he visto muy pocas veces comentado y prácticamente en ningún sitio implementado.

Cualquier organización con un equipo de seguridad, tarde o temprano tiene que elaborar informes y tratar de definir de una forma mas o menos precisa métricas que indiquen aspectos como el grado de exposición ante ataques del exterior o el famoso 'nivel de riesgo'. El problema a la hora de abordar esa tarea es que resulta complejo discernir un riesgo real del simple ruido.

Cualquiera que tenga un servidor web expuesto en Internet se puede pasar divertidas horas ojeando los ficheros de logs viendo toda clase de ataques, da igual que la maquina sea un simple servidor web casero o www.google.com, los ataques se suceden día tras día y van desde escaneos buscando una aplicación especifica generados desde algún host comprometido, hasta barridos masivos con herramientas tipo nikto.

Basar el nivel de riesgo en el numero de ataques de este tipo es bastante irreal, porque el 99,9% son búsquedas de aplicaciones que no tenemos instaladas o buscando versiones realmente vetustas. Tratar de implementar una política de anticipación basada en el numero de ataques recibidos es una tarea fútil.

Una forma bastante efectiva de saber cuando hay que poner en rojo todas las alarmas es la implementación de HoneyTokens como sistema de anticipación. Un HoneyToken, básicamente, es una información aparentemente valiosa, que se encuentra escondida para que no pueda ser descubierta fortuitamente, pero a la cual se puede llegar con algo de hacking. La información que contiene el token conduce a un sitio monitorizado para que, cuando el atacante haga uso de esa información, tengamos certeza absoluta de que algo importante está sucediendo.

Un ejemplo de HoneyToken sencillo de entender y de implementar podría ser esconder dentro de la infraestructura web de la organización un fichero en formato excel con un nombre revelador, tipo contraseñas-servicio.xls al cual no se pueda llegar mediante navegación normal pero que si se encuentre indexado por Google. Es importante que ese fichero aparezca en Google si alguien realiza una consulta del tipo: site:www.organizacion.com filetype:xls

Si alguien se está planteando atacar en serio nuestra organización, es casi seguro que recurrirá al famoso "Google Hacking" para recabar información, y normalmente las cosas que se suelen buscar van en la linea de documentos tipo bases de datos access o ficheros excel

En ese fichero, además de poner varios pares usuario/contraseña se le añade como encabezado algo al estilo "Usuarios soporte Callcenter https://callcenter.organizacion.com" para que el atacante sepa donde debe dar el siguiente paso. Este ejemplo es bastante efectivo pero obvio, la forma en la que cada cual lo implemente varía en función de la imaginación y grado de dificultad que se le quiera dar al "reto".

El siguiente punto es implementar una pequeña aplicación-señuelo en la URL que hemos puesto en el fichero excel simulando una aplicación de soporte a usuario. No es necesario implementar la aplicación en si, basta con un frontal donde introducir usuario/contraseña y que en caso de ser correcto, muestre un mensaje de error tipo "No se pudo contactar con la base de datos". Con eso, suficiente. La siguiente parte es montar el sistema de monitorización, en este supuesto bastaría con hacer que la aplicación web, al realizarse un login satisfactorio, envíe un mail avisando.

Versiones mas complejas de esta idea pasan por simular una aplicación web vulnerable a un ataque de tipo SQL Injection en el que se puedan obtener los usuarios para acceder a algún panel de gestión (Se puede tomar como ejemplo WebGoat). El hecho en si de que alguien se tome la molestia de hackear la aplicación, construir las sentencias sql, sacar la lista de usuarios y contraseñas e intentar usarlas, ya debería ponernos en la pista de que algo fuera de lo común está sucediendo sobre lo que debemos actuar urgentemente.

8 comments :

Oscar Acosta dijo...

Se llaman honey pots, no honey tokens y no es nada nuevo bajo el sol.
http://en.wikipedia.org/wiki/Honeypot_(computing)
Saludos

Yago Jesus dijo...

Estimado cubaman, HoneyPot es el concepto genérico, que engloba múltiples tecnologías, como por ejemplo, HoneyTokens http://en.wikipedia.org/wiki/Honeytoken ;)

Asfasfos dijo...

Me parece un tema muy importante a tratar Jesús, espero ansiosamente mas post sobre este tipo de temas y menos comentarios de gente que no tiene ni idea de lo que dice :).

Anónimo dijo...

Cubaman, con todo respeto, te has leido el articulo entero? :)

des dijo...

A mí también me parece interesante, y si alguien conoce alguna aplicación (web, etc) que lo haya implementado, quisiera saberlo :)

Un saludo

Yago Jesus dijo...

Primero de todo, gracias por los comentarios, y respondiendo a des, yo he implementado varias redes de sensores HoneyPot y la experiencia me dice que lo mejor es hacerlo todo artesanal porque si usas cualquier cosa en forma de 'producto' significa que es 'fingerprinteable' y por lo tanto, corres el riesgo de que alguien saque una herramienta para detectarlo y te tire abajo el proyecto. Escribí el post con idea de que fuera conceptual para que sirviera como inspiración y cada uno le diera su toque personal. Yo por ejemplo, en vez de ficheros excel he usado ficheros .mdb con bases de datos access que simulaban ser un backend de una aplicación web pero ideas, si te pones a pensarlas, seguro se te ocurren 100 mas

Oscar Acosta dijo...

Hola, he vuelto a pasar por aquí después de un tiempo y he visto tu comentario. Tienes toda la razón, muchas gracias por aclararmelo. Un saludo

Cubaman dijo...

Hola, he vuelto a pasar por aquí después de un tiempo y he visto tu comentario. Tienes toda la razón, muchas gracias por aclararmelo. Un saludo