Portal van zes gemeenten bood via lek toegang tot burgerservicenummers

Een inlogportal die zes Nederlandse gemeenten gebruikten om burgers toegang te geven tot gemeentelijke belastingdocumenten, bleek vatbaar voor sql-injectie. Via de kwetsbaarheid waren onder andere burgerservicenummers te raadplegen. Het lek is gedicht.

Tweaker ImNotnoa wilde zijn aanslagen voor de gemeentelijke belasting vast inzien, en merkte daarbij op dat hij bij de portal waar de gemeentesite van Oldambt naar verwees, kon inloggen met alleen zijn burgerservicenummer en geboortedatum. Een burgerservicenummer wordt algemeen niet als betrouwbare inlog beschouwd omdat dit nummer niet vertrouwelijk genoeg is.

Zo waren btw-nummers van zelfstandigen lang te herleiden naar hun bsn's, al is dat bij nieuwe btw-nummers sinds vorig jaar niet meer het geval. Ook moeten burgers nog al eens scans afgeven van hun identiteitsbewijs, waar het bsn op staat. Wie het bsn en de geboortedatum van een persoon heeft, kon via de portal van de gemeente onder andere aanslagen voor de gemeentebelasting, woz-taxatieverslagen en andere persoonlijke documenten van die persoon inzien, constateerde de user.

Medetweaker Slurpgeit constateerde naar aanleiding van de posting naast deze slordigheid een kwalijker euvel: de portal bleek ook kwetsbaar voor sql-injectie. Via deze kwetsbaarheid was het mogelijk bij de database achter de portal te komen en zo de betreffende documenten te benaderen. Ook bleek het mogelijk om een tabel met burgerservicenummers te raadplegen.

Het lek zat dus niet in gemeentesites zelf, maar in een externe site waar gemeenten naar verwijzen op hun pagina voor inwoners die hun documenten in willen zien. De sql-injectie was mogelijk op getimg.php, een functie die het logo van de gemeente ophaalde, maar dankzij het lek ook toegang bood tot een database met persoonlijke gegevens.

De tweaker lichtte Data B Mailservice in over de kwetsbaarheid, het bedrijf dat verantwoordelijk is voor het portaal. Dat bedrijf is gespecialiseerd in fysieke en digitale documentstromen. "Na contact met de ontwikkelaar hebben zij adequaat gehandeld, het lek binnen enkele uren gedicht en de portalen uitgeschakeld", meldt de user.

Steven Jansen, Hoofd ICT bij Data B, bevestigt een melding gekregen te hebben over de kwetsbaarheid en deze verholpen te hebben. De gemeente Oldambt gebruikte volgens hem tegen het advies van Data B in bsn's als inlogoptie: "De gemeente in kwestie gebruikte een verouderde omgeving, waar zonder digid op ingelogd kon worden. Dit is een methode die in het AVG-tijdperk niet meer wenselijk is, en wij hebben alle gemeenten waarmee wij samenwerken eerder reeds geadviseerd een koppeling te maken met digid-login."

In totaal gebruikten zes gemeenten andere loginmethoden dan digid via het portaal, maar alleen Oldambt deed dat met bsn's. De andere vijf werkten op basis van een combinatie van aanslagnummer en bedrag, volgens Jansen. Ook bij deze gemeenten was het mogelijk om na sql-injectie de achterliggende database te raadplegen. De zes gemeenten ontsluiten hun documenten sinds deze week niet meer via het portaal maar via MijnOverheid.

In totaal hadden 189 gemeenten een portal bij Data B met als url gemeentenaam.datab.nl, blijkt uit een inventarisatie. Op al die sites was sql-injectie mogelijk, maar alleen bij de zes sites met verouderde omgeving kon daarbij de database benaderd worden, aldus Jansen. "Alle klanten die gebruikmaken van de veilige digid-variant van de portal worden op een ander platform ontsloten. Het klopt dat dit ook leidde tot een gemeentenaam.datab.nl die online staat, maar de documenten van de digid-portal staan in een andere database. Deze hangt achter een andere applicatie, die alleen vanuit de gemeentedomeinen benaderbaar is. De digid-portal wordt jaarlijks aan een verplichte audit inclusief pentests onderworpen."

Volgens Data B is geen misbruik gemaakt van de sql-injectie: "Wij hebben vastgesteld dat alleen op de portal van de betreffende gemeente requests met sql-injectie zijn afgevuurd." Het bedrijf claimt dat alleen woz-documenten in de database staan en dat deze niet ongeautoriseerd inzichtelijk waren omdat ze versleuteld in de database stonden. Niet duidelijk is van hoeveel burgers de zes gemeenten documenten ontsloten via het betreffende portaal.

Reacties (51)

[WeirCo]

Wat betreft het gebrek aan een DigiD login vóór dit portaal, had allang geregeld moeten worden door de betreffende gemeenten. Het nog aanbieden van een (onveilige) mogelijkheid zonder DigiD had je als bedrijf ook kunnen uitschakelen, nu zijn er willens en wetens risico's genomen. Zo'n SQL injectie zou in deze tijd niet meer moeten kunnen voor komen.

Naast dit vind ik dat het belachelijk is welke tarieven er gerekend worden door de overkoepelende organisatie Logius, van de website:

- DigiD: 0,138 euro per succesvolle authenticatie, exclusief btw
- DigiD Machtigen: 0,732 euro per gebruik machtiging exclusief btw
- MijnOverheid: 0,40 euro per verwerkt bericht exclusief btw

Deze kosten worden dus doorberekend aan de organisaties die DigiD inloggen/machtigen en / of de MijnOverheid berichtenbox gebruiken. Reken hierbij de jaarlijkse audits die Logius vereist bij elke organisatie (en nog per koppeling) voor het gebruik van DigiD, kost de gemeenschap al met al ook een boel geld.

[Verwijderd]

Reken hierbij de jaarlijkse audits die Logius vereist bij elke organisatie (en nog per koppeling) voor het gebruik van DigiD, kost de gemeenschap al met al ook een boel geld.

Gelukkig is Logius een dienst van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties; het geld wat betaald wordt vloeit dus terug naar de staatskas.

[RobbieB]

Precies. De Digi-D infrastructuur en ontwikkelingen kosten geld. Dit is gewoon de manier van de overheid om deze kosten door te belasten... een stuk praktischer dan allerlei administratieve constructies met naberekeningen en wat nog meer.

[widodepido]

ze zouden het net als de KVK uit de gemeentefonds kunnen halen. kvk gegevens opvragen door gemeenten wordt uit het gemeentefonds betaald. Nu factureert Logius alle gemeentelijke aansluitingen apart. Lekker inefficient. Ze zullen wel een reden hebben.

[Mmore]

DigiD is er niet alleen voor gemeentes. Denk aan bijvoorbeeld zorg instellingen of zbo's die gebruik maken van de dienst. Dit lijkt mij een redelijk slimme manier om de kosten te verdelen.

[latka]

Het is gewoon een verkapte belastingverhoging: die DigiD kosten zitten gewoon in de producten.

[incaz]

Ja, de basterds. Waarom verschijnt nuttige infrastructuur niet gewoon graties uit het niets?

[latka]

Dat niet, maar als je landelijk verplicht om DigiD te gebruiken is het wel zo netjes de lasten hiervan te dragen ipv. via Logius per transactie af te laten rekenen.

[dewaal06]

Dat terugvloeien zou een gesloten cirkel moeten zijn, maar de Rijksoverheid besteedt steeds meer zaken uit naar lagere overheden. Waardoor ook deze kosten in feite 'winst' zijn op landelijk niveau. Als er landelijk echt op een digitale overheid gestuurd zou worden, zouden die tarieven nihil moeten zijn voor collega-overheden.

[F-I-X]

*Als* er nog wat voor overblijft na aftrek van "kosten"

[WeirCo]

Jaa audits uitvoeren kost alleen aan de kant van Logius tijd en geld, daar hoeft de "afnemende" organisatie natuurlijk niets voor te doen. Ik snap je gedachtegang, maar het is niet zo dat alle gerelateerde kosten terugvloeien. Een significant deel betaalt de belastingbetaler toch echt zelf.

[Verwijderd]

Alles betaalt de belastingbetaler.
Jij leek in jouw post echter te impliceren dat overheden veel geld moeten betalen aan een 3e partij, en dat dat bedrijf, en dus de aandeelhouders en/of eigenaren van dat bedrijf er alleen maar beter van worden.

Alleen dat probeerde ik duidelijk te maken; er wordt geen externe partij beter van.
Al het geld wat naar Logius gaat zal voor het overgrote deel naar de salarissen van de ambtenaren en de verdere 'algemene kosten' van Logius gaan.

Het kost daarmee 'de gemeenschap' als geheel geen extra geld. Wel gaan middelen die eerst lokaal beschikbaar waren (budget van een gemeente bijvoorbeeld) naar één rijks-onderdeel: Logius.
Alleen zou dat, doordat we validatie gecentraliseerd hebben, wel eens efficiënter kunnen zijn als dat deze 'dienst' versnipperd zou worden aangeboden door allerlei losse diensten, of door specialisten bij verschillende andere rijksonderdelen.

Sterker nog: doordat ook bijvoorbeeld pensioenfondsen en zorg-aanbieders en -verzekeraars gebruik maken van de dienst (en deze dus ook financieel bijdragen) maakt dit Digid als totaal vermoedelijk zelfs goedkoper.
Dus inderdaad: in alle gevallen betaalt de consument, óf als klant, óf als belastingbetaler.
Maar is dat niet zo met alles waar we gebruik van maken?

[harrytasker]

Er is niets makkelijker dan andermans geld uitgeven....

[QaZ.]

Ik zie dat niet alleen gemeenten hier gebruik van maakten. maastrichtuniversity.datab.nl komt er ook in voor en nee geen DigID op die pagina.

[Noxious]

Het gaat absoluut al mis bij het gebrek aan DigiD.

De implementatie daarvan voor een portaal als deze is bijna kinderlijk eenvoudig (technisch gezien, los van de security audit) en dan krijgt je website uiteindelijk gewoon een BSN binnen - dat had dus perfect geweest.

De SQL-injectie is natuurlijk olie op het vuur. Het voorkomen daarvan binnen PHP applicaties is ook geen rocket science en echt les 1 voor iedere ontwikkelaar die ook maar iets met SQL gaat doen. Best wel bizar dus.

Edit: het excuus dat het een oude omgeving is gaat m.i. niet op.
Dit soort omgevingen is kritisch en zou je normaliter jaarlijks opnieuw moeten beoordelen op de dan geldende veiligheidseisen. SQL injection is een bekend probleem sinds 1998(!).

[Reactie gewijzigd door Noxious op 22 juli 2024 13:29]

[Zebby]

Ik ga er even van uit dat een kleine gemeente die een portaal van derden gebruikt geen ontwikkelaar heeft zitten die even een koppeling met DigiD in elkaar weet te flansen. Echt kinderlijk eenvoudig is dat niet.
Daarentegen heeft Data B blijkbaar deze koppeling beschikbaar, en hebben zij de gemeente gewaarschuwd. Klinkt eerder als een kwestie van de gemeente die de centen er niet voor over had. DigiD is niet bepaald gratis (meer).

SQL injectie is wat mij betreft geen excuus, oude software of niet, dat hoor je bij te houden. Daar betalen ze zeer waarschijnlijk onderhoudskosten voor.

[Noxious]

Het gaat duidelijk niet om enkel kleine gemeenten hoor, ik zou zeggen probeer er een paar op de manier die @virtualite beschrijft (gemeentenaam.datab.nl).

Technisch zijn er genoeg SAML2 modules/libraries beschikbaar voor PHP; of het kan zelfs een losse applicatie zijn die de BSN uit de artifact haalt en door-POST naar het aanmeldformulier met een reverse proxy er voor (al weet ik niet zeker of dit volgens de jaarlijkse DigiD-assessment mag).

Edit:
(Oh en, de gemeente hoeft dit niet te ontwikkelen maar de leverancier. De gemeente moet wel de aansluiting aanvragen en de opdrachtgever zijn.)

[Reactie gewijzigd door Noxious op 22 juli 2024 13:29]

[widodepido]

eens. DataB had aan z'n zorgplicht moeten voldoen. Uitfaseren en dat gemeenten geen digid gebruiken is natuurlijk helemaal van de zotte.

[Tozz]

De ontwikkelaar geeft al aan dat dit om hele oude applicaties gaat. Misschien nog wel PHP4, PHP5? Geen PDO in ieder geval. Als je die rommel online houdt om legacy redenen maar er verder geen aandacht meer aan besteed dan is dit een risico.

[Noxious]

Als je die rommel online houdt om legacy redenen maar er verder geen aandacht meer aan besteed dan is dit een risico.

Ja en daar zit precies het probleem. Het gemeentelandschap zit vol met certificeringen, audits, noem maar op.

Wat de techniek betreft:
Ook ten tijde van PHP4 waren er al manieren om SQL-injectie tegen te gaan zoals mysql_real_escape_string en met de komst van de MySQLi-module waren prepared statements de standaard (en voor diegenen die dit niet gebruikten, was een vergelijkbare methode beschikbaar).

[SherlockHolmes]

Welke gemeenten?

[virtualite]

Probeer je gemeentenaam.datab.nl.

De mijne stond er in ieder geval bij. Of het om de verouderde versie gaat weet ik niet. Hij is alleen "offline".

[Reactie gewijzigd door virtualite op 22 juli 2024 13:29]

[ro4sho]

Werkt helaas niet meer

[Noxious]

Hmm voor mijn gemeente (Wageningen) nog wel: https://wageningen.datab.nl

[Reactie gewijzigd door Noxious op 22 juli 2024 13:29]

[ro4sho]

Als ik er op klik krijg ik : 'Deze omgeving is niet beschikbaar'

[Noxious]

Dat klopt:

"Na contact met de ontwikkelaar hebben zij adequaat gehandeld, het lek binnen enkele uren gedicht en de portalen uitgeschakeld"

Maar het maakt wel duidelijk dat dit een van de getroffen portalen was.

[ro4sho]

Ah zo, ik snap hem!

[Jerie]

Vreemd dat dat nergens wordt aangegeven.

Is er melding gemaakt naar AP?

[Mike2k]

Is natuurlijk leuk dat hij eerst even opmerkt dat 'de gemeenten tegen advies in het BSN gebruikten'. Das operatie straat schoonvegen voltooid.

Het is compleet schandalig dat een site anno 2020 nog vatbaar is voor SQL injectie...

[Zebby]

Wat moet je dan als bedrijf, maar zeggen dat ze op moeten hoepelen? Als ze dit inderdaad op papier hebben staan en de klant wilt niet het geld uitgeven voor een DigiD koppeling, hoe is dat dan de schuld van het bedrijf?

SQL injectie wel 100% eens.

[t link]

Als bedrijf heb je een bepaalde standaard hoog te houden ook voor jezelf. dat ik wil betalen voor advertenties voor shady porno en grote piemel pillen betekend ook nog niet dat google dat gaat accepteren. Dat is waarom mensen dit het bedrijf aanrekenen, ze wisten dat het niet goed was en toch hebben ze erin mee gewerkt. op die manier kan je ook makkelijk alle bommen en wapen fabrikanten schoonvegen van schuld, terwijl die toch echt wel een groot deel van het probleem zijn.

[Zebby]

Een web bouwer die een twijfelachtige login toestaat onder voorwaarde dat klant verantwoordelijk is vergelijken met wapen fabrikanten... Nee, sorry.
Het is ook niet alsof dat bedrijf zomaar zijn diensten stop mag zetten, en een procedure starten om je klant te dumpen staat ook echt heel goed.

Bedrijf> Dit is niet veilig meer, ga over of accepteer alle verantwoordelijkheid.
Klant> Wil niet/te duur/te lastig/niet nodig.
Bedrijf> Not my problem anymore.

[kodak]

Als een bedrijf diensten levert waarbij ze kennelijk enigszins bewust faciliteren in een risicovolle en mogelijk zelfs verboden situatie is het maar de vraag of het bedrijf daarin geen grond of zelfs plicht heeft om een dienst tijdelijk te stoppen of zelfs te ontbinden. Waarom ze het in stand gehouden hebben valt alleen naar te raden zolang het bedrijf daar geen uitsluitsel over geeft.

[d4v1d]

Leuke en nette uitleg van de leverancier. Zie je niet vaak.

[Yoshi]

Klopt dat vind ik ook, mag zeker ook eens gezegd worden.

[widodepido]

Das geen leuke vrijmibo voor die jongens bij datab. Hebben ze nu hun hele omgeving uit de lucht gehaald. Ben benieuwd of hun koppelvlakken en iframe integraties ook zo veilig zijn. Ze doen heel veel voor gemeenten. Versturen van aanslagen via allerlei kanalen zoals mijnoverheid, post, email, efacturen etc . Bij ons doen ze nog lekker met de post zo'n mooi bruin blauwe brief in je brievenbus met een betaal QR code en via een ander Digid platform kunnen mensen ook hun aanslag downloaden. Superhandig.

[karma4]

Heel vreemd om een nietszeggend BSN nummer wat als doel heeft persoonsverwisselingen te voorkomen in overheidsadministraties als een gevoelig gegeven te zien. Dat is niet volgens de wet gebruik BSN.

[remmh01]

Ok, Dan heb je een bsn te pakken van een zzp’er of eenmanszaak. Wát kan je daar dan mee. Zonder geldig ID-bewijs (paspoort, rijbewijs oid) kan je er niks mee. Ik ken althans geen voorbeelden.
Het feit dat er nu geen bsn meer in een btw-nummer staat....een beetje ondernemer kent een fiscaal opgelegde bewaarplicht van 7 jaar en beschikt al die tijd dus nog over het bsn van zijn afnemer/leverancier.
En ná die 7 jaar zoekt hij het wel op via de wayback.org site.

[ajolla]

Is er nog iets dat NIET lek is?