Ticketmaster krijgt boete van 1,4 miljoen euro van Britse privacywaakhond

| AE 12338 | Privacy, Security | 28 reacties

Het Britse bedrijf Ticketmaster heeft een boete gekregen voor een datalek in 2018, las ik bij Nu.nl. Door een kwetsbaarheid in de chatbot op de website konden derden toegang krijgen tot betaalgegevens van 37.000 creditcardhouders, en in theorie zelfs 9.4 miljoen mensen uit de hele EU. Opmerkelijk aan de zaak vond ik vooral dat die chatbot een ingekochte component was en dat de leverancier al enige tijd op de hoogte was van het lek.

Het boetebesluit legt uit dat in 2018 een aantal bank-klanten ontdekten dat hun creditcard frauduleus werd gebruikt, wat te herleiden was tot een aanschaf bij Ticketmaster. (Smoking gun: een testbetaling met gefingeerde expiry date dook met diezelfde datum op in het criminele circuit.) De site van Ticketmaster bleek gehackt en voorzien van malware die gegevens doorstuurde.

De hack bleek mogelijk door een ingezette chatbot van het bedrijf Inbenta. De bot was zo’n typische vraagbeantwoordbot om de menselijke helpdesk te ontlasten, en kwam gezellig mee op elke pagina in het besteltraject. Daardoor kon – na het compromitteren van de code – de bot ook gegevens lezen uit bestel- en betaalformulieren, wat dus de creditcarddiefstal mogelijk maakte. Inbenta was desgevraagd erg verbaasd:

The Javascript we created specifically for Ticketmaster was used on a payments page, which is not what it was built for. Had we known that script would have been used in that way, we would have advised against it, as it poses a security threat.

Deze werkwijze was verder in strijd met de PCI-DSS regels voor het verwerken van creditcardgegevens. Desondanks vond Ticketmaster dat niet haar maar Inbenta verwijten te maken waren, zij mocht contractueel rekenen op een veilige chatbot dus dan is het overmacht als de chatbot onveilig blijkt. Een argument dat ik vaak hoor: “In de verwerkersovereenkomst staat dat de leverancier garandeert veilig te zijn, we hebben de veiligheid dus geregeld”.

De ICO accepteert dat excuus volstrekt niet, en ik zou iedereen ook willen aanraden om wie dat argument gebruikt een stevige schrobbering te geven. Security is niet iets dat je contractueel afspreekt, dat is iets dat je praktisch regelt én verifieert. Security doe je.

Natuurlijk zijn superzerodayhacks altijd mogelijk, en ik kan best accepteren dat dat overmacht zou kunnen opleveren. Maar het ging hier om een simpele Javascript aanpassing waarmee betaalformulieren uit te lezen en te kapen waren, iets dat zeker weten in 2018 tot de gewone stand der techniek behoorde en waar dus gewoon beveiliging tegen hoort te zijn.

Maar maar maar, aldus Ticketmaster: wij hadden netjes compliance geregeld, kijk maar:

At §§8-9 of its Comments, Ticketmaster relies upon its receipt of security certifications provided by Inbenta. At §29.3 of the Comments, Ticketmaster emphasises Inbenta’s ISO 27001 certification. The Commissioner places little weight on the mere provision of such certifications by Inbenta as a mechanism of securing the chat bot in the circumstances. Further, ISO 27001 is an information security management standard, which does not apply directly to software development.

Een certificering is nog geen bugfix, laat staan een securitymaatregel. Een code review of een security audit was dat wel, maar daar had Ticketmaster nul moeite in gestoken. En dat wordt ze serieus kwalijk genomen:

Rather, the GDPR requires that each organisation assess the risks arising in the circumstances of their own implementation and put controls in place to protect the personal data that it processes. Ticketmaster has shown very limited knowledge at the date of the Incident of the risk of implementing third party scripts into a payment page, despite it being widely known and documented at that time. A fortiori, Ticketmaster has not evidenced that it deployed appropriate and proportionate controls to manage this risk.

Verder noemt de ICO dit een serieuze overtreding van de AVG: in theorie hadden 9.4 miljoen klanten hun betaalgegevens gestolen kunnen hebben, en Ticketmaster had geen enkele control in place om hier wat tegen te doen. (Zelfs passieve detectie door wekelijks zelf een nepcreditcard te proberen was er niet.) De boete komt uiteindelijk dus uit op 1.4 miljoen euro. Een terechte tik op de vingers, wat mij betreft.

En ik zeg het nogmaals, want ik weet dat er veel contractsjuristen, FG’s en ander AVG compliance volk meeleest: doe alsjeblieft méér dan alleen contractueel vastleggen dat de veiligheid op orde moet zijn. Zonder daadwerkelijk feitelijk handelen ben je gewoon niét AVG compliant, al staan er honderd garanties en heb je duizend certificeringen.

Arnoud

Deel dit artikel

  1. Dit is natuurlijk een privacy issue, maar is dit niet veel meer een fraude-issue?

    AVG gaat over beveiligen van persoonsgegevens. De schade in deze zaak zit hem niet zozeer in het feit dat persoonsgegevens gelekt zijn (ook natuurlijk), maar dat er financiele fraude mee gepleegd is.

    Ook voordat de AVG er was, had dit soort gedrag bestraft moeten worden (faciliteren van crimineel gedrag) + schadevergoeding aan de slachtoffers.

  2. “In de verwerkersovereenkomst staat dat de leverancier garandeert veilig te zijn, we hebben de veiligheid dus geregeld”

    Ik heb deze reactie ook vaak gezien na de Schrems II uitspraak. Diensten leveranciers (die daarvoor zelf weer Amerikaanse cloud diensten gebruiken) haastten zich een GDPR compliance statement op hun site te zetten. Maar waar het vaak op neerkomt is, dat ze alsnog op SCC’s terugvallen, die dus niet geldig zijn in deze situaties.

    Als afnemer van de dienst moet je (als ik het goed heb begrepen) zelf verifieren of de GDPR claims van de leverancier kloppen.

    • Ik ga wel deels mee in de reactie van Marcel. Dat is allemaal heel goed, in theorie, dat checken, maar in de praktijk valt dat nogal tegen

      Ik doe als kleine eenmanszaak een beroep op als betrouwbaar bekend staande leveranciers. Meer kan ik redelijkerwijs niet doen. Ik mis de kennis om zelf te checken om mijn leveranciers hun systemen en organisatie op orde hebben, en de waarde van de IT diensten die ik inkoop is zodanig laag dat ik het no-way kan verantwoorden om daar een deskundige voor in te schakelen. Als mijn leveranciers mij/mijn deskundige al binnenlaten/antwoord geven, ook hun tijd immers kost geld.

      Hoe moet ik in hemelsnaam checken of Google of Microsoft, of zelfs een kleine lokale US leverancier echt GDPR-compliant werken, of dat alleen maar zeggen?

  3. Oss, november 2020. Een 34-jarige bestuurder uit Oss is veroordeeld tot 3 maanden cel, nadat hij betrokken was bij een ongeluk waarbij een fietser ernstig werd verwond. Dit gebeurde nadat zijn stuurkolom plotseling doormidden brak tijdens het rijden. Dit bleek een constructiefout bij Volkswagen. De bestuurder gaf aan dat de garage hem had beloofd dat de wagen veilig zou zijn. Tevens was hij van mening dat hij er op mocht vertrouwen dat dit bij een nieuwe Volkswagen niet zou mogen gebeuren. De rechtbank neemt hem echter ernstig kwalijk dat hij niet zelf de deugdelijkheid heeft gecontroleerd. Zijn verweer dat hij – werkzaam in de schoenenreparatiebranche – geen verstand heeft van auto’s en daardoor andere partijen hiervoor inschakelt, mocht niet baten.

    • Marcel, dat lijkt mij een andere situatie. De deugdelijke werking van een stuurkolom is iets wat bij de typegoedkeuring van de auto al gecontroleerd werd. Het breken tijdens een ongeval is dan een afwijking van de technische specificatie die voor de goedkeuring geldt. Dit is bovendien iets wat zelfs voor een monteur niet controleerbaar hoeft te zijn, omdat het product aan alle kanten technisch correct kan zijn, maar er een materiaalgebrek is. Een overeenkomst waarin staat, dat je aan de voorwaarden voldoet is leuk, maar er is geen organisatie die dit heeft goedgekeurd. Zou die er wel zijn en in de overeenkomst worden vermeld, hoef je als klant alleen maar de juistheid van de vermelding te controleren. Je hebt dan redelijkerwijs een controle van de beweringen uitgevoerd. Maar als vergelijking, bij een tweedehands auto moet je meer controleren dan bij een nieuwe auto. Doe je dat niet, kan het zijn dat een schadeclaim bij de verkoper op niets uitloopt. Doe je dat wel en kun je aantonen (achteraf) dat er informatie is verzwegen of vervalst, is dat anders. Maar een controle op roestschade (voertuiglekkage) wordt je geacht toch echt wel zelf te doen.

  4. Uit beveiligingsoogpunt verbaast het me dat programmeurs zonder serieus naar de codekwaliteit te kijken zomaar softwarebibliotheken van internet downloaden en in hun programma’s gebruiken. Dit is zelfs zo gebruikelijk geworden dat er systemen zijn die het downloaden van bibliotheken en integreren met de code geautomatiseerd hebben. Dit gaat niet altijd goed; van een bekende javascript-repository is bekend dat hackers daar code met ongewenste extra functionaliteit hebben weten te verspreiden.

    De belangrijke vraag is: In hoeverre kan een ontwikkelaar aansprakelijk gesteld worden voor bugs en malware die via deze bibliotheekcode in zijn applicatie terecht komen? Welke maatregelen kunnen de aansprakelijkheid beperken? Mag je vertrouwen op de goede naam van een bibliotheek en/of garanties van de leverancier daarvan?

    • Als je naar de avg kijkt dan ben je als verantwoordelijke (controller) ook verplicht on regelmatig je beveiligingsmaatregelen (inclusief backups) te beoordelen op werkzaamheid (bijv door (penetration) testen).

      Het klakkeloos gebruik van software bibliotheken is een probleem, niet alleen vanwege de avg, maar ook vanuit licentiemanagent oogpunt. Ook open source is niet per definitie bruikbaar met ander open source. Het hangt allemaal van de licentie af. Daarnaast zijn er licenties die verplichten aan te geven dat je de software gebruikt (meestal in een about schermpje of handleiding). Niet moeilijk, wel iets dat nauwkeurig beheer vereist.

  5. Maar het ging hier om een simpele Javascript aanpassing waarmee betaalformulieren uit te lezen en te kapen waren, iets dat zeker weten in 2018 tot de gewone stand der techniek behoorde en waar dus gewoon beveiliging tegen hoort te zijn.

    Wat moet die beveiliging dan zijn, precies? Het punt dat die Javascript van een derde partij niet op de betaalpagina aanwezig had moeten zijn snap ik. Dat je af en toe eens een pentest zou moeten doen, snap ik ook.

    Maar stel nu dat die Javascript niet op die betaalpagina stond, en dat door een programmeerfout of een lek ergens die pagina evengoed aangepast was. Dat kan dan nog steeds een ‘simpele Javascript aanpassing’ zijn. Dan kunnen nog steeds die creditcardnummer gestolen worden. Daar is niet ‘gewoon beveiliging tegen’.

    Het punt is, misschien dat in dit specifieke geval Ticketmaster érg weinig heeft gedaan, maar een gehackte server met een aangepaste pagina kán nu eenmaal voorkomen. Ook als je al je maatregelen netjes neemt. Actief zijn in de IT voelt op dit moment een beetje als Russisch roulette, want als je wel gehackt wordt is er altijd een kans dat de toezichthouder vindt dat je er maar een maatregel tegen had moeten hebben, ook al heb je 5000 andere maatregelen wel genomen. Achteraf is het altijd makkelijk zeggen wat er gedaan had kunnen worden, vooraf is dat een stuk lastiger.

    [edit] Overigens, ik lees nu het boetebesluit, en dat Ticketmaster een boete krijgt is niet meer dan terecht, gelet op de timeline. Maar de uitspraak dat tegen een Javascript aanpassing maar gewoon beveiliging moet zijn val ik als IT’er nog steeds over.

    • Een standaard truc is elke dag de creditcard van de algemeen directeur (nou ja, een nep-CC) door het systeem halen en dan kijken of daar malafide transacties op komen.

      Maar het belangrijkste bezwaar is dat TM niet opgelet heeft waar dat script had mogen zitten. Dáár had tegen geborgd moeten zijn. Dat is organisatorisch, niet technisch, maar beiden moeten net zo goed.

      • Een standaard truc is elke dag de creditcard van de algemeen directeur (nou ja, een nep-CC) door het systeem halen en dan kijken of daar malafide transacties op komen.

        Maar zo makkelijk gaat dat volgens mij niet. Ik zit niet in die sector, maar als je zoiets netjes geautomatiseerd zou willen testen is het maar de vraag of je de inbreuk die hier is gepleegd wel meepakt. Want zo’n Javascript help widget wordt alleen uitgevoerd als je ook daadwerkelijk met een webbrowser langskomt. Verder moet je natuurlijk maar net kunnen detecteren dat zo’n creditcard dan ook op andere plaatsen gebruikt wordt. Geen idee of creditcard verstrekkers daar systemen voor afnemers voor beschikbaar hebben. Het lijkt mij in ieder geval technisch allemaal niet zo recht-toe-recht-aan.

        Dat Ticketmaster hier organisatorisch helemaal fout zit staat buiten kijf. Al op 12 april meldde een bank frauduleuze transacties bij ze, en pas op 23 juni vonden ze de code. Dat tempo rechtvaardigt die boete zeker.

        • Er zijn tools (Selenium is een bekende) waarmee je relatief makkelijk interactie met een webbrowser kunt scripten. Selenium maakt gebruik van een echte webbrowser (Firefox, Chrome) zodat javascript gewoon werkt.

          Ik vind dit weer een voorbeeld van hoe ook gerespecteerde bedrijven gigantisch onderuitgaan waar het gaat om “online veiligheid”. Hoeveel wachtwoorden heeft “Have I been Pwned” ondertussen?

          • Er zijn tools (Selenium is een bekende) waarmee je relatief makkelijk interactie met een webbrowser kunt scripten.

            Totdat iedereen dat toepast en degene die jouw CC nummers wil stelen dus wat basis checks doet voordat hij je gegevens steelt. Dan is zo’n geautomatiseerde test er zo uit te halen.

            Daarnaast zijn de CC nummers natuurlijk ook een tijd op te slaan in plaats van direct te gebruiken. Volgens mij gebeurt dat in de praktijk ook vaak, en zijn het alleen de ‘domme’ criminelen die direct de nummers gaan gebruiken. Door een tijdje te wachten kun je detectie veel beter voorkomen.

            Dit om maar even te schetsen dat er voor deze specifieke casus misschien makkelijk maatregelen te verzinnen zijn, zeker achteraf. Maar dat betekent niet dat vooraf maatregelen verzinnen, of maatregelen tegen iedere aanvaller verzinnen, net zo makkelijk is.

      • Natuurlijk wordt er te weinig rekening gehouden met beveiliging en privacy. Deels is dat omdat klanten graag voor een dubbeltje op de eerste rang willen zitten, deels is dat omdat er een chronisch gebrek aan capabele IT’ers is.

        Maar ook bij Google of Facebook wandelen security researchers weleens naar binnen zonder al teveel moeite, ondanks de honderden miljoenen die die partijen in security steken. Software is gewoon enorm complex, en ik heb af en toe het idee dat de juristen op deze wereld denken dat er een magic bullet is waarmee alle potentiële problemen de wereld uit zijn.

        Uiteindelijk kan iedereen de sjaak zijn, en iedere IT’er die beweert dat zijn beveiliging onfeilbaar is laat daarmee juist zien dat hij niets van beveiliging weet. Die onzekerheid zie ik af en toe te weinig in de discussies terug. Wetgevers, toezichthouders en juristen zouden wat dat betreft zich véél meer bezig moeten gaan houden met de praktijk, in plaats van oeverloze discussies over de papieren werkelijkheid.

        Als je het hebt over ‘systematische controles’ dan komt dat bij veel bedrijven ook neer op een ISO 27001 certificaatje hier en een auditortje daar, of af en toe een pentest van een partij die een standaard security scanner uit de kast trekt. En dan kloppen dat soort partijen zich op de borst over dat ze beveiliging zo serieus nemen. Het zegt echt allemaal helemaal niets in de praktijk.

        • Een van de belangrijke axioma’s van software ontwikkeling is:

          Hoeveel je ook test, met testen kun je niet bewijzen dat software correct is; je kunt alleen aantonen dat er fouten in zitten.
          Dat wraakt zich meedogenloos als het gaat om computerbeveiliging. Een gaatje in de software dat groot genoeg is voor een hacker om een exploit naar binnen te krijgen is funest voor de veiligheid van een systeem. Daarom:
          Een veilig systeem krijg je niet door veel te testen; de veiligheid moet vanaf het begin van het ontwerp meegenomen en door het hele ontwikkelproces afgedwongen worden.
          En daarnaast is er nog de complexiteit van interacties tussen verschillende systeemcomponenten waardoor de combinatie van bepaalde componenten (en hun configuratieopties) tot veiligheidsgaten kan leiden. [Het ticketmaster probleem: chatbot op creditcard pagina.]

          Ik hoop dat ik in mijn softwarecarrière meer beveiligingsfouten heb (helpen) oplossen dan dat ik veroorzaakt heb. Ik ben bang voor het tegendeel, ik heb maar aan één project gewerkt waar ze veiligheid echt serieus namen.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS