Pretpark Walibi had lek waarmee aanvallers bij admin-omgeving konden komen

Door een lek in de website van pretpark Walibi was het mogelijk de accountgegevens van 700.000 klanten in te zien. Het ging om gebruikersnamen en in sommige gevallen bijbehorende e-mailadressen. Het lek is inmiddels gedicht.

Het lek bevond zich op de webpagina van het pretpark en van het moederbedrijf, meldt NOS-journalist Joost Schellevis op Twitter. Gebruikers konden een POST-request doen in hun browser en de uitkomst daarvan gebruiken om de browserheader te manipuleren. Vervolgens was het mogelijk de authenticatie van de beveiligde admin-omgeving te omzeilen. In die Drupal-omgeving was het mogelijk gegevens in te zien van klanten van niet alleen Walibi Nederland, maar ook de Franse en Belgische parken. In het admingedeelte van de site waren rond de 712.000 gebruiker-id's te zien. Van sommige gebruikers was ook het e-mailadres in te zien, maar niet van iedereen.

Het lek kwam aan het licht kort voordat het pretpark een responsible-disclosurebeleid in het leven riep. Inmiddels is het lek gedicht. Het pretpark kwam vorig jaar meerdere keren negatief in het nieuws nadat het dreigde met aangifte tegen een ethisch hacker die een kwetsbaarheid op de site vond. Uit serverlogs zou blijken dat de gegevens niet misbruikt zijn. Walibi nam onlangs een nieuw platform in gebruik waar zowel de website als de bestelmodules op draaien. Het pretpark liet die vooraf door een extern beveiligingsbedrijf doorlichten op kwetsbaarheden.

Reacties (42)

Walibi nam onlangs een nieuw platform in gebruik waar zowel de website als de bestelmodules op draaien. Het pretpark liet die vooraf door een extern beveiligingsbedrijf doorlichten op kwetsbaarheden.

Is dit nu echt zo moeilijk om POST data te manipuleren? Want nu heb ik het idee dat het extern beveiligingsbedrijf niet echt goed werk geleverd heeft.

Het kunnen manipuleren van een POST is niet moeilijk.. maar daar zit het probleem ook niet.

De token werd anoniem verkregen door gewoon een token-request te doen naar de desbetreffende endpoint. Volgens de screenshot kreeg je een bearer-token terug, die altijd geldig was.. zonder eerst een key/secret (wel of niet versleuteld) op te geven. Dat ie überhaupt een token terug gaf en ook nog eens geldig was, is dát zit de lek geweest.. niet in het kunnen manipuleren van een header.

Die endpoint had een 401 terug moeten geven ipv. een token.. en een 401 is weer makkelijk op te merken in de console van de browser en had dat beveiligingsbedrijf wellicht wel aan de bel getrokken en zich afgevraagd "wat gebeurt hier". Nu leek alles in orde en hebben ze waarschijnlijk deze succesvolle request op de achtergrond over het hoofd gezien?

Heeft een cliënt secret en id wel zin in een public web app? Dat betekent dat deze clientside bekend moeten zijn (want hoe kan je anders een token verzoek indienen?) en dus relatief eenvoudig te vinden is voor kwaadwillenden. Had dit stuk authenticatie en verificatie niet gewoon totaal server side moeten gebeuren?

Client id's en secrets gebruik ik om die reden alleen voor interfaces tussen server software en zelfs dan gebruik ik liever certificate based of principal based authentication.

Zelfs al encrypt je de secret en id... Op een moment moeten deze over het lijntje en valt het gewoon met fiddler, developer tabs, etc uit te lezen en weet je precies wat de API aan input verwacht om een geldig token terug te geven.

[Reactie gewijzigd door Laurens-R op 2 april 2020 15:26]

Nee, clientside een key/secret meegeven is inderdaad onjuist. Als er een bearer-token nodig is, die clientside moet leven om toegang te krijgen tot bepaalde delen van de website, dan is het de combinatie username/password, welke de gebruiker in geeft en gepost wordt naar de token-endpoint, welke een bearer-token teruggeeft, die jou toegang verschaft tot bepaalde delen van de website...

wat ik er mee wilde zeggen is, dat een dergelijke endpoint nooit tokens mag teruggeven, zonder enige vorm van credentials. Of dat nou een key/secret is, of een authorization code, of combinatie user/pass.. maakt even niet uit.

Ik wil jou nog even aanvullen, op het feit dat die bearer token dus niet verloopt. Volgens het OAUTH principe mist hier nog een token: refresh-token. De bearer token verloopt op een gegeven moment. Bij een volgend verzoek kan de refresh token worden gebruikt om een nieuwe bearer token op te vragen. Als verdere verzoeken uitblijven, verloopt de bearer token en is het exit.

Ik vind het sowieso vaag dat er een grant_type vue bestaat. Ik vermoed dat het een Oauth flow is maar die heeft dat type helemaal niet. Ik kan het mishebben maar het lijkt erop dat moedwillig een extra grant type is toegevoegd, lekker buiten de spec om, om lekker makkelijk vanuit de frontend te gebruiken is.

Heel eenvoudig.
In chrome:
Element inspecteren, naar network tab gaan, en daar zie je alle requests (zo niet, dan even pagina herladen)
Als je dan op een knop klikt of kijkt bij requests die on page load zijn gedaan, dan kan je op de URL klikken en dan zie je alle headers etc.
Vervolgens kan je met bijv Insomnia of Postman die data overnemen en zelf een post request uitvoeren, en de data aanpassen.

Het is lastig te zeggen of zij hun werk goed of niet goed hebben gedaan. Het is natuurlijk makkelijk zeggen. Maar je moet er maar net op gekomen zijn.
Ook moet je rekening houden met Walibi die budget heeft voor 10u security check. Dat dat bedrijf ook 10 uur het systeem bekeken heeft, en daarmee (mogelijk omdat ze juist zo gronding en goed zijn) niet overal aan toegekomen zijn.
Heel makkelijk dus om de schuld bij externe bedrijf te leggen.

Ik weet in ieder geval dat dit soort dingen erg lastig zijn, en dat het moeilijkste vaak is om op het idee te komen om iets te proberen.
Als iemand had gezegd, joh kijk ook eens goed naar die Bearer token of dat oAuth endpoint, dan hadden ze er misschien wel achter gekomen.

Edit: Als dit een known-issue van Drupal was, dan heeft het externe bedrijf wel wat te verwijten denk ik. Want dat zijn een van de eerste dingen die je uitzoekt dan.

[Reactie gewijzigd door jesse! op 2 april 2020 13:20]

POST data manipuleren an sich is niet zo moeilijk, maar je moet natuurlijk wel weten (of bedenken) wat je aan kunt passen en dat daadwerkelijk uitproberen. Ik weet niet of dit een Drupal lek was dat bekend was (en site niet up-to-date) of dat het hun eigen specifieke implementatie is waar een bug in zat.

Er is niet duidelijk wat er uit dat onderzoek is gekomen en zonder te weten wat de opdracht was en of die redelijk was bij de gegeven tijd en geld vind ik het te ver gaan om iets te suggereren. Dat een bedrijf een beveiligingsonderzoek laat doen wil niet zeggen dat je alle fouten maar gaat vinden of dat het onacceptabel voor de opdrachtgever is als ze wel gevonden worden.

Als je een extern beveiligingsbedrijf inhuurt, krijg je over het algemeen waar je voor betaald.

Betaal je weinig, dan doen ze misschien een scan naar SQL injection en XSS + een check dat je niet je wachtwoorden in plaintext opslaat + dat je niet verouderde software gebruikt, zijn ze in een dagje klaar, en houden ze het daarna voor gezien. Dan zitten dit soort lekken er nog gewoon in, maar heb je wel een aanzienlijk deel van de veelvoorkomende lekken gedekt.

Als je alle endpoints wil checken die een website heeft tegen gemanipuleerde data voor zowel lekken als DoS, ben je wel even bezig, en staan daar ook kosten tegenover. Dit zijn er op een standaard Drupal/WordPress installatie al een hoop. Kans is dus dat dit simpelweg niet gebeurd is.

Als je je volledige codebase ge-audit wil hebben dan moet je daar heel wat geld + tijd voor neerleggen, maar zou je wel dit soort dingen eruit moeten hebben.

Uit dit bericht blijkt niet of dit op de nieuwe site of nog via de oude site een probleem was. Gebaseerd op het feit dat dit de sites van alle drie de pretparken en het moeder bedrijf trof kon het wel eens heel goed zijn dat dit een probleem was van de oude site. Veel al zie je dat bedrijven als ze in meerdere landen opereren en een nieuwe site bouwen dit alleen in een land uitrollen om eerst eens te kijken of het allemaal wel echt naar behoren werkt.
Het zou dus heel goed kunnen zijn dat dit een probleem was van de oude site (geen idee of de nieuwe site in Durpal is gemaakt of niet) en dat het dus is "opgelost" door simpel weg de oude site naar de eeuwige bit velden te verhuizen en een hele nieuwe site uit te rollen.

Ik zou dus denken dat dit iets is wat een security audit wel had moeten melden als een risico (een heel groot risico) maar als mijn vermoeden klopt en de nieuwe site een andere is dan waar dit probleem gevonden werd dan is het niet gek dat men dit niet gezien heeft.

Al moet ik wel zeggen dat een security audit nooit alles zal kunnen af vangen. Heel veel dingen natuurlijk wel maar er zijn altijd dingen die ook een security auditor over het hoofd kan zien en om die reden is een bug bounty programma ook zo handig. Nu heb je op eens een heel leger security auditor's die je alleen hoeft te betalen als ze een probleem vinden en die daar naast ook nog eens oneindig door blijven gaan met testen zo lang jij die wortel maar voor hun neus blijft houden zijn er altijd wel een paar mensen bereid om eens een poging te wagen.

Zouden ze hun Drupal niet gepatched hebben tegen een bepaalde exploit? En hoe zit het met andere Drupal sites?

[Reactie gewijzigd door AW_Bos op 2 april 2020 13:59]

Het is geen Drupal probleem Maar een developer die dacht dat de frontend user die ze voor de vueJS frontend implementatie ook admin rechten nodig had.

Adyax is een Drupal agency, en het lijkt erop dat ze voor het gemak hun admin login ook maar gebruiken voor de authenticatie van de rest API calls.

En nog erger, ze hebben een nieuwe grant type toegevoegd buiten de oAuth spec om.

https://twitter.com/Schellevis/status/1245657032792764417

Technische details: je moest een POST-request vanuit je eigen browser onderscheppen en de tekst daarvan toevoegen aan een authorization-header.

Beetje een eigen, waanzinnige implementatie van het oAuth-authenticatiemechanisme, ontdekte tipgever:

Waar haal jij uit dat dit een probleem van Drupal is, en niet een maatwerk implementatie?
Ik ken Drupal totaal niet, dus ik zou geen idee hebben. Vraag mij meer af of dit een known-issue is / was bij Drupal (of bepaalde versies)

Voor de duidelijkheid, het is inderdaad een probleem in maatwerkcode. Drupal is misschien niet de juiste basis voor een site van deze omvang, maar zó lek is het ook niet.

Ik stel niks, het is een vraag...

"het lijkt erop dat" is een stelling en geen vraag 😉. En daarachter een vraagteken zetten, maakt het niet automatisch een vraag.

Heb het aangepast

Oef, dit is wel de zoveelste keer dat Walibi in het nieuws komt omdat ze hun databeveiliging niet op de rit hebben. Het valt me wel op dat er nu weliswaar een externe partij is ingehuurd, maar dat die dus blijkbaar geen issues hebben gevonden. Dat kan betekenen dat de partij niet kundig genoeg was, maar het kan natuurlijk ook zo zijn dat Walibi niet het budget had om een volledige test te laten uitvoeren? Hoe dan ook, ik denk dat ik mijn tickets in de toekomst maar gewoon aan de kassa scoor...

Of er is een bug gevonden die in het verleden nog niet bekend was. Beveiliging onderzoekers weten uiteraard ook niet alles.

Tja, een open admin omgeving is ook een attractie.

Ik ging stuk, made my day!

Waarom wordt dit alsnog gehost online. Er moet toch wel degelijk een betere manier zijn om data van klanten niet zomaar vrij te geven.

Omdat dit over meerdere locaties gaat. IP whitelist kan wel, maar is ook lastig te onderhouden als je een wisselend IPv4 adres hebt (wat steeds vaker voorkomt tegenwoordig)
Ook kan het dan zijn dat je een IPv4 adres deelt met een ander netwerk. En dan verklein je het probleem wel, maar los je het niet op.

Ook willen mensen kunnen thuis werken, vooral in tijden als nu. Een VPN is dan een oplossing.
Maar dit moet allemaal weer geimplementeerd en onderhouden worden.
Terwijl er in principe niets mis mee is om het online te hebben, zolang je het maar goed beveiligd.
Daarnaast, als je het echt niet online wil hebben dan moet je dat op locatie hebben. Maar het moet toch gesynct worden met andere locaties.
Onderhoud en updates e.d. worden veel lastiger aan het systeem.

Prijskaartje zal ook omhoog gaan. Plus dat bepaalde onderdelen voor iedereen toegankelijk moeten zijn (zoals kaartverkoop) en dus wel online moet staan.
Om dat systeem dan weer te splitsen kan ook erg lastig zijn.

Gemak, snelheid en geld zijn hier denk ik grotere aandelen in dan privacy / online-veiligheid voor de gebruikers/klanten

Dyn DNS verhelpt het probleem met wisselende IPv4 addressen.

Maar gaat je niet helpen met het whitelisten van ip adressen

Mijn opdrachtgever heeft een Dyn DNS provider waarbij er voor mij een account is aangemaakt en met bij van een stuk software mijn IPv4 adress wordt allowed.
Had bij de laatste werkzaa,heden vna ZIggo dat mijn IP-adres veranderde.
Heb toen DUC software van No-ip.com moeten draaien en daarna werkte het weer vlekkeloos.
Geen gezeik dat ik op de firewall in het DC mijn eigen IP steeds moet allowen.

Weet er het fijne nog niet van omdat de senior systeembeheerder dit in beheer heeft.

Dat doen ze ook niet. Het is prima online te doen, maar dan moet je wel een fatsoenlijke beveiliging inbouwen

Een username, en soms een email waar de user email als username gebruikt.

Als je hier elke userID zou scrapen inclusief profiel pagina, heb je hetzelfde

De link van "Joost Schellevis op Twitter" werkt niet

Ik gok dat ze deze link bedoelen : https://twitter.com/Schellevis/status/1245657021937897480 of algemeen zijn profiel : https://twitter.com/Schellevis

[Reactie gewijzigd door Tomsworld op 2 april 2020 13:03]

Die is ook heel mooi https://tweakers.net/LINK . Zal wel gauw gefixt worden.

En die kun je bij de feedback kwijt (zojuist gedaan).

Thanks, toegevoegd.

Semi off-topic maar moest even gniffelen bij het plaatje van Rollercoaster tycoon dat bij het twitter bericht hierover zat.

Heeft deze onderzoeker wel vrij kaartjes gehad of is er opnieuw gedreigd met aangifte?

Bij het vorige nieuws vroeg ik mij al af hoeveel kaartjes een hack als dit waard is t.o.v. een "gratis" kaartje kopen.
Daarom vind ik kaartjes niet op zijn plek, hiervoor zou diegene een all-time pass voor de hele familie moeten krijgen.

Ik vraag me af of Walibi nu extra gepest wordt door hackers nadat ze de vorige keer zo gemeen deden.

Hé jongens, laten we vanavond plezier hebben! Mijn sexy foto's en contacten hier >> http://badose.ml/lukassiery Meld je aan en vind me.