Ataque de Magecart haciéndose pasar por Google Tag Manager
Se ha descubierto una nueva y sofisticada campaña de robo de información web de Magecart en varios sitios web de comercio electrónico. Los ataques de Magecart son un tipo de ciberdelincuencia dirigida específicamente a los retailers online. Estos ataques consisten en inyectar código JavaScript malicioso en las páginas de pago de sitios web, que captura la información confidencial de los clientes en cuanto se introduce y la envía al servidor del atacante. Esta información puede incluir números de tarjetas de crédito y datos personales.
El reciente ataque tenía como objetivo robar información confidencial de los visitantes de páginas y formularios de pago. Los atacantes pudieron inyectar un código JavaScript en línea malicioso en los sitios web atacados aprovechando una vulnerabilidad. El ladrón de información utilizó técnicas como la suplantación de un proveedor legítimo de terceros, como Google Tag Manager, y la ocultación del código malicioso a través de la codificación Base64.
El ataque continúa en algunos sitios web y se parece al reciente ataque sufrido por el mayor retailer de bebidas alcohólicas de Canadá.
Resumen del ataque
Suplantación del código de un proveedor conocido
El ladrón de información inyecta un código malicioso como si fuera un script en línea (un script incrustado en HTML, que no se carga desde un archivo externo) que se parece a un fragmento de código de Google Tag Manager (figura 1). Esto permite al atacante hacer pasar el código malicioso como si fuera un script legítimo ocultándolo detrás de un proveedor conocido. Ya nos hemos enfrentado a varias campañas de Magecart con anterioridad que utilizaron esta técnica de evasión, lo que dificulta más su detección.
Además, el ladrón de información utiliza la codificación Base64 para ocultar las direcciones URL o palabras clave que podrían revelar el código malicioso. Esto sirve para ocultar aún más la presencia del ladrón.
Fig. 1: Impostor de fragmentos de Google Tag Manager
Uso de WebSockets y la función eval
En este caso, el fragmento de código en línea solo sirve como cargador y no como el código de ataque real. El cargador incluye una condición que activa el ataque solo en las páginas de pago, lo que permite que el ladrón de información actúe de forma discreta y cargue el código malicioso completo solo en páginas de información confidencial atacadas que son pertinentes para el ataque.
Una vez descifrada la codificación Base64 del código del cargador, se revela el código JavaScript, que es corto y sencillo y realiza solo dos pasos: crear una nueva conexión WebSocket con el servidor de comando y control (C2) del atacante y configurar una función de escucha que ejecutará el código recibido de C2 con la función "eval" (figura 2).
Fig. 2: El código codificado que estaba oculto dentro del fragmento de código de Google Tag Manager.
El uso de WebSockets y la función "eval" en los ataques de Magecart se considera una técnica avanzada, ya que permite que el código malicioso se ejecute en el contexto de la página como un script propio, lo que dificulta su detección por parte de los investigadores, los servicios de seguridad y los escáneres que pueden estar funcionando en el sitio web atacado (figura 3). Este método ayuda a los atacantes a encubrir sus actividades y a ser menos detectables que las solicitudes XHR o etiquetas HTML tradicionales.
Fig. 3: Otra variación del cargador del mismo ladrón de información con el uso de WebSockets
Comprobaciones de códigos
La iniciación de la conexión de socket permite al navegador y al servidor C2 intercambiar información en cualquier momento. El primer mensaje enviado por el servidor C2 del atacante a la página (figura 4) contiene código JavaScript que se ejecuta inmediatamente mediante una función de escucha especificada en el código del cargador.
El código realiza dos comprobaciones:
- Verifica si se ha establecido una conexión WebSocket a través de una variable global definida en el código del cargador.
- Determina si la página es una página de pago que incluye un botón de envío.
Si las comprobaciones son correctas, el código del atacante envía un mensaje al servidor C2 con la dirección URL de la página actual. Como respuesta, el servidor C2 devuelve el código malicioso adecuado adaptado a la página objetivo en cuestión.
El hecho de que el servidor C2 espere la URL de una página antes de devolver el código de ataque sugiere que esta campaña opera a través de un marco dinámico capaz de ejecutar y atender simultáneamente numerosos sitios web y páginas.
Fig. 4: Conexión WebSocket con el servidor de C2 del ladrón de información
Ofuscación del código
La figura 5 muestra el código de ataque real tal y como se obtuvo del servidor C2 después de validar la URL. El código está muy ofuscado, lo que dificulta determinar su lógica subyacente y la progresión del ataque. Los ladrones de información de Magecart suelen emplear técnicas de ofuscación para que los expertos en seguridad tengan problemas para descifrar el código de ataque y entender todo su flujo.
Fig. 5: Código de ataque oculto enviado por el servidor de C2 a través de la conexión de WebSocket
Código despejado
El uso de una herramienta de desofuscación sirve para aclarar más el caso y revelar la intención del ataque. Como se muestra en la figura 6, el código contiene una amplia gama de palabras clave diseñadas para identificar campos confidenciales en la página atacada y establecer un formulario de pago falsificado bajo el control del atacante.
El objetivo final del atacante es robar información personal a visitantes desprevenidos que interactúan con la página infectada y rellenan el formulario falso inyectado por el código del atacante.
Fig. 6: Código de ataque tras desocultar
Inserción de formularios falsos de proveedores externos
Algunas tiendas atacadas externalizan su proceso de pago a un proveedor externo. Cuando los clientes proporcionan información personal, son redirigidos al proveedor externo para que introduzcan la información de su tarjeta de crédito y completen la transacción. El ladrón de información no puede acceder al proveedor externo para obtener la información de la tarjeta de crédito del usuario final.
En su lugar, crea un formulario de tarjeta de crédito falso en la página anterior a redirigir al cliente al proveedor externo (figura 7). Cuando el usuario hace clic en los botones falsos de "Pagar" o Enviar pago, el ladrón de información envía toda la información recopilada a su servidor C2 y permite al usuario continuar con el flujo de pago legítimo redirigiendo a la página real de pago del proveedor externo.
Fig. 7: Forma falsa creada por el ladrón de información
Si el sitio web atacado no redirige al usuario a una página de pago de terceros, el ladrón de información no creará un formulario nuevo. En su lugar, añadirá escuchadores de JavaScript a todos los datos personales confidenciales introducidos en la página de pago y en los formularios de pago. Una vez que el usuario envíe la información, el ladrón extraerá los datos y los enviará a su servidor C2 mediante mensajes WebSockets.
En ambos casos, el ladrón de información cifra los datos extraídos para dificultar a los investigadores y a los servicios de seguridad la detección de cualquier actividad inusual de la red iniciada por él (figura 8).
Fig. 8: Ejemplo del mensaje cifrado del ladrón de información enviado a través de una conexión de WebSocket
Similitudes del ataque
Durante la investigación, encontramos varios sitios web que fueron víctimas del ataque. No podemos confirmar que todos ellos estén relacionados con la misma campaña, pero hubo similitudes entre los casos que sugieren el uso del mismo marco de Magecart. En algunos casos, se encontraron indicadores como el cargador en línea del ataque que se hizo pasar por un falso Google Tag Manager con parámetros codificados que ocultaban cualquier rastro del ladrón en varios sitios web de víctimas.
Los dominios utilizados por el atacante variaban de un sitio web a otro y, en la mayoría de los casos, el código de ataque real fue obtenido por el código del cargador en páginas pertinentes solo para que el ataque fuera más discreto y más difícil de detectar.
Resumen de las técnicas y capacidades de los atacantes
Suplantan el fragmento de código de un proveedor conocido como Google Tag Manager.
Utilizan la codificación Base64 para ocultar cualquier indicador del atacante, como direcciones URL y dominios.
Utilizan WebSockets para todas las comunicaciones entre el navegador y el C2, extrayendo el código de ataque y exfiltrando los datos.
Ejecutan el código de ataque con “eval” para que el script parezca un script interno orgánico.
Utilizan técnicas de ofuscación para dificultar la comprensión del código por parte de los investigadores.
Inyectan formularios falsos para recopilar datos antes de redirigir a los usuarios a páginas legítimas de servicios de pago de terceros.
Protéjase con Page Integrity Manager de Akamai
Nuestro equipo probó el reciente ataque de Magecart con Page Integrity Manager de Akamai y consiguió identificarlo y mitigarlo de inmediato. Además, se proporcionó información detallada para la resolución de problemas (figura 9).
Page Integrity Manager se ha diseñado específicamente para proteger contra el robo de información web, el formjacking y los ataques de Magecart. Proporciona visibilidad del comportamiento de ejecución de scripts de una página web y recopila información sobre los diferentes scripts que se ejecutan en la página, incluidas sus acciones y su relación con otros scripts.
Al combinar estos datos con un enfoque de detección multicapa, que incluye capacidades heurísticas, puntuación de riesgos, inteligencia artificial y otros factores, Page Integrity Manager es capaz de rápidamente detectar ataques y defenderse de amenazas del lado del cliente.
Fig. 9: Información detallada sobre la solución de problemas de Akamai Page Integrity Manager
Conclusión
Los ladrones de información de Magecart están en constante evolución y cada vez son más sofisticados. El uso de métodos avanzados de evasión y ofuscación por parte del ladrón descrito en esta entrada pone de relieve las dificultades existentes para detectar este tipo de ataques.
El juego continuo del gato y el ratón exige una solución de seguridad integral para detectar y prevenir ataques. La falta de implementación de una solución así puede provocar graves daños a los clientes cuya privacidad puede verse comprometida y causar daños importantes a la reputación de una empresa, así como generar multas importantes.
Los nuevos requisitos incluidos en el estándar de seguridad de datos del sector de las tarjetas de pago (PCI DSS v4,0) hacen que la seguridad en el navegador sea ahora mismo imprescindible para cualquier organización que procese tarjetas de pago en línea.
Más información
Page Integrity Manager de Akamai puede ayudarle a cumplir estos nuevos requisitos al proporcionar un inventario de todos los scripts que se ejecutan en su sitio, visibilidad del comportamiento de los scripts y defensa contra los ataques basados en scripts más sofisticados.
IoC
Los siguientes indicadores de riesgo (IoC) se presentan para ayudar a la comunidad a detectar la actividad maliciosa y los ladrones de información descritos en la publicación:
yachtbars[.]fun
app-stat[.]com
Magento-cdn[.]net
nebiltech[.]shop
Rithdigit[.]cyou
Antohub[.]shop
Okqtfc1[.]org
jquery-node[.]com
Más información sobre cómo obtener visibilidad del comportamiento de los scripts y la protección contra ataques del lado del cliente con Page Integrity Manager de Akamai.
