22 líneas de código JavaScript roban 380.000 tarjetas de crédito a British Airways

Estás a punto de conocer uno de los casos de robo de información sensible más ingenioso y sorprendente de todos los que hemos tratado en este blog.

Como de costumbre, el ingenio puesto al servicio del mal nunca dejará de sorprendernos. Así, un grupo de hackers ha infectado una de las librerías JavaScript más utilizadas hoy en día para lograr, con 22 líneas de código, robar los datos de pago de más de 380.000 usuarios de British Airways. Y todo ello en tan solo 15 días.

Para entender mejor el contexto de este ataque, hemos de concretar que para agilizar y homogeneizar el desarrollo front-end se importan librerías con funciones comunes en prácticamente todos los sitios web, y de esta manera no tener que reescribir el mismo código una y otra vez. Es una práctica muy habitual, recomendada y a la orden del día. Así se consigue que incluso los tiempos de carga mejoren, siendo un beneficio tanto para desarrolladores como para usuarios.

Estas librerías, normalmente almacenadas en una red de distribución de contenido o CDN, son un origen fiable y muy optimizado para cargar estas partes “estáticas” de las webs. El problema se presenta cuando el origen se ve comprometido y deja de ser fiable, como en el caso que nos ocupa.
 

Los pagos en el portal de British Airways comprometidos durante 15 días

 
El pasado 21 de agosto se produjo una fuga de información sensible en la web de British Airways que duro hasta el 5 de septiembre, dando lugar al robo de información de tarjetas de crédito de más de 380.000 usuarios.

En esencia, el ataque llevado a cabo por el grupo hacker conocido como Magecart consistió en introducir código malicioso en una de estas librerías JavaScript almacenada en los servidores de British Airways, en concreto Modernizr, una librería usada para detectar las características que ofrece el navegador del usuario para hacer uso de ellas o, en su defecto, ofrecer alternativas. A esta librería se le inyectaron simplemente 22 lineas de código, que podrían parecer pocas, pero con ellas se lograba obtener de los datos que el usuario introduce cuando va a realizar un pago el número de tarjeta de crédito, la fecha de caducidad e, incluso, el código CVV, es decir: el código numérico de tres dígitos que se encuentra en el reverso de la tarjeta y que no era almacenado por la web de British Airways. De esta manera pudieron suponer desde un primer momento que la fuga de información no se había producido en los sistemas de almacenamiento, si no que había sido capturada en el momento en el que el usuario rellena los formularios correspondiente a los datos de cobro.

En este mismo código, una vez obtenida la información, se le asignaba un formato concreto y se enviaba mediante una petición POST a un origen también manejado por los atacantes. Además, contaba con un nombre de dominio que a simple vista podría hacer creer que se trataba de otro origen propiedad de la aerolínea inglesa.
 

Estos ataques se repiten pero no se extenderán fácilmente

 
Se cree que este mismo grupo de hackers unas semanas antes también logró infectar una de las librerías utilizada por un servicio de chat en tiempo real utilizado por Ticketmaster. En esta ocasión robaron “sólo” la información de 40.000 usuarios, pero además de los datos de tarjeta de crédito, también se hicieron con nombres, direcciones postales y número de teléfono. Incluso, poco después de corregir el ataque a BA.com, el minorista de hardware Newegg también reconoció haber sido víctima de un ataque de Magecart muy similar. En este caso no han transcendido cuántas transacciones se vieron afectadas.

Esto nos lleva a pensar que ataques de este tipo podrían seguir sucediendo en el futuro. No obstante, se trata de ataques muy elaborados con objetivos muy concretos, y no sería posible extenderlos masivamente a otros sitios web a gran escala. Es decir, se trata de ataques muy graves pero puntuales.

En el caso de British Airways, llama la atención que la infección se prolongara durante 15 días cuando podría haber sido muy sencillo detectarla simplemente por la fecha de última modificación del fichero infectado, ya que la versión legítima no se modifica desde 2012 y la versión infectada fue modificada apenas dos horas antes de comenzar el ataque. De hecho existen métodos específicos para prevenir este tipo de vulnerabilidades, como Content Security Policy o CSP, pero de todas las opciones disponibles, el sitio web BA.com sólo se protegía ante los más obvios y menos sofisticados que hacen uso de iframes. Muy probablemente, este fue uno de los motivos que propició que los atacantes prestaran atención a este sitio y no a otros.

En vista de lo sucedido, todos los que prestamos un servicio online y manejamos datos sensibles, tenemos una responsabilidad adicional, ya no sólo con nuestro propio código y el almacenamiento de esta información, sino con todos los elementos externos que entran en funcionamiento en nuestros servicios. En contra de lo que ocurre habitualmente, el usuario deposita su confianza y su información sensible en nosotros sin que pueda hacer nada para impedir este tipo de ataques.