En esta habitación tenemos una aplicación web vulnerable. Nos servirá para practicar la metodología y la aproximación a probar una aplicación web desde la perspectiva de un atacante.

Usaremos esa mentalidad para establecer una estrategia y encontrar debilidades en la aplicación.

La aplicación

Para descubrir vulnerabilidades en una aplicación, primero hemos de averiguar cómo funciona. La mejor manera de hacerlo es pulsando enlaces y viendo qué hacen, algo que podemos automatizar con una araña o web crawler.

Esta seguirá cada enlace e incluso tratará de introducir datos en los formularios. Con eso tendremos una lista de todas las páginas de la aplicación.

La herramienta Burp viene con una araña que puede hacer esto.

Algunas vulnerabilidades son particulares de ciertas funcionalidades, como por ejemplo:

  • Cuando ves una página de autenticación, ¿Puedes usar fuerza bruta?
  • Si hay una autenticación de usuario, ¿Puede haber una de administrador?
  • ¿Puedes subir contenido restringido en alguna funcionalidad de cargar archivos?
  • Si se genera input desde cajas de texto, ¿puedes hacer XSS?

Durante esta fase también es importante mirar qué tecnologías se usan, números de versión, posibles exploits

Así pues, escaneamos y respondemos a las preguntas.

Realizamos un escaneo «agresivo» con Rustscan:

rustscan -a Ip_Objetivo -- -A

¿Qué versión de Apache se está usando? La pista nos dice que miremos los encabezados HTTP de respuesta, la verdad es Rustscan nos los dice.

Pero bueno, podemos hacer

curl -i IP_Objetivo # Obtenemos encabezados y cuerpo 
curl -i 10.10.250.167 | grep -i server # Sacamos solo la parte del servidor

2.4.7

¿Qué lenguaje se ha usado para crear el sitio web? (También viene con la respuesta al pedir los encabezados y el cuerpo)

PHP

¿En qué versión? (También en el encabezado)

5.5.9

Estableciendo una metodología

Hay 2 formas particulares de probar una aplicación web a fin de encontrar vulnerabilidades de seguridad.

  • La primera es yendo página por página y proban toda la funcionalidad.
  • La segunda es dividiendo la prueba en fases, que incluyen, pero no están limitadas a.
    • Autorización.
    • Autenticación.
    • Inyección.
    • Controles en la parte del cliente.
    • Lógica de la aplicación.

En esta habitación combinaremos esos 2 enfoques.

Autenticación

Abarca probar los mecanismos y lógica que permite a los usuarios identificarse como usuarios. Se prueba de las siguientes maneras:

  • Fuerza bruta / credenciales débiles. En muchos casos, los usuarios escogen contraseñas comunes fáciles de adivinar.
  • Gestión de sesión. Las sesiones son los mecanismos por los cuales un servidor retiene un estado sobre la aplicación. Esto es necesario para recordar a los usuarios en sus transacciones. En algunos casos, las sesiones (que se guardan en cookies) guardan información sobre los usuarios, como su nivel de privilegios. Este estado puede ser manipulado y enviado de vuelta al servidor.

¿Cuál es el nombre del administrador? (La pista nos pide que pensemos en nombres comunes).

admin

¿Cuál es la contraseña del administrador? (La pista se pregunta si puede que sea la misma que el nombre de usuario)

admin

¿Cuál es el nombre de la cookie que puede ser manipulada? (La pista nos dice que chequeemos la cookie de la página de administración).

Nos identificamos con las credenciales débiles y echamos un vistazo a la cookie desde las herramientas de desarrollo de Firefox. Storage > Cookies

session

¿Cuál es el nombre de usuario de un usuario autenticado? (La pista nos dice que probemos con esta lista de nombres)

Si registramos un usuario, podemos ver todas las imágenes de ese usuario en esta dirección http://IP_Objetivo/users/view.php?userid=12

Ese 12 final es del usuario que acabo de crear. Si lo cambio a 11, veo las imágenes de otro usuario y cómo se llama.

Bryce

¿Cuál es su contraseña? (La pista nos guía de nuevo en que coincide con el nombre de usuario)

bryce

Cross-site Scripting XSS

Esta es una vulnerabilidad que permite inyectar javascript malicioso en webs. Eso puede servir para:

  • Robar información de sesión vía cookies.
  • Redirigir a usuarios a otras páginas (para hacer phishing).

Hay diferentes tipos de ataques XSS.

  • Persistentes / No reflejados. Aquí, el XSS ha sido almacenado en la base de datos y una vez el servidor / framework pasa los datos desde la base hasta la web, el script/payload se ejecuta.
  • No persistentes / Reflejados. El XSS es construido usando un enlace malicioso, no está almacenado.

Puedes usar javascript para ejecutar diferentes payloads y etiquetas HTML. Esta es una buena lista de recursos para payloads.

La habitación nos pide que probemos XSS en la barra de búsqueda, el libro de invitados y el formulario de la página inicial.

En los 3 sitios podemos sacar una ventana de alerta con:

<script>alert('hacked');</script>

Inyección

Este ataque ocurre cuando el usuario introduce datos que son procesados o interpretados por el servidor. Se da cuando los datos no son validados o saneados en dicho servidor.

Ataques habituales de inyección son:

  • Inyección SQL. Cuando el usuario proporciona datos maliciosos que son procesados por declaraciones SQL en el servidor. Normalmente, se usan para interactuar con bases de datos. Proveyendo un input malicioso, los usuarios pueden leer, modificar e incluso borrar datos de estas bases de datos si no se han parametrizado las peticiones. Más información aquí.
  • Inyección de comandos. Cuando lo que se provee como datos es interpretado como comandos de sistema por el servidor. Se pueden leer hashes de contraseñas o claves privadas. Más información aquí.

En muchos casos, el input se proporciona a través de un campo de texto en un formulario. Sin embargo, en otros casos puede ser cualquier cosa a la que el usuario tenga acceso y que sea interpretado por el servidor, como encabezados HTTP o campos de input deshabilitados.

Nos piden que inyectemos comandos en el campo de repetir contraseña durante un alta de usuario. La pista nos dice que usemos una pipe «|».

Nos vamos a la página de registro y probamos con la «frase mágica» en todos los campos:

' or 1=1--

Podemos ver todos los usuarios en el apartado de quién tiene un nombre similar, por ejemplo.

Miscelánea y lógicas fallidas

Las aplicación también pueden tener vulnerabilidades debido a una lógica fallida. Esta puede descubrirse probando estos componentes e intentando entender cómo se supone que funcionan.

Lo hacemos probando cosas que el desarrollador no tenía intención de que usáramos (poniendo números donde se introducen letras, tratando de iterar a través de un rango de números, etc).

Además de eso, las aplicaciones pueden tener otras vulnerabilidades-.

  • Manipulación de parámetros. Por ejemplo, en www.evil.com/photos?id=1 el parámetro es 1, pero podemos probar a cambiar a ver qué sale.
  • Recorrido de directorios (Directory traversal). Un atacante puede acceder a archivos que no estén en el directorio raíz (debido a un control de acceso incorrecto) manipulando variables que pueden tomar una ruta de archivo (añadiendo ../se puede navegar al directorio superior). Más información aquí.
  • Navegación por la fuerza. Un atacante puede acceder a contenido restringido usando fuerza bruta a través de diferentes URL’s y enlaces. Esto se puede hacer con diccionarios y listas de palabras, usando herramientas como Dirsearch. Más información, aquí.

La primera pregunta nos pide encontrar un vulnerabilidad de manipulación de parámetro y la pista nos dice que veamos la página sample.php.

Básicamente, se trata de cambiar el número de parámetro id final y vamos viendo las fotos de otros usuarios incluso sin estar autenticados.

Luego nos pide encontrar una vulnerabilidad de recorrido de directorio. La pista nos dice que miremos la página /pictures/upload.php

En esa página poner algo dentro del formulario Tag me da la ruta de subida.

Ruta de archivo

Hay una carpeta upload, que se puede listar directamente y aparecen subcarpetas e imágenes. Se puede subir una shell en php desde ahí, porque no hay filtros.

Ahora, hay que encontrar una vulnerabilidad de navegación por fuerza bruta. La pista nos dice que tratemos de acceder a una imagen restringida. Desde el directorio uploads podemos acceder a las imágenes en alta resolución.

Por último, nos dice que tratemos de conseguir gratis una imagen a la hora de comprar y como pista que usemos los descuentos.

A ver, podemos conseguirlas gratis aprovechando los enlaces de alta resolución. Del mismo modo, hay un código de descuento que puedo meter repetidas veces para ir bajando el precio hasta cero.

La habitación no está mal, pero resulta algo confusa, en la inyección de comandos, por ejemplo, o algunas otras peticiones.