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)
Edit: Zie de reactive van bartvb hier onder voor de juiste bug.
--------------
http://www.eweek.com/deve...ot-widespread-researcher/
Zou het daar over kunnen gaan?
--------------
http://www.eweek.com/deve...ot-widespread-researcher/
Zou het daar over kunnen gaan?
Dat klinkt toch als een ernstige fout van de overheid en niet van Ruby dan.most applications are not vulnerable unless they use Authlogic, a third-party authentication framework, and have exposed their secret session key
[Reactie gewijzigd door Mraedis op 9 januari 2013 13:14]
Nee, gaat over dit probleem:
http://arstechnica.com/se...s-more-than-200000-sites/
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."
Nee, vrijwel alle sites die op Ruby on Rails draaien hebben hier last van.
Waarom de downmods? Ruby is echt wat anders dan Ruby on Rails
Kom op zeg. Wat is het systeem nu helemaal? Een username, password en SMS token box. Als er ook maar _enigszins_ defence in depth toegepast zou worden, zou deze core van de applicatie helemaal niet vulnerable zijn omdat je je inkomende argumenten in meerdere onafhankelijke lagen checkt. Of ze nou Ruby, Java of Brainfuck gebruiken.Kan de overheid weinig aan doen dus, vrijwel alle sites die op Ruby draaien hebben hier last van.
Dat de gehele applicatie, inclusief het basale inlogdeel, offline moet om deze reden, toont juist aan dat het systeem matig is opgezet en het weer een typisch overheids ICT project is.
Jij als tweaker kunt dit natuurlijk veel beter beoordelen dan de overheid zelf ...
Ja, want de all-mighty overheid zal allemaal natuurlijk wel veel beter weten wat goed voor ons is. Ik zal niet ontkennen dat de beste stuurlui altijd aan wal staan, maar denk ook dat ik inmiddels genoeg ervaring heb binnen semi-overheidsorganisaties met webapplicatiedevelopment dat ik er iets over kan zeggen.
De kans dat de bouwer van DigiD zich ook hier op tweakers bevind (een tweaker is) is statistisch gezien erg groot ...
Ik heb weinig vertrouwen in de overheid als 't gaat om organisatie structuren en capabiliteit van de werknemers, met name 't management. Maar ongeacht hoe goed je bent of van de daken schreeuwt wat belangrijk is. Als de klant (cq incapabele management) anders besluit heb je 't uiteindelijk maar te slikken, ongeacht wat voor mega tweaker je bent.
Even los van dat 't technisch allemaal niet zo spannend is, heb ik de ervaring binnen de overheid dat 't je soms onmogelijk wordt gemaakt om normaal te werken. Dat is ook de reden dat ik elke aanvraag van de overheid weiger tegenwoordig. Die luxe heb ik nu gelukkig. Je wordt werkelijk gek van die lui wat mij betreft. En er zullen ook vast wel goeie zijn, maar die zijn naar verhouding karig in mijn ervaring.
Het wordt 's een keer tijd voor reorganisatie binnen de overheid. Teveel eilanden die niet of nauwelijks gecontroleerd worden, of door entiteiten die net zo incapabel zijn. En dat heeft maar met 1 ding te maken: mensen.
Je hebt meer aan 1 capabele werknemer dan 10 flierefluiters.
Maargoed, ik dwaal af ...
Het gaat om een fout in Ruby on Rails zelf ... dus heel je betoog maakt geen punt. Ik overigens ook niet bedenk ik me nu Behalve dat de problematiek van slecht IT werk bij de overheid niets te maken heeft met techniek, maar met incapabele mensen. Met name door gebrek aan kennis en omdat de goedkoopste altijd wint ipv te beoordelen op kwaliteit.
Ik heb weinig vertrouwen in de overheid als 't gaat om organisatie structuren en capabiliteit van de werknemers, met name 't management. Maar ongeacht hoe goed je bent of van de daken schreeuwt wat belangrijk is. Als de klant (cq incapabele management) anders besluit heb je 't uiteindelijk maar te slikken, ongeacht wat voor mega tweaker je bent.
Even los van dat 't technisch allemaal niet zo spannend is, heb ik de ervaring binnen de overheid dat 't je soms onmogelijk wordt gemaakt om normaal te werken. Dat is ook de reden dat ik elke aanvraag van de overheid weiger tegenwoordig. Die luxe heb ik nu gelukkig. Je wordt werkelijk gek van die lui wat mij betreft. En er zullen ook vast wel goeie zijn, maar die zijn naar verhouding karig in mijn ervaring.
Het wordt 's een keer tijd voor reorganisatie binnen de overheid. Teveel eilanden die niet of nauwelijks gecontroleerd worden, of door entiteiten die net zo incapabel zijn. En dat heeft maar met 1 ding te maken: mensen.
Je hebt meer aan 1 capabele werknemer dan 10 flierefluiters.
Maargoed, ik dwaal af ...
Het gaat om een fout in Ruby on Rails zelf ... dus heel je betoog maakt geen punt. Ik overigens ook niet bedenk ik me nu
Behalve dat de problematiek van slecht IT werk bij de overheid niets te maken heeft met techniek, maar met incapabele mensen. Met name door gebrek aan kennis en omdat de goedkoopste altijd wint ipv te beoordelen op kwaliteit.
[Reactie gewijzigd door xs4me op 9 januari 2013 14:54]
Het lek zelf zit in RoR, maar een lek in 1 framework of 1 applicatie zou er wat mij betreft niet tot moeten leiden dat het gehele systeem offline gehaald moet worden, zeker gezien het probleem hier in inputvalidatie zit. Dit input kun je gewoon in meerdere lagen controleren, dat is mijn punt.
Naja, het punt zit hem meer in dat je niet een framework moet kiezen dat te veel extra's geeft. Want iedere extra geeft een volgende mogelijkheid voor fouten. Het is natuurlijk van de stomme om een framework te gebruiken en daarna buiten het framework om dezelfde checks te gaan doen. Maja, dit is ondertussen de derde keer dat zich een fout voordoet in de core van het framework (zover ik heb gehoord, ook al was 1tje dat de default instellingen onveilig waren en je eigenlijk gewoon niet gebruik moest maken van een gehele functie omdat ie principieel onveilig was). Dat terwijl met verschillende php frameworks die ik heb gezien dat soort fouten alleen voorkomen als frameworks te veel gaan doen of het *te* makkelijk proberen te maken, terwijl het nooit gebeurd bij de wat diepere frameworks. Maja, point in case, een framework kiezen is stuk lastiger dan alleen: heej dat ziet er leuk en makkelijk uit. Vooral als het om kritieke data gaat.
Dit specifieke probleem is erg complex. Het kan ook enkel misbruikt worden door een serie van- en combinatie van zaken, te weten:
* 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.
* 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 9 januari 2013 17:48]
Een groot framework zou nooit te complex moeten worden, als het te complex wordt is het een teken dat het niet goed opgezet is. Kijk naar andere grote frameworks als Symfony en Zend Framework, beide dan wel toevallig PHP maar wel groot, bekend en veel gebruikt! Beide hebben een best pittige leercurve maar zijn wel overzichtelijk en barstten niet uit hun voegen
Wat is dat nou voor rare reactie.
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.
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.
Daarom moet je ook geen proxies in Rails schrijven, maar in iets waarvan je de correcte werking eenvoudiger kan controleren.Maar voor het zelfde geld is juist deze forward proxy een ruby on rails proxy, en dan zit je met precies hetzelfde probleem.
Natuurlijk, bugs kunnen voorkomen, alleen vind ik de impact in dit geval wel erg groot (namelijk plat gaan voor een dag). Denk je dat commerciële marktpartijen zich dat ook kunnen veroorloven wanneer het om hun identity management gaat, of zouden die failliet zijn als ze een dagje niet kunnen werken?
Vertel eens wat er zo speciaal is aan DigiD dan? Ben benieuwd...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.
Het is geen probleem van DigiD, maar van Ruby (of RoR, niet naar gekeken).
Als jij een Java applicatie bouwt en jouw applicatie is 100% veilig. Maar er zit een fout in Java waar jij NIETS aan kunt doen. Wiens schuld is dit dan als hierdoor jouw applicatie voor een dag dicht moet om te testen om te kijken of de fix vanuit java goed werkt/er geen andere problemen optreden?
Dit is een hele goede actie van de makers achter DigiD om de site plat te leggen totdat ze er zeker van zijn dat de applicatie weer goed werkt met de quick/hotfix vanuit Ruby (of RoR dus).
Als jij een Java applicatie bouwt en jouw applicatie is 100% veilig. Maar er zit een fout in Java waar jij NIETS aan kunt doen. Wiens schuld is dit dan als hierdoor jouw applicatie voor een dag dicht moet om te testen om te kijken of de fix vanuit java goed werkt/er geen andere problemen optreden?
Dit is een hele goede actie van de makers achter DigiD om de site plat te leggen totdat ze er zeker van zijn dat de applicatie weer goed werkt met de quick/hotfix vanuit Ruby (of RoR dus).
Mijn fout wanneer de applicatie zo belangrijk is dat hij eigenlijk altijd beschikbaar zou moeten zijn. Dan bouw je je applicatie namelijk in meerdere lagen op, bijvoorbeeld met een Web Application Firewall ervoor, zodat je verkeerde input kan opvangen.Als jij een Java applicatie bouwt en jouw applicatie is 100% veilig. Maar er zit een fout in Java waar jij NIETS aan kunt doen. Wiens schuld is dit dan als hierdoor jouw applicatie voor een dag dicht moet om te testen om te kijken of de fix vanuit java goed werkt/er geen andere problemen optreden?
Je integration testing is trouwens ook niet geheel op orde als je een dag moet testen voor de uitrol van een security fix, maar daar kan ik me bij het aantal actoren waar DigiD mee te maken heeft nog wel iets bij voorstellen.
Zo'n firewall trekt geen restfull webservice onderuit wanneer er een type yaml of symbol wordt gebruikt. Want het is namelijk valide xml welke regelmatig door resfull webservice vergelijkbaar met soap of ajax calls worden gebruikt
Als je niet weet waar je het over hebt, hou je dan buiten de discussie, die kun je toch niet winnen. XML/YAML wordt gebruikt voor communicatie tussen systemen, of intern als datarepresentatie, niet voor end-users. Een opmerking als "dat gebruik ik niet" bewijst dat je niet weet waar je het over hebt. Als er ergens pagina's zijn die XML accepteren, kun je die als hacker misbruiken, want een hacker weet wel hoe hij XML aan een webapp geeft.
En wat je bedoeld met encoded en niet automatisch snap ik al helemaal niks van. Een webapp doet alleen maar automatische dingen, op basis van input. Of die input nou form-data, XML, JSON of iets anders is, dat maakt niet uit.
En wat je bedoeld met encoded en niet automatisch snap ik al helemaal niks van. Een webapp doet alleen maar automatische dingen, op basis van input. Of die input nou form-data, XML, JSON of iets anders is, dat maakt niet uit.
Misschien moet je er dan niets over zeggen en aannemen dat ik wel weet waar ik het over heb, als jij niet weet waar je het over hebt. In het geval van SAML zijn de assertions base64 en urlencoded. Deze zal Rails dus niet automatisch gaan interpreteren en een WAF kan dus prima de geldigheid van de data afdwingen in relatie tot dit lek.En wat je bedoeld met encoded en niet automatisch snap ik al helemaal niks van
Gezien je verdere persoonlijke aanvallen zal ik maar niet op de rest van je reactie ingaan.
De "security fix" is een nieuwe release van het framework. Ze moeten natuurlijk niet alleen de fix testen, maar ook of de hele applicatie nog werkt op die nieuwe versie. Er kunnen namelijk nog meer dingen gewijzigd zijn dan alleen die fix.
En als jij blind vertrouwd op een firewall hoop ik niet dat ik ooit met jou samen moet werken. Firewalls zijn redelijk domme dingen en een echte hack houden ze toch niet tegen.
Ik vind het goed dat de overheid het plat gooit bij een kritiek lek, zodat ze het in alle rust kunnen testen. Jammer dan, dat je het een dag niet kan gebruiken, maar wat wil je dan? Het zoveelste geval van een datalek omdat ze net zo dom dachten als jij en erop vertrouwde dat er toch niks mis zou gaan?
En als jij blind vertrouwd op een firewall hoop ik niet dat ik ooit met jou samen moet werken. Firewalls zijn redelijk domme dingen en een echte hack houden ze toch niet tegen.
Ik vind het goed dat de overheid het plat gooit bij een kritiek lek, zodat ze het in alle rust kunnen testen. Jammer dan, dat je het een dag niet kan gebruiken, maar wat wil je dan? Het zoveelste geval van een datalek omdat ze net zo dom dachten als jij en erop vertrouwde dat er toch niks mis zou gaan?
Als jij de applicatie bouwt, dan word jij daarop aangesproken, of het nu een fout is in jouw code, één van de libraries die je gebruikt of zelfs de programmeertaal.
Degene die het product/de dienst levert is verantwoordelijk voor schade, als het product niet deugdelijk is.
Als het totale product/de dienst ondeugdelijk is, doordat iemand elementen van een toeleverancier gebruikt, waar een fout in zit, dan zal hij zn schade kunnen verhalen op de toeleveranciers(moet er wel een zakelijk contract bestaan tussen leverancier en toeleverancier, met open source heb je dat bijv. vaak niet...)
DigiD, is hier degene die fout is, als iemand schade oploopt, omdat hij zn digid nu niet kan gebruiken, zal die persoon eerst bij DigiD klacht moeten indienen.
Afhankelijk van het contract tussen DigiD en de leverancier van de applicatie, kan bijvoorbeeld dan door gerechtelijk bakkeleitje, bepaald worden als de applicatie leverancier verantwoordelijke is of niet. (digid kan ook gewoon fouten gemaakt hebben bij aankoop van het product en niet de juiste dingen geëist hebben)
En de applicatieleverancier, kan zn schade niet zomaar verhalen, als hij bijvoorbeeld software/code van derden gebruikt, die openbaar beschikbaar is, het is de applicatieleverancier zn eigen risico om openbare beschikbare code/onderdelen te gebruiken!
Maakt een applicatieleverancier iets op basis van java en er zit fout in java, sorry, das balen, maar de app.leverancier draagt de verantwoording in dit geval, tenzij hij bijvoorbeeld een contract met java ontwikkelaar heeft, die dit risico behandeld.
Als het totale product/de dienst ondeugdelijk is, doordat iemand elementen van een toeleverancier gebruikt, waar een fout in zit, dan zal hij zn schade kunnen verhalen op de toeleveranciers(moet er wel een zakelijk contract bestaan tussen leverancier en toeleverancier, met open source heb je dat bijv. vaak niet...)
DigiD, is hier degene die fout is, als iemand schade oploopt, omdat hij zn digid nu niet kan gebruiken, zal die persoon eerst bij DigiD klacht moeten indienen.
Afhankelijk van het contract tussen DigiD en de leverancier van de applicatie, kan bijvoorbeeld dan door gerechtelijk bakkeleitje, bepaald worden als de applicatie leverancier verantwoordelijke is of niet. (digid kan ook gewoon fouten gemaakt hebben bij aankoop van het product en niet de juiste dingen geëist hebben)
En de applicatieleverancier, kan zn schade niet zomaar verhalen, als hij bijvoorbeeld software/code van derden gebruikt, die openbaar beschikbaar is, het is de applicatieleverancier zn eigen risico om openbare beschikbare code/onderdelen te gebruiken!
Maakt een applicatieleverancier iets op basis van java en er zit fout in java, sorry, das balen, maar de app.leverancier draagt de verantwoording in dit geval, tenzij hij bijvoorbeeld een contract met java ontwikkelaar heeft, die dit risico behandeld.
[Reactie gewijzigd door bangkirai op 9 januari 2013 17:26]
Ga jij maar lekker je eigen proxies schrijven dan. Succes met het overtuigen van je baas waarom jouw bedrijf z'n eigen proxy nodig heeft en niet een van de vele bestaande oplossingen gebruikt.Daarom moet je ook geen proxies in Rails schrijven, maar in iets waarvan je de correcte werking eenvoudiger kan controleren.
Overigens kun je in rails prima de correcte werking aantonen. Rails heeft prima ondersteuning voor het testen van code, zoals unit tests, functional tests en integration tests. Maar goed, ik heb het idee dat je helemaal geen verstand hebt van programmeren, ik las hieronder al dat je niet eens weet waarvoor XML wordt gebruikt.
Misschien het feit dat als je DigiD kan hacken, dat je een heleboel overheidssystemen in kan en grote hoeveelheden vertrouwelijke gegevens kan downloaden?Vertel eens wat er zo speciaal is aan DigiD dan? Ben benieuwd...
Dat de applicatie offline moet toont dat helemaal niet aan. Dat toont aan dat ze security tegenwoordig meer serieus nemen en liever het zekere voor het onzekere nemen. Maarja, er zijn altijd kortzichtige betweters die altijd iets te mekkeren hebben. Als het systeem in de lucht blijft komt er kritiek, als het systeem offline gaat komt er kritiek.Dat de gehele applicatie, inclusief het basale inlogdeel, offline moet om deze reden, toont juist aan dat het systeem matig is opgezet en het weer een typisch overheids ICT project is.
En waarom? Heb je zo'n hekel aan de overheid dat je je genoodzaakt voelt om alles af te zeiken wat ze doen?
https://www.ncsc.nl/diens...pen+in+Ruby+on+Rails.html
Samenvatting
Er zijn nieuwe versies van Ruby on Rails uitgebracht voor twee zeer
ernstige kwetsbaarheden in dit framework. Door de ernst van de
kwetsbaarheden wordt gebruikers aangeraden zo snel mogelijk
maatregelen te treffen om misbruik van deze kwetsbaarheden te
voorkomen.
Gevolgen
Misbruik van de kwetsbaarheden kan leiden tot:
- het uitvoeren van willekeurige (Ruby-)code,
- het uitvoeren van willekeurige SQL-queries,
- het manipuleren van SQL-queries,
- het omzeilen van authenticatiesystemen en
- het uitvoeren van Denial of Service aanvallen.
Lijkt me inderdaad de meest voor de hand liggende oorzaak. Opvallend dat de overheid er dan blijkbaar een week over doet, na bekendmaking van de CVE, om over te gaan tot actie.
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
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 9 januari 2013 13:20]
Maar dan moet er natuurlijk wel iemand zijn die constant dit soort zaken in de gaten houdt en aan de alarmbel trekt. Zelfs als er aan de alarmbel getrokken wordt moeten dit soort beslissingen eerst door een aantal managementniveaus voordat besloten wordt heel DigID offline te halen.
Het gaat inderdaad om de latere CVE, die jij bedoelde (CVE-2012-5664) van 2 jan, was niet erg gevaarlijk want erg afhankelijk van het gebruik van één specifieke rails-addon die niet heel veel gebruikt wordt (authlogic).
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.
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.
Uhm dat is niet zo zeer de vulnerability waar we het hier over hebben.. Waar jij het over heb kan je in je code afvangen.. (hoort eigenlijk door het framework gedaan te worden) vandaar de patch...
Wel fijn dat zij het platform eerder offline halen, dan dat eventuele hackers zouden doen. Nu hopen dat er geen misbruik van is geweest!
Het zal wel het bekende overposting probleem van rails zijn, gok ik zo.
Nee. Het gaat hoogstwaarschijnlijk over CVE-2013-0156 (affects: all versions & remote exploitable)
Eigenlijk moet dit toch haast onmogelijk zijn bij een overheid. Je moet er vanuit kunnen/mogen gaan dat dit soort belangrjike gegevens echt goed beveiligd zijn. Dat de werkelijkheid anders is weet ik, maar dit is al de zoveelste overheid ict blunder in afzienbare tijd.
Wellicht tijd voor een frisse wind door de ICT van de overheid?
Wellicht tijd voor een frisse wind door de ICT van de overheid?
Volgens mij is dit geen blunder hoor. Er is gewoon een lek ontdekt in Ruby, waar DigiD op gebouwd is. Dat kan gebeuren, net als dat er beveiligingslekken in Windows zitten. Dat ze de boel nu offline halen is vervelend, maar de enige juiste zet.
Ik vind dat juist alle lof naar de overheid moet gaan: er zijn maar weinig organisaties die zo'n belangrijke stap zouden nemen om te voorkomen dat er gegevens gelekt worden.
Dapper, zeker. Het is een hele stap om het hele platform down te brengen. Ze mogen echter wel wat meer doen aan informatievoorziening richting de bedrijven / instanties die gebruik maken van DIGID.
Wij kregen meldingen van klanten (ik werk bij een zorgverzekeraar) dat ze niet in konden loggen en konden het probleem niet eenduidig achterhalen, tot we van een collega hoorden dat hij op Nu.nl had gelezen dat DIGID eruit lag. Ik ben een van de contactpersonen met Logius binnen onze organisatie, maar ik heb NIETS gehoord. Geen mailtje, niets.
Wij kregen meldingen van klanten (ik werk bij een zorgverzekeraar) dat ze niet in konden loggen en konden het probleem niet eenduidig achterhalen, tot we van een collega hoorden dat hij op Nu.nl had gelezen dat DIGID eruit lag. Ik ben een van de contactpersonen met Logius binnen onze organisatie, maar ik heb NIETS gehoord. Geen mailtje, niets.
[Reactie gewijzigd door Frituurman op 9 januari 2013 13:59]
Om 13:27 hebben wij een mail van Logius gekregen waarin is aangegeven dat DigiD om 12:20 uit de lucht is gehaald.
Ik heb bij ons ook met beheer gesproken, maar ook zij hebben niets ontvangen. Dan lijkt er ook nog eens iets mis met de notificatie van Logius
Mwa, je kunt software niet perfect maken. Dat dit soort dingen kunnen voorkomen is een feit. Ik vind het juist goed dat hier, voor zover ik dat kan zien, adequaat op gereageerd wordt door de zaak offline te halen.
Dat vind ik een stuk beter dan wat er bijvoorbeeld bij het EPD gebeurt, waar men willens en wetens een lek systeem uit wil rollen.
Dat vind ik een stuk beter dan wat er bijvoorbeeld bij het EPD gebeurt, waar men willens en wetens een lek systeem uit wil rollen.
Ze gebruiken software waar een lek in is ontdekt, en nemen actie. Waarom is dat een blunder?
Een blunder zou ik het niet echt willen noemen, maar meestal maakt software die een hoog level beveiliging nodig heeft geen gebruik van standaard frameworks. Want als die gekraakt zijn, dan zoeken hackers meteen alle systemen op die op hetzelfde framework draaien.
En dan vervolgens klagen dat Overheid ICT projecten zoveel geld kosten? Want het niet mogen gebruiken van standaard frameworks als Ruby on Rails betekend dat je alles zelf moet gaan schrijven, en dan lopen de kosten onmiddelijk hoog op.
Het voordeel van zulke frameworks is dat ze over het algemeen wat robuuster en veiliger in elkaar zitten dan homebrew oplossingen. Dat er dan een keer een fout inzit, is zuur, maar voor hetzelfde geld had DigiD elke maand downtime vanwege 'problemen'.
Dat is echt kletskoek. Ieder systeem van enige complexiteit gebruikt standaard software, libraries, runtimes of frameworks. Denk aan databases, app- en webservers, VC runtimes, .net, java en ga zo maar door. Geef eens een enkel voorbeeld waar dat om beveiligings redenen niet is gedaan?
Onzin. Het is juist andersom. Een framework wat door veel partijen wordt gebruikt is veel meer ondersteuning voor. Er worden bugs gevonden en meteen gefixt. Met een eigen custom prutje heb je veel zelfgeschreven beveiligingsgaten die nooit gevonden worden, totdat een hacker ze misbruikt. Als je iets geeft om security probeer je niet iets zelf in elkaar te prutsen. Vooral niet als je de overheid bent, die staan niet bekend om hun goede security.
Ik vind het juist goed dat ze ruby on rails gebruiken. Er is een grote community omheen en daardoor veel kennis beschikbaar. Je ziet al een deze fixes en de snelle release dat ze security daar serieus nemen. En bovendien is RoR goed in het snel kunnen ontwikkelen van applicaties. Je hoeft niet telkens opnieuw het wiel uit te vinden omdat er voor een hoop zaken gems beschikbaar zijn. Dat scheelt ons allemaal belastinggeld.
Ik vind het juist goed dat ze ruby on rails gebruiken. Er is een grote community omheen en daardoor veel kennis beschikbaar. Je ziet al een deze fixes en de snelle release dat ze security daar serieus nemen. En bovendien is RoR goed in het snel kunnen ontwikkelen van applicaties. Je hoeft niet telkens opnieuw het wiel uit te vinden omdat er voor een hoop zaken gems beschikbaar zijn. Dat scheelt ons allemaal belastinggeld.
In zo een 90% van de ICT zaken van de overheid word dit uitbesteed, zo ook bij DigiD. Het is dus vaak niet zo dat de overheid zelf het probleem niet op kan lossen maar meer dat er vaak voor de goedkoopste oplossing (lees ICT partner) word gekozen die vaak geen of niet genoeg kennis en controle hebben over het product.
Als de overheid nu eens zou investeren in eigen kennis en personeel, dan misschien zou je een systeem kunnen ontwikkelen dat beter aansluit op de bestaande infrastructuur. Helaas is het vaak zo dat elk eilandje binnen de overheid zijn eigen koning/keizer/admiraal heeft, en dat deze allemaal hun eigen bewindt voeren als het hier op aan komt.
ICT zal altijd het ondergeschoven kindje zijn, dus verwacht niet dat dit in de nabije toekomst gaat veranderen. Zeker niet met de bezuinigingen.
Als de overheid nu eens zou investeren in eigen kennis en personeel, dan misschien zou je een systeem kunnen ontwikkelen dat beter aansluit op de bestaande infrastructuur. Helaas is het vaak zo dat elk eilandje binnen de overheid zijn eigen koning/keizer/admiraal heeft, en dat deze allemaal hun eigen bewindt voeren als het hier op aan komt.
ICT zal altijd het ondergeschoven kindje zijn, dus verwacht niet dat dit in de nabije toekomst gaat veranderen. Zeker niet met de bezuinigingen.
Beetje kort door de bocht. Bugs en foutjes zullen in elk stukje software zitten. De lek waar het hier waarschijnlijk over gaat is ook pas net ontdekt en openbaar geworden dus dan kun je het echt nog niet verwijten. Bugfree software bestaat gewoon niet en daarom het is belangrijker om te kijken hoe ze ermee om gaan en in dit geval is daar niks mis mee. Ze hebben het platform meteen offline gehaald toen ze de bug hebben gevonden en werken nu aan een fix.
Tegen dit soort dingen kan je je niet beveiligen. Tenzij je misschien zelf een obscuur framework schrijft wat je closed source houd. Maar dan loop je weer het risico dat het onveilig is omdat er maar een zeer beperkte groep kan controleren of het framework veilig is.
Daarom ben ik ook tegen het EPD, een softwaresysteem dat aan het internet hangt kan je nooit 100% veilig maken. Natuurlijk zijn de dossiers bij de artsen zelf ook te hacken maar dat is een stuk minder lucratief aangezien je per hack veel minder dossiers in handen krijgt.
Daarom ben ik ook tegen het EPD, een softwaresysteem dat aan het internet hangt kan je nooit 100% veilig maken. Natuurlijk zijn de dossiers bij de artsen zelf ook te hacken maar dat is een stuk minder lucratief aangezien je per hack veel minder dossiers in handen krijgt.
dus het is een overheid ict blunder dat ze security serieus genoeg nemen om het offline te halen?
Wat doet de overheid nu verkeerd? Er zit een bug in de software van een externe leverancier en daar handelen ze op... goed lijkt me. Hoogstends misschien nog wat te traag.
Wat doet de overheid nu verkeerd? Er zit een bug in de software van een externe leverancier en daar handelen ze op... goed lijkt me. Hoogstends misschien nog wat te traag.
Wat versta je onder "ICT bij de overheid"? Realiseer je je dat bijna alles wat de overheid laat ontwikkelen gebeurt door de grote "professionele" ICT bedrijven in nederland? Je weet wel, die broedplaatsen voor onkunde.
De fout zit in Ruby on Rails, niet de toepassing...Eigenlijk moet dit toch haast onmogelijk zijn bij een overheid. Je moet er vanuit kunnen/mogen gaan dat dit soort belangrjike gegevens echt goed beveiligd zijn. Dat de werkelijkheid anders is weet ik, maar dit is al de zoveelste overheid ict blunder in afzienbare tijd.
Wellicht tijd voor een frisse wind door de ICT van de overheid?
Ongelooflijk, makkelijker kunnen we het niet maken.
Handig al die sites die van digid gebruik maken.
Zorgverzekering, werkplein, belastingdienst enz.
Hopelijk snel verholpen
Handig al die sites die van digid gebruik maken.
Zorgverzekering, werkplein, belastingdienst enz.
Hopelijk snel verholpen
[Reactie gewijzigd door krotwijk op 9 januari 2013 13:09]
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
tuurlijk, platform ontwikkeld door een externe partij, bug in opensource software, platform direct neer gehaald nadat bug bekend werd maar de overheid als opdrachtgever draagt weer de schuld. Moet jij mij eens uitleggen hoe.
Als het door RoR komt dan betekend het dat hun sleutel dus is gelekt of dat ze gewoonweg een eventuele standaardsleutel niet hebben aangepast. Gezien het doel van DigiID kan dit potentieel ernstig zijn. Je kunt je dan bij de overheid digitaal uitgeven als iemand anders en dat is natuurlijk wel ernstig misbruik.
Dat het zo plotseling offline wordt gehaald zou kunnen wijzen dat er al misbruik van is gemaakt, sterker nog ik vermoed het.
@Egrimm;
Natuurlijk zou dat ook kunnen.
Maar tenzij de update niet silent kan worden doorgevoerd lijkt mij dit eerder een misbruikte exploit. Ik ben altijd wat sceptischer wat dat betreft. Natuurlijk geld hier, net zoals bij intro van Red Alert de welbekende one-liner: "Time will tell. Sooner or later, time will tell."
Dat het zo plotseling offline wordt gehaald zou kunnen wijzen dat er al misbruik van is gemaakt, sterker nog ik vermoed het.
@Egrimm;
Natuurlijk zou dat ook kunnen.
Maar tenzij de update niet silent kan worden doorgevoerd lijkt mij dit eerder een misbruikte exploit. Ik ben altijd wat sceptischer wat dat betreft. Natuurlijk geld hier, net zoals bij intro van Red Alert de welbekende one-liner: "Time will tell. Sooner or later, time will tell."
[Reactie gewijzigd door Auredium op 9 januari 2013 13:23]
OF ze halen het natuurlijk gewoon offline omdat ze niet willen dat er misbruik van gemaakt wordt. Totdat we horen dat er misbruik is gemaakt kunnen we misschien beter gewoon niet doen alsof we knieën zijn waar met hamertjes tegen getikt wordt, en naar conclusies springen ;-)
Dat het voor jou, voor mij en voor andere Tweakers plotseling is wil nog niet zeggen dat de site plotseling uit de lucht is gehaald. Het betekent hooguit dat wij dat niet weten.
Lijkt mij eerder dat de partijen die er verantwoordelijk voor zijn daar geen lichtvaardig besluit over hebben genomen en het één en ander grondig hebben afgewogen. Dat ze bij digid niet aan de grote klok hangen dat er wat speelt lijkt me logisch. Dat het anderen vervolgens verrast is dan ook niet vreemd.
Lijkt mij eerder dat de partijen die er verantwoordelijk voor zijn daar geen lichtvaardig besluit over hebben genomen en het één en ander grondig hebben afgewogen. Dat ze bij digid niet aan de grote klok hangen dat er wat speelt lijkt me logisch. Dat het anderen vervolgens verrast is dan ook niet vreemd.
Dat is een tunnelvisie Het kan ook zijn dat de overheid DigiD dusdanig belangrijk vind dat zelfs al lijken ze niet direct geraakt door deze bug wel alles offline haalt. Better safe then sorry.
Er is ook volgens metasploit nog geen manier bekend om bijvoorbeeld gegevens uit het systeem te trekken.. Natuurlijk met de vulnerability die bijna 20 uur geleden openbaar is gemaakt is de kans erg groot dat er binnen onafzienbare tijd (ze dachten zelf 24 uur) wel een poc zal zijn.
tuurlijk, platform ontwikkeld door een externe partij, bug in opensource software, platform direct neer gehaald nadat bug bekend werd maar de overheid als opdrachtgever draagt weer de schuld. Moet jij mij eens uitleggen hoe
Wat een toeval, wil net gaan inloggen. Zijn ze bezig met onderhoud, en zie ik dit opeens 
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
