Lek in gemeentewebsites maakte inzien en verwijderen van afspraken mogelijk

Een lek in een webapplicatie voor het maken van afspraken met de gemeente maakte het mogelijk om afspraken te verwijderen en in bepaalde gevallen gegevens in te zien. De webapplicatie is in gebruik bij ongeveer twintig procent van Nederlandse gemeentes.

De kwetsbaarheid, die werd ontdekt door beveiligingsonderzoeker Guido Vranken, is inmiddels opgelost. Toen hij contact zocht met de Informatiebeveiligingsdienst voor gemeenten, oftewel IBD, bevestigde deze dat de webapplicatie 'Afspraken en Reserveringen' van JCC Software in gebruik is bij 20 tot 25 procent van de Nederlandse gemeentes. De kwetsbaarheid maakte het mogelijk om toekomstige afspraken die burgers met de gemeente maken in bepaalde gevallen in te zien, waarbij gegevens als naam, adres, telefoonnummer en soms ook BSN in te zien waren, aldus Vranken. Hij heeft dit niet bij de afspraak van een ander getest, omdat hij daarmee buiten de lijnen van responsible disclosure zou treden. Ook was het mogelijk om een ingeplande afspraak eenvoudig te verwijderen.

Deze mogelijkheden kwamen voort uit het feit dat er twee gegevens een rol spelen bij het aanmaken en wijzigen van een afspraak: een 'AppointmentID' en een e-mailadres. Normaal gesproken krijgt een gebruiker een met een cijferreeks gecodeerde link toegestuurd, waarmee hij toegang kan krijgen tot zijn afspraak in de afsprakenkalender. De codering maakt het voor een potentiële aanvaller zeer moeilijk om te raden welke cijferreeks door de server geaccepteerd zal worden. In het huidige geval werden de AppointmentID en het e-mailadres echter in klare tekst meegestuurd in het formulierveld. Aan de hand van deze informatie stelde Vranken vast dat de ID een oplopend nummer was, waardoor het eenvoudig was om ID's van andere afspraken te voorspellen en te achterhalen.

Het verwijderen van een afspraak met een op die manier geraden ID was eenvoudig te bereiken door een curl-call naar de server van de desbetreffende gemeente te sturen. Er vond geen verdere verificatie plaats, bijvoorbeeld op basis van een ip-adres. Voor het inzien van een afspraak en de daarbij horende gegevens moest echter nog een e-mailadres worden ingevuld, alleen een AppointmentID was daarvoor niet genoeg. Volgens Vranken is een bijbehorend e-mailadres te achterhalen door bijvoorbeeld een dump van adressen te gebruiken, die als gevolg van een hack zijn buitgemaakt. Deze zouden voor een ervaren aanvaller zonder veel moeite te vinden zijn. Ook zou het mogelijk zijn om e-mailadressen per gemeente te vinden. Een woordvoerder van JCC laat tegenover Tweakers weten dat er ook voor het verwijderen van een afspraak bevestiging via een e-mailadres nodig was.

De afsprakenplanners van de verschillende gemeentes waren volgen Vranken via Google te vinden. De woordvoerder van JCC stelde verder dat het bedrijf door de IBD op de hoogte is gesteld van de kwetsbaarheid en deze vervolgens heeft bevestigd. Daarna heeft het bedrijf zo snel mogelijk een hotfix ontwikkeld en de getroffen organisaties op de hoogte gesteld. Inmiddels is de software zodanig aangepast dat de afspraken niet meer te herleiden zijn.

Reacties (64)

[unconnected]

weet je wat ik nog veel erger vind... dit heb ik al ontdekt toen ik bezig was met een website voor een gemeente hier in de buurt. aangegeven ook bij die partij in augustus 2012 en daar is blijkbaar nog nooit wat mee gedaan? beetje jammer

http://www.unconnected.nl/gbospoc.png

[Zezura]

hoe is het mogelijk om dit soort fouten te maken, is dat niet gewoon, slechte ontwerp.
ik neem aan dat dit ontwikkelt is door een software bedrijf en niet een Zelfstandige zonder personeel.
van een persoon kan ik het nog verwachten, maar dan vraag ik me af hoe geschikt hij is om dit soort omgevingen te ontwikkelen voor de overheid.

maar een bedrijf, dan vraag ik me af, hoe de ontwikkeling binnen het IT team gaat.
via welke wijze.

want ik neem aan dat je als bedrijf een bepaalde kwaliteit wil leveren, en ook je systeem grondig ontwerpt en test.

[DetonatorB]

Mee eens.
De publieke ID - mwah, maar:
de calls hadden eigenlijk om tenminste twee redenen niet mogen worden uitgevoerd en beide zijn structurele gebreken; inderdaad slecht ontwerp.

1) er is blijkbaar geen sessie cookie of andersoortig token nodig (a big NO-NO). Je hoeft blijkbaar niet in te loggen? En 'gebruikersvriendelijkheid' is echt geen reden om dit soort data op straat te gooien.

2) de AJAX call (het verwijderen) heeft dat probleem ook (geen check van identiteit), maar ook nog geen XSRF-token. Dus ik vermoed dat dat ook nog wel een ander probleempje (attack vector) is, naast het genoemde probleem. Maar dat terzijde.

Daarnaast, als je dit soort links maakt in een e-mail, is het gewoon gebruikelijk om naast het ID (al dan niet versleuteld) ook nog een hash (bijv. SHA256) mee sturen, waarvoor private (en evt publieke data) wordt gebruikt, inclusief een geheime salt. Soms ook nog met een tijd/datum erin zodat de link kan verlopen.
De ontvangende kant maakt dezelfde hash en controleert deze.
Zo kun je in ieder geval niet meer gokken a.h.v. 'buitgemaakte' data.
Echt wel basic eigenlijk.
Kortom: no excuse.

[Jochem]

inderdaad. of je creeert op de server een expliciete hash die je laat verlopen na x uur (TTL) en alleen daarmee samen met wat andere basis info op de server aanwezig kun je inloggen. Analoog password reset hashes.

[Madden]

ik neem aan dat dit ontwikkelt is door een software bedrijf en niet een Zelfstandige zonder personeel.
van een persoon kan ik het nog verwachten, maar dan vraag ik me af hoe geschikt hij is om dit soort omgevingen te ontwikkelen voor de overheid.

Dus volgens jou is software ontwikkelt door een bedrijf kwalitatief hoogwaardiger dan dezelfde software die ontwikkelt is door een zelfstandige?
Zou het niet eerder andersom zijn? Een zelfstandige geeft met wat hij ontwikkelt een visitekaartje af; voor een medewerker van een bedrijf zal dat meestal minder sterk meetellen. En voor een zelfstandige is dat visitekaartje denk ik belangrijker dan voor medewerker X van bedrijf Y. Er kan tenminste op die manier nog meer werk voor de zelfstandige achter vandaan komen.

[Zezura]

ik snap wat je bedoelt en daar heb je inderdaad gelijk in,

maar ik bedoel, als je alleen werkt, dan heb je minder ogen, die iets controleren.
namelijk alleen jezelf. nu is het een gegeven dat programmeurs blind zijn voor eigen fouten, als ze lang aan de code werken.

daarom heeft een professioneel team ook code reviews, bijvoorbeeld na een sprint.
daarbij werken bedrijven meestal eerder in project verband dan een persoon.
en project basis is meer systematisch waardoor je ook minder fouten maakt omdat er al vast staat dat er bijvoorbeeld zoveel uur staat voor code reviews, dat zie ik een programmer alleen niet doen, die zal waarschijnlijk (als deze al project basis probeert te werken) toch meestal minder tijd besteden aan dit soort dingen + feit dat programmeurs blind zijn voor eigen fouten.

maakt het al (vooral in mijn opinie) dat je van een bedrijf toch echt dit soort systematische ontwerp fouten niet mag verwachten.
omdat je met meer mensen naar dezelfde fout hebt zitten kijken en niet gezien hebt.
dus zit de rest te slapen ? of wat voor policy hebben ze daar dat niemand mag aangeven dat er een grote ontwerp fout in zit.

edit: woord veranderd wat iets beter in context past.

[Reactie gewijzigd door Zezura op 31 juli 2024 09:51]

[bazzi]

Hier een zelfstandige die codes laat reviewen en audits krijgt op de oplevering. White, black en grey. Denk dat je beter een serieuze zelfstandige kan hebben dan een bedrijf die iets minder serieus is...

[Rafe]

De reviews worden gedaan door je opdrachtgever? Of laat je die zelf doen?

[bazzi]

Beide. Ik dring aan dat ze het zelf doen, want het moet ook overdraagbaar zijn. Maar als ze dat niet (goed) doen heb ik het zeker laten doen. Verder is de basis vanuit waar ik ontwikkel ook al een keer volledig gereviewd. Tot nu toe zijn er altijd 4 eyes over de code geweest.

[Anoniem: 721593]

Cheap, Fast, Good.
Pick any 2.
Overheid zal ALTIJD Cheap en Fast kiezen.
En daarmee is alles gezegd.

[DinoBe]

Overheid kiest vnl cheap, omdat dat het meest objectieve criterium is.

[Lapa]

Met dank aan het systeem van aanbestedingen.
Ik begrijp 100% waarom dat is ingevoerd (met name voorkomen/bestrijden van corruptie), maar het heeft ook zeer serieuze nadelen.

O.a. wordt vaak een kwalitatief mindere partij gekozen, omdat prijs zo'n belangrijke factor is. Daarnaast levert het héél veel extra kosten op. Zowel voor de overheid, die veel tijd en moeite steekt in het aanbestedingsproces als voor de aanbiedende partijen. Als je de kosten van al die partijen optelt, kan dit echt enorme kapitaalvernietiging zijn.

[DeJaapS]

Nee, het betreft de leverancier JCC. Die bieden klantgeleidingssoftware aan voor o.a. gemeentehuizen, apotheken en anderen.

Gemeentes zijn vrij om zelf hun leveranciers hierin te kiezen.

[mhaket]

Gaan we weer met bashen op overheid en ICT... Ten eerste gaan dit soort dingen op vrijwel dezelfde schaal fout in het bedrijfsleven. Ten tweede gaat het om een commercieel product waar deze fout in zit. Als een overheid een auto aankoopt en die auto moet terug voor een recall, heeft die gemeente dan gefaald?

[mjl]

De gemeente blijft verantwoordelijk om alle risico's af te dekken en de it systemen die ze hebben goed te testen.

Je kunt zoveel willen afkopen als je wilt, maar men blijft zelf verantwoordelijk voor de data veiligheid.

[Reactie gewijzigd door mjl op 31 juli 2024 09:51]

[oef!]

Dat vind ik onrealistisch, je kan niet van een gemeente verwachten dat ze een blik pentesters op al hun applicaties loslaten (al gebeurt het gedeeltelijk wel in de praktijk). Dat is financieel onhaalbaar terwijl een gedeelte van de verantwoordelijkheid bij de leverancier ligt.
Hiernaast ontstaat er het probleem dat er een vulnerability in een OS of webserver volgens je redenering ook de verantwoordelijkheid van de gemeente is.

[mjl]

Wat ik bedoel is dat men zelf moet zorgen voor een risico analyse waarbij een impact analyse op gebied van Confidentiality, Integrety en Availability van het systeem moet worden gedaan voor implementatie of aanschaf. Hieruit kunnen dan controls/measures worden gedefinieerd om de risico's te beperken. Deze controlskomen dan in de requirements en moet de leverancier hieraan voldoen (als die het kan leveren natuurlijk).

Als men dit goed doet wordt meteen duidelijk waar in de implementatie zwaarder getest en gevalideerd moet worden.

En dergelijke benadering is gewoon good IT practice, als men zich dat niet doet ben je gewoon aansprakelijk... en dat koop je niet af door het uit te besteden. Je moet altijd zelf de risico's onder controle hebben.

[Reactie gewijzigd door mjl op 31 juli 2024 09:51]

[cmegens]

En daar zit het probleem. Als je een goede ervaren ict-er bent die dit soort projecten kan opzetten en goede banen kan leiden dan ga je niet bij de gemeente of overheid werken, maar het bedrijfsleven in. Wat je dus krijgt is mensen in de overheids functies die dan wat minder competent zijn. Had er een competent ICT manager vanuit de overheid achter deze aanbesteding gezeten dan had die dit soort dingen al gecontroleerd en terug naar de ontwikkelaar gestuurd.

Kortom, het is incompetentie doordat de overheid geen concurrentie kan bieden aan het bedrijfsleven om echte competente en getalenteerde mensen aan zich te binden.

[oef!]

Eerlijk gezegd denk ik dat een ICT manager (of de mensen die voor hem werken) hier nooit achtergekomen was. Het betreft hier in principe een exploit. De gemeente vraagt hoogstwaarschijnlijk hoe het platform in elkaar zit dat bij deze applicatie hoort en stelt daaraan (hopelijk) eisen. Als de fabrikant daarnaast inzage geeft in hun eigen pentest/audits waarin deze exploit niet naar boven is gekomen, tast iedereen in het duister.

[Reactie gewijzigd door oef! op 31 juli 2024 09:51]

[supersnathan94]

Wat ik me dan weer afvraag is hoe je als ontwikkelaar op het idee komt om een ID oplopend te maken als deze vrijwel direct gelinkt is aan je authenticatie methode. Ik snap dat het makkelijk is om in te bouwen, maar zeker in dit geval zou ik sneller gaan voor iets als een hash van een random nummer. Dat icm emailadres en je hoeft niet eens bij te houden of het nummer eerder al is gebruikt in de afgelopen twee maanden.

[TheMak]

Bedrijven hebben geen DigiD. Buitenlanders ook niet altijd. Mijn DigiD was een keer verlopen..

[supersnathan94]

Ja dat maakt niet uit. Daar zijn allemaal systemen voor ontwikkeld. Hoe wil je je anders aanmelden bij een hoge school als buitenlander? Precies. Dat gaat ook met DigID, maar met uitzonderingen dus.

[consolefreak]

Hoe je het ook went of keert, volgens de wet is de data eigenaar verantwoordelijk die een data verwekker kan verwerken.

[oef!]

Ik vermoed niet dat een gemeente in dit geval gestraft zal worden door de autoriteit persoonsgegevens ook al is er sprake van een datalek.

[Anoniem: 511810]

ja, want in bijna alle gemeentelijke en overheidsbudgetten komt standaard de ontwikkeling van ieder lullig stukje software, of het nu ingekocht wordt of niet, in de begroting terug.

[janbaarda]

Waarom gebruiken deze gemeenten geen DiGiD om de gebruiker te identificeren? Dat is toch bedoeld voor overheidstoepassingen?

[mjl]

Is te duur, en als je dan alsnog dezelfde planninggssoftware gebruikt is je digid ook niet meer veilig

[pizzafried]

dus, we willen dat alle gemeenten digid gaan gebruiken, maar ze doen het niet omdat het te duur is? wat zit daar nou weer voor rare gedachtenkronkel achter? waarom is dit geen verplichte investering voor diensten die je via het web aanbied? waarom zit daar geen subsidie bij voor gemeenten die dat geintje niet kunnen betalen? waarom moet een gemeente voor de implementatie betalen?(anders dan de kosten van de ontwikkelaars die de website onderhouden?

ik kan stoppen voor een oranje of rood stoplicht. maar ik doe het niet, want het kost me te veel energie om dat hele riedeltje van stoppen en wegrijden uit te voeren. dus ik doe het maar niet. zoiets?

geen sneer naar jou ofzo, maar gewoon een constatering.

[Reactie gewijzigd door pizzafried op 31 juli 2024 09:51]

[tERRiON]

Je hebt geen idee hoe vaak gemeenten een poot worden uitgetrokken. Zo heb ik laatst bij een offertebespreking gezeten met een dienstverlener die "beveiliging mailen" met partijen als zorgaanbieders aanbiedt. Initiële kosten voor ons (gemeente <50k inwoners) zijn €4000 + jaarlijks tussen de €3500 en €7500. (afhankelijk van welke dienst we precies zouden afnemen) Dit zijn prijzen ex. BTW.

Meneer kon niet uitleggen wat hun meerwaarde was ten opzichte van een met afgedwongen TLS-versleutelde verbinding, behalve dat we dan geen administratieve lasten zouden hebben omdat vrijwel alle partijen waar wij als gemeente gegevens mee moeten uitwisselen al bij hen aangesloten zijn.

Eenmalig €4000 om onze mailserver over TLS met hun mailserver te laten babbelen en jaarlijks tussen de €3500 en €7500 om het in stand te houden klinkt in mijn oren als pure oplichterij. En dan zijn dit nog miezerige bedragen.

[pvcholten]

ZorgMail?

[mjl]

Je hebt gelijk, op zich zou je verwachten dat ze digid willen gebruiken. Ik kan me echter voorstellend at als DigiD geimplementeerd wordt dit geen goedkope integratie is als je uit bent naar een simple "afspraken systeem" om dan kosten te besparen wordt een afspraak systeem gekocht dat lekker goedkoop is en geen digid IDM ondersteunt.

Een goedkoop afspraken systeem met dergelijke fouten wil je dan ook niet gekoppeld hebben met digid, voor het zelfde kan het dan gebruikt worden om digid binnen te komen...

[DeJaapS]

Ten eerste is het een stukje klantvriendelijkheid. Veel mensen hebben zo nog steeds hun DiGiD nog niet zo in hun hoofd zitten en ervaren het als vervelend dat ze die moeten gebruiken bij het maken van afspraken.
Het maakt het makkelijker om een afspraak te maken als je niet eerst door die authenticatie heen moet.

De tweede reden is geld en tijd. Elk systeem wat gebruik maakt van DiGiD moet jaarlijks aan een audit onderworpen worden. Deze zijn behoorlijk intensief en tijdrovend om uit te voeren.
En ja, elk systeem moet apart gedaan worden. Dus afspraken, digitale meldingen doorgeven, verhuizingen en andere BRP dingen moeten allemaal apart geaudit worden.
Dus als je op veel plekken DiGiD inzet kost je dat ook steeds meer tijd door al die audits heen.

Het voordeel zou wel geweest zijn dat deze fout er met de audit waarschijnlijk wel uitgepakt zou zijn.

[.SnifraM]

De kwetsbaarheid maakte het mogelijk om toekomstige afspraken die burgers met de gemeente maken in bepaalde gevallen in te zien, waarbij gegevens als naam, adres, telefoonnummer en soms ook BSN in te zien waren, aldus Vranken. Hij heeft dit niet bij de afspraak van een ander getest, omdat hij daarmee buiten de lijnen van responsible disclosure zou treden.

Ik snap deze niet helemaal. Je hebt 'soms in bepaalde gevallen' wel of juist geen inzicht in naam, adres, BSN, etc. Maar Guido heeft het echt alleen met zijn eigen afspraken getest? Hoe weet hij dan dat het soms in bepaalde gevallen mogelijk is om BSN adres etc te zien? Dat JCC software zo'n stomme ontwerpfout maakt voor het verwijderen van afspraken betekend namelijk niet dat er op deze persoonsinformatie geen beveiliging zat toch? Dat weet je dan alleen door het te testen op iemand anders zijn afspraak en te concluderen dat het toch mogelijk is om in te zien. Dat je je eigen BSN eruit kan toveren hoeft toch niet te betekenen dat die van andere er ook uit te toveren is zonder foutmelding. Of zie ik hier wat over het hoofd?

[Reactie gewijzigd door .SnifraM op 31 juli 2024 09:51]

[emnich]

Voor zover ik het snap deed hij het met een gewone curl call dus zonder authenticatie.

Als je het dan met je eigen gegevens kan dan kan het dus ook met andermans gegevens omdat de server niet weet wie je bent en dus ook niet weet of het `jouw` gegevens zijn.

[.SnifraM]

Voor zover ik het snap deed hij het met een gewone curl call dus zonder authenticatie.

Als je het dan met je eigen gegevens kan dan kan het dus ook met andermans gegevens omdat de server niet weet wie je bent en dus ook niet weet of het `jouw` gegevens zijn.

Fair enough!

[PolarBear]

Hoe weet hij dan dat het soms in bepaalde gevallen mogelijk is om BSN adres etc te zien?

Het kan zijn dat BSN geen verplicht veld is. Of alleen bij bepaalde afspraaktypes wordt gevraagd.

[Kalief]

Volgens Vranken is een bijbehorend e-mailadres te achterhalen door bijvoorbeeld een dump van adressen te gebruiken, die als gevolg van een hack zijn buitgemaakt.

He, heb ik een nieuwsbericht gemist? Wanneer waren alle emailadressen dan gehackt die gemeenten met dit systeem hadden opgeslagen? Nooit toch, dus over welke buit heeft Vranken het hier dan?

[Maurits van Baerle]

Ik neem aan dat hij bedoelt dat je uit een lijst met bij een andere hack buitgemaakte emailadressen de Nederlandse haalt (is het een .nl adres? Staat er 'van' in? etc.) en die voert aan deze interface. Daar zouden dan afspraken uit zichtbaar kunnen worden.

[dutchgio]

Dan nog heb je wel een woonplaats nodig, anders is het wel heel erg @random emailadressen spammen.

[-GSF-JohnDoe]

Het op dit moment bestaan of niet van die lijst is totaal irrelevant, er hoeft maar 1 goedgeplaatste hack te gebeuren en alles ligt op straat. Het is dus een goed argument van Vranken.

Verder maakt het niet uit of er random email adressen spammen nodig is of niet. Daar heb je immers computers voor.

[mrdemc]

Je kunt het ook andersom redeneren. Je weet dat iemand in de afgelopen dagen een afspraak heeft gemaakt, je weet iemand zn mailadres, je maakt zelf een afspraak via het formulier, ziet dat het een bepaald nummer is, telt vanaf dat moment terug tot er een match is. Zo kun je bij je stalk-slachtoffer of wie dan ook hele vervelende situaties doen ontstaan. Bijv. voor je ex-werkgever of partner

[MrManuel]

Dit is toch wel weer een knap staaltje van niet opgelet hebben over wat wel/niet beveiligd is.
Helaas ben ik dit soort lekken in de praktijk zelf ook al vaker tegen gekomen..

[.SnifraM]

Ongelofelijk simpel weer Hoop dat ze bij JCC Software nog eens goed achter de oren gaan krabben.

[Reactie gewijzigd door .SnifraM op 31 juli 2024 09:51]

[CAPSLOCK2000]

Wat is een "curl-call"?

Ik denk dat het gaat om de tool cURL, dat is zo'n beetje het bekendste gereedschap (na wGet) om vanaf de commandline een URL te fetchen.
https://en.wikipedia.org/wiki/CURL

Er staat dus eigenlijk dat die URLs vrij toegankelijk zijn vanaf internet.

[emnich]

Dit is toch een beetje een storm in een glas water wat mij betreft.

Allereerst heb je dus altijd de combinatie nodig van ID en e-mail adres. Natuurlijk kan je dit bruteforcen maar ik neem aan dat ze dáár wel een beveiliging voor hadden. Dat maakt het filmpje niet duidelijk.

Als de hacker al die moeite had gedaan dan heeft hij daarna naam, adres en BSN van de persoon. Van 99% van de ZZP'er kan je dit al gewoon (zonder hack) van het internet plukken dus zo bijzonder zijn die gegevens ook weer niet.

Vooropgesteld, het blijft slordig dat het sowieso kan en een beetje webbouwer zou beter moeten weten maar zo bijzonder vind ik het nu ook weer niet.

[Crazy D]

Eens. Het is slordig, maar ook weer niet zo groot en schandalig als dat hier door sommigen wordt voorgesteld. Wel is het de vraag wat deze ontwikkelaar nog meer voor software bij gemeentes heeft draaien die wel kritiekere informatie bevatten...