Portada
mis comunidades
otras secciones
![Las 22 líneas de JavaScript que permitieron el robo de datos de 380.000 clientes de British Airways [ENG]](https://cdn.mnmstatic.net/cache/2d/ef/media_thumb_2x-link-3010354.jpeg?1536748927)
#5:
#2 ¿Porque se tendría que dar cuenta la pasarela de pago? Normalmente son webs externas, a las que haces una petición enviándole los datos necesarios. Si al mismo tiempo envías esos mismos datos a otro servidor, es imposible que el servidor de la pasarela de pago se entere de nada, pues las peticiones son independientes.
Lo raro es que hayan conseguido meter una versión modificada de una librería externa. Normalmente se enlazan mediante HTTPS en servidores externos, o en su defecto se copian en el servidor. En el primer caso tienen que haber roto el encriptado del HTTPS, y en el segundo tienen que tener acceso al servidor de British Airways.
Lo raro es que hayan conseguido meter una versión modificada de una librería externa. Normalmente se enlazan mediante HTTPS en servidores externos, o en su defecto se copian en el servidor. En el primer caso tienen que haber roto el encriptado del HTTPS, y en el segundo tienen que tener acceso al servidor de British Airways.
#2:
Wow, vaya análisis forense, desde luego el ataque ha sido bien planificado, aunque me sorprende que sea que se active simplemente cuando el usuario le dé a aceptar el pago, envía una copia de los datos a un servidor externo. Y todo esto sin que la pasarela se de cuenta que se fuga esa información vital.
Llevan refinando el mismo sistema de ataque desde el 2015 ¿Cual debe de ser el tamaño del grupo criminal detrás de esto?
Llevan refinando el mismo sistema de ataque desde el 2015 ¿Cual debe de ser el tamaño del grupo criminal detrás de esto?
Comentarios
Wow, vaya análisis forense, desde luego el ataque ha sido bien planificado, aunque me sorprende que sea que se active simplemente cuando el usuario le dé a aceptar el pago, envía una copia de los datos a un servidor externo. Y todo esto sin que la pasarela se de cuenta que se fuga esa información vital.
Llevan refinando el mismo sistema de ataque desde el 2015 ¿Cual debe de ser el tamaño del grupo criminal detrás de esto?
#2 ¿Porque se tendría que dar cuenta la pasarela de pago? Normalmente son webs externas, a las que haces una petición enviándole los datos necesarios. Si al mismo tiempo envías esos mismos datos a otro servidor, es imposible que el servidor de la pasarela de pago se entere de nada, pues las peticiones son independientes.
Lo raro es que hayan conseguido meter una versión modificada de una librería externa. Normalmente se enlazan mediante HTTPS en servidores externos, o en su defecto se copian en el servidor. En el primer caso tienen que haber roto el encriptado del HTTPS, y en el segundo tienen que tener acceso al servidor de British Airways.
#5 Exacto, la "magia" no está en el javascript, la magia está en conseguir meter un js modificado en los servidores de BA.
A no ser que hicieran una pull request a la librería oficial con las líneas modificadas y así lo consiguieran meter.
#9 Así es, el contenido del script es lo de menos, lo interesante sería saber cómo consiguieron meter la línea que cargaba dicho script.
#5 #9 #11 Pues fácil, javascript y dependencias. Hace nada ya hubo un problema con esto, si encima no tienen una política interna de seguridad apropiada pues les colarían malware.
https://blog.npmjs.org/post/175824896885/incident-report-npm-inc-operations-incident-of
https://www.theregister.co.uk/2018/07/12/npm_eslint/
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
#24 Pero según el artículo (o eso entiendo yo), se modificó el html para que apuntase a un fichero de javascript distinto. No sé cómo harías eso mediante javascript y dependencias.
#26 Muchos programadores compilan descargándose librerías externas, en lugar de descargarlas en su propio repositorio, y así pasar los tests sobre el mismo código que se usará en producción.
La verdad es que el ataque es brillante. Se colaron en una librería de terceros que sabían que usaba BA y la modificaron, así cuando BA se la descargó (ya sea porque se descarga sola cuando compilan o porque piensan que es una actualización y la descargan) ya iba con su código oculto.
Siempre he pensado que los datos de pago de una empresa como British Airways llevarían un proceso de tests un poco más paranoico, comprobando que ninguna URL de terceros fuera llamada en el proceso, pero no me sorprende demasiado que no sea así.
#13 Mi interpretación es que no enlazaron contenido externo, sino que consiguieron que BA se lo descargara y lo incluyera en su propia web sin darse cuenta del "regalito".
#5 #9 Enlazar con o sin https a librerías externas tiene esos riesgos. Muchos confían en que el código haga lo que tenga que hacer, El hackeo puede haber sido tan sencillo como haber untado a un admin, que son voluntarios y no cobran. Las 22 lineas son basicas, es lo de menos.
#13 “con o sin https”
No, no es lo mismo ni mucho menos. Con http es relativamente sencillo ser víctima de un ataque Man in the Middle, con https no.
No han roto el cifrado de https, lo que han hecho es hackear el repositorio donde está el código. La conexión con el repositorio es segura si se hace con https.
#23 te refiere a un asunto diferente del que se estaba discutiendo. Si el codigo de la librería es malicioso, el protocolo da igual.
#9 #2 https://stackoverflow.com/questions/14998961/php-write-file-from-input-to-txt
#9 Lo de la PR creo que podemos descartarlo....
#2 Como bien te dice #5 eso es imposible. Normalmente las paraselas de pago te dan dos formas de integración. Una delegando todo el proceso en sus formularios (te dan las urls). Si esto hubiese sido asi no hubiese habido manera de que un js de un site leyese el de la pasarela. Y la otra opcion es la integración mediante la consumo de servicios SOAP. Que no son mas que llamadas desde tu back-end a servicios de la parasela, en el que mandas un XML con la informacion necesaria. Con esta manera la pasarela tampoco se vería afectada.
El problema viene de una dependencia estupida (Modernizr) que tienen por quitarse trabajo de adaptación del maquetado (no porque sea necesario). Los hacker manipularon el repositorio de donde la aerolinea descarga la libreria, y camuflaron el codigo malicioso como una actualizacion menor (hay que leerse la noticia para saberlo). En un sitio serio, no hay software que se use, ni librería con la que se codifique que no pase por un departamento de seguridad que verifique su integradidad, si puede provocar problemas, etc. Este paso se lo pasaron por el forro de los cojones en la aerolinea, confiando totalmente en las buenas maneras y que haceres de un monton de gente que ni conocen ni saben absolutamente nada de ellos.
Para que te hagas una idea, yo como programador Java, si me traen un PC limpio, tengo que pedir permisos para que me instalen (no lo hago yo) la JDK oficial que es estrictamente necesario para desarrollar aplicaciones J2EE. Y ojito con los "listillos" que tiran de aplicaciones portables no aprobadas. Aquí los cazan.
#10 pero todo esto no se solucionaría delegando todo el proceso de pago a la pasarela?
es decir, en tu web NO TIENES NINGÚN FORMULARIO CON LOS DATOS DE PAGO, sino que te comunicas con la pasarela dándole sólo tu idCliente, una descripción y un importe (todo ello encriptado con tu clave, además), y son los de Redsys los que piden los datos y te comunican el resultado de la operación ?
No sé, pero por lo que dice la noticia, todo viene por la tontería que hacen algunasd webs de recojer ellos los datos bancarios desde su web.... Me quivoco?
#18 Esa es una de las opciones, tambien les tienes que pasar una URL en la que esperar la respuesta. No es la opcion mas común para integrar ya que te dificulta mucho mas el control sobre la gestión y sus estados. Todo depende de como tengas planteado tu negocio y el modelo de la aplicacion. No tiene nada de malo hacer eso, si se hace de forma segura. El problema es que se han utilizado librerías de las cuales no se han auditado las actualizaciones.
#19 precisamente, de ahí el modelo que te decía (y que es el que siempre he usado).
Que un formulario de una web te pida los datos bancarios, creo yo, debería estar directamente prohibido, porque es un agujero de seguridad en ciernes.
Es como la idea que se le ocurrió en su día a Microsoft de permitir scripts en un correo electrónico: por muy bien que lo hagamos, por mucho empeño que le pongamos, siempre acabará saliendo algo.
Personalmente veo como muy imposible realmente tener suficiente personal, y suficientemente cualificado, como para hacer una auditoría de seguridad total, absoluta y fiable a todas las librerías y frameworks que podemos llegar a usar en una web (ya ni te digo grande como la de British Airway), una auditoría capaz de encontrar todos los agujeros de seguridad, y además hacerlo cada vez que actualizemos alguna versión de alguna de las librerías.
Que la web de Redsys es fea y cutre? Pues mala suerte, pero seguro que se han repasado hasta el último carácter para que sea segura. Y además, si algún día le encuentran un agujero, no será culpa nuestra (esto es ya de combo... )
#27 A mi tampoco me gusta usar librerías porque sí, mas cuando se trata de tareas sencillas. Fijate con lo que paso con la funcion leftpad de una libreria de js que usaba todo cristo. Que el dueño del codigo dijo, pues me lo llevo. Y empezaron a petar miles de proyectos por todo el mundo. Si sabes hacer algo, y no es una carga de trabajo excesiva, mejor hazlo.
#40 Es muy complicado para los pobres mortales trabajar sin librerias externas. Pero joder, que es British Airways. Deberían de permitirse el lujo de tener las librerías controladas y/o desarrolladas internamente. Así surgen la mayoría de las herramientas y frameworks.
#44 Eso es, ellos tienen musculo personal y economico para hacer las cosas bien hechas.
#27 No es ilegal pero tiene que cumplir con el PCI. Yo no suelo comprar en webs que piden los datos de la tarjeta y no tienen parasarela y/o banco/paypal.
#42 precisamente, yo me llevé un mosqueo del copón, y les escribí un mensaje-tocho de protesta la semana pasada, porque tuve que comprar 1 libro para el cole de mi hija, y lo tuve que hacer en una web donde pedían los datos de la targeta.
Su respuesta: que tenían otras formas de pago y que mis datos no los almacenaban (esto último no me lo juró por Snoopy...)
#18 Desde mi punto de vista estás en lo correcto.
Si lo que haces es permitir que la pasarela sea la que se encarga del pago, esa técnica no hubiera servido para hackear el sistema. Pero, aun así, los hackers han tenido acceso a la web y han podido meter su código JS, creo que a medio plazo podrían haber conseguido hackear el sistema (teniendo el control de la propia web hay infinidad de cosas que puedes hacer para intentarlo). Eso sí, les hubiera sido muchísimo más difícil.
#5 Eso mismo pensaba yo. La interesante sería saber quién ha modificado ese script y en qué servidor se aloja. Escribir esas 22 lineas en jQuery no es nada del otro mundo.
Me pregunto quién (si es interno) o cómo (si es externo) llegar a modificar el fichero afectado. Y que pasen 2 semanas y nadie se de cuenta...
#3 Nadie se da cuenta porque en un programa de chopocientasmil lineas no es ni medio factible tener a alguien revisando todos los módulos constantemente, vas cerrando cosas y tabajas bajo la suposicion de "cajas negras" en cuanto se valida una, yo ante una confirmación de que la funcionalidad es correcta y pasa la validación de auditoría ahí no toco, doy por supuesto que está bien y tengo a buen recaudo mi documento de validacion que justifica que eso está bien.
Aquí la movida es quien validó esto y como es que no saltaron las alarmas.
#17 Pues por ahí van un poco los tiros... asumiendo que British Airways tiene un control de versiones, un sistema de revisión o aprobación por pares, un sistema de deploy a producción... pues bueno, es raruno que un cambio en un fichero de una libreria de terceros pase tan desapercibido. Me parecería más fácil que alguien hubiera tocado directamente los ficheros en producción. Y de esto no se habla en el artículo.
#21 Escribes sobre las grandes empresas imagino que sin saber que suelen ser como una casa de putas, pero más grande.
No me lo he leído pero me da que las líneas de código dan igual... el tema es cómo consiguieron inyectarlas en el servidor...
El código no tiene nada de especial ni interesante.. se ve claramente su intención, lo habitual es ofuscar el código para dificultar su detección.
El fichero estaba "hosteado" en el sistema de contenidos (CMS) global de la empresa, el artículo no menciona cómo el CMS fue hackeado que sería lo interesante aquí
#31 Exacto. Le echan la culpa a Javascript cuando este simplemente es el cabeza de turco aquí.
Relacionada -> British Airways asume el robo de hasta 380.000 tarjetas en un ciberataque
British Airways asume el robo de hasta 380.000 tar...
lainformacion.com#1 Esta semana comré unos vuelos en su web y había un recuadro diciendo que ya todo estaba arreglado y blablabla. Al pagar había una casilla que decía "recordar tu información de pago (vamos, mi tarjeta) para futuras operaciones?". Y me faltó tiempo para desmarcarla...
#4 si te lees el artículo veras que no tiene que ver con eso.
#16 Me lo he leído antes de comentar. Solo era una anecdota relacionada con el robo que hubo y por eso contesto en el enlace de la noticia relacionada. Ahora respira y sigue con tu rutina.
#22 El problema es que eso que has hecho es contraproducente para este hackeo.
Si el robo fue en la web pero el backend no estuvo afectado, si el sistema recuerda tu información de pago, la segunda vez que pagues la web no va a necesitar procesar esa información. Sin embargo, si cada vez que compras un billete tienes que meter la información de pago, sí que te la pueden pillar la segunda vez y sucesivas.
Y se comieron el marrón en móvil por no hacer una app móvil de verdad. Lo barato sale caro.
#6 La mayoría de aplicaciones móviles son innecesarias. El acceso a través del navegador puede hacer lo mismo sin necesidad de instalar nada en tu teléfono. No es que lo barato salga caro, es simplemente no es necesario
#14 Para nada se puede hacer lo mismo ni la experiencia de usuario es la misma.
El titular de Microsiervos es sensacionalista a rabiar.
#30 Clipper, 286, que tiempos. Me ha saltado una lagrimilla.
Se agradece un código legible.
Buah si le quitan los espacios lo hacen sólo con una línea, pero 22... pff.
Chapó por el programador que puso todos los puntos y comas y declaró las variables
El archivo javascript no tuvo que ser necesariamente validado, se puede ocultar código años o meses atrás en el PHP, framework o libreria que usen que estándo medio ofuscado y difícilmente detectable (sobre todo en webs tan grandes, con tantísimo código) genere ese JS y que después de irte de la empresa lanzes el proceso que crea el JS. Por poner un ejemplo de método, puedes hacer un get a una URL donde tengas almacenado el JS a inyectar y esa URL que esté ofuscada en el código. Un mes haces una función que obtenga un fichero y lo guarde que usas para otro tema, al mes siguiente ofuscas tu URL con variables por el código y al mes siguiente haces una llamada a la función con el parámetro. A ver quien lo detecta.
¿No habéis dejado nunca un huevo de pascua en el código y lanzado cuando os fuisteis?
#20 En una empresa de alquiler de equipos que estuve, el dueño de la misma dejaba al su hijo pequeño de unos 10 años que era un jabalí silvestre, por lo de gordo y oloroso, jugar al another world en el 286 que teníamos para la gestión de clientes. Tanto me tocaba el niño los cojones que le cree un lanzador en un disquete autoarrancable para que jugase sin que tocase el resto del ordenador. Cuando supe que me iba/despedían,hize otro lanzador en Clipper para que si llegase a una fecha borrase todos los archivos de la base de datos mientras arrancaba el juego. Juro que fue la única vez que lo hice y el delito ya ha prescrito, creo.
#30 Con que fuiste tú, por fin te encontré hijo de....
Yo a tanto no he llegado. En algún programa que he hecho para algún cliente también le ponía fecha de autodestrucción para "asegurarme" que me pagasen, en cuanto me pagaban les mandaba una actualización "corrigiendo los bugs". Los otros han sido más bien de autoría, que haciendo tal cosa podías ver quien lo había desarrollado o mostrando alguna cosa cachonda. En un medio de comunicación para el que curraba quise meter un Asteroids en la portada pero no me dio tiempo y me fui antes de tiempo.
#32 Un colega del barrio me contó que para asegurarse el pago de una web que hizo para un negocio local del barrio, puso 2 llamadas ocultas a un CGI que tenían para la gestión de los formularios, cada una ponia una variable en un determinado valor que hacía que la conexión a la base de datos se hiciera o no y así tenía asegurado el cobro.
Esto me hace mucha gracia, problemas con british Airwais , empresa inglesa, problemas de facebook con lo de si espían, que si no se que con la campaña de trump, tiene que ver con una empresa Inglesa, si al final va a ser bueno que se vayan de la UE, los ingleses son y eran un troyano para el fundamento de Europa, tal vez los que metieron ese javascript fueran o no Ingleses , ya se sabrá o no pero los Ingleses más fuera que dentro ya