Overheid haalt DigiD offline vanwege ernstig beveiligingsprobleem - update
De overheid heeft het authenticatieplatform DigiD offline gehaald nadat er een beveiligingsprobleem in Ruby on Rails is ontdekt. Het zou gaan om een 'ernstig lek'. Het platform is waarschijnlijk donderdag pas weer online.
Op zijn website geeft DigiD op dit moment enkel de mededeling weer dat de site 'op dit moment niet beschikbaar' is. Woordvoerder Michiel Groeneveld van Logius, de ict-organisatie van de overheid, bevestigt dat dat het gevolg is van een beveiligingsprobleem, zoals Nu.nl eerder ontdekte.
Het gaat om een ernstig beveiligingsprobleem: daarom is ervoor gekozen om het systeem offline te halen. "We wilden het zekere voor het onzekere nemen", aldus Groeneveld. "Met de downtime willen we misbruik voorkomen en de patch kunnen uitrollen en testen." Het uitrollen van de patch moet wat Logius betreft zo zorgvuldig mogelijk gebeuren. "We willen niet met een patch een ander beveiligingsprobleem veroorzaken", aldus Groeneveld.
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. "Daar gaat wat tijd overheen. Je gaat ook niet zomaar DigiD uit de lucht halen." Het gaat om twee lekken waarvoor Ruby on Rails dinsdag een patch uitbracht. Volgens het Nationaal Cyber Security Centrum maken die kwetsbaarheden het onder meer mogelijk om authenticatie te omzeilen, sql-injecties uit te voeren, eigen code op afstand uit te voeren en een denial of service-aanval uit te voeren.
Vorige week brachten de ontwikkelaars van Ruby on Rails ook al een beveiligingspatch uit naar aanleiding van een beveiligingsprobleem. Op Digid.nl is te lezen dat de dienst waarschijnlijk pas donderdagmorgen weer te gebruiken is.
Update, 15:27: Reactie Logius toegevoegd.
Reacties (104)
Op NU.nl word gesproken dat de lek in het platform onder DigID zit en niet in DigID zelf. dus na mijn weten kan de overheid hier vrijweinig aan doen aangezien zij in deze gewoon afnemers zijn van een dienst. Dus ik vind dat hier niet de overheid beschuld dient te woren van weer een slecht project. als het echt in de onderliggende systemen van DigID ligt.
En er kunnen altijd fouten worden worden gemaakt, een ICT project waarbij je later geen patches of aanpassingen in hoeft te doen bestaan gewoon weg niet.
En er kunnen altijd fouten worden worden gemaakt, een ICT project waarbij je later geen patches of aanpassingen in hoeft te doen bestaan gewoon weg niet.
Systemen
Het bijwerken van de systemen kan enkele uren duren. "Dat moeten we zorgvuldig doen om eventuele ongewenste neveneffecten van de update uit te sluiten", aldus de zegsman. Hij benadrukt dat de problemen niet in DigiD zelf zitten maar in het platform, waarop de dienst is gebouwd.http://www.nu.nl/internet...line-lek-in-platform.html
Gelukkig is de helft van e-herkenning ook offline, gezien de briljante makers van DigiD natuurlijk zelf ook Rails gebruiken, en www.digidentity.eu offline is.
Sorry hoor, maar de grootte van de gevonden lekken in rails over de afgelopen weken toont wederom aan dat het misschien een mooi platform is voor webdevelopment, maar dat het absoluut geen geweldig idee is om het te gebruik voor mission-critical systemen zoals DigiD. Je API iedere versie omgooien, iedere 2 jaar een nieuwe webserver implementatie hebben, en zoveel mogelijk dynamisch en zonder typing doen is leuk voor snel en dynamisch developen. Maar wat moet DigiD nu helemaal kunnen? Een username en wachtwoord bijhouden en een beetje SAML doen. Daar moet je gewoon een zo simpel mogelijk platform voor zoeken, wat zichzelf al jaren heeft bewezen, waar een commerciële vendor achter zit voor de support en waar je de komende 20 jaar nog support op hebt.
Sorry hoor, maar de grootte van de gevonden lekken in rails over de afgelopen weken toont wederom aan dat het misschien een mooi platform is voor webdevelopment, maar dat het absoluut geen geweldig idee is om het te gebruik voor mission-critical systemen zoals DigiD. Je API iedere versie omgooien, iedere 2 jaar een nieuwe webserver implementatie hebben, en zoveel mogelijk dynamisch en zonder typing doen is leuk voor snel en dynamisch developen. Maar wat moet DigiD nu helemaal kunnen? Een username en wachtwoord bijhouden en een beetje SAML doen. Daar moet je gewoon een zo simpel mogelijk platform voor zoeken, wat zichzelf al jaren heeft bewezen, waar een commerciële vendor achter zit voor de support en waar je de komende 20 jaar nog support op hebt.
Je hebt denk ik deels wel gelijk. Maar aan de andere kant onderschat je denk ik wat DigiD allemaal moet kunnen.
En een paar punten die je noemt (API omgooien, webserver-implementatie) heeft niet zoveel met het gebruikte framework te maken, maar meer met de beslissingen die de ontwikkelaar en de systeembeheerders nemen denk ik.
Verder heeft het natuurlijk ook weer heel veel voordelen. Wat je zegt: Dynamisch, volledig open-source. Je hebt ook bij een 'commerciele vendor' nooit de garantie op 20 jaar support. In dit geval kan de overheid de code bij een andere partij dumpen en die zijn er zo in thuis. Zeker als ze de de principes van Ruby-on-Rails een beetje in ere hebben gehouden.
Beveiligingsproblemen ga je altijd houden, en 'elk voordeel heb z'n nadeel'
En een paar punten die je noemt (API omgooien, webserver-implementatie) heeft niet zoveel met het gebruikte framework te maken, maar meer met de beslissingen die de ontwikkelaar en de systeembeheerders nemen denk ik.
Verder heeft het natuurlijk ook weer heel veel voordelen. Wat je zegt: Dynamisch, volledig open-source. Je hebt ook bij een 'commerciele vendor' nooit de garantie op 20 jaar support. In dit geval kan de overheid de code bij een andere partij dumpen en die zijn er zo in thuis. Zeker als ze de de principes van Ruby-on-Rails een beetje in ere hebben gehouden.
Beveiligingsproblemen ga je altijd houden, en 'elk voordeel heb z'n nadeel'
De basis van DigiD is gewoon een SAML identity provider, niet meer en niet minder. Dat is geen rocket science, alhoewel SAML messages parsen wel een naar werkje is. Het probleem is alleen dat er vervolgens allerlei andere toeters en bellen aan zijn gehangen, en dat er ivm backward compatibility ook nog A-Select gesupport moet worden (want iemand had ooit verzonnen dat een willekeurig Nederlands product pakken een veel beter idee was dan een open standaard). Dat maakt het geheel een stuk complexer en foutgevoeliger.Maar aan de andere kant onderschat je denk ik wat DigiD allemaal moet kunnen.
Niet echt. Rails breekt iedere major release best veel van hun public APIs, wat het arbeidsintensief maakt om je applicatie continu op de laatste Rails versie te houden. Er zijn dan ook nog best veel apps die nog op 2.3.x draaien. Dat het landschap versnippert is valt ook wel af te leiden uit het feit dat er voor 4(!) major versies een security update is uitgebracht.En een paar punten die je noemt (API omgooien, webserver-implementatie) heeft niet zoveel met het gebruikte framework te maken, maar meer met de beslissingen die de ontwikkelaar en de systeembeheerders nemen denk ik.
De gebruikte webserver heeft meer te maken met de voorkeuren van de beheerder, en sinds er Rack is ben je redelijk vrij in de keuze van je webserver. Passenger is een redelijke standaard, maar thin begint nu ook aan populariteit te winnen (zie https://www.ruby-toolbox.com/categories/web_servers). En je kan daar wel van zeggen dat je hier zelf kan kiezen, maar uiteindelijk zul je toch over moeten als je support wilt houden en bepaalde projecten uitsterven (zoals met Mongrel is gebeurd).
Open-source betekent niet automatisch dat er geen commerciële vendor achter zit. Het is simpelweg een algemeen bekend feit dat er erg weinig mensen zijn die full-time aan Rails developen, en dat er afgelopen weekend dus wat mensen volledig vrijwillig security fixes hebben moeten kloppen. Alle lof daarvoor natuurlijk, maar om DigiD daar nou van afhankelijk te maken. Zelf zit ik meer in de Java wereld, waarbij het Spring Framework veel gebruikt wordt. Volledig open-source, maar tegelijkertijd commerciële support van SpringSource/Vmware. Zo zijn er meer van die voorbeelden.Verder heeft het natuurlijk ook weer heel veel voordelen. Wat je zegt: Dynamisch, volledig open-source. Je hebt ook bij een 'commerciele vendor' nooit de garantie op 20 jaar support. In dit geval kan de overheid de code bij een andere partij dumpen en die zijn er zo in thuis.
Tsja, Java, dan moet je een kwartaal op Oracle wachten voordat er kritieke lekken gefixt worden.
http://threatpost.com/en_...ruary-patch-update-101712
http://threatpost.com/en_...ruary-patch-update-101712
[Reactie gewijzigd door alef op donderdag 10 januari 2013 00:24]
Ja, alleen heeft dit bar weinig betrekking op webapplicaties, gezien het om een sandbox lek gaat. Een taal als Ruby heeft niet eens een sandbox, dus de vergelijking gaat nogal mank.
Nee, maar het geeft wel aan hoe een commerciële vendor waar je van afhankelijk bent omgaat met security.
Ach, ik denk dan ook dat er niemand in de Java wereld blij is met Oracle. Tegelijk denk ik dat er zeer zelden bugs in Java remote exploitable zullen zijn in het geval van webapps, en dat als ze er zijn deze bijna altijd te patchen zijn door een derde. Wat dat betreft is er geen afhankelijkheid van Oracle.Nee, maar het geeft wel aan hoe een commerciële vendor waar je van afhankelijk bent omgaat met security.
Afhankelijk van de leverancier zou je zijn als de software closed-source is, bijvoorbeeld met de MS/Windows/.NET stack. Het is wat mij betreft daarom ook erg belangrijk dat je stack open-source is, maar daarnaast is wat commerciële support toch mooi meegenomen wanneer mogelijk.
"Foutje, bedankt, graag gedaan". Leuk weer dit. Net nu ik formulieren moet invullen.
Permanent? 
Vandaag maar even met mijn DogID inloggen
Over wie heb je het?
Als je het over de overheid hebt, dan is het wel terecht dat je weggemod wordt. Hier konden ze namelijk niet echt veel aan doen.
Maar als je het over RoR hebt (waar ik helaas niet van uit ga) dan vind ik je opmerking best terecht. Het is een super mooi framework maar het wordt de laatste tijd wel vaak geplaagd door kritieke fouten en spoed-updates. Als ik een groot RoR project in productie had draaien, zou ik daar toch een beetje zenuwachtig van worden.
Als je het over de overheid hebt, dan is het wel terecht dat je weggemod wordt. Hier konden ze namelijk niet echt veel aan doen.
Maar als je het over RoR hebt (waar ik helaas niet van uit ga) dan vind ik je opmerking best terecht. Het is een super mooi framework maar het wordt de laatste tijd wel vaak geplaagd door kritieke fouten en spoed-updates. Als ik een groot RoR project in productie had draaien, zou ik daar toch een beetje zenuwachtig van worden.
Het gaat hier niet om de bug van een week geleden.
Daarvoor was RoR 3.2.10 (onder andere) al voor uitgebracht. Dat probleem was niet zo groot, en met een simpele code-check kon je controleren of actie nodig was.
Het gaat om een andere bug. Zie deze blogpost: http://weblog.rubyonrails...-3-15-have-been-released/
Direct updaten is het advies!
Ik was met mijn twee laagcomplexe mini-apps zo klaar. Zij zijn waarschijnlijk nog even aan het testen (zoals het hoort) voordat ze de upgrade en eventuele wijzigingen in de code kunnen pushen.
Iedereen die weet dat DigiD op RoR (of componenten daarvan) draait zou dit lek dus kunnen proberen te misbruiken.
Dat betekent dus helemaal niet dat dit een aanwijzing is dat het lek al misbruikt is.
Offline halen is dus het beste wat ze even kunnen doen! Goede en snelle respons van de overheid (voor de verandering)!
Daarvoor was RoR 3.2.10 (onder andere) al voor uitgebracht. Dat probleem was niet zo groot, en met een simpele code-check kon je controleren of actie nodig was.
Het gaat om een andere bug. Zie deze blogpost: http://weblog.rubyonrails...-3-15-have-been-released/
Direct updaten is het advies!
Ik was met mijn twee laagcomplexe mini-apps zo klaar. Zij zijn waarschijnlijk nog even aan het testen (zoals het hoort) voordat ze de upgrade en eventuele wijzigingen in de code kunnen pushen.
Iedereen die weet dat DigiD op RoR (of componenten daarvan) draait zou dit lek dus kunnen proberen te misbruiken.
Dat betekent dus helemaal niet dat dit een aanwijzing is dat het lek al misbruikt is.
Offline halen is dus het beste wat ze even kunnen doen! Goede en snelle respons van de overheid (voor de verandering)!
[Reactie gewijzigd door NovapaX op woensdag 9 januari 2013 13:35]
Hier nog wat interessant leesvoer wat ik vond over het exploiteren van het lek: http://www.insinuator.net/2013/01/rails-yaml/
(use at own risk)
(use at own risk)
[Reactie gewijzigd door Sniffert op woensdag 9 januari 2013 13:44]
Wat mij verbaast is dat er een Single Point of Failure is met de communicatie naar de overheid.
Je MOET voor veel zaken DigiD gebruiken.
Wat als dat nu eens langdurig plat ligt?
Dat staat me ook tegen met dat hele OV chipkaart gebeuren: 1 monopolist, 1 centraal systeem.
Als er dan iets mis gaat, gaat het dan ook gierend mis omdat je een single point of failure hebt (organisatie, systeem, methode, noem maar op).
--jeroen
Je MOET voor veel zaken DigiD gebruiken.
Wat als dat nu eens langdurig plat ligt?
Dat staat me ook tegen met dat hele OV chipkaart gebeuren: 1 monopolist, 1 centraal systeem.
Als er dan iets mis gaat, gaat het dan ook gierend mis omdat je een single point of failure hebt (organisatie, systeem, methode, noem maar op).
--jeroen
Wat wil je dan, dat iedere overheidsdienst zijn eigen username en password uitgeeft ?
Ik weet niet hoe het zit in jouw gemeente, maar wij hebben ook nog een gemeentehuis, waar je jouw zaken kunt regelen. Waar MOET je de DigiD persé voor gebruiken, volgens jou?
Daarnaast kan je aan zo'n bug weinig doen. Als zo'n kwetsbaarheid wordt ontdekt, zal je wel actie moeten ondernemen. Zeker als overheid zijnde. Het lijkt me vrij lastig om daarvoor een backup oplossing te verzinnen, als ik dit zo lees.
Daarnaast kan je aan zo'n bug weinig doen. Als zo'n kwetsbaarheid wordt ontdekt, zal je wel actie moeten ondernemen. Zeker als overheid zijnde. Het lijkt me vrij lastig om daarvoor een backup oplossing te verzinnen, als ik dit zo lees.
Belastingaangifte, DUO (Studenten), etc.
Leuk, in een gemeente die enkel volgens een afspraak werkt, en die via de website, (dus Digid) moet maken...
Single Signon is vrijwel automatisch ook Single Point of Failure, dat is het idee ook. Als het wel werkt is het ook een Single Point of Succes 
Je moet de voordelen afwegen tegen de nadelen. Ik heb liever dit dan dan elke hobbybob-systeembeheerder bij de Gemeente Jipsingboermussel het zelf een inlogsysteem regelt.
Je moet de voordelen afwegen tegen de nadelen. Ik heb liever dit dan dan elke hobbybob-systeembeheerder bij de Gemeente Jipsingboermussel het zelf een inlogsysteem regelt.
Nu zitten alle diensten vast aan 1 ID provider.
Als je alle diensten aan een matrix van (vaste) ID providers zou hangen wordt het aan de ene kant ingewikkelder, maar spreid je ook het risico.
Ik bedoel eigenlijk zoiets als StackOverflow doet:
- je logt per site in
- zij vertrouwen een aantal OpenID providers
- je kunt een OpenID provider kiezen die zij vertrouwen, en waar jij je OpenID van hebt
Dan heb je per dienst verbindingen met je ID providers, en keuze/concurrentie tussen de providers.
Minder kans op Single Point of Failure.
En inderdaad: het is en blijft een afweging, en het voordeel van Single Point of Failure is dat als het goed gaat je een Single Point of Success hebt.
Als je alle diensten aan een matrix van (vaste) ID providers zou hangen wordt het aan de ene kant ingewikkelder, maar spreid je ook het risico.
Ik bedoel eigenlijk zoiets als StackOverflow doet:
- je logt per site in
- zij vertrouwen een aantal OpenID providers
- je kunt een OpenID provider kiezen die zij vertrouwen, en waar jij je OpenID van hebt
Dan heb je per dienst verbindingen met je ID providers, en keuze/concurrentie tussen de providers.
Minder kans op Single Point of Failure.
En inderdaad: het is en blijft een afweging, en het voordeel van Single Point of Failure is dat als het goed gaat je een Single Point of Success hebt.
Maar andere ID providers zoals Google, Microsoft Live, Facebook, Amazon zijn niet geschikt voor gebruik door de overheid omdat er geen totale controle is over die logingegevens en je je als overheid afhankelijk maar van commerciele partijen (die ook nog eens onder de Amerikaanse Patriot Act vallen). Bovendien is het bij die providers niet mogelijk te garanderen dat jij bent wie je zegt te zijn, dus de koppeling en verificatie met je GBA/BSN gegevens want die zijn niet voor derden toegankelijk ter verificatie.Nu zitten alle diensten vast aan 1 ID provider.
Wat je dus nodig hebt is een DIGID2 dat een kloon is van DIGID maar wel met een volkomen onafhankelijke eigen implementatie (want als dat ook RoR zou zijn dan zou dat voor dit geval nog niet hebben geholpen). De vraag is dan wie dat moet gaan betalen en is het risico op bugs of lekken met 2 onafhankelijke implementaties niet juist veel groter.
Ik zelf denk dat de huidige situatie de bestee is. Vervelend dat het ligt nu plat ligt (2e keer sinds het bestaan? [diginotar 1e keer?]) maar dit nadeel is volgens mij beter dan de alternatieven. Alles heeft een keerzijde en met dit kleine nadeel is denk ik heel goed te leven.
Op straat kan ik me toch ook met meerdere IDs legitimeren, afhankelijk van je verhuisgedrag zelfs door meerdere gemeentes uitgegeven.
Een verkoop transactie van een huis kan ik bij meerdere notarissen doen: die doen de hele verificatie.
Diverse instanties buiten de overheid kunnen in de GBA kijken/controleren, dus dat lijkt me ook niet echt een probleem.
De belastingdienst kan ik op meer dan 1 rekening betalen (ze hebben o.a. rekeningen bij de Rabobank en de ING), dus daar heb je ook failover.
Ik snap dat het een afweging is, maar het feit dat het nu 1 systeem is maakt het extra kritisch.
Complimenten overigens dat ze het binnen 24 uur weer in de lucht hadden.
Een verkoop transactie van een huis kan ik bij meerdere notarissen doen: die doen de hele verificatie.
Diverse instanties buiten de overheid kunnen in de GBA kijken/controleren, dus dat lijkt me ook niet echt een probleem.
De belastingdienst kan ik op meer dan 1 rekening betalen (ze hebben o.a. rekeningen bij de Rabobank en de ING), dus daar heb je ook failover.
Ik snap dat het een afweging is, maar het feit dat het nu 1 systeem is maakt het extra kritisch.
Complimenten overigens dat ze het binnen 24 uur weer in de lucht hadden.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
