Header Ads Widget

Ticker

6/recent/ticker-posts

Archivos JavaScript (de ataques al estilo Magecart)

 La mayoría de las páginas web ahora constan de varios archivos JavaScript que se incluyen de varias formas (a través de <script> o de alguna manera más dinámica, agrupados y minimizados o no). Pero dado que estos scripts interactúan con todo en la página, pueden representar un riesgo para la seguridad.

Y  Magecart  mostró ese riesgo: el grupo atacó varios sitios web, incluidos  British Airways y Ticketmaster, y robó algunos cientos de miles de números de tarjetas de crédito.

Es un ataque simple en el que el atacante inserta un fragmento de JavaScript malicioso en un archivo javascript confiable, recopila los detalles de la tarjeta de crédito ingresados ​​en formularios de pago y los envía a un sitio web propiedad del atacante. Obviamente, la parte fácil es escribir el javascript malicioso; lo difícil es conseguirlo en el sitio web de destino.

Muchos sitios web se basan en activos alojados externamente (incluidos scripts), ya sea un CDN o un servidor de activos dedicado (como en el caso de British Airways). Estos activos alojados externamente pueden ser vulnerables de varias formas:

  • Los servidores de activos pueden estar menos protegidos que el servidor real, porque son solo activos estáticos, ¿qué podría salir mal?
  • Es posible que se filtren las credenciales para acceder a la configuración de CDN, lo que puede llevar a que un atacante reemplace los scripts de origen originales por los suyos.
  • Los ataques man-in-the-middle son posibles si el servidor de activos está mal configurado (por ejemplo, permitiendo el ataque de degradación de TLS)
  • El servicio externo (por ejemplo, CND) en el que se confiaba anteriormente puede volverse deshonesto; eso es poco probable con los grandes proveedores, pero los más pequeños y baratos son menos predecibles

Una vez que los atacantes han reemplazado el script, están recopilando datos en silencio hasta que los atrapan. Y esto puede llevar mucho tiempo.

Entonces, ¿cómo protegerse contra esos ataques? Un consejo típico es introducir una política de seguridad de contenido, que permitirá que se ejecuten scripts de dominios que no sean de confianza. Esta es una buena idea, pero no ayuda en el caso de que un dominio de confianza se vea comprometido. Hay  varios enfoques principales , y los resumiré a continuación:

  • Integridad de los subrecursos  : esta es una función del navegador que le permite especificar el hash de un archivo de secuencia de comandos y valida ese hash cuando se carga la página. Si no coincide con el hash del script realmente cargado, el script se bloquea. Esto suena muy bien, pero tiene varias implicaciones prácticas. Primero, significa que necesita complicar su canal de compilación para que calcule los hash de los recursos minificados y agrupados e inyecte esos hash en las plantillas de página. Es un proceso tedioso, pero factible. Luego están los scripts cargados dinámicamente donde no puede usar esta función, y están los navegadores que no la admiten por completo (Edge, IE y Safari en dispositivos móviles). Y finalmente, si no tiene una buena canalización de compilación (que muchos sitios web pequeños no tienen), un cambio legítimo muy pequeño en el script puede romper todo su sitio web.
  • No utilice servicios externos; suena sencillo, pero no siempre lo es. Los CDN existen por una razón y optimizan las velocidades de carga de su sitio y, por lo tanto, las políticas internas de clasificación pueden requerir el uso de un servidor de activos dedicado, a veces los complementos (por ejemplo, para WordPress) pueden obtener recursos externos. Se permite una excepción a esta regla si de alguna manera colocas en un sandbox el script de terceros (por ejemplo, a través de iframe como se explica en el enlace anterior)
  • Asegure todos los servidores externos correctamente, si puede hacer eso, eso es genial, actualice los conjuntos de cifrado compatibles, controle durante 0 días, use solo CDN de alta confianza. Independientemente de cualquier cosa, obviamente siempre debes esforzarte por hacer eso. Pero requiere experiencia y recursos, que pueden no estar disponibles para todas las empresas y todos los equipos.

Hay un escenario más que puede parecer extraño: si un atacante piratea su (s) servidor (es) de aplicaciones principal, puede reemplazar los scripts con lo que quiera. Suena extraño al principio, porque si tienen acceso al servidor, el juego termina de todos modos. Pero no siempre es un acceso completo con RCE, puede ser un acceso limitado. Los números de tarjetas de crédito generalmente no se almacenan en texto plano en la base de datos, por lo que tener acceso al servidor de aplicaciones puede no significar que tenga acceso a los números de tarjetas de crédito. Y cambiar el código de backend personalizado para recopilar los datos es mucho más impredecible y requiere más tiempo que simplemente reemplazar los scripts por otros maliciosos. Ninguna de las opciones anteriores protege contra eso (ya que en este caso el atacante puede cambiar el hash esperado para la verificación de integridad del sub-recurso)

Debido a las limitaciones de los enfoques anteriores, en mi empresa decidimos proporcionar una herramienta para monitorear su sitio web en busca de tales ataques. Se llama  Scriptinel.com  (abreviatura de Script Sentinel) y actualmente se encuentra en fase beta inicial. Está dirigido principalmente a propietarios de sitios web pequeños que no pueden obtener ninguno de los 3 puntos anteriores, pero también se puede utilizar para sitios web sofisticados.

Lo que hace es sencillo: escanea una URL determinada, extrae todos los scripts (incluso los dinámicos) y comienza a monitorearlos para detectar cambios con solicitudes periódicas. Si descubre un cambio, notifica al propietario del sitio web para que pueda reaccionar.

Esto significa que el atacante puede tener unos minutos para recopilar datos, pero el tiempo es un factor importante aquí; esto no es una violación de datos "SELECCIONAR *"; depende de los clientes que utilizan el sitio web. Así que unos minutos minimizan el daño. Y no rompe su sitio web (supongo que podemos tener un script para incluir que bloquee la página si scriptinel ha encontrado discrepancias). Tampoco requiere cambios en el proceso de compilación para incluir hash. Por supuesto, un enfoque tan reactivo no es perfecto, especialmente si no hay nadie que reaccione, pero el monitoreo es una buena idea independientemente de si se utilizan otros enfoques.

Existe el problema de las páginas protegidas y las páginas a las que no se puede acceder directamente mediante una solicitud GET, por ejemplo, una página de pago. Para eso, puede ingresar sus archivos javascript individualmente, en lugar de que la herramienta escanee la página. Podemos agregar un escaneo de viaje de usuario más sofisticado, con la especificación de credenciales y pasos para llegar a las páginas protegidas, pero por ahora eso parece innecesario.

¿Cómo resuelve el problema de "servidor principal comprometido"? Bueno, nada lo resuelve perfectamente, ya que el atacante puede hacer cambios que sirvan la versión legítima del script a sus servidores de monitoreo (identificándolos por IP) y los scripts modificados a todos los demás. Esto también se puede hacer en los servidores de activos externos comprometidos (aunque no con credenciales de CDN filtradas). Sin embargo, esto implica que el atacante sabe que se usa Scriptinel, conoce las direcciones IP de nuestros escáneres y ha ganado suficiente control para servidor de diferentes versiones basadas en IP. Esto eleva el listón de manera significativa, e incluso puede resultar imposible de lograr si cambiamos regularmente las direcciones IP en un rango de IP significativamente grande.

Dicha funcionalidad puede estar disponible en algunas suites de seguridad empresarial, aunque no estoy al tanto (si existe en algún lugar, hágamelo saber).

En general, el problema es de nicho, pero difícil, y no resolverlo puede provocar graves violaciones de datos incluso si su base de datos está perfectamente protegida. Scriptinel es una solución fácil de usar y suficientemente buena (y posiblemente mejor que las otras opciones).

La buena seguridad de la información es la combinación correcta de conocimiento, implementación de mejores prácticas y herramientas para ayudarlo con eso. Y tal vez Scriptinel sea una de esas herramientas.

Publicar un comentario

0 Comentarios