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
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.
Tegenwoordig heeft ieder bedrijf / instelling / Webserver omgeving een IPS nodig om dergelijke beveligingslekken te herkennen.
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.
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.
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.