Investigación

Web-Skimming con Google Analytics

El web-skimming es un tipo común de ataques cuyo objetivo suelen ser los visitantes de las tiendas en línea. El principio es bastante simple: en un sitio web hackeado se inyecta un código malicioso que recopila los datos introducidos por el usuario y los envía a un sitio controlado por el atacante. Si el ataque tiene éxito, el atacante responsable de la infección del sitio obtiene los datos de pago de los visitantes.

Para que el envío de datos a un sitio web de terceros sea menos llamativo, los estafadores a menudo registran dominios con nombres parecidos a los de servicios web populares, en particular Google Analytics (google-anatytics[.]com, google-analytcsapi[.]com, google-analytc[.]com, google-anaiytlcs[.]com, google-analytics[.]top, google-analytics[.]cm, google-analytics[.]to, google-analytics-js[.]com, googlc-analytics[.]com,  etc.). Pero logramos establecer que los ataques de este tipo pueden también utilizar el servicio original.

Para recopilar datos sobre los visitantes que utilizan Google Analytics, el propietario del sitio debe configurar los parámetros de seguimiento en su cuenta personal de analytics.google.com, obtener un código de seguimiento (trackingId, una cadena similar a UA-XXXX-Y) e insertar junto con éste un código de seguimiento en las páginas del sitio web. En un sitio web pueden coexistir varios códigos de seguimiento que envían datos sobre los visitantes a diferentes cuentas “analíticas”.

Hace poco, identificamos varios casos de uso abusivo del servicio de Google: el atacante inyectaba en el sitio web un código malicioso que recopilaba todos los datos introducidos por los usuarios y luego los enviaba utilizando el protocolo de “análisis”. Como resultado, el atacante recibía los datos robados en su cuenta de Google Analytics. Descubrimos alrededor de una veintena de sitios infectados en todo el mundo. Entre las víctimas se encuentran tiendas de Europa, América del Norte y del Sur que venden equipos digitales, cosméticos, alimentos y repuestos.

En la captura de pantalla a continuación podemos ver cómo luce la “infección”: código malicioso con un código de seguimiento y el ID de seguimiento del atacante:

Captura de pantalla 1

El atacante intenta ocultar la actividad maliciosa utilizando la clásica técnica anti-depuración. En la captura de pantalla 2, realiza una comprobación para ver si el modo de desarrollador está habilitado en el navegador del visitante. El código en la captura de pantalla anterior se ejecutará solo si se logra pasar la prueba.

Captura de pantalla 2

Es curioso que el atacante haya dejado una laguna: la capacidad de observar el funcionamiento del script en modo de depuración. Si el almacenamiento local del navegador (Local Storage) contiene el valor ‘debug_mode’ == ’11’, el código malicioso funcionará incluso si las herramientas de desarrollador están abiertas e incluso escribirá comentarios en la consola en un inglés rudimentario (con errores). En la captura de pantalla 3, la línea con la prueba ‘debug_mode’ vigila la implementación del algoritmo de cifrado RC4 (que se usa para cifrar los datos recopilados antes de enviarlos).

Captura de pantalla 3

Al completarse la eliminación de errores, la secuencia de comandos recopilará los datos que el usuario ha introducido en el sitio, además de otros como dirección IP, Agente de usuario, zona horaria. Los datos recopilados se cifran y envían utilizando el Protocolo de medición de Google Analytics (Google Analytics Measurement Protocol). El proceso de recopilación y envío se muestra en la captura de pantalla 4.

Captura de pantalla 4

Los datos robados se envían utilizando el llamado del método .sendevent en el campo ‘eventAction’.

La firma de la llamada en este caso es la siguiente:

Esto hace que se envíe una solicitud HTTP a la URL
https[:]//www.google-analytics.com/collect?<parámetros>&ea=packed_stolen_data&<parámetros>

En el caso que acabamos de describir, el código malicioso se inserta en uno de los scripts del sitio infectado en una forma “legible”. Sin embargo, en otros casos, la inyección puede usar técnicas de ofuscación. Además, el código malicioso se puede descargar desde un sitio perteneciente a terceros. En la captura de pantalla 5, un ejemplo de la opción ofuscada. En esta variante, en el sitio infectado se ha insertado la llamada de un script malicioso desde firebasestorage.googleapis[.]com.

Captura de pantalla 5

Después de la desofuscación, obtenemos un script similar, con los mismos comentarios característicos. Parte de su código se muestra en la captura de pantalla 6 (donde se usa otro trackingId).

Captura de pantalla 6

¿Cuál es el peligro?

Google Analytics es un servicio extremadamente popular (según BuiltWith, se utiliza en más de 29 millones de sitios) que goza de la confianza de los usuarios: los administradores escriben *.google-analytics.com en el encabezado Content-Security-Policy (utilizado para enumerar los recursos desde los que se puede descargar el código de terceros), lo que permite que este servicio recopile datos. Además, el ataque se puede implementar sin descargar el código “desde otro lado”.

¿Cómo evitar problemas?

Consejos para los usuarios:

  • Instalar software de seguridad. Las soluciones de seguridad de Kaspersky Lab detectan los scripts maliciosos que se utilizan en ataques y les asignan el nombre HEUR:Trojan-PSW.Script.Generic.

Para webmasters:

  • No instalar distribuciones de aplicaciones web y componentes de CMS desde fuentes no confiables.
  • Mantener actualizado el software. Mantenerse atento a las nuevas vulnerabilidades y seguir las recomendaciones para solucionarlas.
  • Crear contraseñas seguras para las cuentas de administración.
  • Limitar los derechos de usuario al conjunto mínimo necesario. Realizar seguimiento del número de usuarios que tienen acceso a las interfaces de servicio.
  • Filtrar los datos y parámetros de consulta que el usuario introduce para evitar la inyección de código de terceros.
  • Para los sitios web de comercio electrónico, es aconsejable utilizar pasarelas de pago que cumplan con los requisitos de PCI DSS.

IOCs

firebasestorage.googleapis[.]com/v0/b/bragvintage-f929b.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/canature-5fab3.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/ericeirasurfskate-559bf.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/gluten-8e34e.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/laser-43e6f.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/movile-720cd.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/plumb-99e97.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/redfox-64c35.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/tictoc-9677e.appspot.com/o/*

Web-Skimming con Google Analytics

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Informes

BlindEagle vuela alto en LATAM

Kaspersky proporciona información sobre la actividad y los TTPs del APT BlindEagle. Grupo que apunta a organizaciones e individuos en Colombia, Ecuador, Chile, Panamá y otros países de América Latina.

MosaicRegressor: acechando en las sombras de UEFI

Encontramos una imagen de firmware de la UEFI infectada con un implante malicioso, es el objeto de esta investigación. Hasta donde sabemos, este es el segundo caso conocido en que se ha detectado un firmware malicioso de la UEFI usado por un actor de amenazas.

Suscríbete a nuestros correos electrónicos semanales

Las investigaciones más recientes en tu bandeja de entrada