¿Qué es el ‘Web Skimming’?

Hace unos días escuchábamos la noticia de que un grupo de ciberdelincuentes estaban lanzando ciberataques mediante Google Analytics con el objetivo de robar datos personales de usuarios, especialmente datos de pago como los de sus tarjetas de crédito, para robarles dinero posteriormente.

Por lo que se decía en la noticia, el modo de ataque estaba realizándose mediante la técnica de Web Skimming (también conocido como Formjacking)… y tú dirás… «Web… esqui… qué???!!!»

En realidad, aunque es complejo, la filosofía y la técnica de ataque son bastante «sencillas».

Por resumirlo y simplificarlo mucho, se trata de «ponerse en el medio«, en/entre alguno de los  formularios de una pagina web que previamente se ha comprometido (que se conoce como «Web Skimmer«) y el servidor, sistemas o backend de dicha pagina.

De ese modo, el ciberatacante es capaz de «escuchar» lo que el usuario escribe en ese formulario. Es decir, es capaz de interceptar los datos que el usuario está introduciendo en ese formulario de esa página web (los que sean… datos personales, contraseñas, datos bancarios de tarjetas de crédito, etc.) y de recogerlos para utilizándolos posteriormente sin el consentimiento del usuario, de forma inapropiada y delictiva.

Entrando un poco más en detalles, primero es necesario que el ciberdelincuente comprometa la página Web y más concretamente el formulario objeto del ataque que se encuentre en ella. En este caso, una página que utilizase Google Analytics para obtener estadísticas de sus visitas, uso, etc. y que además tuviese algún formulario de introducción de datos por ejemplo, en el caso de una tienda o ecommerce.

Para conseguirlo, el ciberatacante debe realizar una «inyección de código» (también conocida como Cross Site Scripting, o ataque XSS)… Esto es, meter determinadas líneas de programación (en un lenguaje de programación como javascript) en el elemento a atacar. En este caso dentro del código del formulario y campos de la Web que tuviese y trabajase con Google Analytics (GA).

una vez hecho esto, la página ya está comprometida y dicho «código malicioso inyectado» se ejecutará cuando el usuario interactúe con el formulario. En ese momento, dicho código hace lo que el ciberdelincuente quiera, lo que le «haya dicho» que haga, lo que le haya programado.

En este caso será quien se encargue de realizar la intercepción de los datos introducidos por el usuario en el formulario y de enviarlos a un «lugar» donde haya indicado el ciberatacante… y más concretamente de utilizar Google Analytics para hacerlo y así evitar la seguridad.

Pueden existir infinidad de ataques XSS, pero en éste lo que se detectó es que se estaba haciendo uso de Google Analytics como «intermediario» para recoger y enviar datos privados y que. Por  tanto, los datos personales, bancarios y de pago de los usuarios que visitaban esa Web que tenia GA y había sido comprometida, estaban siendo exfiltrados, comprometidos y probablemente comenzados a usar de forma fraudulenta.

La «facilidad» del robo de datos se debía, en el caso de usar a Google Analytics como intermediario, a que se enviaban dentro de eventos de GA como parte de la información a enviar y por eso no eran detectados por los sistemas de seguridad de las webs en las que había seguimiento analítico de GA y habían sido comprometidas… un método útil de camuflaje para conseguir el objetivo sin levantar sospechas.

La protección ante este tipo de ataques, aunque complicada, está del lado de la pagina Web comprometida y/o del servidor que haya por detrás de ella.

No obstante, desde el punto de vista de usuarios que usamos el formulario con ese código malicioso inyectado, podríamos… configurar nuestro navegador para evitar la auto-ejecución de scripts, instalar y usar complementos en el navegador para evitar dichas ejecuciones, mantener actualizado el navegador y el sistema operativo, contar con herramientas de seguridad y antivirus que eviten que se ejecute código javascript…