Hacking web. Ataques habituales y maneras de defendernos. (P.2)

En esta segunda parte de Hacking web  hablaremos de los denominados: Ataques de ficheros y robo de sesiones.

Hacking web : Ataques de ficheros

Dentro de este tipo de ataques vamos a ver los dos más típicos:

• Subida de ficheros sin restricciones. (Unrestricted File Upload)
• Inclusión de ficheros locales. (Local File Inclusion)

Unrestricted File Upload

Esta vulnerabilidad se produce cuando en una aplicación web de ficheros no restringe el tamaño o el tipo de fichero en un formulario de subida de archivos.

Tipos de ataques:

• Insertar un código malicioso dentro del fichero (.jps, php, vbscript, etc) que pueda ser susceptible de ejecutarse en el servidor dependiendo de la gestión del sistema.
• Subir un fichero extremadamente grande (” varios Terabytes (TB)”), que se coma todo el espacio en disco, inutilizando el servidor.
• Ficheros con nombres sensible para conseguir sobre-escribir ficheros del sistema.

Ejemplo de ataque con fichero con código malicioso

Simulemos la subida de una Shell en formato PHP a un servidor mediante el motor de subida de ficheros.

Cuando el servidor intente abrir el fichero que ha subido el atacante para mostrar su contenido, éste levantará un formulario tipo Shell para poder acceder al contenido del servidor donde está corriendo la aplicación.

El atacante buscará una página en la que pueda subir su fichero: Shell.php.

Al pulsar: “seleccionar archivo” , seleccionará el fichero malicioso.

Una vez subido el script, el atacante intentará acceder al fichero subido. Si la aplicación carga el fichero en el servidor para mostrarlo en una página, le aparecerá al usuario que acceda el formulario Shell y podrá intentar acceder a información sensible dentro del servidor.

Otra opción es que el atacante sabiendo que ha conseguido subir su script, intentará acceder vía url a la misma.

Una vez que ha lanzado la consola Shell, podría acceder a cualquier fichero del sistema, si el sistema de directorios y ficheros no está correctamente protegido.

Hacking web. Cómo evitar estos ataques de cara al desarrollador

• Restringir la extensión y el tipo de fichero
• Restringir el tamaño del fichero
• Sanear el nombre del fichero
• Descargar el fichero y no abrirlo desde el servidor

Local File Inclusion

Esta vulnerabilidad se basa en la manipulación de la ruta a un fichero del servidor para acceder a otros.

Ejemplo de ataque de tipo Local File Inclusion

Vamos a ver un ejemplo de una página web que tiene cuatro enlaces a cuatro ficheros distintos.

Cuando se pulse sobre un enlace, el servidor abrirá el fichero en el servidor y mostrará su contenido. El atacante crea un fichero cuya ruta y extensión es la siguiente: ../../../../../../etc/passwd. Su pretensión es ir a la raíz del sistema y a partir de ahí realizar el ataque. Lo sube en el sitio web que corre en un servidor APACHE con el título informe 3, quedando de esta forma:

Si pulsa sobre el título de su fichero subido, la web al abrir el fichero en el servidor, le mostraría lo siguiente:

Como veis le mostraría los usuarios de la aplicación, los grupos, etc. El atacante de esta manera podría acceder a cualquier fichero con permisos de lectura que tenga el usuario que levanta el Apache.

Hacking web. Cómo evitar estos ataques de cara al desarrollador

• Restringir el nombre y la ruta a acceder.

Hacking web : Robo de sesiones

Dentro de este apartado vamos a tratar las siguientes vulnerabilidades:

• Session Prediction
• Fuerza bruta

Session Prediction

Consiste en la deducción del ID de sesión de otro usuario a partir de un ID de sesión propio con el fin de acceder a la aplicación con el usuario de la otra persona.

Ataque de Session Prediction

Vamos a simular que somos el atacante y vamos a modificar el ID de sesión para acceder a la sesión de otro usuario.

Para ello va a utilizar la herramienta Zas de OWASP. Zas es una herramienta gratuita de código abierto desarrollada en JavaScript para realizar auditorías de seguridad web para encontrar fallos comprometedores. Para usarla y ver las vulnerabilidades de una web prácticamente, solo necesitamos pegar la url al que quieres hacer la “auditoria” 😊 y pulsar Atacar. (Descargar ZAS.)

Introducimos, la IP y el puerto de escucha:

Vamos a las opciones de configuración de Firefox y marcamos “Configuración de Proxi Manual” y escribimos la IP local y el puerto. De esta forma todo lo que salga del navegador lo redirigirá a esta ruta y lo capturará la herramienta ZAS.

Ahora vamos a la aplicación de test para que veáis el cambio el robo de ID, y nos logamos:

Al logarme, la web me muestra un texto con mi usuario y mi ID de sesión. El enlace “Ver mis datos”, me muestra el mismo mensaje que cuando me logo. Una vez logados, volvemos a ZAS y pulsamos botón de capturar:

Volvemos a la web de test y pulsamos sobre “Ver mis datos”. Veremos como la web se queda esperando.

Volvemos a Zas para ver lo que se ha enviado

Voy a cambiar desde ZAS al user2 y pulsar el botón de enviar. “He creado el usuario ‘Jose Antonio’ previamente en la web de test y como es incremental el sistema de otorga los id de sesión, le ha dado el user2”:

Ahora volvemos a la web de test y observamos que cuando refresca ya soy Jose Antonio puesto que le he robado la sesión a dicho usuario:

Hacking web. Como evitar el ataque “Session Prediction” por parte del desarrollador

• El ID de sesión:
  • Debe ser creado en el servidor.
  • Tiene que ser único.
  • Siempre aleatorio.
  • Debe ir encriptado.
  • Siempre tener tiempo de expiración.

Por si todo falla es fundamental solicitar contraseña de usuario actual para poder cambiarla por una nueva.

Fuerza bruta

Consiste en adivinar una contraseña probando todas las combinaciones posibles. Los tipos de ataque de fuerza bruta son los siguientes:

• Fuerza bruta: Consiste en probar todas las combinaciones posibles.
• Ataques de diccionario: prueba un subconjunto de opciones (palabras comunes, nombres de mascotas más comunes, etc.…)
• Fechas: Se introducen todas las fechas del último siglo posibles.

Hay muchos patrones lógicos para optimizar la forma de conseguir las contraseñas por el sistema de fuerza bruta, normalmente se averigua el nombre de usuario que está a la vista de todo el mundo en muchos sitios. Una vez hecho esto se le concatena números, ya que un porcentaje muy alto ponen como password un numero seguido de su usuario tipo: AlvaroB35.

Si sabe que mi usuario es AlvaroB, el atacante comenzaría a combinar números hasta dar con mi clave. En el caso que he puesto, solo tendría que hacer 35 iteraciones para averiguar mi contraseña.

Ataque de fuerza bruta

Para simular esta prueba vamos a utilizar una herramienta que está diseñada para pruebas de rendimiento, pero nos viene muy bien ya que realiza peticiones de forma masiva. Esta herramienta es Apache Jmeter.

El objetivo será buscar una password de tipo fecha.

1. Abrimos Apache Jmeter y cargamos el script que queremos que se ejecute. (El script es un código sencillo que va incrementando los días de las fechas de forma coherente): 

2. Ponemos el usuario y fecha inicial con la que vamos a intentar logarnos:

3. Vamos al controlador “While” y le decimos que hasta que la variable de respuesta no sea un 1 que no se detenga.

4. Ponemos la url de donde queremos acceder y la IP del servidor.

5. Le damos a ejecutar y veremos en consola los intentos que realiza:

Comenzará a intentar descubrir la password del usuario:

En cuanto la respuesta sea “logged in”, pondrá el controlador del “while” a 1 y finalizará:

6. Vamos a ver la pantalla de resultados y vemos que la ultima petición está en verde. Eso es que ha encontrado la contraseña y se ha logado.

Hacking web. Cómo evitar el ataque “de fuerza bruta” por parte del desarrollador:

• Bloquear el usuario al x intentos
• No dejar introducir los siguientes intentos hasta que no pase un lapso de tiempo y que éste se incremente según el número de intentos.
• Autentificación multi-factor.

Conclusión Hacking web

La seguridad cada vez toma más importancia, debido a que las personas comparten, cada día más información sensible en multitud de plataformas y aplicaciones.

Es nuestra obligación como profesionales velar por la privacidad de esos usuarios que confían y utilizan nuestras soluciones.

A todos los desarrolladores, ¡no hay excusa para no hacerlo!, ¡no hay tiempos tan apretados como para dejarlo para más adelante! Es sencilla la premisa… por favor, no olvidéis que “Cualquier entrada de datos a tu página web hay que tratarla y controlarla”!

Dicho lo anterior la seguridad no solo es cosa de los programadores o administradores, es responsabilidad de todos:

• No pulsen sobre enlaces sospechosos.
• No descarguen ficheros de origen desconocido.
• Pongan contraseñas de al menos 10 caracteres alfanuméricos con combinaciones de símbolos. Si el sistema no permitiera introducir una contraseña tan grande, se debe elegir combinaciones complejas en lugar de simples.
• No ignoren las advertencias de seguridad de las aplicaciones ni de los administradores.

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internacional.

Compártelo: