Bioscoopketen Vue lekt privégegevens en bankrekeningnummers van bezoekers

Bioscoopketen Vue had te maken met een lek op zijn website, waardoor de gegevens en IBAN-nummers van alle bezoekers waren in te zien. Dat meldt RTL Nieuws op vrijdagmiddag. Het lek is inmiddels gedicht, zo zegt een woordvoerder van het bedrijf.

Het lek werd veroorzaakt door een fout in de website van Vue, zo schrijft RTL Nieuws. Daardoor kon de broncode van de website volledig worden ingezien, inclusief bestanden die normaliter zijn afgeschermd. Daardoor waren ook de secret keys van de database van het bedrijf en de dienst die betalingen verwerkt zichtbaar.

Met het lek waren volgens RTL Nieuws 'miljoenen' transacties van Vue in te zien, inclusief namen en bankrekeningnummers. Het nieuwsmedium controleerde de transacties van een willekeurige dag en trof daar bijvoorbeeld ruim 3400 transacties aan, inclusief de namen en bankrekeningnummers. Ook gegevens over de profielen van Vue-bezoekers waren zichtbaar, waaronder woonadressen, geboortedata en e-mailadressen.

De kwetsbaarheid werd ontdekt door programmeur Sten Lankreijer; hij trof de kwetsbaarheden aan omdat hij zelf wel eens naar een Vue-bioscoop gaat en de website van de bioscoopketen inspecteerde. Lankreijer heeft melding gemaakt bij Vue. De bioscoopketen laat aan RTL Nieuws weten dat het lek inmiddels is gedicht. Volgens de bioscoopketen heeft alleen Lankreijer toegang gehad tot de gevoelige data. Er zijn volgens Vue geen gegevens openbaar gemaakt. Het bedrijf gaat melding van het datalek doen bij de Autoriteit Persoonsgegevens.

Reacties (86)

[slaay]

"Het nieuwsmedium controleerde de transacties van een willekeurige dag en trof daar bijvoorbeeld ruim 3400 transacties aan, inclusief de namen en bankrekeningnummers. Ook gegevens over de profielen van Vue-bezoekers waren zichtbaar, waaronder woonadressen, geboortedata en e-mailadressen."

en dan vervolgens:

"Volgens de bioscoopketen heeft alleen Lankreijer toegang gehad tot de gevoelige data."

Kortom, niet allleen Lankreijer heeft toegang gehad, maar ook RTL Nieuws!

[FONfanatic]

En de bot van Google niet dan?

[SuperDre]

OF, Lankreijer heeft de data die hij gedownload heeft ter beschikking gesteld aan RTL Nieuws... In dat geval mag meneer Lankreijer wat mij betreft dus rustig vervolgd worden immers had hij de data gewoon moeten verwijderen. En anders zet ik sowieso vraagtekens bij waarom hij meteen naar de media is gestapt zonder eerst te wachten tot Vue het probleem had opgelost of met hem had overlegt.

[kozue]

Nou nou, al dat azijnpissen hoeft niet hoor. Er staat toch nergens dat ie data heeft gelekt? En dat ie het gemeld heeft aan de Vue staat *letterlijk* in het artikel. Heb je een hekel aan security onderzoekers die gratis op eigen initiatief websites inspecteren ofzo? Of ben je boos dat het lek nu opgelost is?
Ik lees nergens slechte bedoelingen…

[kozue]

Nog meer aannames
Ik lees hier niks over dat hij de data bewaard heeft. Een aantal records noemen is niet hetzelfde als data bewaren. En het lek *is* toch opgelost? Hoe kom je erbij dat ie naar de media is gestapt voordat het opgelost was?

[Aldy]

Ik ben het volledig oneens met @SuperDre , laat ik dat voorop stellen, maar uit het verhaal lees ik ook dat Lankreijer naar RTL is gestapt voordat het was opgelost. RTL heeft namelijk ook een bepaalde dag kunnen inkijken, dus toen was het nog niet opgelost. Verder vind ik dat er veel meer mensen zoals de heer Lankreijer moeten zijn.

[FerronN]

Een bestand met database credentials. Dat is niet heel fris. Van zo'n club zou je toch een goede inrichting verwachten met een keyvault of iets dergelijks.

Natuurlijk kun je deze weer naar een bestand schrijven, maar dat heeft nooit de voorkeur.

Blijkbaar was de database ook nog via het internet te benaderen. Dat hoort ook niet...

[Reactie gewijzigd door FerronN op 22 juli 2024 15:35]

[kozue]

Tis altijd makkelijk wijzen naar anderen. Maar bedenk je eens hoe een applicatie bij z’n database moet komen? Ergens moeten credentials staan, want de website moet in de database kunnen schrijven. Dat werkt dus niet even met een “keyvault”, en ik hoop vooral niet dat er iemand iets over 2-factor gaat roepen, want dat kunnen servers niet.

Uiteraard horen die credentials niet in de broncode te staan, dat is heel slordig. Dat hoort ergens in een config bestand wat alleen de server zelf kan lezen (buiten de webroot), of environment variables ofzo. Maar niet iedere programmeer omgeving heeft daar nette standaarden voor.

Van bv php ben ik gewend dat je gewoon een directory met code in je webroot dumpt, en dat is dan je applicatie. Inclusief config file met credentials, die je dan in je webserver config expliciet ontoegankelijk moet maken via bv htaccess. Zoiets past allang al niet meer in een moderne webapplicatie. Iets als ruby on rails gaat daar veel beter mee om. Daar is alleen je /public directory je webroot, en je applicatie staat er helemaal buiten. Plus dat credentials encrypted opgeslagen (kunnen) worden. Maar zoals met alles moet je server ze uiteindelijk nog steeds kunnen lezen, dus is dat meer voor je source control (bv git) belangrijk, want de decryption key moet toch ergens op die server staan.

Dat een database direct vanaf het internet bereikbaar is verbaast me tegenwoordig niet zo veel. Steeds meer bedrijven gebruiken cloud omgevingen. Daar krijgt een VM vaak bij het aanmaken direct een publiek IP adres en als je luie developers hebt die de moeite niet nemen dat IP adres weg te halen en een lokaal subnet opzetten, heb je je lek al. Teveel bedrijven denken dat de cloud iets magisch is wat alles goed voor je regelt Het hoort niet zo, maar is wel de praktijk. Vooral bij bedrijven waarbij IT niet hun core business is. De Vue is op de eerste plaats een bioscoop, geen IT toko.

[FerronN]

Een keyvault kan prima en ook zonder dat ergens credentials staan. In Azure kun je bijvoorbeeld met een managed identity verbinden naar de keyvault en of direct naar de database.

En MFA werkt ook op een Azure database I.c.m. een Azure AD account.

In andere clouds zullen soortgelijke oplossingen bestaan.

Het klopt dat databases zo aan het internet gehangen kunnen worden in de cloud, maar een ip whitelist helpt al een stuk als je geen private network wil opzetten.

In andere woorden. Alle punten die jij noemt kunnen in de moderne wereld van vandaag prima ondervangen worden.

[kozue]

Ja hoor, het kan allemaal opgelost worden, maar dat kost moeite en doet dus niet iedereen.

Maar wat je zegt over die identity doet er niet toe. Je hebt dan de credentials van je identity nodig in je app. Hoe dan ook zal ie ergens op in moeten loggen zonder tussenkomst van een mens. En voor jou als mens werkt 2fa wel, maar voor een server niet.

[davince72]

DMZ ? Scheiding tussen client en server? Dit is gewoon onacceptabel, ook voor een bioscoop. Welke dienst zie jij dan wel als IT toko die security op orde zou moeten hebben? Precies, elke dienst gebruikt IT en is van zichzelf niet een IT toko, maar hebben wel de verantwoordelijkheid veilig met je gegevens om te gaan.

[Tonkie1967]

Dat het je niet verbaast dat een database server rechtstreeks via internet te benaderen is wil niet zeggen dat dat professioneel is: als je als bedrijf (zoals vue) een website laat bouwen die e-commerce transacties incl betalingen verwerkt mag je juist toch verwachten dat basis zaken als afschermen van de databases onderdeel is van de dienstverlening...
Dat iedereen zo graag alles op de cloud doen vind ik al langer zorgelijk... Zoals alle security scan data dat verzameld word door scammers "raw" uploaden naar 'de cloud ' om mooie rapporten in Kenna te kunnen zien..... Alle voorstanders van dit massaal scannen van netwerken en de data in de cloud te zetten vertrouwen blijkbaar blind op de cloud providers alles voor elkaar heeft, maar je hebt er nul invloed op of inzicht in.... Niet dat alles on prem houden perse beter is, maar het vertrouwen in de cloud verbaast me meer en meer

[Yggdrasil]

Alle bekende PHP frameworks zetten hun code buiten de webroot hoor.

Ook het gebruik van versleutelde database wachtwoorden in een config file is normaal gedrag.

[TabCam]

Ik mag hopen dat ze het door een software engineer laten schrijven. Het Is geen IT toko maar je hebt wel de verantwoordelijkheid voor de persoonsgegevens en dan hoop ik dat ze het goed hebben 'gedelegeerd'.

Dan is wat mij betreft , en volgens mij ook van de wet, de ontwikkelaar degene die de verantwoordelijkheid heeft, die kennis mag je niet bij de opdrachtgever verwachten.

Dat de database direct van het internet toegankelijk is, is ook niet nodig, deze hoeft alleen vanaf de server bereikbaar te zijn. Dat vereist wel goed beheer. Dat kost geld en dan sneuvelt de veiligheid al snel.

Wat mij betreft mogen ze dit soort lekker financieel veel flinker mogen afstraffen zodat beveiligen 'loont'.

[Webgnome]

Van zo'n club..

Je weet dat dit een bioscoop keten is en dat hun primaire doel dus niet is om websites te ondersteunen etc? Wie weet hebben ze dit uitbesteed ? Of is dit nog een site uit de tijd dat het neefje van de eigenaar wel zei dat ie iets kon?

[FerronN]

Dat zou inderdaad kunnen. Als je met gevoelige gegevens werkt zou je verwachten dat men daar zeer zorgvuldig mee omgaat. Helaas blijkt vaak toch het tegenovergestelde waar.

[Oon]

Het probleem is dat heel veel bedrijven überhaupt niet inzien dat ze met gevoelige gegevens werken..

Regel 1 van eCommerce is gewoon geen betaalgegevens opslaan. Dat laat je een partij als Mollie, Skrill, Stripe, Adyen etc doen, die worden daar meerdere keren per jaar op geaudit omdat hun core business het veilig opslaan en verwerken van betaalgegevens is.

[OptimusPrima]

Regel 1 van eCommerce is gewoon geen betaalgegevens opslaan.

Nagenoeg iedere winkelketen die online actief is heeft een klantensysteem voorzien van transactie historie met de mogelijkheid om betaalgegevens te wijzigen. Daarnaast hebben bedrijven een wettelijk bewaartermijn voor financiele transacties. Mogelijk dat je verwijst naar de wettelijke kaders (o.a. PCI-DSS) die gelden voor betaalproviders, waar meer aandacht is voor het scheiden van betaalgegevens.

Ik zie meer heil in het verfijnen van de geldende wettelijke kaders en het uitbreiden van capaciteit bij de toezichthouder (AP), zodat zij de cyberveiligheid van bedrijven die in grote getale en/of gevoelige persoonsgegevens verwerken periodiek kan doorlichten. Nu geldt er alleen een piepsysteem en slokken de reuzen als FAANG alle capaciteit op. Ook komt de AVG op het gebied van het specificeren van technische maatregelen niet veel verder dan 'pas adequate beveiligingsmaatregelen toe'.

[Oon]

Daarnaast hebben bedrijven een wettelijk bewaartermijn voor financiele transacties.

Ze moeten bewaren wie een bepaalde factuur/nota heeft betaald ja, niet alle bankinformatie van die persoon. Er is geen enkele wet die je verplicht stelt om onnodig bankinformatie op te slaan, in tegendeel zelfs, de AP verbiedt het.

Het gebruiken van een payment provider is gewoon 9/10 keer de beste keuze.

[ro4sho]

De Iban opslaan is niet nodig voor de keten zelf.

[Anomnomnomymous]

Dat is omdat de boetes nihil zijn voor dit soort overtredingen.

Ik vraag me ten eerste af wat ze sowieso met betaal gegevens van mensen/klanten moeten - je betaalt, betaling geverifieerd, je krijgt een ticket/nummer: wat moeten ze dan nog met die gegevens?

[The Zep Man]

[...]


Je weet dat dit een bioscoop keten is en dat hun primaire doel dus niet is om websites te ondersteunen etc? Wie weet hebben ze dit uitbesteed ? Of is dit nog een site uit de tijd dat het neefje van de eigenaar wel zei dat ie iets kon?

Als bioscoopbezoeker heb je geen relatie met een onderleverancier of het neefje van de eigenaar. Vue blijft verantwoordelijk en mag daarop aangekeken en -gesproken worden.

[Frame164]

Als ze het hebben uitbesteed aan een bedrijf met verstand van zaken is dat te preferen. Een bioscoopketen zou zich hier niet mee bezig moeten houden. Ze hebben ook geen drukkerij voor de poster of bierbrouwerij voor het bier dat ze verkopen. Ieder z'n vak. Ben ook wel benieuwd of de verantwoordelijke developer ook wel eens op deze site komt. Hier weten we immers allemaal hoe het moet.

[ydd1987]

Als ze dit hebben uitbesteed FerronN zijn comment nog steeds van toepassing; van een club die websites maakt mag je meer verwachten. Dus juist als het uitbesteed is, is het extra schrijnend.

[bytemaster460]

Dat wordt uitbesteed aan een IT-bedrijf en dan verwacht je JUIST dat het goed geregeld is.

[Finraziel]

De website van Vue is best wel goed hoor, dat is echt niet 10 jaar geleden door een amateur in elkaar geschroefd.

[PolarBear]

Een bestand met database credentials. Dat is niet heel fris. Van zo'n club zou je toch een goede inrichting verwachten met een keyvault of iets dergelijks.

Nou ja zelfs dan een web.config in de ASP.Net wereld waar je dat zou kunnen opslaan (even los of dat een goed idee is) zou je niet zomaar moeten kunnen benaderen.

Blijkbaar was de database ook nog via het internet te benaderen. Dat hoort ook niet...

Nee dat is ook vreemd inderdaad.

[KeesAlderlieste]

Je kan 'm ook niet zomaar benaderen, IIS blokkeert 't downloaden van web.config (of elke willekeurige .config), daar kan je alleen bij als je toegang hebt tot 't filesystem.

[captain007]

Ik heb het ook wel eens gezien bij een foutmelding op een site van de rijksoverheid dat er gewoon een .NET exceptie met connectionstring gegevens voorbij kwam. Alleen daar kon je tenminste niet fysiek de database in, omdat dat wel dicht stond. Die moeite hebben ze hier blijkbaar nog niet eens genomen....

[thomas_n]

Volgens de bioscoopketen heeft alleen Lankreijer toegang gehad tot de gevoelige data

Vertaling: Lankreijer is de enige dit ons heeft verteld dat hij toegang tot de gevoelige data had.

Een crimineel die deze beveiligingsfout eerder ontdekt kan hebben, meldt dat natuurlijk niet netjes.

[TommySprat]

Mogelijk hadden ze access logging wel in orde en kunnen ze die claim onderbouwen, tenminste tot hoe ver de access log teruggaat.

[kozue]

Als ik het voorbeeld hierboven zo zie gaat een access log je niks helpen. Je ziet dan alleen aanroepen naar de thumbnailer, dat hoort bij standaard functionaliteit die iedere bezoeker aanroept. De complete argumenten staan eigenlijk bijna nooit in zo’n log. Hooguit in een applicatielog. Bovendien bewaart niemand die oneindig. Meestal een week of 2 tot een maand, dan roteren ze verder.

[davince72]

Hoezo staan query parameters niet standaard in de access log?

[KoudeAardbei]

Ben heel benieuwd wat de fout is geweest die zo massaal te exploiten was. SQL injecties komen met nieuwe frameworks bijna niet meer voor, dan moet je het wel behoorlijk bont maken.

[Jeffrey_KL]

Staat zo'n beetje in het artikel wat de fout was. Waarschijnlijk configuratie fout op de webserver waardoor de config bestanden rechtstreeks opgevraagd konden worden net zoals een normale web pagina.

Dit zou op zich geen probleem moeten zijn als de database ook netjes was afgeschermd.

[Cyb]

In het artikel (van RTL, en gek genoeg niet in het Tweakers artikel, dat juist op zijn minst net zo technisch zou moeten zijn) wordt SQL injecties wel degelijk genoemd, maar dat was meer een aanvullende kwetsbaarheid.
En het ging niet om het rechtstreeks opvragen, maar indirect via een thumbnail functionaliteit.

Het ziet er ook gewoon slordig uit:

<img alt="{{title}}"
src="{{base}}/thumb?w=268&f=auto&src={{image_relative}}&alt=img/movie_placeholder.png"
srcset="
{{base}}/thumb?w=268&f=auto&src={{image_relative}}&alt=img/movie_placeholder.png 268w,
{{base}}/thumb?w=591&f=auto&src={{image_relative}}&alt=img/movie_placeholder.png 591w
"
sizes="(max-width: 799px) 268px,591px"
width="268"
height="382"
class="movie-poster"
>

Template functionaliteit mixen met URL routing/constructie.....

Er wordt verder gebruik gemaakt van Handlebars.js lijkt het.

[Reactie gewijzigd door Cyb op 22 juli 2024 15:35]

[GertMenkel]

Zo erg vind ik dit er eerlijk gezegd niet uitzien. Je backend moet natuurlijk wel in orde zijn (beperkt tot alleen de map met static inhoud en geen gedoe met path traversal) maar qua frontendcode vind ik dit niet zo heel erg.

Of je je variabelen nou met 2MB aan Javascriptroutingdependencies concatenate, het in de backend doet, of er een template voor gebruikt, de frontend is hier het probleem eigenlijk gewoon niet.

[Stenlan]

De database stond netjes achter een NAT hoor, en het CMS achter een IP whitelist. De database credentials waren weliswaar in te zien, maar niet direct te gebruiken. Maar de IP whitelist was te bypassen en vervolgens kon je met SQLi admintoegang tot het CMS verkrijgen, waarna de kous natuurlijk af is. In het CMS is alles te zien, maar via een file upload (gewoon een feature binnen het CMS) kan je ook een PHP shell uploaden met alle gevolgen van dien.

Voor het inzien van transactiegegevens was de path traversal alleen al genoeg, deze werden namelijk ook naar een logfile geschreven.

[elmuerte]

SQL injecties komen met nieuwe frameworks bijna niet meer voor

Met de frameworks van 20 jaar geleden ook niet. Maar ja...

[bytemaster460]

Lijkt me goed wanneer dit soort bedrijven helemaal geen namen meer gaan opslaan. Het is helemaal nergens voor nodig om namen te registreren als je bioscoopkaartjes verkoopt.

[divvid]

Precies. Vroegah, kon je gewoon een kaartje reserveren onder Pietje puk en contant betalen. Elders in Europa kan dat ook nog gewoon, net als anoniem met de trein een kaartje bij de conducteur kopen zonder lullige toeslagen etc. Tijd voor Nederland om te ontloggen

[kozue]

Ik ben sowieso allergisch voor digital footprint en dit soort artikelen bewijzen keer op keer weer waarom. Er wordt op al die online troep altijd veel te veel data gevraagd en veel te lang bewaard. Zo heb ik bv een gruwelijke hekel aan die verplichte telefoonnummer velden overal. Bijna niemand hoeft me te kunnen bellen. Als ze contact op willen nemen doen ze dat maar per email. Daar kan ik tenminste aliasen aanmaken. Dus krijgen ze standaard 0612345678 in hun “verplichte” veld. Wegwezen met je datahonger.

Maar voor wat betreft de bioscoop: mijn gegevens hebben ze niet in hun systeem staan. Ik reserveer nooit (de bios zit toch nooit meer helemaal vol tegenwoordig), en betaal aan de balie contant. Niemand die weet dat ik daar ben geweest. De bios zelf niet, de bank niet, al die tussenbedrijfjes in de geldstroom niet (currence, maestro, ccv, etc), en belastingdienst niet, etc.
Het mag allemaal best wat minder met de digitale datahonger.

[MrMonkE]

Maar je telefoon provider en (android)google/(apple)iPhone weten het wel?
Maar ik deel je afkeer van het loggen en volgen.

[Buntuhein]

Volledig met je eens. Voor de diverse logins gebruik ik ook steeds meer de 'verberg mijn emailadres' functie van Apple. Was wel grappig om te zien dat (puur bij toeval) iets van 'zwemmers' in de email werd gebruikt bij een waterpark. Vooral voor eenmalige accounts/logins is dat een prima optie. Zo komt ook je echte emailadres niet op straat te liggen.
Wat mij betreft hoeft niemand mijn naam en (email)adres te hebben voor een simpel kaartje.

[mongkut]

Je zou er bijna een film van maken

[Diagoras]

Er zijn volgens Vue geen gegevens openbaar gemaakt. Het bedrijf gaat melding van het datalek doen bij de Autoriteit Persoonsgegevens.

Dat gaan ze nog doen? Gezien dat binnen 72 uur na kennisname moet, kan ik me niet voorstellen dat het nog op tijd is.

[Anoniem: 1576590]

Diagoras schreef:

Dat gaan ze nog doen? Gezien dat binnen 72 uur na kennisname moet, kan ik me niet voorstellen dat het nog op tijd is.

Vooral niet omdat de AP dit weekend gesloten is (wegens onderhoud)

[Tusk]

"Volgens de bioscoopketen heeft alleen Lankreijer toegang gehad tot de gevoelige data."

tuuuuurlijk....

Zo zie je maar weer. Je kunt nog zo je best doen om je data te beschermen met aliasen en adblockers, maar door dit soort gestuntel ligt gewoon alles op straat.

[Martijntjeh]

Lekker dan. Volgens mij is het niet mogelijk om je account bij Vue te verwijderen (?)
En dat zou wel mogelijk moeten zijn toch?

[dutchgio]

Dat is nu al te laat natuurlijk. Het lek is gedicht dus dat kan men geen gebruik meer van maken.
En als een aanvaller er wel eerder bij kon zijn die gegevens al lang geëxporteerd.

[TNAC]

Daar is gewoon een knop voor.

Net zoals er een knop is om een rapport met je persoonlijke gegevens te downloaden.

Daar staan geen bankrekeningen of andere betaalgegevens op overigens, evenmin staan er adressen in, enkel een postcode (mits ingevuld, niet verplicht).

[TweakerCarlo]

Is het een website van Vue of word Vue.js gebruikt? Mogelijk haal ik hier iets door elkaar.

[Reactie gewijzigd door TweakerCarlo op 22 juli 2024 15:35]

[GewoonYunus]

Het is de website van Vue bioscopen (vuecinemas.nl), dat is weer wat anders dan het Javascript-framework

[TweakerCarlo]

Lezen is ook een vak. Thanks en excuus voor deze rare post.

[Janusch]

Ik wilde een flauw grap maken over Vue.js, maar eerst CTRL-F gedaan...

[TweakerCarlo]

Saved by the bell.