Een eenvoudige analyse van het Ruby on Rails lek

Geschreven door Ariejan de Vroom op 10-1-2013

Op 9 januari jl. werd DigiD.nl offline gehaald in verband met een beveiligingslek in het Ruby on Rails framework. De nationale media heeft dit breed uitgemeten en verbaasde burgers stelden terechte vragen zoals:

Kunnen die programmeurs niet wat beter opletten als ze iets doen? Hoe kan ik DigiD nog vertrouwen? Moet er geen wettelijke regelgeving komen op het gebied van IT security?

Om die vragen te kunnen beantwoorden is het belangrijk te weten wat er precies met het Ruby on Rails framework aan de hand was. Zonder gebruik te maken van vakjargon zal ik een analyse van de situatie geven.

Een webapplicatie, zoals DigiD, bestaat uit verschillende componenten, net als je mobiele telefoon of je auto die ook heeft. Iedere component heeft een eigen taak en zodra je een nieuwe auto of telefoon ontwikkelt, kun je componenten uit het vorige model hergebruiken.

Een voordeel van dit hergebruik is dat meerdere fabrikanten dezelfde componenten kunnen gebruiken en dat ze samen voor een betere en slimmere component kunnen zorgen. De Toyota Aigo / Citroën C1 / Peugeot 107 is hier een goed voorbeeld van.

Bij web development is dit niet anders. Ruby on Rails is een solide basis voor webapplicaties. Rails is al sinds 2004 in ontwikkeling en duizenden developers over de hele wereld hebben bijgedragen aan de ontwikkeling van dit framework. In februari 2012 maakten zelfs ruim 235 duizend websites gebruik van Ruby on Rails, waaronder DigiD.

Deze week werd er bekend gemaakt dat er een mogelijk lek zat in het Ruby on Rails framework. Wat die fout precies inhoudt is moeilijk uit te leggen, maar het is vergelijkbaar met de volgende analogie:

Er zit een fout in de pinautomaten en er komt gratis geld uit. Om dat geld uit de automaat te halen moet je het volgende doen: je moet een specifieke tekst op de chip van je bankpas zetten, deze tekst moet achterstevoren geschreven worden en je moet gebruik maken van een specifiek type pas. Alleen bij bepaalde pinautomaten kun je je pas dan invoeren en als je dan op de juiste toetscombinatie drukt, dan pas krijg je een willekeurig bedrag aan geld, dat uit de automaat rolt.

Het idee is duidelijk: het klinkt vaag en de analogie staat vol van toevalligheden. Dat is precies wat er ook met Ruby on Rails aan de hand is. Het is gebleken dat in Ruby on Rails een foutje zit waardoor specifiek aangeleverde data verkeerd kan worden geinterpreteerd wat ertoe zou kunnen leiden dat er enige toegang is tot gegevens.

Ondanks dat duizenden Ruby on Rails programmeurs bezig zijn om elke mogelijke vorm van toegang tot gegevens te voorkomen, is er toch een exotisch scenario doorheen geglipt: De kans dat een kwaadwillende misbruik van dit lek maakt en er gegevens mee buit maakt of schade mee aanricht is zeer klein – maar als het lukt, zou de schade erg groot kunnen zijn.

De onderzoeker die dit lek vond heeft melding gemaakt bij de ontwikkelaars van Ruby on Rails. Binnen een paar uur was er een oplossing in de vorm van een Ruby on Rails versie 3.2.11. Ontwikkelaars die gebruik maken van Ruby on Rails in hun webapplicatie, zoals DigiD, kunnen deze nieuwe versie installeren waarmee ze gewapend zijn tegen aanvallen op dit nieuwe lek.

Het upgraden van Rails kun je vergelijken met het vervangen van het chassis van een auto. Alles hangt eraan vast, en hoewel het nieuwe chassis dezelfde maten heeft wil je toch zeker zijn dat de rest van de auto er weer goed op gemonteerd is voor je de snelweg op gaat.

Nu duidelijk is wat er aan de hand was en hoe het is opgelost is het tijd om te kijken naar de vraag of dit voorkomen had kunnen worden.

Het antwoord daarop is simpelweg Nee. Beveiliging is de kunst van het beperken van risico’s. Helaas is het voor mensen onmogelijk om vooraf elk risico af te dekken.

De brandweer heeft goede procedures en materieel om veilig branden en rampen te bestrijden; toch vielen er bij de vuurwerkramp in Enschede vier doden.

In Fukushima bleek dat de kerncentrales daar niet goed bestand blijken tegen een zeldzame combinatie van aardbeving en tsunami.

Israel’s Yitzhak Rabin was goed beveiligd, zijn body guards tot de tanden toe bewapend. Toch bleek Yigal Amir in 1995 in staat hem dodelijk te verwonden.

Net als de professionals die branden blussen, kerncentrales bouwen of personen beveiligen zijn web ontwikkelaars zich zeer bewust de beveiliging van hun producten. Een 100% waterdichte beveilig bestaat simpelweg niet.

Wat wel bestaat is een professional die goed voorbereid is, snel en adequaat ingrijpt en daarna lering trekt uit dat incident voor in de toekomst.

De vraag is dan ook niet: is DigiD 100% beveiligd? Nee, de vraag is: hoe wordt er omgegaan met een dergelijk incident? Of zoals in dit geval: de dreiging van een incident.

De developers bij DigiD hebben gedaan wat ook iedere goede body guard zou doen: het beveiligde in veiligheid brengen, en daarna het risco zo snel en effectief mogelijk uitschakelen.