Creditcarddata van miljoenen hotelboekingen was vrij toegankelijk

Meer dan tien miljoen bestanden met details over hotelboekingen waren inzichtelijk op een verkeerd geconfigureerde AWS S3-bucket. De data werd beheerd door Prestige Software, een Spaans bedrijf dat samenwerkt met onder andere Agoda, Booking.com en Expedia.

Het beveiligingsteam van Website Planet ontdekte de data. Volgens de onderzoekers gaat het om 24,4GB aan logbestanden en bevat de verzameling gegevens van hotelboekingen wereldwijd. Zowel recente boekingen als details over oudere boekingen, tot 2013, werden aangetroffen.

De persoonsgegevens werden zonder enige bescherming opgeslagen. Het gaat om creditcardgegevens, naam- en adresgegevens, paspoortnummers en e-mailadressen van hotelbezoekers. Ook de details van hotelreserveringen, zoals de kosten, het aantal nachten en aanvullende verzoeken staan vermeld.

Het datalek zit bij Prestige Software, een Spaans bedrijf dat een channel management-platform aanbiedt aan hotels onder de naam Cloud Hospitality. Hotels kunnen daarmee de beschikbaarheid van hun kamers doorgeven aan sites als Agoda, Booking.com en Expedia. Volgens Website Planet blijkt uit de data dat het onder andere gaat om boekingen die via die grote platforms zijn gemaakt, maar ook tal van andere platforms.

De onderzoekers troffen de data vrij toegankelijk aan op een S3-bucket van Amazon Web Services. Die was verkeerd geconfigureerd en daardoor te benaderen. Op het moment dat het datalek geconstateerd werd, was de database in gebruik en werden er nieuwe records aan toegevoegd. Het is niet bekend hoe lang de data toegankelijk was en of die door anderen is ontdekt en gedownload.

Vanwege de gevoeligheid van de data, zegt Website Planet direct contact gezocht te hebben met Amazon. Een dag na de ontdekking zou de toegang tot de S3-bucket zijn afgegrendeld. Prestige Software heeft bevestigd eigenaar van de gegevens te zijn. Het Spaanse bedrijf heeft geen statement naar buiten gebracht, maar is volgens GDPR-wetgeving verplicht om melding te maken van een datalek bij de privacytoezichthouder.

Voorbeeld van data die inzichtelijk was

Reacties (66)

Ik vind het ook schokkend dat er überhaupt een veld voor de CVC-code in de xml staat. Dit nummer mag NOOIT worden opgeslagen.

Inderdaad, het is namelijk alleem bedoeld voor verificatie. Amazon gebruikt het niet eens omdat ze "zeker zijn" van hun betaalsysteem tegen creditcardfraude.

Beter gezegd: ze maken meer winst met impulsaankopen en 1 click buy dan dat ze verliezen met chargebacks.

Als ik dit zo zie wordt dit veld ook niet gevuld.

Opnieuw. Onbegrijpelijk in deze tijden.

Opnieuw. Onbegrijpelijk in deze tijden.

Onbegrijpelijk dat deze data opgeslagen wordt op tientallen verschillende websites of onbegrijpelijk dat ie uitlekt?

Dat de data uitlekt lijkt me een super logisch en blijvend gevolg van onnodig centraal opslaan van gevoelige data.

Werkende credit card databases (en paspoort scan databases, etc) zijn al decennia te koop voor een tientje per credit card op de dark net en dat zal nog wel even zo blijven tot de wetgeving omtrent opslaan van data zinvol en logisch wordt.

Ik denk dat @DJTony doelt op het feit dat er wederom een bedrijf data lekt via een S3 bucket welke publiekelijk benaderbaar was. Al jaren zegt AWS dat je je S3 buckets niet op public moet zetten tenzij dit een weloverwogen bewuste keuze is geweest. Keer op keer gaan bedrijven hiermee de fout in, gelukkig doorgaans kleinere bedrijven of niet zulke gevoelige informatie als dit, maar nog steeds enorm fout natuurlijk.

Het is kinderlijk eenvoudig om dit soort risico's binnen je eigen AWS accounts op te sporen, op te lossen en te voorkomen. Zo wordt er in de S3 web console enorm duidelijk aangegeven wanneer een bepaalde bucket public is of public kan zijn. Zo kan je simpelweg op alle buckets policies instellen die public access onmogelijk maken (kwestie van 4 vinkjes zetten), en zo heb je ook nog AWS services die je nagenoeg gratis kan gebruiken welke controleren op dit soort risico's en misconfiguraties welke binnen enkele minuten opgezet is.

Keer op keer communiceert AWS naar buiten dat je buckets NIET public moeten zijn. Letterlijk IEDERE AWS audit/pentest controleert op dit soort risico's/misconfiguraties. Dit nieuwsbericht betekent dus het volgende:

• Prestige Software doet niet aan audits/pentests
• Prestige Software heeft geen capabele AWS engineers in dienst
• Prestige Software geeft niks om security
• Prestige Software luistert niet naar AWS/kan niet lezen

Onacceptabel voor een bedrijf van deze grootte die met het soort data omgaat als dit. Tevens onbegrijpelijk dat de klanten blijkbaar geen eis hebben dat er regelmatig audits en pentests plaats vinden bij dit soort dataverwerkers waar zij zaken mee doen.

[Reactie gewijzigd door Hatsjoe op 9 november 2020 16:34]

Hoe kan je controleren of bedrijven pentests en of audits uitvoeren?

Door te verifiëren of de partij daadwerkelijk de certificeringen heeft die het claimt te hebben. Deze audits worden altijd uitgevoerd door een onafhankelijke derde partij. Het is ook vrij gebruikelijk om de rapporten van de audits beschikbaar te stellen op de website. AWS doet dit bijvoorbeeld keurig. Alle rapporten van de audits en certificeringen zijn publiekelijk in te zien.

Mochten deze zaken niet publiekelijk te vinden zijn, dan sta je volledig in je recht deze informatie op te vragen voordat je zaken doet met een bedrijf. Wanneer je het over B2B contracten hebt zoals in dit geval tussen bijvoorbeeld Prestige Software en Booking.com is het ook gebruikelijk dit soort eisen op te nemen in het contract.

Hopelijk mag je dat ook als particulier, ik vind dat bedrijven echt verplicht zijn om te laten zien aan consumenten ongeacht of ze zakelijk zijn dat hun mogen opvragen hoe veilig een bedrijf is met data.

Je vergeet de optie dat mensen ook fouten kunnen maken. Je kan wel een audit doen maar dat voorkomt fouten niet en verhelpt ze ook niet. Auditis zeggen ook vaak alleen maar iets over dat moment.
Om te beweren of er aan de hand is wat jij meent zal je dus meer moeten weten. En dat is waar het hier aan ontbreekt: genoeg uitleg waarom dit geen toevallige fout was. Niet om het voor het bedrijf op te nemen maar omdat het zo belangrijk is dat een bedrijf als booking of andere organisaties die hier gebruik van maken zich niet kunnen verschuilen dat ze dit soort bedrijven in dienst nemen. Want die lijken het meeste uit te moeten leggen dat het weer mis gaat bij inhuren en anderen het werk laten doen.

Ik vergeet zeker niet dat mensen fouten kunnen maken, daarom heb je ook audits en pentests. Het is heel normaal (en vaak zelfs een eis) dat er een pentest plaatsvindt voordat iets live gaat. Daarnaast heb je ook zogeheten "Well Architected Framework" reviews waarbij je AWS omgeving tegen het licht aan gehouden wordt om te kijken of je alle AWS best practices op de juiste manier geïmplementeerd hebt. Als je daarbij geen services gebruikt welke dit soort cruciale fouten kan detecteren (met bijvoorbeeld de service AWS Config) dan kom je gewoon niet door dat soort audits heen.

Mensen maken absoluut fouten. Wanneer ik AWS omgevingen ontwerp en bouw voor mijn klanten maak ik ook nog regelmatig fouten. Daarom hoor je er een vangnet omheen te hebben in de vorm van reviews, audits en pentests. En ja, die zijn ook niet 100% waterdicht. Echter een probleem als dit was bij geen enkele review, pentest of audit heen gekomen. Sterker nog, dit is vaak het allereerste waar ik zelf naar kijk bij nieuwe klanten, en waar security specialisten/pentesters als 1e naar kijken.

Fouten maken is inderdaad menselijk. Zelfs met controles kom je nooit aan de garantie dat je beveiliging 100% waterdicht is. In dit geval lijkt het me geen menselijke fout, maar gewoon laksheid van het bedrijf. Databeveiliging is daar gewoon geen issue geweest. Zelfs nu reageert men niet.
Men slaat paspoort en bankgegevens op en daar zou men zeer zorgvuldig mee om moeten springen. Daarbij hoort ook dat je de beveiliging regelmatig controleert en door externen laat controleren. In eerste instantie ligt de fout bij Prestige software, maar ook de klanten zijn zelf verantwoordelijk voor de databeveiliging. Geen van allen heeft (voor zover is na te gaan) een melding gedaan bij de privacy autoriteit. Ook de gedupeerde klanten hebben geen bericht gehad. Met de gegevens die men buit heeft kunnen maken zou men op uitgebreide schaal identiteitsfraude kunnen plegen.
Ik hoop dat hier een serieus vervolg op komt. Niet alleen in de vorm van (hoge) boetes, maar ook in de vorm van extra eisen in de vorm van verplichte audits door gecertificeerde bureaus.

En daarmee verwijs ik je naar mijn eerste comment waar ik precies dat zeg Waar mensen werken worden fouten gemaakt. Dat dit soort fouten echter tot en met productie kan komen is onbegrijpelijk en niet goed te praten.

Dit heeft niks te maken met "in een mooie situatie" of "in een ideale wereld", maar puur met basis principes. Deze zaken mogen gewoon absoluut niet meer fout gaan. De enige bedrijven waar dit soort zaken fout gaan zijn de bedrijven die je nooit kan vertrouwen met dit soort data.

@ kodak, de oorzaak van de fout is niet zo relevant. De opsporing daarentegen wel.

Dus test op test op test op test enzovoort. Ook na live gaan blijven testen. Dit lijkt mij een basisprobleem. Desinteresse in het product.

@ kodak, de oorzaak van de fout is niet zo relevant.

De oorzaak is juist relevant. Stel ze hadden moeite gedaan om fouten te proberen te voorkomen dan is het dus belangrijk om te weten waarom het alsnog fout is gegaan. En ook bij het opsporen kan het fout gaan. Ook dan valt er pas te leren als je weet wat er voor zorgde dat het opsporen niet deugde. Zonder leren van fouten of opzettelijke blunders kan er moeilijker geleerd worden. Dat dit door anderen ontdekt is zorgt er helaas niet zomaar voor dat het bedrijf of hun opdrachtgevers dus willen leren en het volgende keer anders doen. Er is dus meer nodig dan alleen maar belang hechten aan audits of opsporen of menen dat fouten niet zo belangrijk zijn omdat we een mening hebben dat het niet hoort te gebeuren.

De oorzaak is heel belangrijk om te weten. Van domweg een fout fixen leer je niets. Je moet de root cause vinden en zorgen dat die fout nooit meer wordt gemaakt. Dan komen er natuurlijk wel weer andere fouten maar stukje bij beetje wordt het steeds beter. Vergeleken met software van een paar decennia geleden is de kwaliteit al stukken beter geworden, zeker als je ook nog eens de veel kortere ontwikkeltijd meeneemt.

"Refactoring" in het jargon...

fouten zijn fouten en deze sluit je niet selectief uit. Als je totaal geen procedures en processen hebt om deze fouten te kunnen detecteren maakt het niet meer uit hoe deze fouten zijn ontstaan, want je weet er niet van. Daarom heb je zaken als reviews, audits en pentests die fouten aan het ligt kunnen brengen. Vervolgens ga je onderzoeken hoe die fout erin heeft kunnen sluipen en zorg je ervoor dat het een volgende keer niet meer gebeurt.

In het geval van dit bedrijf is het hoogstwaarschijnlijk een combinatie van factoren; onwetendheid, geen aandacht voor security, geen reviews, geen pentests, geen audits, tijdgebrek, geldgebrek, noem het maar op. Daarom zijn er allerlei certificaten in het leven geroepen met alle bureaucratische rompslomp eromheen. Die certificeringen zijn geen garantie dat je data 100% veilig is, maar een garantie dat er in ieder geval aandacht is geweest voor gegevensbescherming en er in ieder geval een goede basis is.

Het punt dat ik je duidelijk probeer te maken is dat de fout die hier gemaakt is absoluut nooit had mogen gebeuren omdat dit zo fundamenteel is en zo enorm simpel te detecteren en op te lossen. We hebben het hier niet over een hele lastige 0 day exploit die enkel plaats kan vinden als de zon en de maan in de juiste positie staan op moment van compileren. We hebben het hier over een fout/lek waar je aan alle kanten voor gewaarschuwd wordt welke je kan dichten door 4(!) vinkjes te zetten. Meer is er niet nodig.

Fouten zijn situaties die ongewenst zijn, niet situaties die hoe dan ook voorkomen kunnen worden. Risicos zijn nu eenmaal niet volledig te voorkomen. Ook niet als je had kunnen weten dat dit zwaar ongewenst is. Je kan wel vinden dat het maar voorkomen had moeten worden maar zonder interesse te hebben wat de oorzaak was en een mening te hebben maakt dar nog niet dat fouten niet gemaakt worden. Maar we beginnen nu in circeltjes te discussieren dus hier stop ik de discussie.

Onbegrijpelijk dat deze data opgeslagen wordt op tientallen verschillende websites of onbegrijpelijk dat ie uitlekt?

Nee, onbegrijpelijk dat er:

1. ergens een software techneut van Prestige Software zo'n privacy-gevoellige database niet achter een stel digitale equivalenten van sloten zet.
2. ergens een software techneut van Prestige Software zo'n financieel-gevoellige database niet achter een stel digitale equivalenten van sloten zet.
3. bij een bedrijf als Prestige Software, dat handelt met dit soort data niet, blijkbaar geen Data Security Officer (of hoe je het beestje ook wilt noemen) in dienst is die dit onbedoeld onbeveiligd live zetten had moeten stoppen bij controleren van live gaan.

[Reactie gewijzigd door JumpStart op 9 november 2020 16:27]

Devops techneut, net een iets andere afdeling Al sluit het een het ander niet uit.

In dit geval dus een devoeps techneut

Het issue is juist dat het niet centraal genoeg is opgeslagen en dat verschillende bedrijven het 'anders' doen dan de rest om maar een paar centen te besparen.

Ik vraag mij altijd af... hoe kun je zelf kijken of je hierdoor getroffen bent.

Een betere vraag zou zijn dat als jij hier door schade lijd, wie dat gaat betalen?
Jij als persoon hebt hier niets fout gedaan maar anderen kunnen nu wel je gegevens misbruiken.

Als je cc data wordt misbruikt dan gaat meestal de cc verzekering dat vergoeden, wordt de cc geblokkeerd en krijg je een nieuwe. Ik vermoed zo dat een cc maatschappij dergelijke zaken aan een lopend dossier hangen en vervolgens gaat kijken waar die enorme stapel cc gegevens vandaan komt. In dit geval Agoda, Booking.com en Expedia, die hebben immers een contract met een cc maatschappij die wat zegt over beveiliging van cc gegevens tijdens verwerking. Waarschijnlijk gaan die dan weer verhaal halen bij Prestige Software

Vergoedt de cc maatschappij ook de schade van identity theft?
Er is veel meer dan cc gegevens gelekt: "Het gaat om creditcardgegevens, naam- en adresgegevens, paspoortnummers en e-mailadressen van hotelbezoekers. Ook de details van hotelreserveringen, zoals de kosten, het aantal nachten en aanvullende verzoeken staan vermeld."

Als jij hierdoor schade lijdt kan je dat natuurlijk verhalen op deze personen.

Probleem is het woordje 'hierdoor' ga jij maar eens bewijzen dat door hun lek jij schade hebt opgelopen. Dat is vrijwel niet te doen, zeker niet als kleine consument. Je moet bewijzen dat het hacker x is geweest en bewijzen dat x de data van plaats y heeft.

Kortom kans dat je het ook echt gaat verhalen is nihil.

Een handige tool hiervoor wanneer het ook om emailadressen gaat:
https://haveibeenpwned.com/
of als je het Firefox sausje eroverheen wil (maar is letterlijk dezelfde dienst):
https://monitor.firefox.com/

Ik heb een eigen domein, met heel veel dienst-specifieke e-mail adressen. Is er ook een mogelijkheid om alle e-mail adressen voor het hele domein te checken?

Voorheen kon dat ook op https://haveibeenpwned.com/ maar dat is er, op zich om begrijpelijke redenen, uitgehaald in de online versie. Is er nog een alternatief?

Uh je bedoelt toch gewoon https://haveibeenpwned.com/DomainSearch ?

Thankx!

En damnit.. 7 hits

Thanks!

Gelukkig alleen de 2 bekende hits: Adobe en Dropbox.

Dat werkt helaas alleen als de gegevens bij die sites bekend zijn en als je kan weten dat de gegevens uit dit lek komen als ze via een kopie zijn ontdekt.

Deze breach zit voor zover ik weet nog niet in de database van haveibeenpwned.

@gitaarwerk haveibeenpwned is een mooie website om te kijken of jouw email in een databaselek op is gedoken, voor creditcard data heb ik geen alternatief. Misschien een andere tweaker.

Ben benieuwd hoeveel mensen hun creditcard nummer zouden invullen in zo'n variant.

Vul hier uw CC code in om te checken of deze gehacked is, stap 2 de cvc code

Alleen het creditcard nummer valt nog mee zolang je er geen naam, verloopdatum en CVC code bij hebt. Tenminste, hier in het westen. In sommige landen kun je zelfs betalen met je bankpas zonder pincode in te hoeven voeren dus ik kijk eigenlijk nergens meer van op.

Je kunt mensen laten zoeken op de laatste 4 cijfers bijvoorbeeld

10.000 mogelijkheden hoeveel credit cards zijn er in de wereld?

Ik heb geen CC dat scheelt. Maar ik check 'm inderdaad af en toe. Thx!

De site https://haveibeenpwned.com/ is een start.

De eerste manier is om als klant van deze reserveringsbedrijven of hotels uitleg te eisen dat ze kunnen uitsluiten dat je gegevens er tussen zaten. Ze hebben namelijk een plicht om te weten welke gegevens het betreft.

De andere manier is om bij het bedrijf dat lekte te vragen voor wie ze werkte en uit kunnen sluiten dat je gegevens er tussen zaten.

Hoe dan ook ben je zelfs met de strengere wetgeving over privacy nog heel afhankelijk van wat die bedrijven je willen vertellen, zelfs al gaat het om jou gegevens.

Waarom bedrijven de tools en services niet gebruiken die AWS aanbiedt om dit soort fouten te voorkomen is mij een raadsel.

https://docs.aws.amazon.c...uide/access-analyzer.html
en
https://docs.aws.amazon.c...-block-public-access.html

Kost te veel geld of te veel moeite om in te stellen, want zonder in te stellen werkt het ook toch?

Disclamer: Oogpunt van inrichter of inkoper

Ja of incapabel. Ik heb echt geen idee, want zo moeilijk is het niet als je je er even in verdiept (en dat zou iedereen die hier verantwoordelijk voor is moeten doen)

You don't fix stupid/lazy with tools...

AWS en andere clouddiensten worden maar al te vaak gezien als gemaksproducten. Het is simpel genoeg om er gebruik van te maken zonder verstand te hebben van beveiliging. Dan kan je helaas niet verbaasd zijn dat er grote lekken bestaan. En zolang dit soort bedrijven zo slordig en amateuristich om kunnen gaan met andermans gegevens zonder dat het ze hun inkomsten zwaar treft en ze verantwoordelijk worden gehouden blijf je dit keer op keer houden.

Waarschijnlijk omdat ze hun applicatie eerst voor een ander platform hebben gemaakt, niet met AWS in gedachten, en dus al helemaal niet voor de specifieke tools en services die AWS biedt.

Ik vraag me af hoe dit allemaal werkt in licht van GDPR ? Ik werk met één Spaans platform (nu ja toen we nog reisden...) Travelperk die een disclosure doen van al de derde partijen waar ze mee werken. Heb dit nooit gezien van een booking.com waar ik professionele en privé account heb. Je vult dus je data in en dat gaat zo maar via derde partijen ?

Als booking.com/expedia/etc. partner, kan ik je zeggen dat ze streng zijn voordat je credit cards mag verwerken.
Je moet PCI-DSS en ISO compatibiliteit aantonen.
Dan ben je wel dom om je logs bij AWS te dumpen.

Een hotel wil zijn kamers overal verkopen en gebruikt daarom een channel manager.
Je gaat niet zelf handmatig 50 websites updaten bij een boeking in de nacht om overboeken te voorkomen (overdag natuurlijk ook niet).

Hier worden alle logs met een asynchrone public key op de server opgeslagen.
Je kan er alleen bij met je SSH sleutel en als je de private sleutel hebt.

Sorry, maar als PCI-DSS en ISO van je geeist wordt en je voldoet daar aan met server X, dan ben je gigantisch dom om het niet overal te doen.

Dit wordt een zware straf voor ze.

[Reactie gewijzigd door DJMaze op 9 november 2020 22:16]

"We trust you. Trust Prestige!!" staat echt letterlijk op de homepage

Verkeerd geconfigureerde services en servers komen maar al te vaak voor.
MongoDB heeft in dat opzicht ook fouten gemaakt.
De oorzaken zijn bijna altijd terug te vinden in meerdere voorwaarden, zoals het 'tijdelijk' iets instellen op een testomgeving en vervolgens die instellingen overnemen naar productie. De developer heeft niets verkeerd gedaan, want zijn configuratie draait (hopelijk) in een gesloten omgeving maar de afdeling die het in productie moet nemen, controleert niet altijd even goed. (Procedurele fouten)

In het geval van Amazon services; het lijkt relatief eenvoudig om een omgeving op te tuigen. Een korte cursus over de termen die gebruikt worden en wat ze ongeveer betekenen is meestal voldoende om iets in te richten. S3 buckets kennen een instelling voor 'open en beschikbaar voor iedereen'.

Amazon geeft voldoende voorbeelden en informatie om data veilig op te verwerken. Daarnaast zijn er prima cursussen op internet met goede voorbeelden van hoe en wat om in ieder geval niet in de 'bekende' valkuilen te stappen. Services kunnen prima beveiligd worden, data kan uitstekend versleuteld worden met eigen private keys en alles kan uitstekend gemonitored worden met behulp van door Amazon geleverde diensten.

"Root Cause Analisys"; bijna altijd is een verkeerde configuratie of onduidelijke documentatie van en voor beheerders een oorzaak.

Ik ben 4 jaar geleden op Mallorca op vakantie geweest (nee geen jongeren vakantie, bejaarden hotel ergens op een berg). Geboekt via Booking.com en heb lokaal nogmaals gegevens moeten overhandigen. Twee jaar later kreeg ik een telefoontje van ICS dat iemand een tv probeerde te kopen via een online winkel, vanuit Spanje. Hmmmm zou het met elkaar te maken kunnen hebben...

Daarom altijd zicht houden op wat anderen met jouw credit card of paspoort doen. "Even op kantoor een kopietje maken" accepteer ik niet. Ik stuur wel een zelf gemaakte foto waarbij ik bepaalde gegevens onleesbaar heb gemaakt.

Dat Spaanse bedrijf kan beter gelijk zijn naam aanpassen.

Prestige hoort duidelijk niet thuis in de naam.

Kijkende naar de data is dit opgeslagen in een XML en waarschijnlijk zo aangeboden bij hotels. De reden dat dit op public stond was natuurlijk om het niet al te complex te maken.

Maar ja; qua schade is het al gebeurd. er hoeft er maar 1 tussen te zitten die daar een rip van heeft weten te maken en het staat vol op darkweb fora's.