Cómo hackear aplicaciones web no seguras

En este artículo me gustaría demostrar lo fácil que es obtener información confidencial de una aplicación web que… bueno, no presta mucha atención a la seguridad. Con lo que trabajaré es con una aplicación Java de ejemplo que creé en Spring Boot con fines de demostración. Pero los ataques realizados son válidos para cualquier otro lenguaje de programación o framework. Algunas vulnerabilidades y problemas de seguridad que se demostrarán incluyen:

• Inyección SQL
• Exposición de datos sensibles
• Registro insuficiente
• Autenticación rota

La configuración

Trabajaremos con una aplicación web ficticia que le permite iniciar sesión como usuario que forma parte de algún grupo. En función del rol del usuario, puede ver datos básicos o confidenciales. En este caso, verá una lista de empleados en una empresa, su estado, etc.

Puedes encontrar las fuentes de esta aplicación en mi Github: https://github.com/rapasoft/hackme.

Ataque #1: Ataque del hombre en el medio

Imagine que está sentado en un restaurante y le gustaría comprobar algo en la aplicación anterior. Se conecta al Wi-Fi del restaurante, abre la página de inicio de sesión, introduce credenciales y obtiene la información que desea (por ejemplo, la lista de empleados específicos). Lo que puede que no sea ahora, es que sus credenciales han sido comprometidas. Examinemos de cerca la página de inicio de sesión:

Esta aplicación no utiliza SSL/TLS (por ejemplo, sin conexión https://). Esto significa que cualquier información enviada puede ser vista como texto plano por cualquier persona con acceso a la comunicación entre el cliente y el servidor.

Esto es exactamente lo que está sucediendo en el llamado ataque del Hombre en el medio. Más específicamente, en este caso, la suplantación de ARP se ha utilizado como una forma de envenenar toda la red para que el atacante esté al tanto de todo lo que sucede y pueda oler todos los paquetes. No voy a entrar en detalles sobre cómo funciona la suplantación de ARP, pero lo demostraré en este video:

Es posible que necesite abrir este video de Youtube en una nueva ventana y a pantalla completa para ver más detalles

Lo que puede ver arriba es que he iniciado Ettercap, que es una suite completa para ataques MITM, y he realizado spoofing ARP en mi red local. Mientras tanto, cuando el usuario (yo a través de iPad) ingresa las credenciales, estas son visibles tanto en Ettercap como en Wireshark (herramienta para el análisis del tráfico de red).

Ataque # 2: Inyección SQL

Continuando con nuestro papel como atacante de esta aplicación, ahora tenemos las credenciales para usuario hgraves con contraseña P4SSW0RD. Puede ver que no solo esta aplicación no usa TLS, sino que tiene una política de contraseñas muy débil que permite a los usuarios elegir contraseñas realmente horribles.

Iniciamos sesión con las credenciales anteriores y podemos ver un campo de entrada con la opción de buscar la lista de personas. Al pulsar Search obtendremos la lista completa de personas. Si ponemos «Fra», por ejemplo, obtendremos resultados filtrados basados en la búsqueda. ¿Y si ponemos un personaje ilegal? Es obvio que hay una base de datos detrás de esta aplicación, así que probemos el carácter ' :

No solo falló, sino que podemos ver que la solicitud POST ha fallado con un mensaje de error muy específico que expone la estructura de la instrucción SQL completa. Podemos ver que WHERE P.NAME LIKE '%'%' se usa al final.

El hacker experto no necesita más. Ajustar la cadena de búsqueda puede producir estos resultados después de unos pocos intentos:Resultados de inyección SQL

En este caso, la inyección creó la instrucción union to select que obtiene nombres de usuario y contraseñas junto con su función. No solo fue un éxito, sino que hemos logrado mostrarlo en la aplicación cliente original.

Ahora tenemos credenciales de todos los usuarios y sus roles (mostrados por el entero en la columna «Edad»). Si hframe tiene el rol 1, rgraves debe ser un usuario más importante con el rol 3.

Ataque # 3: Atacar contraseñas débilmente hash

Hemos aprendido en el primer ataque, que probablemente no hay ninguna política de contraseñas establecida para esta aplicación. Esto nos daría la esperanza de que rgraves tampoco preste demasiada atención a la seguridad.

La forma más fácil de descifrar el hash de la contraseña que utiliza un algoritmo de hash insuficiente (como MD5 en este caso) es realizar un ataque de tabla de diccionario o arco iris. Hay muchas posibilidades, pero la más fácil es usar servicios de Internet que ya tienen una gran base de datos de combinaciones de contraseña a hash:

El primero es hframe, el segundo es rgraves. smorgan parece estar usando contraseñas más fuertes que otras, ya que no está en el diccionario.

Puede ver que la contraseña para rgraves es pez espada, lo que significa que ahora no sabe lo importante que es elegir una contraseña que no sea de diccionario ;). Ahora, nada nos impide iniciar sesión como este usuario y descubrir la sección «administrador» y la información confidencial:

No leas esto si eres alemán 🙂

¿Cómo arreglar esto?

Se podría decir que todo esto se podría prevenir fácilmente. Se podría decir que estos fueron errores de novato. Bueno, esto podría ser cierto, pero lo que también es cierto es que el Proyecto de Seguridad de Aplicaciones Web Abiertas enumera la inyección como vulnerabilidad #1 en aplicaciones web (y ha sido así durante varios años).

Así que, si te has preguntado cómo evitar todo esto, recapitulemos:

• Utilice siempre SSL / TLS cuando envíe algo al servidor. No tiene que ser credenciales, actualmente se considera una buena práctica en general. ¡Incluso si no tienes ninguna entrada en tu página! La forma más fácil es proporcionar certificados a través de servicios como Let’s Encrypt.
• Recuerde que los certificados autofirmados pueden mitigar el problema de exposición de datos, pero no evite que el atacante MITM falsifique todo el sitio con su propio certificado autofirmado por completo.
• Cuando se trata de consultas SQL, siempre se escapan los parámetros obtenidos del cliente. La forma más fácil de hacerlo es usar las capacidades de su marco, por ejemplo, en primavera puede usar NamedParameterJdbcTemplate, que también es bueno para la legibilidad.
• Estar paranoico. Validar cualquier entrada de usuario. De nuevo en Java / Spring World, puede agregar reglas de validación usando JSR-380 implementación de validación de frijol como validador de Hibernación y parámetros de anotaciones, por ejemplo, @Pattern(regexp = "*") String name evitaría ingresar '.
• Registre cualquier intento de pasar entradas no válidas en la aplicación. Además, en caso de error, no exponga al cliente ninguna información específica de la implementación.
• Mejore su autenticación.
  • Si es posible, utilice al menos la autenticación de 2 factores.
  • No implemente algoritmos de cifrado o almacenamiento de contraseñas personalizados. Es extremadamente difícil de hacer por su cuenta y definitivamente fracasará. Hay soluciones probadas como BCrypt.
• Lea y marque OWASP TOP 10 como favorito. Comience con allí y luego repase su lista de mejores prácticas.