¿Y si no podemos usar herramientas?

A muchos nos ha pasado que estando en el desarrollo de una auditoria, nos damos cuenta de que el cliente posee métodos de protección como Firewall, Waf, IDS, IPS, etc. O que por el contrario, su sistema es tan inestable que cualquier exceso de peticiones o escaneo activo le puede ocasionar una denegación de servicios, afectando la disponibilidad de su activo, y de paso ocasionándonos como auditores un problema mayor.

Personalmente,  además del uso de algunas herramientas como apoyo, me gusta hacer un análisis manual del sitio a auditar, pues viendo cómo se comporta ante peticiones bien formadas (esperadas) o peticiones mal formadas (inesperadas), es cómo se logra entender el funcionamiento del sitio web y cuáles fueron las posibles fallas que el desarrollador pudo tener al momento de codificarlo.

Además, al realizar un análisis manual del sitio, se enviarán menos peticiones  innecesarias al servidor evitando así la detección o bloqueo por algún dispositivo de seguridad que se encuentre implementado, o provocando una denegación de servicio si el sitio de nuestro cliente es inestable. De esta forma podremos enfocar el uso de las herramientas de explotación a vulnerabilidades específicas que se hallan detectado. Para lograr este objetivo tenemos varios aliados, que vemos a continuación.

Análisis de los mensajes de errores que nos podría brindar la aplicación web.

Para este caso pondré solo como ejemplo los posibles mensajes de error que nos puede brindar una página al ser vulnerable a un SQL-injection (error based) en los diferentes motores de bases de datos:

  • SqlServer

  • Oracle

  • PostgreSQL Error:

  • MySQL

Una vez obtenidos estos mensajes de error, podemos identificar dentro de ellos el motor de base de datos utilizado.

Con esta información ya podremos utilizar nuestra herramienta preferida y configurarla para que solo realice ataques a las variables vulnerables y sobre un motor de bases de datos específico, evitando así la sobrecarga de peticiones sobre el sitio a auditar.

Códigos de respuesta del servidor web

Otros tipos de mensajes que debemos tener en cuenta son los que nos envía el servidor en sus respuestas. Como ya sabemos, un servidor web responde con un código de respuesta ante cualquier petición que se le realice, por ello, es importante conocerlos para así identificar qué información nos brinda y que acciones podemos tomar.

A continuación coloco algunos de los códigos más comunes que nos podemos encontrar al realizar una auditoria:

  • 404: Recurso inexistente. Como atacante ya no realizaríamos más acciones sobre este recurso.
  • 403: El recurso existe pero se necesita autorización para acceder a él.
  • 301: Este código indica una redirección y especifica que el recurso solicitado se ha movido permanentemente a otro sitio.
  • 302: Este código también hace referencia a una redirección, a diferencia del anterior se especifica que se ha movido temporalmente.
  • 500: Nos indica que el servidor tuvo un error interno, se puede seguir analizando el comportamiento para obtener más información.

Cabeceras HTTP

Además de los códigos de respuestas del servidor, en la cabecera server y la cabecera x-Powered-by  también se puede encontrar información de interés, tal como, servidor usado, tecnologías, aplicaciones y versiones instaladas, como se muestra a continuación:

Listado de directorios

En ocasiones nos encontramos con sitios que nos permiten listar los directorios y así navegar por todas las carpetas de la aplicación, obteniendo información de interés, como logs, backups o archivos sensibles que dejan olvidados dentro de dichas carpetas.

Páginas por defecto:

Otra forma fácil de obtener información es buscar las páginas por defecto que se encuentran normalmente en la raíz del servidor. Estas páginas nos pueden brindar información sobre servicios, el servidor de aplicaciones web usado, versiones etc.

 

 

 

Esta es solo una muestra de las muchas acciones que podemos realizar sobre un sitio que necesitemos auditar y sobre el cual no podamos ejecutar muchas peticiones. Por supuesto, por este mismo camino existen muchas otras herramientas de las que nos podemos ayudar, tales como el fichero robots.txt, Google hacking, uso de proxys para capturar y modificar peticiones con el objetivo de generar errores en el servidor, verificación del código fuente en busca de comentarios o versiones, etc.