¿Qué es el skimming web (Magecart, formjacking, e-skimming)?

Qué es el skimming web, en palabras sencillas

Un skimmer físico es un dispositivo colocado en un lector de tarjetas que copia los datos de su tarjeta cuando la usa. El skimming web es la misma idea trasladada a un sitio web. En lugar de un aparato en un cajero automático, el atacante coloca unas pocas líneas de JavaScript en una página donde las personas escriben los datos de su tarjeta. Cuando el cliente completa el número de tarjeta, la fecha de vencimiento, el código de seguridad y la dirección de facturación, el script lee esos valores del formulario y envía una copia a un servidor que controla el atacante.

El cliente completa la compra, el comercio recibe el pedido y el procesador de pagos ve una transacción normal. Eso es lo que hace tan silencioso este tipo de ataque: nada falla, así que nada parece estar mal. El robo de tarjetas suele descubrirse mucho después, cuando un banco emisor, una marca de tarjetas o un investigador de seguridad rastrea un patrón de fraude hasta un comercio en común.

Nombres con los que lo encontrará

Cómo funciona un ataque de skimming

Casi todos los casos siguen los mismos cuatro pasos, sea cual sea el grupo detrás.

1. Conseguir un punto de apoyo. El atacante necesita una forma de cambiar lo que carga el navegador. Las vías habituales son credenciales de administrador robadas, un complemento o una biblioteca vulnerable del sistema de gestión de contenido, un servidor comprometido, o el compromiso de un servicio de terceros cuyo script el sitio ya carga. El artículo sobre XSS y manipulación del DOM explica estas vías con más detalle.
2. Inyectar el skimmer. El atacante añade un script, o modifica uno existente, para que se ejecute en la página. El código inyectado suele ser un pequeño cargador que descarga el skimmer real desde otro dominio, lo que mantiene mínimo el cambio en los archivos de la víctima.
3. Capturar los datos. El script escucha cuando se completa o se envía el formulario de pago y lee los campos. Algunos skimmers también capturan datos de inicio de sesión, y otros muestran un formulario de pago falso sobre el verdadero.
4. Enviarlos fuera. Los datos se envían al atacante, por ejemplo mediante una solicitud de imagen oculta o una solicitud en segundo plano a un dominio parecido al de un servicio de analítica. Después las tarjetas robadas se usan o se venden.

Los skimmers suelen escribirse para pasar desapercibidos: pueden ejecutarse solo en las páginas de pago, omitir a los visitantes que parecen administradores, ocultar su código con ofuscación o esperar a que la página termine de cargar. Por eso un vistazo rápido a la página en un navegador, o una revisión manual ocasional del código fuente, rara vez los encuentra.

Por qué las herramientas de seguridad del servidor suelen no verlo

La mayoría de los controles de seguridad vigilan el servidor, la red o el código de un repositorio. Un skimmer hace su trabajo en el navegador del cliente, cuando la página ya salió de sus servidores. De ahí se derivan tres consecuencias.

• HTTPS no lo detiene. El script lee los campos del formulario en el navegador, antes de que los datos se cifren para el transporte. Una conexión segura protege los datos en tránsito, no contra un script al que se le permite ejecutarse en la página.
• Un firewall de aplicaciones web solo ve las solicitudes a su servidor. La solicitud de salida del skimmer va del navegador del cliente al atacante, no pasa por su infraestructura.
• Su propio código fuente puede estar limpio. Si el script malicioso viene de un tercero, o lo añade un gestor de etiquetas o una CDN, una revisión del código de su repositorio no lo mostrará. Lo que importa es lo que el navegador realmente recibe.

Esta brecha es la razón por la que PCI DSS añadió requisitos centrados en la vista que tiene el navegador de la página de pago: vea por qué el PCI SSC creó los requisitos 6.4.3 y 11.6.1.

¿Un iframe o una redirección hacen inmune a un comercio?

Enviar a los clientes a la página alojada de un proveedor de pagos, o incrustar el formulario de pago del proveedor en un iframe, reduce mucho los datos de tarjeta que tocan sus propios sistemas. Es una decisión de diseño sensata. Pero no vuelve irrelevante la página que lo rodea:

• Con una redirección, un atacante que controle su página antes de la redirección puede enviar a los clientes a una página parecida.
• Con un iframe, un atacante que controle la página principal puede quitar el iframe y poner un formulario falso en su lugar, o alterar cómo se comporta la página a su alrededor.

El PCI SSC ha tratado estos casos de forma explícita. Cómo se aplican los requisitos a cada forma de aceptar pagos se explica en el artículo sobre SAQ A, SAQ A-EP y SAQ D.

Cómo reducir el riesgo

Ningún control detiene por sí solo todos los skimmers, por eso las organizaciones combinan varios. Los que tienen mejor respaldo son:

• Cargar la menor cantidad posible de scripts en las páginas de pago. Cada script es un lugar donde un atacante puede esconderse. Elimine todo lo que no sea necesario para cobrar.
• Mantener un inventario y un motivo para cada script, y aprobar los cambios de forma deliberada. Vea cómo crear un inventario de scripts de la página de pago.
• Restringir desde dónde se pueden cargar scripts con una Política de Seguridad de Contenido (CSP), y fijar los archivos externos con Integridad de Subrecursos (SRI) cuando sea práctico.
• Gobernar los gestores de etiquetas y a los terceros como parte de su cadena de suministro: riesgo de JavaScript de terceros y riesgo de los gestores de etiquetas.
• Aplicar parches y reforzar el sitio: actualizar complementos y bibliotecas, usar autenticación multifactor para los administradores y limitar quién puede publicar cambios.
• Detectar cambios. Comparar lo que recibe el navegador con una línea base conocida y avisar a las personas cuando algo difiera: cómo detectar la manipulación del lado del cliente.

Si cree que una página ha sufrido skimming

Trátelo como un incidente de seguridad conforme a su plan de respuesta a incidentes. Elimine o desactive el script, conserve la evidencia (la página tal como se recibió, los registros del servidor, el historial de cambios), encuentre y cierre la vía de entrada, e informe a su adquirente, a las marcas de tarjetas y a su asesor legal según lo exijan sus contratos y la ley. Su adquirente puede indicarle qué esperan las marcas de tarjetas.