A raíz de la entrada del correo electrónico donde se enlazaba a un troyano bancario, comencé a desarrollar un programita que tenía en mente desde hacía tiempo. Se trata de un recolector de Malware de correos electrónicos, encargado de acceder a distintas cuentas de correo, obtener el correo electrónico, almacenarlos en base de datos, y en caso de poseer adjuntos, ser analizados con la API de Virus total.

Veámoslo con más detenimiento. Primero será necesario disponer de una serie de sondas, correspondientes a cuentas de correo electrónico perteneciente en distintos servidores públicos como son Gmail, Yahoo o Hotmail, así como una serie de correos privados como por ejemplo el corporativo. Dichas cuentas de correo solo se usarán para recoger el correo que llegue a la bandeja de entrada y Spam. Para ello en ocasiones será necesario hacer filtros para trasladar el correo de la carpeta Spam a bandeja de entrada. Por ejemplo para Gmail sería necesario crearse un filtro de tipo texto con la siguiente entrada “is:spam” e indicar que debe enviarse como correo no leído a la bandeja de entrada. Con esto dispondremos de varias cuentas de correo distribuidas sobre distintos servidores de correo cuyo único objetivo es almacenar los correos de entrada.

Ayer domingo mientras pensaba qué excusa poner a mi compañero Raúl por lo del partido del Levante ante el Valencia —donde todo sea dicho de paso claramente nos robaron— me llegó un correo electrónico con una supuesta oferta de trabajo, tal como podemos ver en la siguiente imagen:

A lo largo de estos últimos años hemos escrito sobre los honeypots y las ventajas que aportan a nuestra infraestructura. Por ello para intentar promulgar el uso de este tipo de herramientas he preparado un entorno virtual que emula varios honeypots de distintas clase formando una red completa: una honeynet.

Como tecnología de virtualización he escogido User Mode Linux por estar bastante familiarizado con ella, debido a que fue la opción escogida en mi proyecto de fin de carrera (véase http://bastionado.blogspot.com/2011/07/mi-proyecto-de-fin-de-carrera.html). Pero no solo por esto, ya que UML tiene una ventaja muy importantes respecto al resto de tecnologías: la máquina virtual es ejecutada con permisos de usuario sin privilegios, y por tanto, en caso de que un atacante consiga saltar al entorno anfitrión, éste accedería como usuario no privilegiado, es decir, sin ser root. De ahí su nombre, User Mode, ya que se ejecuta en el espacio de usuario y no en el espacio del kernel.

(N.d.E.: Vean antes la primera parte y la segunda parte)

Cuando la sesión se encuentra alojada en la cookie resulta mucho más difícil de explotar, debido a que cualquier navegador Web básico emplea la protección de mismo origen o “origin server”, donde un recurso web solo puede modificar atributos si ese recurso pertenece a su mismo dominio, puerto y protocolo, es decir, el servidor atacante no puede modificar la cookie del servidor víctima, y por tanto, no podrá fijar su sesión a la víctima.

Aún así existen distintas formas de intentar explotar una fijación de sesión almacenada en una cookie:

Tal como se describió en la anterior entrada, la fijación de sesión es una vulnerabilidad debida a un tratamiento incorrecto en la gestión de sesiones por parte de una aplicación Web. En concreto la vulnerabilidad radica en que cuando se concede una sesión a un usuario no autenticado, y éste se autentica en dicha aplicación, el valor de la sesión no cambia. Por tanto, el vector de ataque para explotar la vulnerabilidad consiste en intentar que la víctima se autentique en la aplicación usando una sesión previamente conocida por el atacante, de tal forma que una vez el usuario se autentique, el atacante pueda acceder a la aplicación con el mismo rol que la victima gracias a que conoce la sesión de ésta.

Para comprender de forma más sencilla el funcionamiento de la vulnerabilidad vamos a presentar una posible prueba de concepto, donde el recurso web “login.php” es vulnerable a la fijación de sesión en un escenario con un servidor web vulnerable, una víctima, un atacante y un servidor web del atacante. Veamos por paso el funcionamiento mediante un ejemplo:

El protocolo HTTP fue diseñado para cumplir unos requisitos muy limitados, sin tener en cuenta muchas de las necesidades de la actualidad; por ejemplo, el protocolo no es capaz inicialmente de proporcionar o restringir visibilidad sobre sus recursos dependiendo de qué usuario los solicite.

Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.

…mañana puede que a ti.

Hace casi una semana el nombre de Anonymous volvió a surgir de nuevo en las redes sociales y medios de propósito general, debido a un comunicado donde se indicaba un supuesto robo de información que obligó a las autoridades españolas a cerrar la web de la Policía Nacional durante unas horas. En este comunicado se hacía público el listado de los escoltas del actual presidente del gobierno español (Zapatero) y se amenazaba con la posibilidad de publicar datos del Grupo Especial de Operaciones (GEO) del Cuerpo Nacional de Policía. Unos días después el grupo Anonymous desmentía cualquier tipo de relación con el robo de información mediante un comunicado, lógicamente sin la certeza de que realmente dicho comunicado sea auténtico.

Pues bueno, hoy, cinco días después, se ha hecho público un listado de once supuestos miembros de los GEO: nombre, DNI y cargo. Lógicamente esta información no ha podido ser contrastada todavía, pero el comunicado comienza con el siguiente párrafo:

A lo largo del día de hoy ha habido mucho movimiento en los ámbitos de la seguridad debido a una vulnerabilidad de denegación de servicio en Apache descubierta por “Kingcope”

Junto a la publicación de la vulnerabilidad se ha hecho público en Full Disclousure un pequeño script en perl encargado de sacar ventaja de la vulnerabilidad y explotarla. Por tanto se trata de una vulnerabilidad 0 day sin parche a aplicar en la cual se dispone de un exploit público muy sencillo de ejecutar.

Seguramente muchos de ustedes estarán pensando que tras esta entrada se esconde el humosoft o vaporware que tanto gusta en estos días, pero créanme que no hablaré de sinergia, aportar valor, retorno de la inversión ni de ninguna de esas coletillas que tan bien suenan pero que tan difíciles son de apreciar. En su lugar, vamos a explicar de forma sencilla que es realmente la correlación exponiendo sus ventajas e inconvenientes. De manera muy resumida ésta consiste en, dadas una serie de fuentes de información, ser capaces de obtener los datos más relevantes para nuestra infraestructura, así como ser capaces de detectar una acción que por si sola cada una de las fuentes de información no serían capaces de detectar. Aquellos datos relevantes correlados se notificarán mediante alertas a una consola centralizada.

Como ven hemos introducido un elemento adicional: la fuente de información. Pero, ¿qué es realmente y que tipo de fuente nos interesa? La fuente de información no es más que “un algo” que aporta información al correlador de los acontecimientos ocurridos en nuestra infraestructura. Por ejemplo una herramienta de detección de intrusos, monitorización de los recursos, registros de un servidor, control de acceso físico, estación meteorológica, etc. Cuanto más fuentes de información dispongamos y cuanto más distinta sea la información aportada por cada una de éstas respecto al resto de ellas mejor visión de los acontecimientos tendrá el correlador, y por tanto, mejor funcionará. Como verán no nos interesa tener veinte fuentes de información que aporten casi lo mismo sino tres que aporten información totalmente distinta.

Cada vez más las tecnologías de virtualización están más extendidas y prácticamente no se suelen encontrar servidores físicos dedicados. Es por ello que a la hora de gestionar un incidente que requiera de análisis forense detallado es necesario conocer el funcionamiento de cada tecnología de virtualización existente para poder tomar las evidencias necesarias para el estudio del caso.

Normalmente, dentro del grupo de gestión de incidentes solemos encontrarnos con casos donde la tecnología de virtualización empleada es VMWare o Hyper-V. Pero en otras ocasiones, como la que veremos a continuación, nos encontramos con otro tipo de tecnología de virtualización que no es tan común. Para esta entrada explicaremos de forma sencilla y resumida los pasos necesarias para tomar las evidencias del sistema de ficheros de un entorno de virtualización XEN, el cual presenta la particularidad de disponer de volúmenes lógicos LVM.