Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 54 reacties
Submitter: theguyofdoom

De overheid heeft de dienst voor het digitaal controleren van de identiteit van burgers, DigiD, weer online gezet. De dienst ging woensdagochtend offline vanwege een 'ernstig' beveiligingslek in Ruby On Rails, dat gebruikt wordt voor DigiD.

DigiD is na bijna een dag downtime donderdag weer beschikbaar. Burgers konden in die tijd nergens inloggen met DigiD, dat onder meer wordt gebruikt voor identificatie bij gemeenten en andere overheden. DigiD moest offline om de patch voor het beveilingslek uit te rollen en te testen voordat gebruikers de dienst weer zouden gebruiken. "We willen het zekere voor het onzekere nemen", zei Michel Groeneveld, woordvoerder van overheids-ict-dienst Logius, woensdag tegen Tweakers. "Zo willen we misbruik van het lek voorkomen."

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.

DigiD is in de nacht van dinsdag op woensdag kwetsbaar geweest; de lekken waren toen al bekend, maar DigiD was toen online. Woensdagochtend ging de identificatiedienst offline. 

Reacties (54)

Reactiefilter:-154051+141+23+30
Moderatie-faq Wijzig weergave
Je hebt gelijk. Ik ben geen doorgewinterde Rails expert, maar ken de in's en outs goed genoeg om de complexiteit van dit probleem goed te doorgronden.

Het is een hl ingewikkeld lek. En feitelijk ook geen SQL-injectie, maar code-injectie; Het feit dat Brenno dat niet snapt geeft aan dat hij zeker een toontje lager had moeten zingen.

Mooi detail is dat dit specifieke lek ontdekt is in navolging van een eerder lek, op 2 januari, wat wl een SQL-injectie-lek was, maar welke slechts in heel specifieke configuraties ook exploitable was. Dat lek heeft een heleboel onderzoekers op een spoor gezet; wat geleid heeft tot het ontdekken van het huidige lek.

Merk ook op dat om dit lek uit te leggen; de proof of concepts; pagina's tekst en voorbeelden nodig zijn; dat is een indicatie van hoe complex het is.

Heel in het kort: op plekken waar je in de rail-applicatie XML POST/PUT verwerkt, kan een aanvaller XML insturen waarin hij gebruik maakt van een heel obscure "feature" in XML. Hierdoor worden bepaalde beveiligingen die normaliter over die XML worden uitgeschud, omzeild. Wanneer je de XML dan vervolgens nog prepareert met extra code kun je die code in de applicatie uitgevoerd krijgen. In deze uitleg ga ik kort door de bocht, maar de essentie is er. En duidelijk is dat het erg complex is en een code-review door een overheid cht niet achter dit lek gekomen was.
Nee. Dan was het dinsdagavond 21:15 offline gehaald. Pas toen was dit lek en de CVE bekendgemaakt.

Je verwart waarschijnlijk met CVE-2012-5664 (2 jan) ;Dat was een ander lek, een klein, in slechts heel beperkte situaties exploitable lek. We kennen de exacte opzet van DigiD niet, maar het is zeer onwaarschijnlijk dat dit probleem bij hun exploitable was (voorwaarden waren enkele specifieke versies van libraries n het gebruik van AuthLogic een niet erg populaire addon die dan ook nog eens op een speficieke manier geconfigureerd moet worden).

CVE-2013-0156 is 8 januari 21:15:06 vrijgegeven. Dat is het lek waar het hier om gaat.
De CVE's zijn 08 Jan 2013 12:15:06 PST de wereld in gebracht. Dat is dinsdagavond 9:15 Nederlandse tijd.

We weten niet of Logius toen al direct actie ondernomen heeft; maar wl dat ze woensdagochtend, in alle vroegte, de boel offline hebben gehaald.

Tja, dus dat zou dan hebben betekend dat DigiD een hele week niet gebruikt had kunnen worden omdat er mogelijk misbruik van gemaakt zou kunnen worden

Is dus vreemd. Het zou betekend hebben dat ze om 9:15 alles al platgegooid hadden; en DigiD zeven uur langer offline geweest was; uitgaande dat ze het dan ook niet eerder weer terug online hadded gebracht maar ook donderdachochtend. Geen week, dus.
Ruby en het web-app-framework Ruby on Rails zijn heel volwassen. Het feit dat er zo'n beveiligingslek wordt gevonden heeft te maken met het feit dat er een hele grote groep gebruikers, researchers en beveiligingsexperts dagelijks met de open-source code bezig zijn.
Nou de vraag (ook op het forum) was eerder, hoe is het mogelijk dat er zo'n gigantisch beveiligingslek in kan zitten. Dat doet bij mij toch wel twijfelen of RoR wel zo'n volwassen framework is en of het niet uit zijn voegen begint te barsten.
Als ik deze commends zo lees als leek op dit gebied, dan is het eerste waar ik aan denk dat DigiD op 2 verschillende platforms parallel (of afwisselend on line) moet kunnen draaien t.b.v. redundantie. Het is een te kwetsbaar systeem om hiervan als overheid volledig van afhankelijk te zijn en op een goeie dag voor volledige chaos kan zorgen.
Hmm, zo'n systeem zou ongeacht de taal in principe nooit op wat voor bloated framework dan ook gebouwd moeten worden. Een security review van je code betekent alleen wat als je vertrouwen in je fundering minimaal net zo hoog is als wat je van je eigen codebase verwacht. Als je bouwt op bloated frameworks en/of servers zoals Rails, Django, Spring, etc, dan heb je bij voorbaat de handoek eigenlijk al in de ring gegooid.

Ideaal gezien zou je dit soort systemen eigenlijk from-the-ground-up met Caha of Joe-E willen bouwen. Dat zijn in capability secure versies van de mainstream talen JavaScript en Java die uitermaten geschikt zijn om high integrity systemen mee te bouwen.

http://en.wikipedia.org/wiki/Object-capability_model
Ik wist niet dat RoR een framework is, dan stel ik mijn vraag fout. Waarom is er dan voor Ruby gekozen?
Zal wel via aanbesteding gedaan zijn en geen technische eisen opgenomen. De goedkoopste wint en die had RoR in gedachten. Waarom denk je dat er bewust een technische keuze door Logius is gedaan?
Het lijkt mij dat Rails een Security Advisory uitstuurt in dit soort gevallen. Het lijkt me dan ook een kleine moeite om bij een SA volautomatisch de hele service offline te gooien. False positives zou ik dan voor lief nemen. :)
Waarom is het gebouwd op RoR Ruby? Waarom is er niet voor PHP of ASP gekozen? Ben wel benieuwd waarom.

[Reactie gewijzigd door Xieoxer op 10 januari 2013 07:59]

Heb je die bug zelf wel gelezen man? Dan had hooguit digid dus alleen voor FF gebruikers dicht gemoeten.Dat is m'n hele punt, een systeem zal altijd bugs kennen, maar wat is de impact van die bugs. Zonder o-caps en POLA based design is de impact al heel snel desastreus.
Ideaal gezien zou je dit soort systemen eigenlijk from-the-ground-up met Caha of Joe-E willen bouwen. Dat zijn in capability secure versies van de mainstream talen JavaScript en Java die uitermate geschikt zijn om high integrity systemen mee te bouwen.
Je bedoelt natuurlijk Caja en dat is ook wel eens vulnerable. Dan was digid.nl op 18 september offline gehaald. Waarmee je zo iets ook bouwt, het zal altijd vulnerabilities kennen.

@pibara: Zelfs als iets alleen maar kwetsbaar is voor FF gebruikers is dat voor een site als digid.nl reden genoeg om hem inderdaad offline te halen,
We can now execute any JavaScript and bypass the sandbox because the sandboxed setTimeout function specifically checks for a string type but forgets the array literal.
http://www.thespanner.co.uk/2012/09/18/hacking-caja-part-2/

[Reactie gewijzigd door Jan-E op 10 januari 2013 14:26]

100% veilig nee, veiligheid is een combinatie van de pijlers 'robuustheid', 'beschikbaarheid' en 'vertrouwlijkheid', en je kunt die drie noot allemaal 100% afdichten. Vroeger (en bij veel bedrijfen trouwens nu nog steeds) was de prioriteit tussen deze drie:

1) Bechikbaarheid.
2) Vertrouwlijkheid.
3) Robuusteid.

De laatste jaren komen we er steeds meer achter dat je deze prioritering beter om kunt draaien. Dat als je een robuust systeem maakt, dat het daarmee veel eenvoudiger is on vertrouwlijkheid goed te impementeren, en dat het best mee valt welke beschikbaarheidsoffers je daarvoor moet brengen. Wat betekent dit, als je een systeem wilt bouwen dat veilig genoeg is voor DigID, EPD, stemcomputers, etc, dan is een eerste vereiste dat je de basis Principle Of Least Authority high-integrity-computing beginselen door je hele systeem gebruikt. Je kiest een object-capability taal (of subset van een taal met o-cap eigenschappen), ontwerpt je software volgens POLA, bepaalt via architectuur analyse wat de critische onderdelen van je software zijn, en laat op die onderdelen een grondige security review doen.

Nee, de 100% veilig haal je niet, maar al je je boos maakt en de richtlijnen goed volgt, dan kun je voor 99% zeker zijn dat de robuustheid en vertrouwlijkheid van je applicatie 100% in orde zijn.
Ik ben het zat hoe de overheid ons de DIGI-D in jaagt, de kant op van ICT. Zo kreeg een oom van me een brief van het UWV waarin staat dat ie vanaf nu geen post meer thuis ontvangt maar dat hij met zijn DIGI-D kan inloggen om te zien wat voor mutaties er zijn.

Men wil vanuit de overheid en uitvoerende instellingen dat je steeds meer zelf regelt, maar het systeem waardoor je toegang krijgt tot al die zelf regel zaken is inherent gevoelig voor misbruik. Is het niet door stommiteit dan wel door het feit dat ICT gewoon blijkbaar als technologie niet ontworpen is voor beveiliging.

Als ik van de bank tenminste nog een apparaatje krijg beveiligd met een pincode, waar ik dan mee kan inloggen, wat mij redelijk tot goed overkomt als systeem van authenticatie, waarom dan niet zoiets vanuit de overheid regelen?

Ik wil gewoon papier ontvangen met mutaties van overheidsinstanties. Dat is enerzijds veiliger voor m ij en anderzijds heb ik ook bewijsstukken in handen van wat een instelling mij toestuurt. Zo krijg ik ook een digitale factuur van Ziggo. Maar als de Ziggo server offline gaat, of een UWV, of een CWI of wat dan ook, dan heb je helemaal geen bewijsstukken.

In principe kunnen ze simpelweg achteraf met de 'stukken' knoeien en zo 'bewijzen' dat je nooit recht had op een uitkering of vergoeding etc. En wie zegt me dat dat niet ook kan gebeuren gewoon door een fout? Hoe bewijs je als burger zonder enig papier wat je meent dat er fout zit? Je mag niet zo maar even de servers induiken van zo'n organisatie. Dus je positie als burger wordt zwaar ondermijnt! Of wie zegt me dat een hacker die me wil naaien niet iets aanpast in een dossier en ineens stopt een uitkering, vergoeding of subsidie?

ICT is net als geld, een zaak van vertrouwen. We zien dat geld niet te vertrouwen is, gezien de economische crises. Het is fiat geld waarmee we betalen. ICT blijkt ook meer een zaak van vertrouwen dan van zorgvuldigheid en kennis.

Als alles in databases zit op een server ergens, dan is het wat mij betreft niet eens ontologisch 'echt'. De harde schijf gaat stuk en dan mag je een backup hebben, maar uiteindelijk is het maar vertrouwen dat een ICT-er met ongelimiteerde toegang tot gegevens alles juist regelt en bewaakt. Als burger heb ik daar geen inzicht in en dat mag ik ook niet eens hebben - voor mijn eigen bestwil, want als iedereen kan snuffelen of de beveiliging op orde is...dan is dat op zich een lek.

Ik vind deze trend tot digitalisering heel schadelijk voor onze burgerrechten en onze positie ten opzichte van de overheid en uitvoerende diensten.

Helaas blijkt dat de trein doordendert en er wordt nauwelijks nagedacht of het moreel is en slim om alles via een een of ander generiek vormpje op het scherm te toveren.

Immers, mijn Ziggo factuur daar is niets persoonlijks aan. Ik behoor als klant gewoon tot een categorie, die met een bepaald contract voor een bepaalde abonnementsvorm. Als ik inlog zie ik gewoon een generieke factuur waarin alleen mijn naam is toegevoegd. Het is dus niet zo dat er een apart digitaal document is speciaal voor mij gemaakt.

Ook voor inzage in je eigen gegevens bij UWV, GAK, CWI, Belastingdienst, zal dat tenminste grotendeels hetzelfde zijn.

Om te bewijzen, nadat er iets helemaal fout gaat in een systeem, dat je daadwerkelijk recht had op een subsidie of toeslag of uitkering etc kon wel eens een probleem worden. Men zal dan handmatig na moeten gaan wie je bent, wat je inkomen was en dus waarop je recht had. Denk eens aan hoe moeilijk Ron Kowsoleaa het had om te bewijzen dat hij geen crimineel was en hoe extreem moeilijk het was om de computersystemen te zuiveren van de vergissing die ontstond door identiteitsfraude.
Als je ziet hoe heilig die systemen zijn voor medewerkers... dan gaan ze eerder er van uit dat jij liegt, voor de telefoon, in een brief, dan dat ze geloven dat er iets mis is met het systeem.

Wie burgerrechten belangrijk vind gebruikt geen Digi-D of zo min mogelijk en zo mogelijk, schrijft instanties aan dat je papier wilt ontvangen. Dat is voor je eigen veiligheid beter en dus in je eigen belang.
Het is heel simpel, 95+% van de gevallen zijn je systeemintegiteitseisen dusdanig dat een standaard web framework hardstikke goed voldoet, en dan moet je het ook gewoon gebruiken. Er zijn echter een paar procent van de gevalen, laten we zeggen DigID, EPD, stem-machines, etc waarbij de eisen een flink stukje hoger zouden moeten liggen dan voor de gemiddelde app. In die (en alleen die) situaties zou je gebruik moeten maken van de principes en technologieen die nodig zijn om high-integrity systemen te maken. De gebruikelijke frameworks vallen dan eigenlijk gewoon altijd af. Dat kost je meer tijd/geld (naar mijn ervaring tussen de 50% en 200% meer), maar dan heb je een systeem waar je echt vertrouwen kunt hebben. Met de genoemde object-capability talen kun je de benodigde ontwikkeltijd trouwens behoorlijk naar beneden brengen, en omdat het veilige subsets van bekende talen zijn zijn ze behoorlijk rap te leren. Helaas zijn er echter nog weinig bedrijven die Joe-E of Caja in hun pakket hebben zitten dus betaal je (nu nog) een behoorlijk bedrag als je zo'n project wilt laten doen, maar ik ben er van overtuigd dat de marktwerking dat nog wel op zal gaan lossen. Er hoeft in de huidige ecconomie maar een detacheerder op te staan die inziet dat high-integrity systemen een markt met potentie is en z'n Java/JavaScript mensen Joe-E/Caja laat leren, en high-integrity wordt heel snel main-stream en voor main-stream prijzen.
Downtime voor zulke services wil je inderdaad niet. Digid wordt steeds kritieker omdat steeds meer mensen hun zaken via Internet willen regelen en de overheid daar in mee moet gaan.

Keihard liegen over de ernst van het lek is daarentegen natuurlijk ook niet zoals het hoort.
DigiD is in de nacht van dinsdag op woensdag kwetsbaar geweest; de lekken waren toen al bekend, maar DigiD was toen online. Woensdagochtend ging de identificatiedienst offline.
De vorige versie van Ruby 3.2.10 was van 2 januari, de versie daarvoor stamt uit november vorig jaar. Het is een overheidsservice, dus het is vrijwel zeker dat ze nooit direct updaten nadat er een nieuwe versie van Ruby uit komt.

Er wordt niet bekend gemaakt vanaf welke versie men heeft ge-update. Daarom acht ik het zeer waarschijnlijk dat dit lek maanden lang aanwezig is geweest.
Probeer dat maar eens aan het algemene publiek uit te leggen.
Ik zie de nieuws artikelen al.
"DigiD al jaren onveilig, gegevens van alle gebruikers kunnen op straat liggen"

Hoewel feitelijk juist gaat dat politiek gezien natuurlijk weer een heel eigen leven leiden.
Elk systeem is per definitie onveilig, het belangrijkste is welke risico kwalificatie je aan je data geeft en hoe ver je wilt gaan met de beveiling van je data.
Of dat goed gegaan is bij DigiD durf ik geen uitspraken over te doen, maar het is een van de reden waarom ik ook nog steeds erg sceptisch ben over het EPD omdat ik het niet vertrouw dat die analyse daar goed is uitgevoerd.

Op dit item kan niet meer gereageerd worden.



Microsoft Windows 10 Home NL Apple iPhone 6s Star Wars: Battlefront (2015) Samsung Galaxy S6 Edge Apple Watch Project CARS Nest Learning Thermostat Microsoft Windows 10 Home EN

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True