Logius haalt DigiD offline na lek in Ruby on Rails

09-01-2013 15:02 | Door Sander Hulsman | Lees meer artikelen over: Authenticatie, SQL, SSL, DigiD, Ruby (on Rails) | Lees meer over het bedrijf: Logius | Er zijn 5 reacties op dit artikel | Permalink
DigiD

De dienst Digitale overheid van het ministerie Binnenlandse Zaken Logius heeft per direct het digitale authetiecatiesysteem DigiD offline gehaald. Reden hiervoor is de vondst van een ernstig lek in het onderliggende open source webapplicatieframework Ruby on Rails. Het probleem is zo ernstig dat het gevoelig is voor een denial of service (DoS)-aanval, beveiligingsmaatregelen zoals authenticatie omzeild kunnen worden, er gesjoemeld kan worden met gebruikersrechten, SQL-injecties mogelijk zijn en er toegang tot gegevens mogelijk was. DigiD zelf is niet lek.

Doordat er misbruik van DigiD gemaakt kon worden is besloten per direct de dienst offline te halen. Logius is momenteel bezig met het nemen van noodmaatregelen. Als er een oplossing is gevonden, moet de update eerst nog getest worden voordat DigiD weer gebruikt kan worden. Naar verwachting zal de dienst pas donderdagochtend weer beschikbaar zijn.

JSON- en XML-parameters

In een raportage van NCSC staat het volgende te lezen: ‘Door een fout in de afhandeling van JSON-parameters door ‘Active Record’ bestaat de mogelijkheid om sql-queries te beïnvloeden. De kwetsbaarheid stelt kwaadwillenden niet in staat om de volledige query te wijzigen maar wel om controles op NULL-waarden te beïnvloeden en de WHERE-clause van een query te elimineren. Dit kan een hoge impact op de applicatielogica hebben, maar dit hangt af van de specifieke applicatie die gebruikt maakt van deze functionaliteit.’

Ook is er een fout in verwerking XML-parameters. Hierover wordt gezegd: ‘Ruby on Rails handelt bepaalde typen data niet goed af wanneer deze data is opgenomen in een XML-bericht of als YAML-parameter. Kwaadwillenden kunnen dit XML-bericht aan een Ruby on Rails-applicatie aanbieden via de body van een ‘HTTP POST’-verzoek. Misbruik van deze kwetsbaarheid kan leiden tot het injecteren van willekeurige code en sql-queries, het omzeilen van authenticatiesystemen en het uitvoeren van DoS-aanvallen.’

NCSC, Diginotar en Ombudsman

Het is niet de eerste keer dat DigiD vanwege kwetsbaarheden offline wordt gehaald. Begin 2012 waarschuwde het Nationaal Cyber Security Centrum (NCSC) voor kwetsbaarheden op webservers van Logius. Die zwakke plekken hadden invloed op de beveiliging van DigiD. De apparatuur kon misbruikt worden voor een DoS-aanval.

Ook zorgde een vervalst ssl-certificaat bij het inmiddels failliete Diginotar ervoor dat DigiD offline ging. Overigens was de overheid toen al eens een keer gewaarschuwd door de Nationale Ombudsman. DigiD zou namelijk niet goed beveiligd zijn.

Reacties op dit artikel
De redactie vindt deze reactie: OKICT-er, 09-01-2013 21:33
Goede en snelle actie van Logius. Maar moeten we tevreden zijn? Nee, DigiD en de aangiftemogelijkheid van de Belastingdienst ligt er net zo vaak uit als ING internetbankieren.
 
Zelf kon ik een week geleden geen aangifte doen. Kreeg via een pide meldingpagina (niet de standaard) te zien dat” Uw sessie is verlopen en u bent automatisch uitgelogd” Maar ik was nog niet eens ingelogd. Was de verbinding gekraakt? Dacht van niet; de terugmelding klopte gewoon niet. Volgens het PDFje van belastingdienst.nl voldeed het gebruikte systeem ruim aan de systeemeisen. Op een andere PC met dezelfde browser en browserversie, maar met een ander OS/SP, kon ik wel mijn opgave doen.
Ze hebben dus geen standaard webtest uitgevoerd, waarbij de door hen gemelde systeemeisen getest zijn.
Dus ik vraag me af of de beveiliging van de applicatieketen wel eens goed getest is. Ik vrees van niet, zoals bij veel cloud ketens.
De redactie vindt deze reactie: OKEtienne van der Woude, 10-01-2013 15:11
Tegenwoordig heeft ieder bedrijf / instelling / Webserver omgeving een IPS nodig om dergelijke beveligingslekken te herkennen.
De redactie vindt deze reactie: OKPascal, 10-01-2013 17:02
Ik wil niet (alweer) rot doen maar SQL injections dat zijn toch echt beginners fouten he.
Dat er gekozen wordt voor Ruby on Rails is nog daar aan toe maar waarom wordt die via het web aangeboden data (ongeacht op welke technische manier dat gebeurd) niet even gecontroleerd voordat je het in een query stopt.
Zo moeilijk is dat toch allemaal niet.
De redactie vindt deze reactie: OKGert Jan Wolfis, 10-01-2013 19:29
Goede actie van Logius om de dienst uit de lucht te nemen, omdat de veiligheid niet meer kon worden gewaarborgd. Gezien de typen kwetsbaarheden waarover wordt gesproken lijkt mij eerder een web application firewall op zijn plek, dan een IDS/IPS oplossing.

IDS/IPS snapt alleen algemene applicatie-protocol gerelateerde zaken, maar kan niet het onderscheidt maken op ISO laag 7 (applicatielaag) en applicatie specifieke zaken. Daarbij wordt web verkeer vaak in SSL verpakt en dat is meestal niet zo gunstig voor een IDS/IPS oplossing die vaak niets met SSL verkeer kan en daarom zonder inspectie doorlaat of diep in de beschikbare capaciteit moeten grijpen om SSL te decrypten en weer encrypten wat een performance degradatie van de web omgeving als geheel betekend. Een IPS beschikt vaak over andere kwaliteiten waardoor het zeker een toevoeging op de beveiliging is.
 
Het beschermen van applicaties op het juiste niveau, namelijk de applicatie laag (ISO laag 7) is juist de specialiteit van een web application firewall. Die kan dan tevens de rol van XML firewall op zich nemen, zodat ook de genoemde XML berichten en bijbehorende HTTP posts kunnen worden beschermd.
 
Om dit soort problemen in de toekomst te voorkomen is het zaak om te beschikken over Security LifeCycle Management waarin een vulnerability scanner wordt gekoppeld aan de web application firewall en dit combineert met een SIEM (Security Information and event Managment). Hierdoor ben je als organisatie in staat om bij iedere verandering zelf vast te stellen of de omgeving nog voldoet aan het vereiste niveau van beveiliging. Overigens, het hebben van een bovenstaand SLCM ontslaat u niet van periodieke manuele pentesting.
De redactie vindt deze reactie: OKRutger Storm, 11-01-2013 10:44
Beetje kort door de bocht Pascal. Het ging hier niet om de SQL injection bug maar de kritieke bug (CVE-2013-0156) https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ wat het mogelijk maakt om de authenticatie te bypassen via het RoR platform. Gewoon checken op queries houd dat niet tegen want de lek zit veel dieper. Jij bent in de war met de security vulnerability van vorige week, dat was een SQL injection error.
 
Dit is gewoon een goede actie geweest van Logius. Dinsdag middag/avond kwam de post op de mailinglist en woensdagochtend was DigiD al uit de lucht om het te patchen.
3 vacatures
Security officer

Ministerie van Veiligheid en Justitie, Immigratie- en Naturalisatiedienst , Rijswijk ZH

Senior ICT-Beheerder

Gemeente Breda , Breda

Systeembeheerder Kantoorautomatisering

SURFsara , Amsterdam

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1563 6.2
Klik voor meer info2 1299 6.0
Klik voor meer info3 1266 6.2
Klik voor meer info4 1069 6.2
Klik voor meer info5 976 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 521 6.1
Klik voor meer info9 397 6.0
Klik voor meer info10 391 6.2