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)
http://arstechnica.com/se...s-more-than-200000-sites/
Kan de overheid weinig aan doen dus, vrijwel alle sites die op Ruby draaien hebben hier last van."An attack can send a request to any Ruby on Rails sever and then execute arbitrary commands. Even though it's complex, it's reliable, so it will work 100 percent of the time."
* Het betreft enkel JSON en XML input; niet de forms.
* De fout zit diep in de code op een tweetal plekken waar waardes in JSON en XML omgezet worden en dan doorgegeven worden naar de laag die deze waardes verwerkt in de SQL.
Jij doet het klinken alsof ze even in "contact.php" de $sql door mysql-escape moeten halen en dat het daarmee is opgelost. Het is heel wat complexer.
"Dit input [sic]" wordt in Rails al op diverse lagen gecontroleerd. De Sec-advisories bevatten naast gebruikelijke instructies om te upgraden en patches om snel fixes door te voeren, ook voorbeelden van code waarmee je de fout in je applicatie kunt onderdrukken.
Door configuratievlaggen te zetten, kun je de XML-parser instrueren bepaalde waardes niet door te laten; waardoor de vervalste XML-POSTS/PUTS e.d. niet verwerkt worden tot onveilige database-instructies. Of door de JSON te controleren alvorens hier waardes van in de ORM te gebruiken, kun je het ook onderdrukken.
In de meeste grote RoR applicaties betekent dit echter dat je op honderden plekken code moet gaan aanpassen.
Terwijl de patch en upgrade juist het exacte probleem verhelpt op het meest centrale punt waar de waardes doorheen komen.
Het enige wat je ervan kunt zeggen is dat Rails te complex is (geworden) waardoor dit soort zeer geavanceerde aanvallen tot SQL-injecties kunnen leiden. Dat Rails zoveel "magische" "blackboxes" heeft dat niemand écht een duidelijk overzicht heeft van wat in alle situaties precies gebeurd. Daar is dan weer tegenin te brengen dat een groot framework eigenlijk vanzelf complex wordt.
[Reactie gewijzigd door berkes op woensdag 9 januari 2013 17:48]
Als de bug in Ruby on Rails zelf zit, zit het op een heel ander niveau dan applicatieniveau. Dan kan je nog zo veel voorzorgsmaatregelen hebben getroffen, daar kom je niet onderuit.
Ja, natuurlijk zou er een forward proxy of iets als varnish (cache) voor kunnen zitten die de request delegeert aan een interne Ruby on Rails server. Maar voor het zelfde geld is juist deze forward proxy een ruby on rails proxy, en dan zit je met precies hetzelfde probleem.
De opmerking "wat is het systeem nu helemaal?" impliceert dat het een naar jouw mening een eenvoudige en simpele "login" is, waar jij überhaupt geen kijk op hebt.
Typisch een reactie om de overheid onnodig onderuit te halen. Terwijl juist in dit geval er naar mijn mening weinig aan gedaan had kunnen worden.
http://weblog.rubyonrails...-0-18-have-been-released/
https://groups.google.com...ails-security/DCNTNp_qjFM
Vooral bij zoiets kritieks als DigiD verwacht je toch dat er binnen 1-2 dagen duidelijkheid is of het systeem vatbaar is voor het lek en of en welke actie ondernomen moet worden.
Ah, denk dat bartvb gelijk heeft. Dat is een nieuwere CVE.
https://groups.google.com...ty/61bkgvnSGTQ/discussion
Bovenstaande neem ik dus terug
@YopY
Blijkbaar niet, want in dit geval is de overheid er erg snel bij. Als het om bovenstaande CVE gaat althans
[Reactie gewijzigd door SidewalkSuper op woensdag 9 januari 2013 13:20]
Wél heeft dat CVE ertoe geleid dat mensen "down that rabbithole" gingen en het probleem in 5664 zeer nauwkeurig onderzocht hebben; waaruit dan weer de twee securityreleases van vannacht kwamen.
Merk ook op dat al tijdens die security-release er al exploits in het wild gesignaleerd waren. Dus dat het offline halen van een site wel degelijk een goede reactie is.
Zover bekend op reddit en news.ycombinator.org zijn er nog geen (grote) publieke sites bekend die hiermee al gehacked zijn.
Zo te zien bedoel je het ironisch, maar het is juist wel handig. Ja, jammer dat alles nu even off-line is maar het alternatief is een woud aan inlogmethodes en dat woud is denk ik veel meer gevoelig voor bugs, want:Handig al die sites die van digid gebruik maken.
- Tig implementaties met in elke implementatie kans op bugs
- Minder competent systeem beheer want niet elke organisatie zal altijd de goede mensen hebben
- Grote kans op niet ontdekken (want minder exposure dus sneller onder de radar)
- Grotere kans op lang on-line blijven want niet elke organisatie zal de ballen hebben om hun login server off-line te halen, zeker als die organisatie de ballen verstand heeft van dit soort zaken
- Grotere kans op niet weten want niet elke system administrator zal zo scherp op security bulletins letten
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google 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
