Minister: aanvallers konden DigiD-database stelen
Door het beveiligingslek in Ruby on Rails zou het voor aanvallers mogelijk zijn geweest om een deel van de DigiD-database te stelen, zo heeft minister Plasterk tijdens het vragenuur in de Tweede Kamer laten weten. Hij benadrukt dat de kwetsbaarheid waardoor DigiD op 9 januari offline ging, in het onderliggende platform zat en niet in DigiD zelf. Vanwege de ernst werd besloten DigiD offline te halen.
"Bij dat besluit speelde ook de overweging mee dat men voorzag dat het mogelijk was om binnen enkele uren dat eventuele lek te dichten en die kwetsbaarheid te verhelpen. Dat is toen onmiddellijk ook breed gecommuniceerd zodat iedereen daarvan wist", aldus Plasterk. Via DigiD kunnen burgers zich bij allerlei overheidsdiensten authenticieren.
"Het is inderdaad gelukt om diezelfde dag nog, eerder dan gepland overigens, DigiD weer in de lucht te brengen, waardoor mensen maar een aantal uren storing hebben ervaren." Volgens de minister is er geen enkele reden om te denken dat kwaadwillenden van het lek in het DigiD-platform misbruik hebben gemaakt.
Preventief
"Het was uitsluitend preventief. Ik denk dat er direct en adequaat is ingegrepen. Als dat iets illustreert, is het wel dat er voldoende waakzaamheid is om ervoor te zorgen dat DigiD veilig genoeg is. Nogmaals, er zijn geen gegevens opgehaald voor zover men dat kan achterhalen."
Er zou nog wel een onderzoek lopen om dit definitief te bevestigen. Plasterk krijgt daar deze week het laatste uitsluitsel van. Laat ik toezeggen dat ik daarvan een afschrift naar de Kamer zal sturen. Ik denk dat het goed werkt. Is het onberispelijk? Niets in het leven is helemaal onberispelijk, maar ik denk dat het zo goed is als kan."
Twijfel
Ondanks het beveiligingslek heeft Plasterk naar eigen zeggen geen reden om te twijfelen aan de degelijkheid van DigiD. "Ik ben er dus niet aan toe om DigiD te gaan heroverwegen. Dat signaal zou ik hier helemaal niet willen geven. Nogmaals, er is geen sprake van een lek. Er heeft niets gelekt."
De minister spreekt van een potentieel lek dat onmiddellijk is gedicht. "Men ziet daar dus op toe. Het blijft een ratrace tussen mensen die beveiligen en mensen die proberen door die beveiliging heen te komen. En die is ook deze keer gewonnen door DigiD."
ik zeg maar niets meer.
DigID is qua ontwerp niet het sterkste wat je kan verzinnen, maar de mensen die verantwoordelijk zijn voor de uitvoering kan je in dit geval niet bekritiseren. Sterker nog, ik vind dat ze een pluim verdienen en dit als voorbeeld binnen de overheid gebruikt moet worden om aan te tonen dat het wel degelijk mogelijk is om snel en adequaat te handelen als je je organisatie op orde hebt. Er zijn nog genoeg overheidsorganisaties waar ze het lang niet zo goed op orde hebben als in dit geval. Het kan kennelijk met het budget wat ze krijgen wel goed, dus laten die andere overheidsinstellingen hier lering uit trekken.
Maar dat terzijde, het is niet zo raar dat veel mensen toch een geringe vorm van zenuwachtigheid over zich heen krijgen, je verwacht dat hetgeen waarmee je jezelf authenticeert bij de overheid, belastingdienst, zorgverzekeraars etc. erg solide en betrouwbaar is. Dit geeft gewoon geen goed gevoel. Zeker daar nog niet zo'n lang geleden we het DigiNotar Debâcle hadden.
De hackers hadden de DigID database kunnen downloaden, dan vraag ik me toch af:
A) hoe weten we zeker dat men dit niet heeft gedaan (niet aan de hand van een log van een mogelijke gecompromiteerd systeem naar ik hoop)
B) Kan er misbruik gemaakt worden van deze DB ?
Kijk, welke opties heeft men dan wel? Zelf opnieuw het wiel uitvinden en een nieuw framework als RoR maken? Dat betekent: ontwikkelkosten, bevat nieuwe bugs, kosten om mensen voor dit onbekende framework te trainen, en zo voort. Lijkt me ook niet zaligmakend.
Hoe lang het lek er was?
Wanneer ze de patch hadden?
En of ze dus goed hebben gereageerd?
ik zeg maar niets meer.
Om te huilen gewoon deze reactie.
ik zeg maar niets meer.
goed om te zien dat sommige mensen wél oplettend zijn +1
on topic:
Leuk dat de overheid nu weleens wakker was, en niet bleef slapen. zoals whizzman al zei: deel maar 'n pluimpje uit hoor.
Kijk, welke opties heeft men dan wel? Zelf opnieuw het wiel uitvinden en een nieuw framework als RoR maken? Dat betekent: ontwikkelkosten, bevat nieuwe bugs, kosten om mensen voor dit onbekende framework te trainen, en zo voort. Lijkt me ook niet zaligmakend.
wie wat goeds wil, zal dr z'n portemonnee voor moeten trekken. 't zou geen gek idee geweest zijn, hoewel de mensen van digid goed gereageerd hebben op dit probleem. liever goed getrainde vaklui, dan grote risico's blijven lopen, en maar wachten tot er een hacker optreed die allemaal dubieuze dingen uithaalt met onze Digid gegevens.. ik bedoel zulke voorbeelden hebben we in t verleden al gehad toch?
ik zou voor 'n ander alternatief voor digid zijn.
En dan hoor je Brussel niet hé?
nee inderdaad. alleen maar hackforums geratel.
ik zeg maar niets meer.
Tx :)
ik zeg maar niets meer.
Om te huilen gewoon deze reactie.
ik zeg maar niets meer.
goed om te zien dat sommige mensen wél oplettend zijn +1
on topic:
Leuk dat de overheid nu weleens wakker was, en niet bleef slapen. zoals whizzman al zei: deel maar 'n pluimpje uit hoor.
Is het dus wel een Chrome-probleem??
Men zegt dat men de database had kunnen stelen. Dat betekent hoogstwaarschijnlijk dat die database rechtstreeks aan de webapplicatie hing, wat bij RoR ook voor de hand ligt. Zelf zou ik daar liever een stap aan toevoegen: maak een goed afgeschermde applicatieserver die het handjevol benodigde service-calls, en niets meer, beschikbaar stelt aan de webserver. Er zal vermoedelijk op de achtergrond ook een interactie zijn tussen bijvoorbeeld een gemeentelijke website en DigID als een burger aanlogt. Als het uiteindelijk bij een applicatieserver bij elkaar komt hoeft dat niet via de DigID-website die de burger ziet te lopen.
Verschillende componenten kunnen op verschillende platforms worden gebouwd, en als het voor de burger zichtbare deel inderdaad zo beperkt is als ik denk dan kan je daar zelfs een paar implementaties van maken zodat bij problemen met het actieve platform je direct over kan schakelen op een platform dat die problemen niet deelt. Als ik bedenk dat ik ooit met een groep van zo'n 7 mensen een webapplicatie ontwikkelde en beheerde die qua functies in de user-interface uiteindelijk denk ik zowat 100 keer zo groot was als wat ik hier zie, gebouwd in het naar hedendaagse maatstaven primitieve klassieke ASP, dan zou dat toch moeten kunnen voor zo'n centrale functie. Voor het onderdeel wat je als burger te zien krijgt dus, kaal de authenticatiefunctie en die paar instellingen. Van andere functies vind ik ook niet dat ze op dezelfde website thuishoren.
Wat mij zorgen baart is dat er blijkbaar via de client toegang tot de database kan worden verkregen. Naar mijn mening horen databases vanaf Internet gewoon niet bereikt te kunnen worden.
Ten eerste moet elke controle die in de client wordt gedaan, op de server nog eens dunnetjes over worden gedaan.
Ten tweede moet de server ook nog niet eens direct op de database kunnen queryen, maar een fatsoenlijke service gebruiken die de database benadering abstraheert. En die service mag geen functionaliteit bieden om hele databases te kunnen benaderen.
Dat gecombineerd met fatsoenlijke scheiding tussen de verschillende zones (DMZ , isolatiezone, intern netwerk, etc.) waardoor de database zeker niet direct te benaderen is.
Knappe aanvaller die daar dan nog doorheen komt.
Of zeg ik hier nu iets raars?
Helemaal niet! Ik wou net zo een reactie schrijven na lezing van het artikel.
Juist omdat deze dienst zo centraal staat in het autenticatie verhaal zou de architectuur dat moeten reflecteren door 'defense in depth' attributen. Dat DigiD kwetsbaar is voor RoR kwetsbaarheden lijkt aan te geven aan dat hier met de pet naar is gegooid. (Misschien is dit weer een gevalletje openbare aanbesteding tegen laagste prijs: de beunhazen komen zo boven drijven.)
Mensen kunnen hier nog zo vaak schrijven dat er goed is gehandeld door de beheerders, ik stel dat dat niet helpt zolang je applicatie zo knullig in elkaar steekt. Het is vergelijkbaar met security-through-obscurity: het werkt even maar je vaart blind op het moment dat het gecompromitteerd is door een kwaadwillende parij.
Dinsdagavond werd het beveiligingsprobleem bekend; woensdagmorgen was Logius op de hoogte en werd ervoor gekozen om het systeem offline te halen. Dat betekent dat DigiD vannacht dus kwetsbaar was.
De belangrijke vraag is of het lek eerder bekend was bij black hats...
Verder eens met opmerkingen hierboven over scheiden database maar ook over snelle optreden overheid.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?