‘Ruby on Rails blijft zonder update risicovol’

Het eerste grote lek van 2013 werd gevonden in het applicatieontwikkelframework Ruby on Rails. Het lek op zich was niet zo spannend, want binnen een dag was het gepatched. Toch kunnen de gevolgen ervan verstrekkend zijn, menen Computable-experts. Vooral organisaties en websites die niet snel de software-update doorvoeren zijn kwetsbaar.

Graham Bolton, voorzitter, IfSQ

Programmeurs maken fouten. Goed geschreven, goed geteste programmatuur bevat nog altijd zo’n vijftien tot vijftig verborgen gebreken per duizend regels code. Systemen bevatten, mede door het gebruik van alles omvattende frameworks, vaak vele miljoenen regels code. Dat vertaalt zich in vele tienduizenden fouten.

De programmeurs die het Ruby on Rails-framework schreven, hebben geluk: hun software wordt dagelijks door vele duizenden programmeurs gebruikt en daardoor grondiger getest. De codekwaliteit van populaire frameworks is daardoor vaak beter dan die van hun minder populaire concurrenten.

Gelukkig is sql-injectie een type lek dat een duidelijke patroon heefe en daarom is een update snel voor handen. Het grote gevaar voor gebruikers van Ruby on Rails die de update niet in gebruik nemen, is dat er een lek in je website zit. De vraag is of dit erg is. Het is namelijk veel erger als mensen weten waar dat lek zit.

Gert Jan Timmerman, hoofd Kenniscentrum, Info Support

Het lek in Ruby on Rails kan zeker ook gevaarlijk zijn voor anderen. Het uitschakelen van een where-clause in een query kan ervoor zorgen dat gebruikers informatie te zien krijgen die niet voor hen bedoeld is. Afhankelijk van de privacygevoeligheid van de beheerde gegevens kan dit zeer ernstig zijn. Ook kan het ertoe leiden dat onbevoegden kunnen inloggen op een site waar ze eigenlijk geen toegang tot mogen hebben.

Ook denial of service-aanvallen zijn gevaarlijk voor alle websites. Dit houdt in dat een website ontoegankelijk gemaakt wordt voor gewone gebruikers door bijvoorbeeld extreem grote berichten te sturen. In feite zijn dit soort lekken gevaarlijk voor elke website die ermee gebouwd is. Afhankelijk van de gevoeligheid van de gegevens op een site, kan het risico groter of kleiner zijn, maar het is een niet te onderschatten risico voor iedereen die deze technologie gebruikt.

Gerard Stroeve, manager security & continuity services, Centric

Ruby on Rails wordt door meer dan 240.000 websites gebruikt. Het gevonden lek is al meer dan zes jaar aanwezig in de software. Dit houdt in dat alle websites (van de afgelopen zes jaar!) die gebruikmaken van Ruby on Rails vatbaar zijn voor dit lek.

HD Moore van Rapid7 heeft al bekend gemaakt dat er een exploit toegevoegd is aan Metasploit. Zonder veel inhoudelijke kennis zullen mensen in staat zijn Ruby on Rails te exploiten. Ook wordt er een workaround aangeboden.

Steven Dondorp, managing director, Northwave

In principe is het lek in Ruby on Rails gevaarlijk voor iedereen die het gebruikt. De database is manipuleerbaar waardoor je er informatie uit kunt halen, of de website kan crashen doordat er commando’s uitgevoerd worden op het serversysteem. De kwetsbaarheid biedt mogelijkheden voor aanvallen om continu andere websites op te sporen om ook daar dezelfde manipulatie uit te voeren. Op die manier ontstaat een infectieketen.

Anderzijds is deze potentiële kwetsbaarheid ruim vijf jaren bekend als probleem in steeds wisselende vormen. Het probleem doet zich snel voor wanneer er een standaard installatie heeft plaatsgevonden, zonder dat continue beveiligingschecks en aanpassingen worden uitgevoerd. Het geeft des te meer aan dat beveiliging niet stopt bij design, maar juist een continue controle en opvolging nodig heeft middels periodieke pentests en aanpassingen. Daarmee kan gesteld worden dat de keuze voor Ruby on Rails niet pertinent een slechte hoeft te zijn, gezien de evenzeer krachtige functionaliteit en businessmogelijkheden die het biedt. Zolang de consequenties voor de continue bewaking op de beveiliging en de passende aanpassingen dan wel periodiek opgevolgd blijven worden bij een dergelijke keuze.

Richard Jansen, ceo, SDB

Ik heb wel ervaring met Ruby on Rails en ik kan niet anders zeggen dan dat het een serieuze bedreiging is voor de veiligheid van elke applicatie die met Ruby on Rails is ontwikkeld. Het gaat met name om alle installaties met Ruby-versies van de laatste zes jaar die standaard zijn ingericht en uitgerold. Hierbij ga ik er vanuit dat de meeste zo zijn gedeployed. Je zal moeten weten wat je moet doen, maar de echte hackers met kennis van Ruby zullen daar geen probleem mee hebben. Als ze de website aanvallen dan is succes 100 procent gegarandeerd. Je kunt een website platleggen, maar je kunt ook informatie uit de database halen of de informatie veranderen. Met een code-injectie met de juiste sql-statements kun je de informatie opvragen.

De oplossing is om snel te upgraden naar de nieuwste versie van Ruby on Rails of in ieder geval de versies 2.3.15. 3.0.19, 3.1.10 of en 3.2.11. Je kunt ook tijdelijk de XML of YAML uitzetten, alhoewel dat natuurlijk de werking van de website zal beïnvloedden als je er gebruik van maakt.

René Pieete, senior sales systems engineer, McAfee

Praktisch iedere Ruby on Rails-webapplicatie is gevoelig voor de kwetsbaarheid genaamd CVE-2012-5664. Voor Ruby on Rails is inmiddels een patch uitgebracht die dit probleem moet adresseren. De dreiging is een vorm van sql-injectie die mogelijk is op zowel de applicatie als op het onderliggende Ruby on Rails-framework. Aangezien Ruby on Rails een zeer populair ontwikkelframework is voor (web)applicaties, heeft deze kwetsbaarheid potentieel een grote impact. Iedere organisatie die een Ruby on Rails-applicatie heeft draaien (en dat zijn er heel wat) loopt dus gevaar.

Gezien de almaar toenemende dreigingen, is het voor organisaties essentieel om een goed inzicht te hebben in de potentiële risico’s, ook wel ‘risk posture’ genoemd. In het kort gezegd betekent dit: welke risico’s loop ik en wat kan ik daar aan doen?. Ik zou organisaties daarom sterk aanbevelen om een oplossing voor vulnerability assessment en management in te zetten. Daarmee kan je snel in kaart brengen welke systemen binnen je netwerk kwetsbaar zijn en wat die kwetsbaarheid inhoudt. Ook krijg je een praktisch advies over welke stappen je moet nemen om de gedetecteerde risico’s te reduceren of weg te nemen. Voor bijvoorbeeld de kwetsbaarheid in Ruby on Rails zal dan duidelijk worden dat de snelste en meest effectieve manier om dit risico weg te nemen, het installeren van de uitgebrachte patch is. De volgende versies zijn inmiddels gepatched: 3.0.18, 3.1.9, en 3.2.10.

Dirk van Veen, security consultant, ITQ Consultancy

Het lek waar het hier om gaat treft voor zover bekend alle webapplicaties die op het Ruby on Rails-platform geschreven zijn. Het maakt hierbij niet uit wat voor webapplicatie het is, wat de applicatie doet of hoe goed de applicatie zelf beveiligd is. Dit komt doordat het gaat om een fout in het Ruby on Rails-platform zelf, en dan met name om het gedeelte dat de vertaling regelt van normale (http-) verzoeken naar specifieke acties en parameters binnen de Rails-applicatie.

Als een verzoek bij (bijvoorbeeld) de DigiD-website binnenkomt, moet eerst bepaald worden welke functie van DigiD wordt aangesproken, wat voor soort gegevens allemaal worden meegegeven aan deze functie en wat de inhoud van die gegevens zijn. Pas als dit bekend is, kan het juiste gedeelte van DigiD actief worden en kunnen de verschillende benodigde veiligheidschecks uitgevoerd worden. Dit zijn checks als ‘Mag de gebruiker hier wel zijn?’, ‘Mogen deze gegevens opgevraagd worden?’, ‘Is de data die opgeslagen wordt wel veilig’, et cetera.

In dit geval zit het lek in het eerste gedeelte, het gedeelte waarin bepaald wordt welke functie met welke gegevens aangeroepen wordt. Het maakt dus eigenlijk niet wie het slachtoffer is (DigiD, Twitter, de site van de slager om de hoek) en hoe de applicatie beveiligd is (volgens de strengste eisen of absoluut niet), want de schade is al veroorzaakt voordat de site de kans krijgt om zich te verdedigen.

Raymond Huwaë, business development director, KryptonVPN

Een database/applicatie is net zo veilig als dat men het beveiligt. Met andere woorden, Ruby on Rails is een geweldige platform om je applicatie op te bouwen, maar men dient wel goed met de beveiliging om te gaan. Dat is ook de reden waarom men toch achterdochtig blijft bij overheden en veiligheid. Men zou ervan uit moeten gaan dat juist de overheid het juiste voorbeeld moet geven hoe om te gaan met veiligheid en beveiliging van je data. Om de schuld nou gelijk bij Ruby on Rails te leggen, is te eenvoudig gedacht.

Een lek als deze heeft waarschijnlijk geleid tot in verscheidene lagen van hun database. Dat heeft als gevolg dat de burger hier last van zou kunnen krijgen, als de hacker zich toegang heeft kunnen verschaffen tot het database en tot in de verschillende lagen van het database.

2013 moet het jaar worden dat organisaties hun securitymaatregelen onder de loep moeten nemen om na te gaan of de databases goed beveiligd zijn of worden. Men heeft voor ogen om de hele maatschappij in te richten in een grote database, zoals bijvoorbeeld DigiD of het patiëntendossier, maar men moet dan ook voor ogen houden om juist deze databases optimaal te beveiligen.

John Knieriem, algemeen directeur, Intermax

Het lek in Ruby is inderdaad voor alle gebruikers gevaarlijk, mits ze die versie gebruiken die kwetsbaar is uiteraard. Het gaat om een soort sql-injectie. Als je de laatste versie installeert is dat lek eruit, maar dat is voor een grote en complexe omgeving als DigiD nogal een operatie. Dus dat ze even de stekker eruit hebben getrokken is eigenlijk de enige juist weg, hoe lastig ook. Er was immers al binnen een uur een exploit voor het lek. Probleem voor DigiD is denk ik dat de nieuwe versie gelijk weer een nieuwe bug introduceert voor JSON-gebaseerde api’s. Dus je zit behoorlijk in een Catch-22 dan.

Ruud de Boom, senior consultant, Seneca

Het lek bestaat uit de mogelijkheid tot sql-injectie als gevolg van het misleiden van Ruby on Rails om een verzoek als een YAML-document of een Ruby on Rails-symbol (beide gebruikersdocumenten) af te handelen. Omdat het omzetten van strings naar bekende datatypen (type casting) niet of niet goed werkt voor de genoemde gebruikersdocumenten, is het mogelijk gebleken om arbitraire code in een Ruby on Rails-applicatie te laten uitvoeren. Dus ook code die een database benadert of een server aanstuurt.

De ernst van de bug is zeer ernstig. Want, als je het eenmaal weet, is het eenvoudig toe te passen. En de mogelijkheden zijn zeer groot… De bug is in ieder geval van toepassing op de versies 1.8.7, 1.9.2, 1.9.3, 2x en 3x (aangetoond). Vrijwel zeker is dat het op alle versies van Ruby on Rails van de laatste zes jaar (en mogelijk eerder) van toepassing is. Iedere gebruiker die Ruby on Rails gebruikt als applicatieframework. Bekende gebruikers zijn, naast DigiD, onder andere Groupon, Basecamp, GitHub, Hulu en Twitter. In totaal betreft het zo’n kwart miljoen websites. De bug kan alleen worden voorkomen door het installeren een workaround of recent uitgebrachte aangepaste versie van de software.