'British Airways- en Ticketmaster-hacks zijn het werk van dezelfde groep'

Volgens een analyse van beveiligingsbedrijf RiskIQ zit dezelfde groep achter de hacks op British Airways en Ticketmaster. Het zou gaan om de zogenaamde Magecart-groep, die uit is op betaalgegevens en andere gevoelige informatie.

Het bedrijf legt de link tussen beide incidenten in een analyse van de scripts op de site van British Airways. Normaal gesproken krijgt het bedrijf een melding als er een Magecart-script op een site verschijnt dat op een zwarte lijst staat, maar in dit geval ging het om een aangepaste variant. Door de wijzigingen op de site te onderzoeken, kwam RiskIQ erachter dat er op 21 augustus van dit jaar een aanpassing was gedaan in de Modernizr-bibliotheek voor JavaScript op de British Airways-pagina voor bagageclaims. Het script was aangevuld met 22 regels code, die het mogelijk maakten om ingevulde gegevens te stelen, aldus het beveiligingsbedrijf.

De toegevoegde regels code na opschoning, afbeelding van RiskIQ

Die regels code zorgden ervoor dat bij bepaalde gebeurtenissen de inhoud van de velden paymentForm en personPaying werden doorgestuurd naar een server die werd gehost op het domein baways.com. Dit domein behoort aan de aanvallers en maakt deel uit van een infrastructuur die specifiek voor British Airways was opgezet. Volgens het beveiligingsbedrijf ging het dan ook om een zeer gerichte aanval, waarbij Magecart niet zomaar zijn gebruikelijke skimmer-script injecteerde.

Het skimmen van gegevens was niet beperkt tot de site van de luchtvaartmaatschappij, claimt RiskIQ verder. Ook in de mobiele app was een kwaadaardige pagina aanwezig die gegevens stal. De app laadt namelijk in bepaalde gevallen de mobiele versie van de British Airways-site in plaats van gebruik te maken van de beschikbare api's. Een van deze pagina's, die ging over belastingen, bevatte eveneens het aangepaste script. De aanvallers zouden moeite hebben gedaan om de methode te laten werken op mobiele apparaten.

RiskIQ oppert dat de aanvallers brede toegang moeten hebben gehad tot de British Airways-infrastructuur om hun aanpassingen te doen. Daarnaast zou het mogelijk zijn dat ze lang voordat de aanval begon al toegang hadden. British Airways maakte vorige week bekend dat onbekenden de gegevens van 380.000 klanten hebben gestolen tussen 21 augustus en 5 september. Daarbij ging het om volledige namen, factuuradressen, e-mailadressen en creditcardgegevens bestaande uit nummers, verloopdata en cvv-codes. RiskIQ publiceerde eerder ook al een analyse van het Ticketmaster-incident.

Reacties (28)

[Alternativ]

Toevallig in de periode waarin de hack actief is geweest een boeking gedaan op de website. Op moment van schrijven heb ik een tweetal mails van British Airways gekregen dat ik mogelijk kwetsbaar ben geweest.

Contact opgenomen met American Express en die geven aan dat er op dit moment nog veel speelt en dat ze nauw contact houden met British Airways. Na verdere inspectie lijkt het probleem zich alleen te manifesteren op pagina's betreffende bagageclaim, vraag me af waarom deze nuance niet wordt gedeeld door British Airways.

1:

We’re deeply sorry, but you may have been affected. We recommend that you contact your bank or credit card provider and follow their recommended advice.

2:

As you may be aware, from 22:58 BST 21 August 2018 until 21:45 BST 5 September 2018 inclusive, the personal and financial details of customers making or changing bookings at ba.com, and on our app were compromised. We’re truly sorry, but you may have been affected.

quote: https://www.riskiq.com/bl...t-british-airways-breach/

The script was loaded from the baggage claim information page on the British Airways website.

[jozuf]

Hoog script kiddie gehalte. Combineren van pure JS en jQuery slaat echt in de totaliteit nergens op. Gebruik of geen jQuery of schrijf alles in jQuery.
Lijkt een beetje alsof elke regel code apart gegoogled is en direct van StackOverflow af is gekopieerd ofzo.

[Reactie gewijzigd door jozuf op 23 juli 2024 16:30]

[ZpAz]

Vraag me af waarom de async optie de waarde "niet 0" heeft. In JS wordt dat gewoon true.

[jimmy_dg]

Denk niet dat er een logische reden achter zit. Het evalueert inderdaad naar 1, en dus true omdat het een Boolean veld is. Misschien het werk van een minifier/crappifier zodat de code minder leesbaar wordt. Kan me geen ontwikkelaar voorstellen die dit met opzet zou doen.

[ZpAz]

!0 is inderdaad een beetje korter dan false. 3 bytes bespaart!

[Beagon]

Hij had er ook gewoon 1 van kunnen maken, als het om bytes te besparen ging natuurlijk.

[Cerberus_tm]

Maar dat is dan weer niet Boolean. Misschien was er een Boolean waarde nodig op die plaats?

[jimmy_dg]

Neen, draai dit eens in je dev console:
console.log(1)
console.log(!0)

[Cerberus_tm]

Maar wat nou als die waarde uiteindelijk getest wordt op === true?

[davekok]

Wat maakt het uit. Ze hoeven deze code echt niet te onderhouden. Als ik snel even wat code wil schrijven, ga ik ook echt niet over stijl nadenken. En dan is het maar net wat er het eerste in je gedachten op komt. Pure JS of jQuery of wat dan ook.

[jozuf]

Dat is wel een hele frappante manier van ontwikkelen.
Als je jQuery gebruikt weet je dat toch, en gebruik je dat ook. Dat zal dan dus ook als eerste in je op komen (iig bij mij). Dit lijkt echt gewoon googlen op vraagstukken en copy-paste van antwoorden.
Wat het uitmaakt? Helemaal niets, dat beweer ik verder ook niet. Het geeft gewoon de skills van deze cracker aan, dat ligt duidelijk niet in frontend ontwikkeling maar totaal ergens anders.

[Reactie gewijzigd door jozuf op 23 juli 2024 16:30]

[[Yellow]]

Hackers werken meestal alleen en proberen zo snel mogelijk iets te maken dat (net voldoende) werkt. Programmeurs daarentegen moeten met veel anderen samenwerken en hun code moet onderhoudbaar zijn ook jaren later nog. Ik denk dat dat de reden is dat deze code er zo uit ziet!

[GeoBeo]

HackersCrackers werken meestal alleen en proberen zo snel mogelijk iets te maken dat (net voldoende) werkt. Programmeurs daarentegen moeten met veel anderen samenwerken en hun code moet onderhoudbaar zijn ook jaren later nog. Ik denk dat dat de reden is dat deze code er zo uit ziet!

Fixed that for you.

Overigens ligt het er natuurlijk maar net aan wat het doel is. Een cracker kan "beter" zijn in programmeren dan een programmeur die zich niet met cracken bezighoudt. En omgekeerd.

[110124]

script kiddie of niet, ze hebben er wel behoorlijk wat mee bereikt. Of ze nu achter de data zelf zaten of een slechte reputatie aan deze bedrijven wilden geven.

[VincentdeVreede]

Zeker hoog script kiddie gehalte, de Modernizr-bibliotheek is namelijk pure JS. Zonder jQuery code dus beter verstopt geweest.
Verder is natuurlijk ook nog de vraag hadden ze de code geminified of was het openen van de .js file genoeg geweest om te zien dat er in de code geknoeid was? (Hash en datum daargelaten, geloof al niet dat ze dat gemanipuleerd hebben)

[alt-92]

Hoog script kiddie gehalte.

If it works, it works.

Feit blijft dat 3rd party code in betaalflows niet tot nauwelijks gecontroleerd wordt, en het heel eenvoudig blijkt om zonder al te veel moeite de stap van cryptominer code in ad networks naar dit soort dingen te doen.

[kodak]

Wat is het scriptkiddy gehalte als er toegang met schrijfrechten moet zijn geweest tot geselecteerde systemen en locaties waar een scriptkiddy met beperkte kennis en tooltjes niet toe in staat is?

[mrdemc]

Volgens mij had dit voorkomen kunnen worden door gebruik te maken van een Content Security Policy met connect-src. Dit wordt volgens mij alleen niet zo heel vaak gebruikt. Kom het in ieder geval niet vaak tegen. Dan had dit domein niet op de lijst gestaan en was de XMLHttpRequest niet toegestaan geweest naar dit domein omdat het simpelweg vanuit de webserver niet was toegestaan met de betreffende header. Aan de andere kant hadden ze toegang tot de infra, dus hadden ze deze header ook kunnen slopen.

[Reactie gewijzigd door mrdemc op 23 juli 2024 16:30]

[Bartmanz]

Het request wordt niet vanuit de webserver maar vanuit de client gedaan. CSP is dan ook een policy die door (sommige) webbrowsers wordt nageleefd.

[TomONeill]

Daar dient CSP dan ook voor. En dat het (nog) niet door elke browser wordt ondersteund is natuurlijk geen reden om het helemaal maar niet te gebruiken.

[mrdemc]

Dat is toch exact wat ik zeg? Het enige deel waarin ik de webserver noem is het deel waarin ik het heb over het toevoegen van de betreffende header. En die header wordt vanuit de webserver verstuurd naar de client waarna de client er iets mee moet doen. Of begrijp ik je verkeerd?

[Reactie gewijzigd door mrdemc op 23 juli 2024 16:30]

[Bux666]

Die regels code zorgden ervoor dat bij bepaalde gebeurtenissen de inhoud van de velden paymentForm en personPaying werden doorgestuurd naar een server die werd gehost op het domein baways.com.

Een domein wordt gehost op een server, niet andersom.

[mashell]

Is dat zo? Grote sites gebruiken meerdere servers die allemaal van het zelfde internet domein gebruik maken.

[kristofv]

Nee, een Active directory domein wordt inderdaad gehost op een server (of meerdere) maar een domein in de pure zin van DNS wordt helemaal niet gehost.

Wat jij bedoelt zijn authorative nameservers, maar dit is in essentie niets meer dan een oplijsting van A records & CNAMES.

[pe0mot]

Vreemd dat de baways.com server (unbuntu) nog steeds in de lucht is.
Of is dit een honingpotje?

[anpat]

Toegang tot de infra of alleen de DMZ servers.. Ik mag hopen op dat laatste, want als ze volledig binnen zouden zijn dan gaan ze ook echt wel een achterdeurtje hebben opengelaten lijkt me.

Je zou dit mogen onderzoeken zeg... Toffe job