Web Hacking : Una línea para manejarlos a todos
¿Podría darte una línea de código acceso a un sitio Web completo? ¿Qué información obtendría un atacante si consiguiera llegar al nivel más bajo de tu página Web? es decir, a tu BBDD o SSOO. Dependiendo del objetivo de la misma podría encontrar seguramente información sobre la identidad de los usuarios, transacciones bancarias, compras online, usuarios, contraseñas y mucho más.
¿Cuánto vale tu información? Debemos de establecer unos controles de seguridad mínimos a nuestro sitio Web, llevar a cabo una serie de auditorías de seguridad que garanticen el buen funcionamiento de la misma. No sólo tener en regla la política de cookies y poco más, sino os puede ocurrir como la Web con la que me encontré hace unas semanas a la hora de preparar una charla. Antes de nada os muestro un disclaimer.
Aviso Legal y Descargo de Responsabilidad
- El objetivo de lo mostrado a continuación tiene fines educativos para aprender a mejorar la seguridad de nuestros sitios Web.
- No nos hacemos responsables del mal uso que se le pueda dar a las herramientas mostradas.
- Toda la auditoría Web mostrada a continuación se ha llevado a cabo con permisos de sus administradores según lo acordado en documento legal.
Vamos a llevar a cabo la auditoría de un sitio Web siguiente la metodología OWASP, concretamente seguiremos la OWASP Testing Guide V4. Los diferentes puntos que abarca dicha metodología los podéis ver detalladamente en el enlace anterior. A continuación nombramos los aspectos generales a tratar.
- Information Gathering
- Configuration and Deployment Management Testing
- Identity Management Testing
- Authentication Testing
- Authorization Testing
- Session Management Testing
- Input Validation Testing
- Error Handling
- Cryptography
- Business Logic Testing
- Client Side Testing
Seguiremos algunos de los pasos sobre el sitio Web auditado, sobre todo la primera fase y veremos como la auditoría termina antes de tiempo.
Information Gathering
OTG-INFO-001 Fuga de Información. Hacemos uso de buscadores con Bing, Google, Shodan… en busca de fugas de información utilizando los operadores de estos.
Vamos a ver que información nos da Shodan, para ello simplemente le añadimos la IP del sitio Web obtenida mediante un ping, por ejemplo.
Vemos información de muchos servicios en puertos conocidos que más adelante nos darán juego.
OTG-INFO-002 Fingerprinting del servidor Web. Vamos a intentar averiguar sobre que tipo de servidor está trabajando nuestro sitio Web objetivo, para ello usamos la herramienta whatweb que podemos encontrar en Kali.
Vemos como el tipo de servidor es un nginx, además de bastante información como el tipo de CMS (SPIP), el gestor de sitio que utiliza (Plesk), correo electrónico del administrador…
OTG-INFO-003 Metadatos encontrados en ficheros del servidor. En este punto podemos hacer uso de herramientas como Foca o Metagoofil para obtener metadatos que tengan los documentos publicados en el sitio Web.
Podemos encontrar varios usuarios y algo de información sobre el tipo de software utilizado.
OTG-INFO-004 Enumeración de subdominios y aplicaciones del server. Haremos uso de herramientas que nos den información sobre posibles subdominios, servidores DNS, puertos de Apps conocidas…
Nos vamos a Bing para comprobar si el hosting es dedicado o compartido.
Vemos que tenemos un hosting compartido entre 18 dominios. Vamos ahora a ver los DNS que utilizan y si hay posibilidad de transferencia de zona por algún fallo en la configuración.
En este punto podrían utilizarse más herramientas o servicios, como nmap o dnsmap o el servicio netcracft.
OTG-INFO-005 Comentarios y Metadatos de la Web. Podemos encontrarnos con fugas de información en los comentarios de la Web que utilizan los programadores para depurar el código.
Otro punto a inspeccionar también sería la cabecera META donde encontraremos también información importante : emails, versiones, si la cual quiere que sus enlaces sean o no indexados por las arañas (NOINDEW, NOFOLLOW)…
OTG-INFO-006 y OTG-INFO-007 Identificar puntos de entrada y Mapa del Sitio Web. Pasamos a ver todos los puntos de entrada de la Web (peticiones y respuestas con GET y POST), para lo cual vamos a utilizar un proxy inverso Web (ZAP, Burp o WebScarab) y utilizamos su Spider de tal forma que nos genere un mapa completo de la Web y sus puntos de entrada.
Vemos los diferentes puntos de entrada y sus métodos, con el spider nos hacemos una idea del mapa de navegación Web.
OTG-INFO-008 Fingerprinting Web Application Framework. Se trata de averiguar que tipo de framework se ha utilizado para desarrollar la Web, es decir lenguaje de programación y la tecnología. Concretamente podemos encontrar toda esta información en las cabeceras HTTP, las cookies, código HTML y diferentes ficheros y carpetas. Cunado hicimos uso de whatweb pudimos observar que utilizaba JQuery con otras tecnologías específicas que usa el CMS utilizado.
OTG-INFO-009 Fingerprinting Web Application. Se trata de averiguar si se ha utilizado para desarrollar la Web algún tipo de CMS: WordPress, Joomla u otro tipo de CMS, en este caso en el apartado dos vimos como se trataba del CMS SPIP 3.0.20. Ahora que ya tenemos la versión, sería cuestión de ver vulnerabilidades más adelante.
OTG-INFO-0010 Arquitectura del Servidor. No sabemos hasta el momento el tipo de arquitectura exacta que utiliza el servidor, si hay algún tipo de firewall en medio de la comunicación. Para ello vamos a llevar a cabo un escaneo tipo ACK y vemos que no hay WAF (puerto 80 unfiltered).
También se podría descubrir si se utiliza algún tipo de proxy inverso inspeccionando la información de la cabecera, etc.
Una línea para manejarlos a todos.
Llegados hasta este punto y antes de seguir con la siguiente fase de la auditoría nos debemos de fijar en la siguiente línea que nos ha dado el Spider.
Vemos una variable de entrada que se llama URL, huele de lejos a dos posibles vulnerabilidades: RFI (Remote File Inclusion) o LFI (Local File Inclusion). Para aquellos que no sepáis en que consisten os las describo en pocas líneas.
- RFI: Permite cargar un fichero de otro dominio en el navegador, por ejemplo una shell en PHP que tuviésemos alojada en otro servidor.
- LFI: Permite cargar ficheros locales del propio servidor en el navegador, como por ejemplo /etc/passwd.
Probando con RFI vemos como nos muestra el código HTML de la dirección dada en el parámetro URL, es decir, el resultado de hacer la petición al servidor.
Probando con LFI vemos como si que nos muestra el código PHP del fichero del servidor que pasamos por el parámetro URL.
Si nos fijamos en el nombre del fichero, ver.php, podemos imaginarnos lo que hace. Si ahora le pasamos por parámetro el propio fichero, obtenemos el código fuente del propio fichero. Y ahí tenemos, ¡¡ una línea para manejarlos a todos !!
Si analizamos la línea de código, vemos que utiliza la función show_source() de PHP. Cualquier fichero del servidor que pasemos por el parámetro URL nos muestra su código fuente, por tanto el objetivo es encontrar el fichero con los parámetros de configuración de acceso a la BBDD. Vamos viendo el código fuente de todos los index.php de todos los paths por donde ha pasado el Spider, hasta encontrar un include (‘config.php’) en el path:
sitio/aulavirtual/index.php
El resultado de mostrar el código fuente del fichero config.php es el siguiente:
Ya tenemos las credenciales de acceso a la BBDD de un aula virtual Moodle, pero aún podemos ir más lejos. ¿Y si el SGBD (Sistema Gestor de BBDD) nos estuviera bien configurado y permitiera acceso desde el exterior? Si vemos los servicios que tenía indexados Shodan, teníamos un servicio MySQL y un puerto 3306. Lanzamos un nmap al puerto para descubrir el servicio en concreto:
Vemos que el puerto está abierto desde el exterior y que el servicio en concreto es un MySQL 5.5.44-MariaDB. El siguiente paso es coger algún gestor de BBDD MySQL como PHPMyAdmin y cambiar los parámetros para apuntar a la BBDD de la cual tenemos los credenciales. El resultado es el siguiente: 
Buscando por las tablas de la BBDD encontramos la tabla de los usuarios. Estamos accediendo como usuario Administrador, por tanto tenemos permisos para hacer lo que queramos. Fijaros la importancia de una única línea de código el daño que puede hacer.
¿Qué pasaría si pudiéramos inyectar de manera persistente este código en la BBDD? sería muy dificil para un antivirus encontrarlo, lo primero porque no modificamos los ficheros del servidor y lo segundo porque dudo que ningún antivirus detectase esa línea de código como código malicioso.
Al final hemos terminado la auditoría antes de tiempo con una única línea de código que permite dejar todo el sitio al descubierto. Espero que os haya gustado el artículo y ya sabéis, cuidar de la seguridad de vuestro sitio Web llevando a cabo auditorías de seguridad, no sólo con tener actualizado el sitio basta.
Un #handshake
«Cuando más grande es el caos, más cerca está la solución»