Home Artículos técnicos Ataques de guiones entre sitios (XSS) en el cuarto trimestre de 2020: Tendencias y mejores prácticas
Applications

Ataques de guiones entre sitios (XSS) en el cuarto trimestre de 2020: Tendencias y mejores prácticas

About The Author

Outline

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 Investigación de Violaciones de Datos (DBIR) de Verizon 2020, el 43% de todas las filtraciones de datos involucran una aplicación web,¹ y el 80% de todos los vectores de hacking se dirigen a aplicaciones web.²

En el cuarto trimestre de 2020, Verizon Media vio un marcado aumento en el tráfico de scripts entre sitios (XSS) en nuestra red de entrega 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 de XSS intentadas. También compartimos cómo utilizar estos datos para aplicar medidas de protección.

Utilice este contenido como una guía impulsada por la acción para manejar el tráfico XSS potencialmente malicioso que golpea 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 contrapartes comerciales / operacionales.

‍We Tenga los datos — Exploremoslos

‍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 bloque, una respuesta personalizada o una 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:

  1. La cantidad de análisis de vulnerabilidad de fondo es inmensa. Te equivocas si crees que estás a salvo porque no vale la pena atacar a tu objetivo o porque no eres bien conocido. Según el Verizon DBIR, “Si nos permiten una metáfora mixta, no hay superación del oso en este caso, porque todos los osos están siendo impresos en 3D a granel y automatizados para cazarte”³
  2. Si sus aplicaciones web están protegidas, tal escaneo puede parecer no más dañino que un ladrón jiggling pomos de las puertas, y permitir que dicho tráfico llegue a sus servidores es inofensivo que incurrir en carga adicional en su servidor. Pero en la guerra asimétrica de la ciberseguridad, el atacante solo tiene que tener razón una vez, lo que facilita que tengan razón en el futuro. Entonces, ¿por qué dejar que el ladrón empuje el pomo de la puerta si se puede prevenir?

Para conducir esta casa un poco más lejos, echemos un vistazo más de cerca a parte del tráfico bloqueado del cuarto trimestre de 2020.

El tráfico bloqueado de secuencias de comandos entre sitios (XSS) en los últimos tres trimestres se movió desde el primer lugar en el segundo trimestre de 2020 al cuarto lugar en el cuarto trimestre de 2020, casi duplicando el volumen durante este período de tiempo, lo que representa el 10% del tráfico bloqueado.

Gráfico 1. En solo seis meses, vimos el tráfico XSS más del doble.

‍Getting Conocer su tráfico XSS

‍According En el proyecto de seguridad de aplicaciones web abiertas (OWASP), se producen fallas de XSS cuando una aplicación incluye datos no confiables en una nueva página web sin la validación adecuada o escapes o cuando una aplicación actualiza una página web existente con datos proporcionados por el usuario utilizando 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, descifrar sitios web o redirigir al usuario a sitios maliciosos.

Esta exposición amenaza su infraestructura, la 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 está oculto a la vista una vez que está conectado y expuesto a Internet: Si lo pone de pie, se escaneará. Una vez que una nueva aplicación web entra 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, continuemos 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 distribuidos de denegación de servicio (DDoS) en la capa de aplicación.

Teniendo en cuenta el aumento de los ataques XSS detectados por el Verizon WAF, no es de extrañar que XSS encabece la lista de MITRE CWE Top 25 para 2020 también:⁴

Gráfico 2. Una breve lista de las debilidades en el Top 25 CWE 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 Vulnerabilidad (NVD) que también están conectadas a exploits XSS:

  • ‍513 Vulnerabilidades XSS documentadas en los últimos tres meses (171 al 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 las vulnerabilidades. Por lo tanto, es importante reconocer el potencial de que la existencia de tráfico de aspecto malicioso no necesariamente significa que hay malas intenciones detrás del tráfico. Pero podría haber.

Como mínimo, si un curioso mal actor escanea con éxito un sistema, podría intentar un exploit XSS, todo con el espíritu de realizar reconocimiento. Peor aún, la actividad de reconocimiento, y los resultados obtenidos de ella, podría usarse para eliminar una carga útil comprometedora o destructiva a través de XSS o usarse como un trampolín para algo más nefasto, como una falsificación de solicitudes del lado del servidor (SSRF).

‍Is Eso es un “excelente escalón”, lo veo?

‍Remember ¿El escenario de puñetazo de puerta que mencionamos anteriormente? Es hora de traer esa metáfora de vuelta.

La mayoría del tráfico y los eventos de XSS pueden no ser críticos para sí mismos, pero podrían conducir a desafíos y problemas significativos en el camino, un escalón 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 apunta a una página controlada por el atacante, como sitios web de abrevaderos o anuncios.

Veamos la violación de la regla principal para el cuarto trimestre de 2020, designada internamente como ID de regla 941100, que se mapea a una de las cargas útiles principales, lo que demuestra la capacidad de usar XSS como un ataque de piedra angular:

“><Alerta de script >(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», verificando 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 en un mensaje de correo electrónico u otro sitio web. Cuando un usuario es engañado para que haga clic en un enlace malicioso, envíe un formulario especialmente diseñado, o incluso 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 realizar cualquier cosa en el sitio web que el usuario que está siendo atacado puede realizar, incluida la “divulgación de la cookie de sesión del usuario, lo que permite a un atacante secuestrar la sesión del usuario y hacerse cargo de la cuenta”.⁷ Por ejemplo, un script que cambia la contraseña de un usuario enviada en nombre del usuario puede resultar en una adquisición de la 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 el archivo local arbitrario leído en el servidor”⁸

No todos los investigadores (ni los cibercriminales) serán lo suficientemente pacientes como para vincular su explotación 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 obtener el gran premio en sus programas de recompensas de errores.

‍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 lleve al resultado deseado una vez que tengas 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.

  1. Asegúrese de estar al tanto de todos los dispositivos orientados a Internet y de que tanto los sistemas heredados como los de prueba se consideran para el endurecimiento o se desconectan. Esto es especialmente importante en la era de la infraestructura en la nube, donde los equipos de desarrollo pueden hacer girar las máquinas con solo unos pocos clics o enviando un formulario.
  2. Configure y endurezca correctamente los servidores web. Considera usar herramientas como los Benchmarks de Center for Internet Securities para entender cómo configurar los controles de tu servidor. Configure correctamente sus configuraciones TLS para protegerse contra ataques MITM.
  3. Parche regularmente todos los servidores orientados a Internet. A veces, los frameworks de uso común 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.
  4. 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 de prueba DAST o de penetración para descubrir y escanear servidores vulnerables que se enfrentan a Internet.
  5. Habilite un firewall de aplicaciones web (WAF) para bloquear ataques comunes.
  6. Mantenga el WAF actualizado para bloquear cualquier vulnerabilidad descubierta inmediatamente, 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.
  7. Habilite el registro e inspeccione esos registros.
  8. Proteja sus sitios web y la infraestructura de red crítica de ataques volumétricos utilizando un servicio DNS autoritativo altamente redundante y servicios de protección DDoS y aceleración web altamente distribuidos, es decir, CDN.

Empieza con tu data‍

Es posible que tenga sus aplicaciones finamente ajustadas para ofrecer contenido y un conjunto robusto de controles de seguridad para ayudar a mitigar los riesgos y tal vez incluso bloquear los ataques que entran en el 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 se pierda una política o se pase por alto un control?

Los clientes de Verizon Media Security tienen dos capacidades a su alcance que pueden protegerlos de amenazas:

  1. Vemos el tráfico de red potencialmente dañino (o al menos inútil) que golpea su sitio.
  2. El Verizon Media WAF integrado se puede habilitar 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 mismo para obtener más información.

Referencias

  1. Verizon, “Informe de investigaciones de violación de datos de 2020,” Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Página 7.
  2. Ibíd., página 88.
  3. Ibíd., página 23.
  4. CWE, “2020 CWE Las 25 debilidades más peligrosas del software,” CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
  5. HTMLpurifier, “HTML purifier XSS Attacks Smoketest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
  6. OWASP, “Cross site scripting (XSS),” owasp.org, owasp.org/www-community/attacks/xss/
  7. Ibid
  8. Buerhaus, Brett, “Escalando XSS en la representación de imágenes PhantomJS a SSRF/local-file read, buer.haus. 29 de junio de 2020.