Zapier meldt hack in coderepository's waarbij klantgegevens zijn gestolen

Automatiseringstool Zapier meldt dat een 'ongeautoriseerde gebruiker' toegang heeft gekregen tot sommige coderepository's en dat daarbij ook gegevens van klanten zijn gestolen. Om welke gegevens het gaat, wordt niet vermeld.

Volgens Zapier wist een hacker toegang te krijgen tot de coderepository's, omdat een werknemer de tweefactorauthenticatie van zijn account niet goed had geconfigureerd. Meer informatie over de oorzaak wordt niet gegeven. Volgens het automatiseringsplatform bevatten deze repository's normaliter geen klantdata, maar waren er per abuis in sommige gevallen toch gebruikersgegevens aanwezig 'voor debuggingdoeleinden'.

Zapier heeft de toegang tot de repository's naar eigen zeggen beter beveiligd en de hacker kan er niet meer bij. Het bedrijf heeft een mail gestuurd aan klanten die getroffen zijn door de hack. Er wordt niet genoemd om welke gegevens het precies gaat, maar Zapier raadt klanten onder meer aan om eventuele plaintextauthenticatietokens in code aan te passen. Deze hack heeft volgens Zapier geen impact op zijn database en infrastructuur, of op zijn 'productie-, authenticatie- of betalingssystemen'.

Reacties (49)

[Antrax]

Ik blijf het toch maar roepen, al jaren: Het is absoluut cruciaal om productiegegevens nooit, maar dan ook nooit, in repositories te plaatsen. Er bestaat simpelweg geen enkele valide reden om dit goed te keuren of recht te praten. Zorg er altijd voor dat je werkt met testdata of gesimuleerde gegevens in je repositories.

[Frame164]

Ons vakgebied is na 70...75 jaar gewoon nog steeds niet genoeg geprofessionaliseerd. Dat zien we iedere dag in de nieuwsberichten. Ook bij veel reageerders zien we nog vaak een hiog hobbygehalte. Vorige week nog iemand die het prima vond om nog steeds Office 2010 te gebruiken. In vrijwel iedere andere sector zijn veel strengere regels.

[lenwar]

In de basis heb je natuurlijk gewoon gelijk. Maar het is in de praktijk ook lastig. Ons vakgebied raakt ook 'alles'. Voor de meeste bedrijven is IT niet het doel, maar een middel. Een stuk gereedschap. Zo wordt er tegen aan gekeken. En terecht. (vanuit hun perspectief.)

Idealiter timmeren we alles dicht met concepten als least privilege, communicatielijnen helemaal dicht op de lijnen na die noodzakelijk zijn, enz, enz, enz.

Vervolgens wordt er een stuk software het bedrijf ingereden, dat allerlei vage eisen heeft. Dan kan 'beheer' wel roepen "Het is niet goed", maar ja. De functie van die software is het doel. En dat maakt het lastig. Je wordt dus door hoge heren overruled, en je ziet maar hoe je die brakke software veilig in je omgeving kunt houden.
Je hebt in de praktijk ook geen sterk verhaal richting management. Management ziet 'ons verhaal', met heel veel 'potentiëlen, en als dit dan dat', enz. tegen 'Deze tool doet dit concreet iets voor ons'.

Of denk aan verouderde software die alleen nog op RHEL5 draait (of zo). RHEL5 Ondersteunt geen TLS 1.2, dus het communiceert nergens meer mee. Dan kunnen we wel roepen van 'Wij ondersteunen het niet'. Het systeem gaat uitgefaseerd worden. (horen we al 5 jaar). Het 'tijdelijk vervangen kost 40 miljoen'. Het in de lucht houden 100.000 per jaar. Makkelijke rekensom voor management. Maar ja. Als de boel plat ligt, komt puntje bij paaltje en ben je toch nog 's nachts bezig met die oude meuk.

Uiteindelijk heeft veel te maken met centen. Er moet een financiële afweging gemaakt worden tussen 'technisch goed/veilig' en 'wat zijn de kosten als het misgaat'. En dat voelt voor mij als techneut niet goed. Maar ik snap hem vanuit het commerciële bedrijfsaspect zeker wel.

[svenslootweg]

Aan de andere kant moet ik ook regelmatig in conclaaf met ontwikkelaars die er maar vanuit gaan dat er niets mogelijk is, zonder uberhaupt een poging te wagen. Dan blijkt dat de baas ze verteld heeft dat ze het op manier X moeten doen, en dat hebben ze maar aangenomen. Moedig ik ze dan aan om het probleem bij de betreffende baas naar voren te brengen en daarin doortastend te zijn, dan blijkt er ineens wel meer te kunnen.

Ik vraag me regelmatig af hoeveel van dit soort problemen daadwerkelijk stuklopen op het kostenplaatje, versus in hoeveel gevallen het simpelweg een kwestie is van "ontwikkelaar doet direct wat manager zegt zonder enig tegengas te geven, en gaat er maar vanuit dat de genoemde deadline/budget ook echt een beperking is", en waar er dus wel gewoon oplossingen mogelijk zijn. Van buitenaf lijken die twee situaties identiek, maar dat zijn ze niet.

Want onderdeel van die professionalisering van een vakgebied betekent ook dat je leert om voor jezelf op te komen, en achter de kwaliteit van je werk blijft staan, en dus ook bereid bent om "nee, dat doe ik niet" te zeggen. En dat is in dit vakgebied echt gewoon nog veel te zeldzaam.

[lenwar]

Zeker waar. Er zijn een oneindig aantal voorbeelden te bedenken. Sommigen zijn beperkt door (bedrijfs)politiek, sommigen door budget, sommigen door gebrek aan kennis, sommigen door het ‘niet durven vragen’ (schamen/ongemakkelijk), enz, enz.
De ergsten zijn in mijn ervaring altijd de afdelingen waar één persoon iets van besturingssystemen weet (omdat ie thuis ook aanhobbyt), maar dat dat gedrag niet in corporate omgeving past en dat diens manager die persoon op handen en voeten draagt. Waardoor je intern het ‘not invented here’-syndrome aanhoudt.

Ik heb ze de afgelopen 20 jaar allemaal voorbij zien komen. Maar ik heb over de jaren ook gezien

[TheMak]

Ik gebruik vi

[Unstable Element]

Als je dan over 3 jaar upgrade naar vim kun je over 20 verder naar nvim

[Accretion]

Nano, omdat ik de rest voor geen meter begrijp.

[haam]

Men that was long long ago in a country far far away.

Als je een beetje los bent met regular expression kun je echt de gekste dingen doen in 1 commandline.
Maar denk niet dat dat bedoeld wordt

[latka]

Omdat zodra iets een beetje ok begint te worden qua tooling en regels er een nieuwe fad onstaat waar iedereen opspringt en de lessen van weleer negeert. Ik geef toe dat ik daar ook aan meedoe en geen cobol gebruik.

[Accretion]

daar ook aan meedoe en geen cobol gebruik.

[Lord Anubis]

Dat is ook het probleem, er was indertijd voor veel werknemers een pc-prive cursus en diegenen waanden zich pro’s zonder enige verdere opleiding of begeleiding van boven af in het bedrijf. Sommigen zijn door gegroeid in functie bv naar zelfs manager maar niet in kennis. Als dan een derde partij ingehuurd werdt was dat tegen het verkeerde been en ging men op de oude voet verder.

[ari3]

Het blijft een lastige balans. Zelfs (geanonimiseerde) testdata of gesimuleerde gegevens zijn in een bepaalde zienswijze fout om in een repository te plaatsen. Je geeft hackers daarmee inzicht in wat getest wordt en daarmee impliciet ook inzicht in wat niet getest wordt. En wat niet getest wordt is mogelijk een zwakke plek in de beveiliging.

[sir_huxley]

Ik snap je, maar naar mijn mening staat dit haaks op hoe je vandaag de dag zou moeten ontwikkelen. Je dient er juist voor te zorgen dat nagenoeg 100% van je code base een unit test dan wel integratie test heeft. (TDD) Test data kan gegenereerd worden met dummy data bibliotheken. (Bijvoorbeeld Faker/bogus, etc) In sommige gevallen wil je die fake data een beetje masseren zodat deze bijvoorbeeld een bepaalde edge case simuleert die een opgeloste bug valideert.

Neemt niet weg dat ik ook wel eens gezien heb dat sommige ontwikkelaars productiedata gebruiken om een bug op te lossen en deze dan ook als input gebruiken voor en unit test. Dit is natuurlijk not done. Maar het geeft vaak aan de er iets mis is in de aanlevering van ruwe data. In principe zou deze data al geanonimiseerd moeten worden bij extractie van de gegevens uit bijvoorbeeld de database.

[Accretion]

100% unit test is een farce die nergens op slaat.

Je kunt 100% van de code raken zonder ook maar iets qua security te testen.

[Croga]

Nog sterker: 100% unit test is waste. Je bent dingen aan het testen die in productie nooit voor komen en dus ben je tijd aan het verspillen aan dingen die er niet toe doen.

Voorbeeld:
Ik gebruik een wiskunde bibliotheek omdat ik een bepaalde (ingewikkelde) berekening moet doen.
Als ik 100% unit test dekking wil hebben dan zal ik die volledige bibliotheek moeten testen terwijl ik slechts een klein onderdeel van die bibliotheek gebruik.

Soortgelijk:
Moet ik alle mogelijke input van een functie gaan testen als ik volledige controle heb over die input? Nee, laat dat lekker aan een integratie test.

De blik van een oud gediende:
https://pythontest.com/st...st-unit-testing-is-waste/

[sir_huxley]

Door testen toe te voegen baken je je systeem af. Natuurlijk moet je geen onnodige testen toevoegen. Maar je wilt toch weten dat als je iets veranderd hebt in je systeem dat het nog steeds werkt?
Of ga je dat pas in je staging environment testen? Externe bibliotheken is niet jouw code, deze dienen hun eigen tests te hebben.

Maar goed ik denk dat we op het punt zijn aangekomen dat er binnen software ontwikkeling verschillende inzichten zijn. Sommige mensen vinden nou eenmaal dat integratie en unit testen onzinnig zijn. Ik ga daar helaas niets aan veranderen.

[sir_huxley]

Deze volg ik even niet. Graag toelichten of onderbouwen waarom je dit denk. Ik weet dat er bepaalde bekende streamers zijn die anti unit test zijn. Maar als je 100% van je code gedekt hebt dan heb je ook je security gedekt. Je dient dus ook je controllers te testen. De controllers test je met verschillende authenticatie en verschillende autorisatie niveaus. Het zelfde doe je voor row level security indien van toepassing. Maar ik de meeste software producten mag ik hopen dat je niet zelf je autorisatie en authenticatie schrijft. Je maakt gebruik van industrie standaarden zoals oauth en bibliotheken die dit geïmplementeerd hebben.

[Accretion]

Neem als voorbeeld een buffer overflow, als jouw code die conditie niet controleerd, telt deze ook niet mee voor de unittest.

De coverage gaat alleen over de code/beveiligingen die je wél geschreven hebt, niet die je niet geschreven hebt.

Unit tests zijn zeker belangrijk, maar geen heilig middel dat incompetentie wegpoetst.

Je test immers alleen de cases waarvan jijzelf voorziet dat het mis kan gaan.

[Reactie gewijzigd door Accretion op 3 maart 2025 00:00]

[sir_huxley]

Eenvoudige buffer overflow test kun je overigens wel testen middels een integratie test. Juist door het gebruik hiervan kun je in een vroeg stadium achterkomen of de implementatie en validatie solide is. Specialistische pen tests zijn natuurlijk aan te raden en in sommige gevallen zelfs verplicht. Maar zodra er een gat is gevonden en ge-patched is, dan wil je toch een test hebben om ervoor te zorgen dat die kwetsbaarheid niet opnieuw voor kan komen?

[stefanhendriks]

Iets wat je niet weet kun je niet testen. Of heb je nu voor elke denkbare scenario, variabele, of constructie met “mogelijk” een bufferoverflow een test gemaakt?

[sir_huxley]

Lees mijn reactie waarop je reageert nog eens. Het is een bewijs dat je systeem werkt zoals je verwacht. Tevens test je ook een aantal scenario’s waarvan je verwacht dat er een fout ontstaat. Alle nieuwe fouten die ontstaan dan dien je die op te lossen en een test toe te voegen zodat herhaling hopelijk niet kan voorkomen.

[stefanhendriks]

lees mijn reactie dan ook nog eens ;-)

Je stelling dat je door integratie testen in een 'vroeg stadium' erachter kan komen of er een overflow ontstaat. Maar hoe dan? Dek je alle variabelen die je in je integratie test maakt? Als developer X later een variabele toevoegt, gevoelig voor overflows, hoe weet je zeker dat de integratie test dit nog gaat dekken?

Een (integratie) test, bewijst hooguit dat je voor het specifieke scenario iets aantoont wat werkt. Het toont niet aan dat het systeem 100% waterdicht is en geheel buffer-overflow proof is. Dat is een illusie.

[sir_huxley]

Ik heb het niet over alle overflows, maar eenvoudige overflows. Stel je spec geeft aan dat je wachtwoord lengte minimaal 8 tekens moet zijn en maximaal 20. Als je dan 3 tests toevoegt,
- 1 met minder dan 8, resultaat false
- 1 tussen de 8 en 20 en resultaat true
- 1 met een stringlengte van > dan 20 resultaat false
(Je hoeft dus niet alle mogelijk string te testen).

Door je input te valideren en deze middels een test the controleren kun je dus een nested functie die bijvoorbeeld geen juiste string allocatie heeft voorkomen dat er een overflow ontstaat.

Natuurlijk dient er een security audit en pen test plaatst te vinden. Niemand kan 100% veiligheid garanderen. Maar sommige personen claimen dat deze test 100% onzinnig zijn in naar mijn mening pertinent onwaar.

[Reactie gewijzigd door sir_huxley op 3 maart 2025 10:33]

[stefanhendriks]

Ok I'll bite ;-). Dit is namelijk best een leuk voorbeeld en het kan snel heel complex worden.

Als we het bijv over een web applicatie hebben, hebben we al een aantal lagen in de applicatie. Bijv, van browser naar backend. Binnen de backend heb je al laagjes in code.

Als je je 'echt' wil verzekeren dat er geen overflows kunnen ontstaan dan zou je op ieder laagje potentieel meerdere tests moeten toevoegen. Je moet o.a. denken over encoding (bijv, is het UTF-8? Of iets anders?).

100% dekking is idd onzinnig en pen/security testing zal zeker helpen. Het altijd 100% gedekt krijgen is een mooi streven.

Wat ik probeerde aan te geven, als je niet bewust bent dat er potentiele overflows kunnen zijn, dan zal je het niet weten (tenzij je gehackt bent OF je laat een test doen EN je moet er 100% op vertrouwen dat ze alle scenario's dekken).

[Niema]

Het is uiteraard een slecht plan on echte data te gebruiken, maar ik kan me wel voorstellen dat het gebeurt. Er zijn echt veel dingen die fout kunnen gaan in real use die je misschien niet merkt bij een dummy account. Speciale tekens in wachtwoorden, wachtwoordllengte, gare andere configuratie fouten. De echte wereld is vaak weerbastiger Dan de testomgeving en dichterbij de echte situatie willen Komen is niet alleen raar

[dez11de]

Ah een voorstander van security through obscurity. Zie je niet veel meer tegenwoordig maar goed dat je dapper vol blijft houden.

[eazyq]

Dat lijkt mij ook de enige juiste manier

[HenkEisDS]

Hoe doe je UAT dan?

[GewoonWatSpulle]

Met echte data op een acceptance omgeving, maar dat betekent niet dat de gegevens in de repository staan, sterker nog daar staat niet eens credentials naar databases of api's als het goed is.

[Accretion]

Ja, dat is logisch, maar d'r hoeft maar een keer iemand niet op te letten...

[Annihlator]

Door die dingen dus niet in de repo's mee te nemen e.d. maakt het dus niet uit als iemand vervolgens een keer niet oplet dan zou doordat op dat moment de juiste flags niet aanstaan een in-between ontstaan.

bijv Environment checks op een variabele die zegt Dev, Auth of Prod en bij een andere waarde onherroepelijk gaat gillen.

[HollowGamer]

En gebruik voor secrets - Secrets(!)

[Dutch_CroniC]

Veel gekker; hoe kan je nou je "2fa niet helemaal juist hebben ingesteld".

Ik vat dit op als helemaal niet ingesteld.

[lenwar]

De meest gebruikelijke vormen van 2fa zijn 'slechts' een extra controle op de serverkant. Als de serverkant die 2fa op dat account als 'optioneel' had ingesteld, dan kan het voor de rest van het bedrijf wel ingesteld zijn.

Er is van alles en nogwat mogelijk.

N.B. 2fa als 'optioneel' zou je uiteraard ook als 'niet ingesteld' kunnen bestempelen.

[graceful]

Klant data downloaden om te debuggen is wel echt bizar. Tegenwoordig kun je zoveel simuleren. Bestaan hele code platformen waarin je gewoon met productie data kan simuleren zonder dat je die data zelf uberhaupt aan hoeft te raken.

[HollowGamer]

Ik weet helaas hoe moeilijk het is om tegen developers te zeggen: 'gebruik a.u.b. geen productie gegevens lokaal of op een dev-omgeving'.

Standaard antwoord: 'Er kan niemand anders bij, dan mijzelf'.

[pbk]

Als je afhankelijk bent van de medewerkers om de 2fa tool goed te gebruiken heb je het niet goed ingericht lijkt me.

[Dutch_CroniC]

Hoe kan je zoiets niet goed ingesteld hebben dan?

[pbk]

Ik weet niet hoe dit voor andere omgevingen zit, maar zelf ben ik beheerder van een Microsoft tenant. Niet instellen is daar geen toegang. Er is geen mogelijkheid tot verkeerd instellen en dan alsnog toegang hebben tot de gegevens.
De verantwoordelijkheid voor de veiligheid moet niet liggen bij de eindgebruiker/werknemer. Dat wordt in dit bericht wel gesuggereerd.

[Patrick1995]

Je kunt een screenshot van de QR-code van 2FA op een onveilige plek opgeslagen hebben, waardoor die ook gehackt is. Of je hebt een wachtwoordbeheerder zonder 2FA met daarin al je wachtwoorden en 2FA codes.

[HollowGamer]

Ook niet als je gebruikersdata gebruikt om te 'debuggen'.

Daarvoor heb je fabrics en andere fictieve profielen.

[lenwar]

In het gelinkte artikel staat het anders dan dat Tweakers het neerzet:

Due to a two-factor authentication (2FA) misconfiguration on an employee’s account, an unauthorized user gained access to

Daarin wordt niet specifiek gezegd dat de gebruiker iets verkeerd heeft gedaan. Er was een misconfiguratie 'van een account'. Dit kan dus ook prima door de betreffende beheerders gedaan zijn.

[HenkEisDS]

Ik heb geen mail, maar totaal iets van 30 accounts. Lijkt allemaal beperkte impact dan. Misschien dat er een klein subsetje aan test data gebruikt is?

[The Zep Man]

Volgens Zapier wist een hacker toegang te krijgen tot de coderepository's, omdat een werknemer de 2fa van zijn account niet goed had geconfigureerd.
(...)
Volgens het automatiseringsplatform bevatten deze repository's normaliter geen klantdata, maar waren er per abuis in sommige gevallen toch gebruikersgegevens aanwezig 'voor debuggingdoeleinden'.

Dat ze gehackt zijn is één ding, maar deze rode vlaggen geven aan dat Zapier hun informatiebeveiliging niet op orde heeft.

[Lord Anubis]

Misschien wel het beleid maar je hoef maar net 1 misser te hebben ik begrijp dat klanten ook info hebben blootgesteld.

[kodak]

Ze doen nogal wat beweringen die niet zomaar geloofwaardig zijn.

Na de hack zijn ze gaan controleren wat oorzaken en gevolgen zijn. Toen pas kwamen ze er achter dat er meer dan één beveiligingsblunder was begaan. Dan kan je als bedrijf wel beweren dat een hack van repositories gewoonlijk geen invloed op klanten heeft en het bedrijf geen klantgegevens in repositories verwerkt, maar het blijkt allemaal nergens uit. Eerder het tegenovergestelde. Omdat nu er een hack is het overduidelijk al gevolgen voor klanten heeft. En omdat ze duidelijk wel degelijk klantgegevens in de repositories verwerken. En er duidelijk pas nadat het enorm is mis gegaan ze er pas achter komen dat wat ze zichzelf wijs maakte duidelijk op meerere gebieden niet klopt.

In een gunstige situatie hadden ze aantoonbare organisatorische en technische maatregelen die voorkomen dat dit gegevens in de repositories verwerkt konden worden. Samen met regelmatige audits om te controleren dat die maatregelen effecfief zijn. Maar daar lezen we geen enkel bewijs van. Ze doen zelfs geen enkele moeite ook maar meer dan bagatelliserende beweringen te doen.

[djwice]

Klinkt bijna als een gevalletje opzet:
normaal geen klantgegevens in repo
normaal werkt 2FA op repo goed

Nu staan er voor een bepaald doel tóch klantgegevens in én juist op dat moment werkt 2FA niet naar behoren.

Maar goed, verderop staat:

Zapier raadt klanten onder meer aan om eventuele plaintextauthenticatietokens in code aan te passen.

Authenticatietokens horen niet plaintexf opgeslagen te zijn en horen überhaupt niet in code thuis, laat staan in je code repository. Ook niet voor test doeleinden.

En blijkbaar zijn dat het type klantgegevens dat gelekt is;
authenticatie tokens voor test omgevingen.

[Reactie gewijzigd door djwice op 2 maart 2025 18:27]

[neps]

Volgens Zapier wist een hacker toegang te krijgen tot de coderepository's, omdat een werknemer de 2fa van zijn account niet goed had geconfigureerd.

Nee, Zapier, het was slecht beleid, niet de schuld van een enkele werknemer. Die gegevens hadden nooit in een repo moeten rondhangen, en goed gehandhaafde policies zouden het verkeerd instellen van 2fa niet mogelijk moeten maken. Hopelijk gaan ze echte maatregelen nemen, en niet genoegen nemen aan alleen de vinger naar iemand wijzen, want daar kom je echt nergens mee.