Duizenden persoonsgegevens toegankelijk door lek in webshopplatform

Door een lek in het webshopplatform van mijnwebshoppartner.nl waren duizenden persoonsgegevens voor iedereen toegankelijk. Na mijn CVD-melding op 18 september wist de leverancier het lek binnen een aantal dagen te dichten, maar schitterde vervolgens door afwezigheid. Het betrof een unauthenticated Insecure Direct Object Reference (IDOR) kwetsbaarheid, waardoor gegevens van ruim 7200 webshopklanten makkelijk toegankelijk waren.

Ik stuitte op deze kwetsbaarheid toen ik zelf iets bestelde bij een van de aangesloten webshops. Na het plaatsen van een bestelling werd er automatisch een account aangemaakt en was ik automatisch ingelogd. Toen ik mijn eigen accountgegevens wilde inzien, viel mijn oog op een specifieke URL die ik in de netwerkmonitor van Firefox voorbij zag komen: /action/account.php?a=getClientDetails&id=2389.

Wanneer ik deze URL handmatig benaderde via de browser, kreeg ik mijn gegevens in XML formaat te zien.

Door het wijzigen van het nummer “2389” in een lagere waarde, kreeg ik de gegevens van een andere klant te zien die al eerder een bestelling had geplaatst. Het nummer na mij (2390) werkte pas enige tijd later, waardoor ik makkelijk kon concluderen dat klantnummers oplopen en telkens met een increment van 1 worden toegekend.

Toen ik Burp startte om de Intruder aan het werk te zetten, viel op dat de URL ook werkte zonder ingelogd te zijn met mijn eigen webshop account. Je hoefde dus niet geauthenticeerd te zijn om klantgegevens (van anderen) op te vragen, wat de ernst van deze kwetsbaarheid verder deed toenemen.

Het onderstaande screenshot laat zien dat het relatief gemakkelijk is om alle klantgegevens geautomatiseerd op te vragen. Met specifieke software of een script, is een kopie van het volledige klantenbestand snel gemaakt. Dat is een kwestie van een paar minuten.

Dankzij “Powered by” teksten op de webshop, vond ik met Google nog 3 andere webshops die op hetzelfde platform draaien. Met de eerder genoemde URL kon ik ook bij deze webshops alle klantgegevens opvragen. Zonder in te loggen. In totaal ging het om 7232 records met persoonsgegevens waaronder NAW, telefoonnummer, e-mailadres, en BTW-nummers. Bedenk hierbij dat BTW-nummers in bepaalde gevallen ook iemands BSN kunnen bevatten.

Ik hoop dat de leverancier in staat is geweest om een datalek uit te sluiten. Bijvoorbeeld op basis van beschikbare loggegevens. Wanneer dit niet redelijkerwijs kan worden uitgesloten, zullen de 4 webshops in kwestie binnen 72 uur melding moeten maken van een datalek.

Het lijkt me daarnaast ook verstandig wanneer de ontwikkelaars van het webshop platform zich wat verder verdiepen in de OWASP Top 10. Dit overzicht met de 10 meest voorkomende kwetsbaarheden in webapplicaties is er al vele jaren en dat is niet zonder reden. Deze specifieke ‘Insecure Direct Object Reference (IDOR)’ kwetsbaarheid heeft jaren lang onder deze benaming in de Top 10 gestaan, totdat deze in 2017 met een andere kwetsbaarheid werd samengevoegd onder de noemer ‘Broken Access Control‘.

Teleurstellend optreden leverancier MijnPartnerGroep.nl

Op zoek naar een handige plek om mijn kwetsbaarheid te melden, zocht ik op de website naar een e-mailadres. Het viel hierbij op dat de links naar Algemene voorwaarden, Verwerkingsovereenkomst, Privacy policy en Diclaimer niet werkten en op moment van schrijven nog steeds resulteren in een 404 error. Op de contactpagina trof ik een e-mailadres voor het doen van abuse meldingen. Die leek me het meest geschikt, dus op vrijdagmiddag 17 september om 15:00 mailde ik de Coordinated Vulnerability Disclosure melding. Mijn voornemen tot publicatie (na het verhelpen van de kwetsbaarheid) heb ik duidelijk aangegeven.

Omdat ik geen bevestiging kreeg, en de website niet bepaald de indruk wekte dat zaken goed voor elkaar waren, besloot ik zaterdag 18 september dezelfde mail te forwarden naar het e-mailadres van de sales afdeling. Binnen een half uur kreeg ik een reactie terug: “Bedankt voor het melden. Ik heb het doorgestuurd naar de desbetreffende afdeling. We komen er op terug bij je.” Kijk, daar was ik naar op zoek. Nu wist ik in ieder geval dat het bericht was aangekomen.

Op maandag 21 september ontdek ik dat het probleem rond 11:00 is verholpen. Misschien ben ik ongeduldig, maar ik verwachtte op diezelfde dag eigenlijk nog een terugkoppeling. Toen deze terugkoppeling niet kwam, reageerde ik dinsdagmiddag 22 september op de eerder ontvangen e-mail: “Dank voor je bericht. Ik heb gezien dat het probleem maandagochtend is verholpen, maar heb hier nog geen terugkoppeling over gehad. Kun jij dit bevestigen?” Een paar uur later ontving ik het volgende bericht: “We komen hier nog inhoudelijk deze week op terug bij je.” Misschien was ik inderdaad wat ongeduldig, dus ik besloot het af te wachten.

Toen ik vrijdag 25 september aan het einde van de dag nog steeds niks had gehoord, besloot ik weer te mailen: “Klopt het dat ik nog niks heb vernomen?” Geen reactie. Maandag 26 september halverwege de middag een nieuwe mail gestuurd: “Het blijft stil en het is me niet duidelijk waarom. Het probleem lijkt namelijk te zijn verholpen. Graag jullie reactie.” Ook hierop ontving ik geen reactie, waardoor ik uiteindelijk besloot om op 1 oktober tot publicatie over te gaan.

Update 09-10-2020: Ontbrekende terugkoppeling van MijnPartnerGroep.nl gevolg van e-mail probleem

Vanmiddag (9 oktober) ontving ik alsnog een reactie van leverancier MijnPartnerGroep.nl. Dit maal vanuit een Gmail-adres, omdat eerder verstuurde e-mails volgens de leverancier niet bij mij werden afgeleverd. Ik ben uiteraard meteen op onderzoek uitgegaan. Uiteindelijk kwam ik op twee redenen waardoor mails van de leverancier na 24 september niet in mijn mailbox terecht kwamen:

1. Op 24 september heb ik de TLS configuratie van mijn primaire mailserver aangescherpt in lijn met de TLS richtlijnen van het NCSC. Hoewel uit handmatige uitgevoerde tests met testssl.sh blijkt dat er wel degelijk een overeenkomstige cipher is tussen mijn primaire mailserver en de mailserver gebruikt door MijnPartnerGroep.nl, blijkt dit (om nog onduidelijke reden) in de praktijk te mislukken waardoor de STARTTLS handshake faalt. Hierdoor komt er geen verbinding tussen beide mailservers tot stand en resulteert het mailtransport in een error.
2. Als gevolg van deze gefaalde poging wijkt de door de leverancier gebruikte SMTP server uit naar mijn secundaire mailserver. Deze server kent qua ciphers een iets soepelere instelling, maar kende een ander probleem. De ClamAV service was gecrashed waardoor de interne mailflow niet meer functioneerde, met als gevolg dat e-mails bleven hangen in de queue.

Ik heb dit uitgelegd aan de leverancier en uiteraard aangegeven dat ik door deze zeer onfortuinlijke samenloop van omstandigheden in de veronderstelling was geraakt dat ik na initieel contact bewust werd genegeerd. Onterecht blijkt nu, want ik heb in de logs op mijn secundaire mailserver gezien dat er inderdaad is geprobeerd te mailen. Dit doet weliswaar niks af aan het door mij aangetroffen lek, maar ik vind het wel zo netjes om terug te komen op de door mij gebruikte woorden “teleurstellend optreden”. Achteraf gezien is dit niet juist, maar omdat mijn bericht al is overgenomen door andere media, laat ik de tekst hierboven in doorgestreepte vorm staan.

Toen er eenmaal contact was, verliep de inhoudelijke afstemming met MijnPartnerGroep.nl naar tevredenheid. Hoewel de leverancier bij voorkeur de tekst van deze blogpost voor publicatie had willen afstemmen om wenselijke nuances aan te brengen, sprak men wel de waardering uit voor de gedane melding en de energie die ik erin heb gestoken. Positief is in ieder geval dat er vanaf vandaag een security policy op de website gevonden kan worden. Dat gaat bij nieuwe meldingen ongetwijfeld helpen.