En esta segunda parte de Hacking web hablaremos de los denominados: Ataques de ficheros y robo de sesiones.
Dentro de este tipo de ataques vamos a ver los dos más típicos:
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:
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.
Esta vulnerabilidad se basa en la manipulación de la ruta a un fichero del servidor para acceder a otros.
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.
Dentro de este apartado vamos a tratar las siguientes vulnerabilidades:
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.
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:
Por si todo falla es fundamental solicitar contraseña de usuario actual para poder cambiarla por una nueva.
Consiste en adivinar una contraseña probando todas las combinaciones posibles. Los tipos de ataque de fuerza bruta son los siguientes:
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.
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.
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.
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:
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internacional.