Todas las aplicaciones web tienen recursos que deben utilizar para brindar funcionalidades consistentes a sus usuarios, dichos recursos pueden ser elementos tan simples como imágenes, hojas de estilos CSS, páginas HTML estáticas, documentos de texto y casi cualquier tipo de elemento que contenga información. En muchas ocasiones el volumen de información manejada por una aplicación puede ser tan grande que el mantenimiento y administración de estos recursos puede ser muy complejo y evidentemente, propenso a errores, es en ese momento donde pueden ocurrir fugas de información privada o sensitiva que no debería estar expuesta al publico por el contenido de la misma, así como también pueden dejarse fallos sobre la configuración del servidor web o la aplicación. En este punto, un hacker o pentester “entra en escena” recolectando y analizando toda esta información. Se trata del primer paso que siempre se debe realizar, recolectar información del sistema o aplicación objetivo y “encajar” las piezas, como si tratara de un puzzle, cada pieza de información permite tener una imagen global del funcionamiento de la aplicación y por consiguiente, de los fallos que esta puede tener.

Ahora bien, para llevar a cabo estas primeras etapas del pentesting se debe contar con una plataforma completa de pruebas, (a menos que ya se tenga un objetivo sobre el que se desee aplicar el ataque) en este caso, se utilizará Web Security Dojo. Se trata de una plataforma de entrenamiento con un conjunto bastante completo aplicaciones con distintos niveles de vulnerabilidades, además de contar con con herramientas para intentar encontrar y aprovechar dichas vulnerabilidades, es una plataforma similar a Backtrack, sin embargo su contenido es enteramente destinado al pentesting de aplicaciones web, las aplicaciones web vulnerables que se incluyen en esta plataforma son:

  • Damn Vulnerable Web App
  • Gruyere
  • Hacme Casino
  • Insecure Web App
  • W3AF Tests Application
  • OWASP Webgoat

Por otro lado, también cuenta con las siguientes herramientas para realizar pentesting sobre los objetivos anteriormente listados:

  • Arachni
  • Burpsuite
  • Davtest
  • Dirbuster
  • J-Baah
  • JBroFuzz
  • MetaSploit
  • Ratproxy
  • rats
  • Skavenger shell
  • skipfish
  • sqlmap
  • W3AF
  • Watobo
  • WebScarab
  • Websecurify
  • Zed Attack Proxy

Además de las aplicaciones anteriores, existen otras herramientas que no se encuentran incluidas en la plataforma pero que serán de utilidad a lo largo de esta serie de publicaciones. A continuación se explica brevemente el procedimiento de instalación de Dojo

INSTALACIÓN DE WEB SECURITY DOJO

El procedimiento de instalación de esta plataforma de pruebas es muy simple, solamente es necesario tener instalado una herramienta como VirtualBox o VMWare player, posteriormente es necesario descargar el fichero comprimido donde se encuentra la imagen de maquina virtual de la plataforma, se encuentra disponible aquí: http://dojo.mavensecurity.com/ descargar y descomprimir el fichero.

Ahora desde VirtualBox (suponiendo que se utilice VirtualBox) se debe seleccionar la opción “File → Import Appliance” y posteriormente ubicarse en el directorio donde se han descomprimido los ficheros de la plataforma y seleccionar el fichero con extensión “ovf” a la fecha de escribir este articulo, la última versión disponible es la 1.2, el fichero tiene el nombre de Web_Security_Dojo-v1.2.ovf. Una vez cargado el fichero solamente es necesario continuar con el asistente dejando los valores por defecto. El proceso de importación puede tardar algunos minutos, una vez ha terminado resulta conveniente editar la configuración de red seleccionando el “Adaptador Puente” para que se le pueda asignar una dirección IP en el segmento de red local a la máquina virtual creada. Finalmente el usuario y la contraseña por defecto utilizados para acceder al sistema es: usuario: dojo password: dojo Con estos sencillos pasos será suficiente para comenzar a utilizar Web Security Dojo

Ahora que se ha instalado la máquina virtual, es necesario aclarar que por defecto solamente permite que sus aplicaciones instaladas como “Targets” sean accedidas de forma local, de esta forma se evita que se instale esta plataforma (insegura) en un entorno de red que debería ser “seguro”, sin embargo a efectos prácticos, resulta interesante y muy útil poder realizar pentesting de las aplicaciones disponibles desde cualquier punto de la red, principalmente para que otros usuarios puedan hacerlo (esto es lo que habitualmente se conoce como un hacklab) además de que también resulta interesante para hacer pruebas de “caja negra” partiendo de la premisa que no se conoce absolutamente nada sobre el procesamiento de las peticiones y como el sistema genera sus respuestas (el cual es un entorno normal para un atacante, ya que habitualmente antes de atacar una aplicación no tiene conocimiento sobre como esta implementada y solamente por medio de pruebas de caja negra puede adquirir información valiosa que le guié a conseguir sus objetivos).

Ahora, para comenzar a configurar esta máquina virtual, es necesario ir aplicación por aplicación, para que estén disponibles a otras máquinas en el entorno de red local, a continuación se indica la configuración que debe ser aplicada en cada una de las aplicaciones vulnerables que se encuentran disponibles en Web Security Dojo

En primer lugar, todos los “Targets” (aplicaciones vulnerables) se encuentran localizadas en el directorio /home/dojo/targets donde cada una de estas aplicaciones cuenta con su correspondiente directorio y ficheros de configuración, es necesario recorrer cada uno de estos directorios y hacer los cambios de configuración correspondientes para que se pueda acceder a cada aplicación web desde cualquier máquina remota en el segmento de red local.

NOTA: Estas actividades solamente se recomienda hacerlas en entornos de laboratorio, donde no se exponen datos importantes o aplicaciones expuestas al público, dado que son altamente “peligrosas” dada la cantidad de vulnerabilidades que se encuentran incluidas en estas aplicaciones, así que “Advertidos estáis!”

 

GRUYERE WEB APPLICATION

Esta aplicación es un excelente repositorio de pruebas, sencillo y bastante completo que le permite a un usuario con un nivel de conocimientos básico o intermedio en seguridad en aplicaciones web, avanzar rápidamente en la exploración y explotación de vulnerabilidades comunes (y no tan comunes) en aplicaciones web. Esta aplicación ha sido desarrollada por Google y esta licenciada bajo los términos de la licencia Creative Commons, se encuentra programada en Python y cuenta con unos pocos scripts fáciles de entender (si se tienen conocimientos básicos de programación en dicho lenguaje). Además como casi todas las herramientas de Web Security Dojo viene con documentación sobre los posibles ataques que pueden realizarse sobre esta aplicación, sus consecuencias y algunos “tips” interesantes. Para que pueda ser utilizada desde cualquier máquina en el segmento de red, es necesario editar el fichero gruyere.py que es el “servidor” de la aplicación, aunque es realidad es simplemente un pequeño servicio que abre un puerto en una interfaz de red especificada y trata cada petición por dicho puerto. Para ello abrir el fichero /home/dojo/targets/gruyere/ gruyere.py y los cambios que deben realizarse en dicho fichero son los siguientes:

  1. En la linea 104 establecer la variable “insecure_mode” a True, el valor por defecto es False, lo que indica que solamente desde la interfaz local se permite su uso.

    insecure_mode = True

     

  2. A partir de la linea 50, se puede editar las validaciones de esta variable de la siguiente forma:

    if insecure_mode:
    server_name = '192.168.1.41'
    else:
    server_name = '127.0.0.1'
    

    Se debe cambiar la dirección “192.168.1.41” por cualquier otra, esta es la dirección IP de la máquina donde se esta ejecutando Web Security Dojo

  3. Ahora se deben incluir las direcciones IP que pueden acceder a este servicio. Para ello editar la linea 795 e incluir las direcciones IP que podrán conectarse con Gruyere

    allowed_ips = [‘127.0.0.1′,’192.168.1.33′,’192.168.1.34’]

    Aquí se permite la conexión desde los clientes con direcciones 127.0.0.1, 192.168.1.33 y 192.168.1.34

Con estos sencillos pasos se puede comenzar a utilizar Gruyere desde las máquinas que se han establecido como “permitidas”. Por otro lado en el mismo directorio donde se encuentran los ficheros en fuente en Python, también se encuentran dos ejecutables que son utilizados desde el menú “Applications → Targets” que son “start.sh” y “stop.sh” los cuales como su nombre lo indica, permiten iniciar y detener el servidor Gruyere, el script de arranque invoca al navegador (firefox) para cargar la aplicación, si se desea se puede quitar esta ultima linea para que no salte el navegador de forma automática, si el lector prefiere dejarlo así tampoco hay ningún problema, cuestión de gustos.

HACMECASINO WEB APPLICATION

Esta aplicación web incluida en Dojo, se encuentra escrita en Rails (implementación Ruby) e incluye una serie de vulnerabilidades que a lo largo de esta serie de publicaciones se irán comentando. Esta aplicación es un poco más “seria” que Gruyere en el sentido de que implementa un modelo de desarrollo de software bastante difundido (MVC – Modelo Vista Controlador) utilizando Ruby, de un modo bastante similar a como programaría una aplicación web siguiendo un patrón de diseño previamente establecido. Cuenta con funcionalidades mucho más completas que Gruyere y la estructura del servidor es un poco más compleja, a diferencia de Gruyere, HACMECASINO no necesita ningún tipo de configuración previa para que se pueda acceder desde otras máquinas en la LAN, por defecto se puede acceder a dicha aplicación sin restricciones. Ademas de lo anterior, Rails utiliza un servidor web llamado WEBrick y se encuentra embebido directamente en el directorio donde se encuentra la aplicación web, esta configuración para efectos prácticos es suficiente, sin embargo en entornos un poco más “serios” no se utiliza WEBrick, en lugar de este se suele usar directamente Apache con su correspondiente modulo FastCGI, el cual le permitirá a Rails ejecutarse sobre Apache con un rendimiento óptimo.

INSECURE WEB APP

Esta aplicación web, se encuentra escrita en Java utilizando Servlets y JSP, se ejecuta sobre una máquina virtual un poco antigua (con JDK 1.4) y un servidor web Apache Tomcat también algo antiguo (versión 4.1). Es una aplicación bastante similar a HACMECASINO, pero implementa una base de datos SQL embebida, HSQL en este caso, (aunque también permite la instalación de otras bases de datos como MySQL) lo que permite probar ataques contra la capa persistente de la aplicación por medio de explotación de vulnerabilidades SQL Injection. Dado que se trata de una aplicación con bastantes agujeros de seguridad, cuenta con un mecanismo de “protección” que impide que pueda ser accedida desde cualquier máquina distinta a la maquina en la cual se hospeda, en este punto es bastante similar a Gruyere, dado que es necesario editar la configuración del servidor web (Apache Tomcat) para que pueda ser utilizada desde cualquier punto de la LAN.

Cuando esta aplicación se inicia desde la opción “Applications → Targets → Insecure Web App Start” se invoca el script que se encuentra ubicado en: “/home/dojo/targets/bin/InsecureWebApp_start.sh” cuando se ejecuta este script, automaticamente se ejecuta el script “/home/dojo/targets/insecurewebapp/bin/startup.sh” el cual se encarga de iniciar el servidor web Tomcat alojado en el directorio “/home/dojo/targets/insecurewebapp/” Ahora bien, para que esta aplicación pueda ser accedida desde cualquier máquina en el segmento de red de área local, es necesario editar el conector de Tomcat para que “escuche” en la dirección “0.0.0.0” lo que le indicará al servidor web que puede utilizar cualquier interfaz de red con una dirección IP valida en la máquina local para recibir peticiones. Para hacer esto, se edita el fichero de configuración “server.xml” el cual se encuentra ubicado en el directorio “/home/dojo/targets/insecurewebapp/conf” en dicho directorio se debe editar el tag “Connector” de tal como que quede así:


De las lineas anteriores, lo único que se ha cambiado de la configuración por defecto es la instrucción “address” estableciendo el valor “0.0.0.0”.

Con esto será suficiente para acceder a la aplicación desde cualquier máquina en la LAN.

WEBGOAT

Aplicación por excelencia del proyecto OWASP, se trata de una aplicación que tiene un fuerte enfoque en el auto-aprendizaje con varias demostraciones de fallas en servidores de aplicación y malas practicas de programación. Cuenta con una serie de “lecciones” que se van llevando paso a paso, donde el objetivo de cada usuario es superar dichas pruebas y acceder a la siguiente lección. Una de las ventajas que tiene esta aplicación es que es posible adicionar Lecciones adicionales y extender la aplicación utilizando una sencilla API escrita en lenguaje Java. Del mismo modo que ocurre con Insecure Web App, esta aplicación cuenta con un servidor web Tomcat que almacena los Servlets y páginas JSP que son utilizadas para la aplicación. Del mismo modo que las demás aplicaciones indicadas anteriormente, WebGoat solamente puede ser accedida desde la máquina donde se ejecuta (local) y para que otros clientes puedan acceder a esta herramienta desde una ubicación remota, es necesario editar la configuración del servidor web del mismo modo que se ha hecho con Insecure Web App. En este caso concreto el servidor web utilizado por WebGoat se encuentra ubicado en “/home/dojo/targets/WebGoat-5.2/tomcat” allí se encuentra ubicado el directorio “conf/” el cual contiene los ficheros de configuración del servidor web, solamente es necesario editar el fichero “server.xml” e incluir lo siguiente:

<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<!-- Note : To disable connection timeouts, set connectionTimeout value to 0 -->
<!-- Note : To use gzip compression you could set the following properties : compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml" -->
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile=".keystore" />;

Con las lineas anteriores, se le indica al servidor web que el puerto utilizado para prestar el servicio es el 8088 para HTTP y 8444 para HTTPS y que la dirección utilizada será 0.0.0.0 para que este servidor pueda ser accedido remotamente.

Finalmente, existen otras dos aplicaciones web vulnerables incluidas en Web Security Dojo que son: DVWA y W3AF Test environment, las cuales se encuentran en el servidor web Apache que viene instalado por defecto en el la maquina virtual, se trata de un servicio de arranque automático y utiliza el puerto 80 para HTTP y 443 para HTTPS, es por esta razón que los servidores web explicados en párrafos anteriores para cada aplicación web vulnerable.

Como se ha dicho anteriormente, estas aplicaciones serán estudiadas para determinar cuales son las vulnerabilidades que les afecta y cual es su impacto y que medidas o buenas practicas en programación deberían ser aplicadas para evitar que se reproduzcan dichos fallos. Esto se hará a lo largo de esta serie de publicaciones, sin embargo antes de comenzar con la parte “divertida” se hablará sobre algunas buenas practicas a la hora de configurar servidores web Apache y Tomcat (que también es muy divertido e ilustrativo para aprender sobre seguridad en aplicaciones web). De esto se hablará a partir de la próxima publicación.