jueves, 8 de abril de 2010

Security Module (Parte II)

Buenas a todos!, tras unos días poniéndome al día con los quehaceres diarios y graduarme ayer junto a mi compañero y amigo de Informática 64 Pablo (en cuanto tenga fotos las colgaré por aquí =) ), os traigo la primera versión del Módulo de Seguridad que estoy desarrollando como proyecto para la asignatura de ASS en la universidad.

En los siguientes apartados os explico detalladamente las partes de las que se compone el proyecto:

ESTRUCTURA DEL SISTEMA

El sistema implementado en el presente proyecto se compone de las siguientes partes:

  • Servicio Web Excel: Servicio web implementado en ASP.NET que simula una hoja de Excel, en la que los usuarios registrados desde su navegador podrán almacenar y recuperar datos en una tabla que se almacenará en una base de datos.
  • Metaservicio XML: Servicio Web que contendrá patrones de ataque que un hacker puede utilizar para vulnerar una base de datos. Este servicio debería ser actualizado regularmente para mantener la fortificación del sistema.
  • Módulo de Seguridad: Software instalado en el servidor web que colabora en las labores de protección de la Base de Datos filtrando las peticiones maliciosas.
  • Base de datos: Base de datos utilizada para almacenar las tablas del Servicio Web Excel y los datos de autenticación de los usuarios en el sistema.

El diagrama del sistema completo se muestra en la figura 1. Se basa en la idea de controlar desde el servidor web los accesos a una base de datos realizados por los usuarios, sin que lleguen a la base de datos, para evitar poner en peligro a la misma.

Para lograr filtrar las peticiones maliciosas antes de que lleguen a la base de datos se ha implementado un módulo de seguridad, que se instala en el servidor web. Este módulo se encarga de filtrar todos los contenidos de las peticiones realizadas por los usuarios al servidor. Durante la etapa de filtrado, el módulo de seguridad compara los patrones de ataque utilizados hasta la actualidad por hackers, obteniéndolos de un Metaservicio implementado en XML, con el contenido de las peticiones web, buscando posibles ataques a la base de datos. Obviamente no se han añadido todas las posibles inyecciones que existen, labor que sería prácticamente imposible, pero si las principales, además de unas especiales que me pasó Thor la semana pasada =) (gracias Oca).

Para este proyecto se ha decidido estudiar los casos de ataque basados en Inyecciones SQL para delimitar la envergadura final del proyecto.

image

Figura 1: Sistema de securización basado en la implementación de un módulo de seguridad

METASERVICIO XML DE SEGURIDAD

El Metaservicio XML de Seguridad, almacena un conjunto de los patrones de ataque más utilizados por hackers para aprovecharse de las vulnerabilidades más comunes de las bases de datos.

Estos patrones intentan simular las inyecciones que un usuario con intenciones maliciosas utilizaría para obtener información privilegiada de una base de datos o intentar penetrar en un sistema saltándose un campo de login.

En la figura 2 se muestra una captura de pantalla del Metaservicio XML, con algunas de las Inyecciones SQL que pueden ser utilizadas en el Servicio Web Excel desarrollado para el proyecto, para saltarse el campo de login inicial, para borrar la base de datos, para ejecutar una Shell remota, para apagar el sistema, etc.

image

Figura 2. Captura de pantalla del Metaservicio XML de Seguridad

MÓDULO DE SEGURIDAD

El Módulo de Seguridad es la piedra angular del sistema, es el encargado de filtrar todas las peticiones web que llegan al servidor. Para ello, analiza el objeto Response de una petición web, donde se encuentra toda la información de las peticiones realizadas al servidor y compara su contenido con la del Metaservicio XML explicado en el punto anterior para buscar patrones de ataque.

El desarrollo del Módulo se ha realizado en C# utilizando el IIS7 Managed Module Starter Kit para Visual Studio que ha producido el IISTeam y que facilita en gran medida la tarea de integrar un software en el IIS. Este kit permite acceder a las peticiones realizadas por los usuarios al servidor web analizando el objeto Response antes comentado.

En la figura 3, se muestra una captura de pantalla del código fuente del módulo. En la figura 4, se muestra el módulo de seguridad instalado en el servidor web.

image

Figura 3. Código Fuente del Módulo de Seguridad.

image

Figura 4. Instalación del Módulo de Seguridad en el servidor web IIS7.

SERVICIO WEB EXCEL

Para probar la protección que ofrece el Módulo de Seguridad junto con el Metaservicio XML de Seguridad se ha desarrollado un pequeño servicio web que simula una hoja de Excel. Este servicio es accesible por cualquier usuario registrado utilizando un navegador web, sin necesidad de instalar ningún cliente en el equipo.

El servicio web ha sido implementado en ASP.Net por la sencillez de implementación de formularios que ofrece Visual Studio.

En la figura 5 se muestra la pantalla inicial del servicio web, en la que solicitará los datos de un usuario del sistema.

image

Figura 5. Sistema de login para acceder al servicio web.

Tras pasar el login inicial, se abrirá la hoja de Excel del usuario con el que se ha realizado el registro en el sistema. Desde este formulario un usuario podrá descargarse los datos almacenados con anterioridad, modificarlos y volver a almacenarlos para recuperarlos posteriormente y contará con un botón que le permitirá vaciar la tabla completamente.

image

Figura 6. Servicio Web Excel, en el que un usuario podrá almacenar y recuperar datos.

FUNCIONAMIENTO DEL SISTEMA

Tras instalar el módulo de seguridad, no se verá alterado el funcionamiento del sistema exceptuando el caso en el que se detecte algún patrón de ataque.

En la figura 7 se muestra un simulacro de los datos que podría introducir un usuario durante el registro en el sistema.

El primer usuario, introduce sus datos normales de registro, usuario y contraseña, el servidor web solicita confirmación a la base de datos de que el usuario es correcto y está registrado, y esta le devuelve su consentimiento para acceder al sistema.

El segundo usuario de la misma manera que el anterior introduce sus datos de registro, pero este usuario se aprovecha de una mala implementación en el código de la base de datos, en el que no han sido parametrizadas las sentencias que permiten acceder al contenido de las tablas para evitar que las queries introducidas por el usuario se ejecuten como código, cuando en realidad deberían ser interpretadas únicamente como texto.

El tercer usuario, intenta utilizar la misma técnica que el anterior, pero es frenado en este caso por el módulo de seguridad, que impide que la petición llegue tan siquiera a la base de datos.

image

Figura 7. Simulacro del comportamiento de los posibles usuarios con el sistema con y sin módulo de seguridad.

En la figura 8, se puede ver cómo funciona el ataque y el sistema de protección comentado en la figura anterior. En ella, un usuario inyecta la query <<‘or’1’=’1>>, que utiliza para saltarse la siguiente sentencia <<select>> encargada de comprobar la existencia de un usuario en el sistema:

SELECT * FROM TUsuarios WHERE user=’’ or ‘1’=’1’ AND pass=’’ or ‘1’=’1

Con esta sentencia el usuario está indicando al sistema que quiere logarse como el usuario vacío con contraseña vacía, usuario que evidentemente no existe, pero al introducir el comando OR, está anulando el poder de esta sentencia, prevaleciendo el 1=1, que evidentemente es una sentencia que siempre se cumple y permitiendo de esta manera obtener una lista de todos los usuarios del sistema.

Tras obtener la lista completa, el sistema validará al usuario como el nombre y contraseña del primero que aparezca en la lista devuelta por la sentencia <<select>>.

image

Figura 8. Inyección de código SQL para penetrar en el sistema de forma ilícita.

Tras lanzar el ataque, el usuario debería haber penetrado en el sistema, pero como se muestra en la figura 9, ha sido identificado un patrón de ataque por el módulo de seguridad del servidor web, y le ha redireccionado inmediatamente a la página de error mostrada en dicha figura.

image

Figura 9. Página de error mostrada al usuario tras identificar un patrón de ataque el sistema.

En la figura 10, se muestra otro ejemplo de query introducida por el usuario, en este caso para intentar apagar el sistema mediante el código <<‘;shutdown>>.

image

Figura 10. Inyección SQL introducida para intentar apagar el sistema.

De la misma manera que antes, el usuario recibió inmediatamente la página mostrada en la figura 9.

Como se puede ver en la figura 10, el usuario con el que se registra un cliente en el sistema se pasa por la URL desde el formulario de login al servicio web Excel. Esta manera de pasar los datos es muy insegura, ya que un usuario podría modificar fácilmente desde la URL el nombre de usuario, accediendo a los contenidos de las tablas de cualquier usuario sin necesidad de realizar ninguna inyección de código. Además, podría inyectar código XSS (Cross-site Scripting) malicioso para ejecutar código javascript con los peligros que esto conlleva. Pero como se muestra en la figura 11, el propio lenguaje ASP.NET ya lleva instalado por defecto un filtro de seguridad, de funcionamiento semejante al que se ha desarrollado en este proyecto, pero en este caso dedicado a filtrar las inyecciones basadas en XSS, filtrándolas e impidiéndolas actuar.

image

Figura 11. Filtrado de un intento de XSS en el servidor web IIS7.

Todo el entorno está implementado en una máquina virtual con un Microsoft Server 2008. Para próximos proyectos intentaré ir ampliando las inseguridades de la máquina virtual para que sirva de práctica. En el próximo post intentaré colgar los elementos necesarios para que os montéis este entorno virtual, ya que colgaros la máquina virtual directamente se me hace casi imposible porque que pesa algo mas de 11GB.

Hasta el próximo post!

5 comentarios:

Pedro Laguna dijo...

Buenas!

Una puntualizacion: el "modulo" para detectar XSS es propio del ASP.Net y no del IIS7, por lo que tambien funciona en IIS6.

Por otro lado las inyecciones que muestras en la captura son facilmente modificables para pasar el filtro. No se como seran las demas, pero otras soluciones por el estilo (como mod_security) hacen uso de expresiones regulares para detectar posibles ataques.

Un saludo!

Juan Antonio Calles dijo...

Gracias por la puntualización sobre el ASP.Net =)

Las inyecciones que salen en la captura se han visto multiplicadas en los últimos dias, gracias a unas cuanta nuevas que me pasó Oca el otro día y porque he volcado en el xml varios diccionarios de inyecciones SQL, de todas maneras suena interesante lo de las expresiones regulares, me la apunto para estudiarlo.

gracias Pedro como siempre :), saludos!

Juan Antonio Calles dijo...

Autocompleto el comentario anterior. No utilizo expresiones formales pero si un algoritmo que he diseñado que entre otras cosas, se come los espacios tanto de la inyeccion como de la expresion del xml, pasa todas las letras a minúscula y demás, para asi no equivocarse pq la inyección tenga alguna letra en mayúscula o muchos espacios. Creo que es semejante a lo que te refieres con las expresiones regulares no?

saludos!

Pedro Laguna dijo...

No. Expresiones regulares son para, por ejemplo, detectar tanto 1=1 como 42=42. O cosas como esta: http://elladodelmal.blogspot.com/2010/02/semi-trues.html

Es muy dificil hacer la solucion perfecta, pero ya que es para la universidad siempre puedes intentarlo ;)

Juan Antonio Calles dijo...

jejeje ok, gracias Pedro, a ver que se me ocurre, aunque ando ultimamente muyyyy liado.

saludos!