Incidentes notables de robo de tarjetas del lado del cliente y qué enseñan

Sobre este artículo

Este es un resumen de fuentes públicas, escrito con fines educativos. Los hechos, las fechas y los importes se indican como los dan las fuentes citadas, y cuando solo hay información de fuentes secundarias lo decimos. No afirmamos nada más allá de lo que establecen esas decisiones e informes. Algunas de las empresas mencionadas han cuestionado aspectos de las conclusiones; lea los documentos originales de las referencias para tener el panorama completo.

British Airways (2018): un archivo JavaScript del propio sitio de la aerolínea

En un aviso de sanción fechado el 16 de octubre de 2020, la ICO impuso a British Airways una multa de 20 millones de libras conforme a la ley de protección de datos por un incidente de 2018 en el que los datos de tarjetas de pago introducidos en el sitio web de la aerolínea se copiaron a un atacante. Según el aviso, esto ocurrió sin interrumpir el proceso normal de reserva y de pago, y el aviso describe que el atacante modificó un archivo JavaScript del sitio de la aerolínea para que los datos de tarjeta se enviaran a un dominio que controlaba. La ICO estimó que los datos personales de aproximadamente 429.612 personas pudieron verse afectados.

British Airways notificó a la ICO el 6 de septiembre de 2018. La ICO había anunciado por primera vez la intención de multar a British Airways con 183,39 millones de libras el 8 de julio de 2019; el importe final fue menor después de que la ICO considerara las alegaciones de la empresa, los factores atenuantes y el impacto económico de la Covid-19 en el sector aéreo. El comunicado de 2019 decía que se creía que el ataque había comenzado en junio de 2018.

Qué enseña: el archivo alterado formaba parte del propio sitio de la aerolínea, así que los atacantes no solo apuntan al código de terceros. También muestra que las consecuencias regulatorias de un incidente de skimming pueden ser muy grandes, y que la ICO examinó las medidas de seguridad existentes alrededor de la página.

Ticketmaster UK (2018): un script de chatbot de terceros

El 13 de noviembre de 2020 la ICO impuso a Ticketmaster UK Limited una multa de 1,25 millones de libras. Las conclusiones de la ICO se referían a un chatbot, suministrado y alojado por un tercero, que Ticketmaster había incluido en su página de pago en línea. Código malicioso en el JavaScript del chatbot capturó los datos introducidos en la página, entre ellos nombres, números de tarjeta de pago, fechas de vencimiento y códigos de seguridad. Hasta 9,4 millones de clientes en Europa, unos 1,5 millones de ellos en el Reino Unido, pudieron verse afectados.

La sanción se refiere al período desde el 25 de mayo de 2018, cuando entró en vigor el RGPD, hasta el 23 de junio de 2018, cuando se retiró el chatbot del sitio. Resúmenes de despachos de abogados sobre el aviso indican que la ICO consideró bien conocido el riesgo de los scripts de terceros en las páginas de pago, y señaló medidas que habrían podido usarse, como la Integridad de Subrecursos o mantener el chatbot fuera de la página de pago. Ticketmaster dijo que apelaría y sostiene que el proveedor fue el responsable del compromiso; no hemos verificado el resultado de ninguna apelación.

Qué enseña: un script sin conexión evidente con los pagos, aquí un widget de atención al cliente, se cargaba en la página donde se introducen las tarjetas. Es exactamente la situación que PCI DSS 6.4.3 aborda al pedir un inventario con un motivo escrito para cada script. Vea riesgo de JavaScript de terceros.

Newegg (2018): un skimmer corto en la página de pago

En septiembre de 2018, investigadores de Volexity y RiskIQ informaron de un skimmer en la página de facturación del minorista de electrónica Newegg. Según su análisis, tal como lo recoge la cobertura secundaria, los datos de tarjeta introducidos en el pago quedaron expuestos entre el 14 de agosto y el 18 de septiembre de 2018, unas cinco semanas. Los atacantes habían registrado un dominio parecido, neweggstats.com, el 13 de agosto, un día antes de añadir el skimmer, y el skimmer le enviaba los datos del formulario. Se informó de que el código era muy corto y de que estaba colocado para ejecutarse solo en la página de procesamiento del pago. El número de clientes afectados no se confirmó públicamente.

Los investigadores vincularon la campaña con el conjunto de actividad conocido como Magecart.

Qué enseña: un skimmer puede ser de unas pocas líneas, puede ejecutarse solo en la página que importa, puede enviar los datos a un dominio que parece un servicio de estadísticas corriente y puede funcionar durante semanas. Lo encontraron investigadores externos y no el monitoreo del propio minorista.

Lecciones que se aplican a toda página de pago

1. Mire la página que recibe el navegador del cliente. En los tres casos el código dañino se ejecutó en los navegadores. Las revisiones de servidores y repositorios no lo habrían mostrado.
2. Cada script de una página de pago necesita un motivo. Un chatbot o un ayudante de estadísticas no necesita ver números de tarjeta. Elimine, aísle o justifique cada uno.
3. Restrinja adónde pueden ir los datos. Una Política de Seguridad de Contenido (CSP) que limite los orígenes de scripts y las direcciones a las que una página puede enviar datos dificulta tanto cargar un skimmer como sacar datos.
4. Detecte los cambios rápido. En los incidentes anteriores pasaron semanas. Una detección que compare la página con una línea base aprobada acorta la exposición; vea cómo detectar la manipulación del lado del cliente.
5. Los reguladores y las marcas de tarjetas se enteran. Las decisiones de la ICO examinaron si había medidas de seguridad apropiadas, no solo si ocurrió el ataque. Estos y otros casos similares forman parte del contexto de la atención que hoy recibe la seguridad del lado del cliente en PCI DSS; vea por qué existen los requisitos 6.4.3 y 11.6.1.