Para quienes aún no lo sepáis, el pasado 23 de junio de 2018 la filial británica de la compañía de venta de entradas Ticketmaster admitió en un comunicado haber sufrido un incidente de seguridad en sus plataformas Ticketmaster International, Ticketmaster UK, GETMEIN! y TicketWeb.

Este incidente tuvo como origen un malware escrito en javascript (Infostealer), que fue inyectado dentro de un componente de atención al cliente (chatbot) proporcionado por una empresa externa (Inbenta Technology). Este malware se encargaba de identificar y capturar datos sensibles ingresados por el usuario en la página de Ticketmaster que coincidieran con unos patrones definidos, para su posterior envío a un servidor externo gestionado por el atacante. Un análisis detallado de este malware se puede encontrar en el artículo “TicketMaster, un drama en tres actos (y un epílogo)” de una-al-dia de Hispasec.

Figura 1. Captura de pantalla del chatbot comprometido proporcionado a Ticketmaster por Inbenta (fuente: The Wayback Machine)

En principio, los clientes afectados corresponden en su mayoría a ciudadanos ingleses o a extranjeros que hayan hecho uso de la plataforma británica de Ticketmaster entre septiembre de 2017 y junio de 2018 (aproximadamente 40.000 usuarios). La información que fue comprometida incluye credenciales de autenticación de clientes (nombres de usuarios y contraseñas), nombres, direcciones, números de teléfonos y datos de tarjetas de pago.

Como agravante a lo sucedido, Ticketmaster ya había recibido una notificación por parte de una entidad emisora (Monzo) acerca de una serie de fraudes con sus tarjetas (primero cuatro y luego nueve), cuyo punto en común era que habían sido empleadas anteriormente su plataforma. Lamentablemente, Ticketmaster no prestó la suficiente atención a estas notificaciones sino hasta cuando el problema se les salió de las manos. Por esta razón, Monzo tuvo que remplazar de forma preventiva más de 40.000 tarjetas de pago.

Figura 2. Línea de tiempo de las acciones de notificación de Monzo en el incidente de Ticketmaster (fuente: Monzo)

Ahora mismo Ticketmaster se expone potencialmente a recibir una de las primeras multas millonarias por incumplimiento a la nueva ley de protección de datos inglesa (Data Protection Act (DPA) 2018, alineada con la ley de protección de datos europea – GDPR/RGPD) y tendrá que asumir los costes del remplazo de las tarjetas afectadas, los servicios gratuitos de monitorización de crédito ofrecidos a los usuarios con datos comprometidos, las demandas de sus clientes, las multas de las marcas de pago y las investigaciones forenses, sin contar con la pérdida de reputación y clientes que pueda tener en el futuro. Aún se desconoce si los portales de Ticketmaster cumplían con PCI DSS o no.

Desde la perspectiva de PCI DSS, ¿qué podemos aprender de este incidente?

A pesar de que PCI DSS no es un estándar perfecto y los niveles de seguridad que proporciona pueden ser mejorables, la implementación de sus controles hubiese ayudado a identificar, contener y mitigar el incidente ocurrido en Ticketmaster:

Riesgo identificadoControl PCI DSS relacionadoRiesgo gestionado
Uso de componentes innecesarios en la página de pagos:
Ticketmaster había incluido el uso de un sistema de chatbot dentro de la página de pagos, funcionalidad totalmente inútil en esta parte del proceso.
2.2.5 Elimine todas las funcionalidades innecesarias, como secuencias de comandos, drivers, funciones, subsistemas, sistemas de archivos y servidores web innecesarios.Un error muy grave por parte de Tickemaster fue el de permitir que la funcionalidad de chatbox estuviera presente en la misma página en la que se realizaba la captura de datos de pago.
Si este componente se hubiera retirado y el formulario de pago se hubiera aislado, el malware no hubiera tenido acceso a este tipo de datos.
Puesta en Producción de código sin autorizacion:
Según la empresa Inbenta (responsable del servicio de chatbot afectado), para el servicio de Ticketmaster se hacía uso de una serie de componentes personalizados. Ellos argumentan que Ticketmaster desarrolló y publicó sin su autorización el componente que finalmente fue afectado por el malware.
6.4.5.2 Aprobación de cambio documentada por las partes autorizadas.En PCI DSS, los cambios en la plataforma deben ser aprobados y autorizados. Si esto se hubiera realizado de esta forma, tanto Ticketmaster como Inbenta hubieran estado al tanto del código modificado.
Puesta en Producción de código sin revisión: Inbenta maneja dentro de sus hipótesis que el código desarrollado por Ticketmaster podría haber tenido vulnerabilidades y que esto dio paso a la infección por malware.6.3.2 Revise el código personalizado antes de enviarlo a producción o de ponerlo a disposición de los clientes a fin de identificar posibles vulnerabilidades en la codificación (mediante procesos manuales o automáticos).Si se hubiera realizado un análisis de código, se tendría garantía y evidencias por parte de Ticketmaster de que su código estaba desarrollado de forma correcta siguiendo las mejores prácticas y potencialmente se habrían minimizado vulnerabilidades relacionadas con el proceso de desarrollo.
Problemas en la identificación y delegación de responsabilidades en proveedores de servicio (terceros): La seguridad de los servicios del proveedor Inbenta no estaba claramente estipulada y sus responsabilidades respecto a la protección de datos de tarjetas y otros datos sensibles no estaba asignada.2.8 Mantenga e implemente políticas y procedimientos para administrar los proveedores de servicios con quienes se compartirán datos del titular de la tarjeta, o que podrían afectar la seguridad de los datos del titular de la tarjeta.A pesar de que Inbenta y sus servicios no procesan, almacenan y/o transmiten de forma explícita datos de tarjetas de pago, al estar presente el chatbox en la página de pago, este componente puede afectar la seguridad del flujo de datos (como finalmente ocurrió) y, por lo tanto, este proveedor debería haber estado dentro del ámbito de PCI DSS, lo cual hubiera permitido garantizar que sus servicios tendrían unos niveles de seguridad mínimos.
Problemas en la respuesta a incidentes: Desde meses antes, Monzo había notificado a Ticketmaster respecto a diversos incidentes con sus tarjetas de pago y no se había realizado ninguna acción de investigación.12.10 Implemente un plan de respuesta ante incidentes. Prepárese para responder de inmediato ante un fallo en el sistema.Si se hubiesen seguido los controles establecidos en el Req. 12.10 relacionados con respuesta a incidentes, la recepción de la notificación de Monzo se hubiera gestionado de forma correcta y el incidente se hubiera mitigado sin mayor impacto.

Es de aclarar que otros controles técnicos como antimalware, monitorización de integridad (FIM), detección de intrusos, gestión de logs, etc. no fueron efectivos en este caso, dado que el código malicioso estaba alojado en un entorno externo a los servidores web de Ticketmaster (servidores de Inbenta ubicados en http://ticketmasteruk.inbenta.com) y eran cargados/invocados directamente desde el browser del usuario final. Los datos sensibles eran capturados del lado del usuario y desde allí eran exfiltrados/transmitidos directamente al servidor malicioso sin que ese tráfico pasara por la infraestructura de Ticketmaster.

Otros controles adicionales (no requeridos por PCI DSS) que hubieran sido útiles en este escenario serían:

  • Uso de herramientas de “client honeypot“: Este tipo de controles “de engaño” (“deception”) son usados como señuelo para ser vulnerados de forma intencional por parte de un atacante y permitir conocer su comportamiento antes de que afecte a un activo “real”. A diferencia de los “honeypots” tradicionales que suelen ser instalados en servidores, los “client honeypots” son instalados en equipos que emulan a los clientes finales, interactuando con los servicios como lo haría un usuario normal y generando alertas si las acciones resultantes no son las esperadas, como ocurre en el caso de malware proveniente desde ataques de phishing, cross-site scripting (XSS), asalto de sesiones y otros, que se ejecutan de lado de cliente.
  • Uso de monitorización reputacional: Este tipo de servicios monitoriza diversos recursos web (páginas, componentes de contenido activo javascript/ActiveX, etc.) y los compara contra recursos que han sido catalogados por la comunidad como “maliciosos”.

Conclusión

El uso de componentes innecesarios (un chatbot en una página de pago), la ausencia de aprobación para cambios en el entorno,  la mala praxis en la gestión de proveedores y los errores en la gestión de reportes de incidentes han causado que finalmente una empresa ampliamente reconocida pierda credibilidad ante sus clientes y tenga que asumir una gran cantidad de costes que, si se hubieran invertido en medidas preventivas, se hubieran minimizado.

Ahora, nuestra tarea es aprender de los errores de los demás y evitar que se vuelvan a presentar en nuestro entorno de TI. Es aquí en donde entra PCI DSS y es en estos momentos en los cuales se puede obtener evidencia tangible de su retorno de inversión (“return of investment” – ROI).