Disponer de un sitio web, nos brinda la oportunidad de negocio en internet las 24 horas en los 365 días del año. Si embargo, esto también puede tener una vertiente negativa: tenemos expuesta nuestra empresa en la red las 24 horas de los 365 días del año.
Esto no es un problema, siempre que nuestro sitio o aplicación cuente con auditorías rutinarias, vulnerabilidades corregidas y software legal y actualizado. Pero por desgracia, en ocasiones esto no se cumple, provocando dolores de cabeza, pérdida económica o de datos y daño reputacional a nuestra organización.
Hazte estas preguntas: ¿Dejarías la puerta de tu edificio sin protección? ¿Te olvidarías del mantenimiento?
Estoy seguro de que no. Si los delincuentes se dieran cuenta de la poca de seguridad que tiene tu finca, es muy probable que tuvierais robos o vandalismos en reiteradas ocasiones; provocando que este problema afecte al resto de personas y viviendas.
Llevado al mundo informático, es un claro ejemplo de lo que podría ocurrir teniendo un sitio web o aplicación vulnerable. No solo nos “jugamos” la seguridad de nuestro sitio web, si no la posibilidad de que un atacante pueda hacerse con el control de otras aplicaciones y servicios que están ejecutándose por debajo, comprometer nuestros servidores, o incluso peor, que pudiera afectar a la seguridad e integridad de la información de nuestros clientes.
¿Entonces? ¿Por qué te la juegas con tu web?
Por ello, en este artículo os explico algunas de las vulnerabilidades más conocidas y utilizadas por los ciberdelincuentes para comprometer nuestras aplicaciones web.
Clickjacking
Este ataque consiste en engañar al usuario para que pulse en un enlace, botón o imagen malicioso que estará de forma oculta o transparente y sobrepuesto en una zona específica del sitio web (por ejemplo, el menú); al pulsar, este será redirigido a un sitio web fraudulento.
Demostración:
Cross-site Request Forgery (CSRF)
Este ataque consiste en engañar al usuario para que realice una acción determinada sobre una aplicación web vulnerable y sin que la víctima se percate de ello.
En el siguiente ejemplo, el usuario cliqueará en un enlace malicioso y este, hará una transacción a otro usuario y cambiará su nombre:
Efectuando el ataque:
- Atacante: Creará un formulario con tres campos ocultos que utilizará para robar los créditos y cambiar los datos del usuario que lo ejecute.
- Víctima: Ejecutará el botón del formulario y será redirigido al sitio web de su banco, la víctima no sospechará nada, pero la realidad será diferente cuando acceda a su perfil.
Demostración:
Cross Site Scripting (XSS)
Esta vulnerabilidad permite que un atacante pueda ejecutar código en el navegador del cliente (víctima), pudiendo este conseguir, credenciales o cookies de sesión, redirigir conexiones a sitios con contenido malicioso, realizar ataques de phishing utilizando el servidor, e incluso lanzar ataques de denegación de servicio sobre el navegador del usuario.
En este ejemplo, un atacante aprovechará esta vulnerabilidad en unos de los plugins del CMS para ejecutar código desde una Shell (atacante) al navegador del usuario (víctima).
Demostración:
Inyección SQL (SQL Injection)
Un ataque de inyección de código SQL trata de la manipulación de un parámetro de entrada que introduce el cliente hacia la aplicación web. Mediante una cadena de texto especialmente manipulada, se podría modificar la consulta SQL que realiza la aplicación contra el backend y recuperar consultas arbitrarias, pudiendo descargar y obtener información crítica de la base de datos, subir ficheros (Shell reversa) o evadir sistemas de autenticación sin el uso de credenciales legítimas.
Veremos dos ejemplos, en el primero vemos una inyección SQL para conseguir evadir el sistema de autenticación de la aplicación. Esta técnica es conocida por Bypass Authentication:
Envío de la petición maliciosa:
Respuesta del servidor:
Demostración:
En este segundo ejemplo, aprovecharemos la vulnerabilidad de SQL Injection para obtener las credenciales de la base de datos:
Envío de la secuencia maliciosa (payload) por medio de la herramienta Sqlmap:
Evidencia de las credenciales almacenadas en la base de datos:
Demostración:
Ejecución de código remoto (RCE)
Un atacante utilizaría esta vulnerabilidad para ejecutar código arbitrario desde nuestra aplicación web. Este método, permitiría el acceso inmediato a la máquina, pudiendo alojar, eliminar o modificar ficheros, instalar y ejecutar malware en su interior, en incluso, podría aprovechar otras vulnerabilidades del Sistema Operativo, o servicios instalados; para realizar una escala de privilegios y/o el acceso a otros recursos de la compañía.
Envío de la petición maliciosa:
Respuesta del servidor:
Demostración:
Inclusión de ficheros (LFI)
Esta técnica consiste en cargar ficheros en la ejecución de la aplicación a consecuencia de un fallo en la programación de la aplicación al no controlar el origen del fichero que se está incluyendo dentro del flujo de ejecución.
Ese tipo de técnicas podría ser por:
- Inclusión de fichero local (LFI): Esta técnica permitiría descargar cualquier fichero del servidor.
- Inclusión de fichero remoto (RFI): Este permitiría subir y probablemente, ejecutar cualquier fichero al servidor.
Envío de la petición maliciosa:
Respuesta del servidor:
Demostración:
Inclusión de fichero y ejecución de código (LFI + RCE)
Hasta ahora, os he mencionado las vulnerabilidades por separado, pero también sería posible convertir una inclusión de ficheros (LFI) en una ejecución de código remoto (RCE), la “magia” reside en lograr que un texto arbitrario sea procesado por un lenguaje del lado del servidor, este lo procese y nos sea devuelto con la información.
Para la siguiente demostración, he utilizado una técnica muy conocida llamada “Envenenamiento de registro” (Log Poisoning), esta consiste en leer un fichero de registro (log) por medio de una “inclusión de fichero” (LFI) y modificar el texto de las cabeceras (ej. User-agent) para escribir código arbitrario y conseguir que sea ejecutado (RCE) por la máquina víctima.
Envío de la petición maliciosa:
Respuesta del servidor:
Demostración:
Redirección de URL a sitio no confiable
Existe un servicio web que tiene implementado una redirección que podría usarse ilícitamente, por lo tanto, un atacante podría aprovechar esta redirección desde el dominio legítimo para llevar a estos usuarios a un sitio web controlado por el atacante o maliciosa.
Demostración:
¿Conocías estas vulnerabilidades web? ¿Estás seguro de que tu web o aplicación está bien protegida? En Sothis nos adelantamos a “los malos”, por eso te recomendamos realizar una auditoría periódicamente de tus aplicaciones web y así comprobar tu nivel de salud en este mundo digital.
