Een gebruiker verkreeg zonder toestemming toegang tot een repository van Zapier. De oorzaak: een 2FA-misconfiguratie. Omdat Zapier-klantendata perongeluk in repositories was gekopieerd, contacteert de maker van de gelijknamige automationtool het deel van het klantenbestand dat door het lek geraakt is.
Afgelopen donderdag had Zapier het lek voor het eerst in de gaten. Het hief de toegang voor de niet geautoriseerde gebruiker zo snel mogelijk op. Het incident had geen impact op de databases, infrastructuur of productie-, authenticatie- of betaalsystemen, legt het bedrijf uit. Het geeft echter toe dat sommige klanten zich alsnog zorgen moeten maken: de geraadpleegde repositories bleken klantendata te bevatten die “voor debugging-doeleinden” er naartoe was gekopieerd.
Het gebruik van echte klantgegevens voor debugging-doeleinden kan simpelweg eenvoudiger en sneller zijn dan het genereren van ‘mock data’ voor een test. Toch lijkt het ons een bijzonder slecht idee om dergelijke informatie bloot te stellen aan een systeem dat het niet strikt nodig heeft. Mock data wordt om voor de hand liggende redenen altijd gebruikt wanneer de pers een demonstratie krijgt van een IT-systeem. Interne tests kunnen een vals gevoel van veiligheid geven over de gebruikte gegevens, net als 2FA op de repositories waarop de gegevens in dit geval belandden.
2FA-fout
De oorzaak van het lek werpt veel vragen op. “Hoe kan een 2FA-fout ertoe leiden dat iemand toegang krijgt tot [Zapier’s] repo’s?” vraagt een online gebruiker zich af. En ook: hoe kan het dat er klantgegevens zomaar in een repository belanden waar ze niet hoeven/horen te staan?
Het is belangrijk om te vermelden dat Zapier verre van de enige partij is met een incident als deze. Zo lekte een DevOps Cloud Engineer bij AWS in 2020 zowel persoonlijke documenten als wachtwoorden en cryptografische sleutels voor verschillende cloudomgevingen. Gelukkig was een externe securityonderzoeker er destijds als de kippen bij, zodat het lek in een halfuur was gedicht.
Aangezien we alleen horen over de situaties waarin dergelijke datasecurity wordt doorbroken, kunnen we niet stellen dat dit per se vaak voorkomt. Er zijn nu eenmaal ontzettend veel gevoelige gegevens om te beschermen en genoeg ontwikkelaars die een beginnersfoutje maken. Maar in dergelijke situaties zou 2FA/MFA hen moeten beschermen. Hoe het kan dat dit bij Zapier misging, is een raadsel. Mogelijk was het account niet van een gebruiker of ontwikkelaar, maar een testaccount. Deze soort accounts worden weleens uit het oog verloren. Het is ook mogelijk dat een gebruiker 2FA niet correct had ingesteld, waardoor een enkele gecompromitteerde computer beide authenticaties kon verschaffen.
Hoe dan ook is het een herinnering aan andere partijen om zowel testaccounts bij te houden als MFA-hygiëne na te laten leven door medewerkers. Dat zal altijd een zware strijd zijn. Het kan een partij als Zapier ook klanten kosten, mochten zij al erover twijfelen om naar één van de vele alternatieven over te stappen.
Klantgegevens in repository
Het is gebruikelijk dat een IT-leverancier na een incident de gevolgen in kaart brengt met een temperende toon. Zo spreekt het over “afzonderlijke gevallen” waarin klantgegevens waren gevonden, die überhaupt al “uit een overvloed aan voorzichtigheid” waren ontdekt. We zijn bepaald geen voorstander van dergelijke terminologie in deze omstandigheden. Je controle is per definitie niet overvloedig als er gevoelige gegevens opduiken waar ze niet horen.
Wel is de e-mail naar klanten toe (die door The Verge in zijn volledigheid is gedeeld) helder. Het lijkt erop dat elke gebruiker van Zapier die door het incident is geraakt, precies kan inzien welke gegevens zijn blootgesteld aan het lek. Wie nog verdere problemen ervaart, kan Zapier contacteren.
Lees ook: Cyberaanvallen anno 2025: SaaS is blinde vlek, China rukt op