Fuente original: Edgecast
La seguridad de las aplicaciones web sigue siendo un vector de amenaza principal para las organizaciones grandes y pequeñas. De acuerdo con el Informe de Investigaciones de Violación de Datos de Verizon 2020 (DBIR), el 43% de todas las violaciones de datos involucran una aplicación web,¹ y el 80% de todos los vectores de piratería se dirigen a las aplicaciones web²
En el cuarto trimestre de 2020, Verizon Media experimentó un marcado aumento en el tráfico de scripting entre sitios (XSS) en nuestra red de distribución de contenido (CDN) en comparación con trimestres anteriores. Este blog explora algunos puntos de datos de tráfico y disecciona una de las principales cargas útiles XSS intentadas. También compartimos cómo utilizar estos datos para aplicar medidas de protección.
Utilice este contenido como una guía orientada a la acción para manejar el tráfico XSS potencialmente malicioso que toca la puerta principal de su organización. También puede ayudarle a tener una conversación de seguridad necesaria con su equipo de liderazgo y sus homólogos de negocios / operaciones.
We Tenga los datos — exploremos
The Verizon Media WAF mitigó 1,5 mil millones de solicitudes en el cuarto trimestre de 2020. Definimos “mitigar” como cualquier evento WAF que desencadenó un bloqueo, respuesta personalizada o redirección URL. Estos 1,5 mil millones de bloques representan solicitudes HTTP que de otro modo habrían llegado a los servidores de origen de nuestros clientes. Estos datos nos dicen:
- La cantidad de análisis de vulnerabilidades de fondo es inmensa. Te equivocas si crees que estás a salvo porque tu objetivo no vale la pena atacar o porque no eres bien conocido. De acuerdo con el DBIR de Verizon, “si nos permiten una metáfora mixta, no hay que superar al oso en este caso, porque todos los osos están siendo impresos en 3D a granel y automatizados para cazarte”.³
- Si sus aplicaciones web están protegidas, tal escaneo puede parecer no más dañino que un robo de pomos de puerta, y permitir que dicho tráfico llegue a sus servidores es inofensivo, aparte de incurrir en carga adicional en su servidor. Pero en la guerra asimétrica de ciberseguridad, el atacante solo tiene que tener razón una vez, lo que facilita que tenga razón en el futuro. Entonces, ¿por qué dejar que el ladrón agite la perilla de la puerta si puede prevenirlo?
Para conducir este hogar un poco más lejos, echemos un vistazo más de cerca a algunos de los bloqueos del tráfico del cuarto trimestre de 2020.
El tráfico de scripting cruzado (XSS) bloqueado en los últimos tres trimestres pasó del primer puesto en el segundo trimestre de 2020 al cuarto puesto en el cuarto trimestre de 2020, casi duplicando su volumen durante este período de tiempo, representando el 10% del tráfico bloqueado.
Gráfico 1. En solo seis meses, vimos el tráfico XSS más del doble.
Getting Para conocer su tráfico XSS
According En el Open Web Application Security Project (OWASP), se producen fallos XSS cuando una aplicación incluye datos no fiables en una nueva página web sin validación o escape adecuados, o cuando una aplicación actualiza una página web existente con datos proporcionados por el usuario mediante una API de navegador que puede crear HTML o JavaScript. XSS permite a los atacantes ejecutar scripts en el navegador de la víctima, lo que puede secuestrar sesiones de usuario, destruir sitios web o redirigir al usuario a sitios maliciosos.
Esta exposición amenaza su infraestructura, confidencialidad e integridad de los datos, y la disponibilidad de los datos entregados a través de Internet. Estos ataques pueden resultar en el acceso no autorizado al contenido, la pérdida de información de identificación personal (PII) y la difusión de información privada / con derechos de autor.
Este es un problema, ya que nada se oculta de la vista una vez que está conectado y expuesto a Internet: Si lo pone de pie, será escaneado. Una vez que una nueva aplicación web se pone en línea y se expone a Internet, se probará para ver cómo reacciona a diferentes acciones o solicitudes. Los resultados de estos hallazgos pueden crear un giro interesante de la trama, que discutiremos en breve.
Primero, sigamos explorando el alcance de la exposición potencial. Muchos sitios web, aplicaciones web y servidores reciben y procesan solicitudes fuera de la red interna protegida de una empresa. Como resultado, son vulnerables a varias amenazas maliciosas agrupadas por OWASP, incluyendo inyecciones SQL, XSS y ataques de denegación de servicio distribuido (DDoS) en la capa de aplicación.
Teniendo en cuenta el aumento de los ataques XSS detectados por el WAF de Verizon, no es de extrañar que XSS encabeze la lista de MITRE CWE Top 25 para 2020 también:⁴
Gráfico 2. Una breve lista de las debilidades en el CWE Top 25 2020, incluyendo la puntuación general de cada uno.
Así como hemos visto un aumento en el tráfico XSS bloqueado, también lo es el número de vulnerabilidades reales documentadas en la Base de Datos Nacional de Vulnerabilidades (NVD) que también están conectadas a exploits XSS:
- 513 Vulnerabilidades XSS documentadas en los últimos tres meses (171 por mes)
- 5,507 Vulnerabilidades XSS documentadas en los últimos tres años (153 por mes)
- 16,936 Vulnerabilidades XSS documentadas todo el tiempo
Sí, los defensores usan las mismas herramientas que los atacantes para investigar vulnerabilidades. Por lo tanto, es importante reconocer el potencial de que la existencia de tráfico de aspecto malicioso no significa necesariamente que haya malas intenciones detrás del tráfico. Pero podría haber.
Como mínimo, si un actor curioso y malo escanea con éxito un sistema, podría intentar un exploit XSS, todo con el espíritu de realizar un reconocimiento. Peor aún, la actividad de reconocimiento, y los resultados obtenidos de ella, podrían usarse para eliminar una carga útil comprometida o destructiva a través de XSS o usarse como un paso hacia algo más nefasto, como una falsificación de solicitudes del lado del servidor (SSRF).
Is ¿Ese es un “excelente paso”, veo?
Remember ¿El escenario de jiggling de la manija de la puerta que mencionamos anteriormente? Es hora de traer de vuelta esa metáfora.
La mayoría del tráfico y los eventos XSS pueden no ser críticos para sí mismos, pero podrían llevar a desafíos y problemas significativos en el futuro, un paso adelante para un compromiso exitoso, si se quiere.
Los ataques XSS exitosos podrían permitir a los atacantes ejecutar HTML y JavaScript arbitrarios en el navegador de la víctima. Por lo general, el usuario tendrá que interactuar con algún enlace malicioso que apunte a una página controlada por el atacante, como sitios web de agujeros de agua o anuncios.
Echemos un vistazo a la infracción de la regla principal para el cuarto trimestre de 2020, designada internamente como ID de regla 941100, que se asignó a una de las principales cargas útiles, lo que demuestra la capacidad de usar XSS como un ataque de paso a paso:
“><Script >alert(String.fromCharCode(88,83,83))</script>”
Esta es una cadena de prueba XSS muy común en muchos repositorios de código, como htmlpurifier.org.⁵. Mientras se busca validar si esta carga útil en particular funcionará, se muestra un cuadro de alerta emergente con la cadena “XSS”, que verifica inmediatamente al atacante que un sitio web específico es vulnerable a XSS reflejado.
Una vez que un atacante verifica que existe un XSS reflejado, los ataques reflejados se envían a través de otra ruta, como un mensaje de correo electrónico u otro sitio web. Cuando se engaña a un usuario para que haga clic en un enlace malicioso, envíe un formulario especialmente diseñado o simplemente navegue por un sitio malicioso, el código inyectado viaja al sitio web vulnerable, lo que refleja el ataque de vuelta al navegador del usuario.”⁶
Gráfico 3. Cómo los ciberatacantes aprovechan las vulnerabilidades XSS.
Este ataque puede llevar a cabo cualquier cosa en el sitio web que el usuario atacado pueda realizar, incluida la “divulgación de la cookie de sesión del usuario, permitiendo que un atacante secuestra la sesión del usuario y se apodere de la cuenta”.⁷ Por ejemplo, un script que cambie la contraseña de un usuario enviado en nombre del usuario puede resultar en una toma de cuenta.
Hay otros ejemplos de trampolín a los que recurrir. En otro caso documentado públicamente, un ataque SSRF se inició originalmente a través de un exploit XSS, y el investigador de seguridad «fue capaz de escalar desde XSS dentro de una imagen hasta la lectura arbitraria de archivos locales en el servidor».⁸
No todos los investigadores (ni cibercriminales) serán lo suficientemente pacientes como para vincular su exploit XSS a algo más significativo. Sin embargo, mantener un XSS para cosas más grandes y mejores parece ser un método común para algunos investigadores que buscan ganar el gran premio en sus programas de recompensa de bug.
Mitigation y defense
En ausencia de datos, es difícil tomar una decisión. Sin embargo, se vuelve más fácil identificar un camino que te lleva al resultado deseado una vez que tienes visibilidad de una situación. Aquí hay una colección de consejos y recursos para ayudar a mitigar el riesgo que el tráfico XSS trae a su red y su negocio.
- Asegúrese de estar al tanto de todos los dispositivos que tienen acceso a Internet y de que tanto los sistemas heredados como los de prueba se consideran para el endurecimiento o se toman fuera de línea. Esto es especialmente importante en la era de la infraestructura en la nube, donde los equipos de desarrollo pueden activar máquinas con solo unos clics o enviando un formulario.
- Configure y refuerce correctamente los servidores web. Considere utilizar herramientas como el Centro de Valores de Internet para comprender cómo configurar los controles de su servidor. Configure correctamente sus configuraciones TLS para protegerse contra ataques MITM.
- Regularmente parchee todos los servidores de Internet. A veces, los frameworks comúnmente utilizados son vulnerables a XSS. A partir de febrero de 2021, la base de datos ATT&CK de MITRE enumera casi 17.000 vulnerabilidades y debilidades con alguna conexión a XSS.
- Verifique periódicamente la efectividad de su endurecimiento de seguridad. Utilice las mismas herramientas de prueba dinámica de seguridad de aplicaciones (DAST) que utilizan los atacantes, como OWASP ZAP o herramientas similares de análisis de vulnerabilidades en Kali Linux. Alternativamente, utilice un servicio DAST o de prueba de penetración para descubrir y escanear servidores vulnerables que se enfrentan a Internet.
- Habilite un firewall de aplicaciones web (WAF) para bloquear ataques comunes.
- Mantenga el WAF actualizado para bloquear inmediatamente cualquier vulnerabilidad descubierta, lo que permite al equipo de aplicaciones implementar una solución. Actualice el WAF a medida que las nuevas reglas estén disponibles para protegerse contra vulnerabilidades recién descubiertas.
- Habilite el registro e inspeccione esos registros.
- Proteja sus sitios web y su infraestructura de red crítica de ataques volumétricos utilizando un servicio DNS autoritativo altamente redundante y servicios de protección DDoS altamente distribuidos y aceleración web, es decir, el CDN.
Empieza con tu data
Es posible que tengas tus aplicaciones bien ajustadas para ofrecer contenido y un sólido conjunto de controles de seguridad que te ayuden a mitigar los riesgos y quizás incluso bloqueen los ataques que llegan al interior. Aún así, ¿por qué dejar que el tráfico potencialmente dañino entre en su red en primer lugar? ¿Por qué arriesgarse a que una póliza se pierda o un control se eluda?
Los clientes de Verizon Media Security tienen dos capacidades al alcance de sus dedos que pueden protegerlos de las amenazas:
- Vemos tráfico de red potencialmente dañino (o al menos inútil) que llega a su sitio.
- El Verizon Media WAF integrado puede ser habilitado para bloquear el tráfico malicioso antes de que se convierta en un problema automáticamente.
Dé un paso importante para mejorar la seguridad de sus aplicaciones web, contáctenos hoy para obtener más información.
Referencias
- Verizon, “Informe de Investigaciones de Violación de Datos 2020”, Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Página 7.
- Ibíd., página 88.
- Ibíd., página 23.
- CWE, “2020 CWE Top 25 Debilidades de Software Más Peligrosas ,” CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
- HTMLpurifier, “HTML Purifier XSS Attacks Smoketest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
- OWASP, “Cross site scripting (XSS),” owasp.org, owasp.org/www-community/attacks/xss/
- Ibíd
- Buerhaus, Brett, “Escalando XSS en la representación de imágenes PhantomJS a SSRF/local-file read, buer.haus. 29 de junio de 2020.
