Het recent gevonden lek in het webapplicatieframework Ruby on Rails heeft minder impact op organisaties en websites dan dat de markt die indruk wekt. Uit rondvraag onder Computable-expert blijkt dat de bug wel ernstig is, maar dat het euvel relatief makkelijk is op te lossen. Daarnaast wijzen de experts op oplossingen om dit soort problemen in de toekomst te voorkomen.
Het digitale authenticatiesysteem DigiD ging op woensdag 9 januari 2013 volledig offline omdat er een lek was gevonden in het onderliggende webapplicatieframework Ruby on Rails. Toch meent Raymond Comvalius, it-infrastructuurspecialist bij NextXpert, dat dit lek slechts een vrij beperkte impact heeft. ‘DigiD was met name vatbaar vanwege de gebruikte authenticatiemethodiek in combinatie met publiek beschikbare session keys. Daarin is DigiD redelijk uniek in de wereld. Andere sites kunnen vatbaar zijn wanneer de default key is gebruikt bij de ontwikkeling. Dit lijkt door de fabrikant te worden afgeraden en schijnt geen common practice te zijn. Mijn indruk is dat we nooit van dit lek hadden gehoord wanneer DigiD hier niet door getroffen was. Overigens ben ik onder de indruk van de openheid en slagvaardigheid van de betrokken organisaties. Zeer professioneel.’
Stortvloed aan nieuwe exploits
Ook expert Gerco Kanbier, managing director bij Trust in People, kent het probleem in Ruby on Rails en vindt dat je beleid moet opstellen hoe om te gaan met dergelijke problemen. ‘Het ontwikkelen van patches voor het oplossen van softwarelekken en vervolgens implementeren kost tijd en je loopt dus per definitie altijd achter de feiten aan. In je beveiligingsarchitectuur moet je rekening houden dat de beveiliging aan de buitenkant snel kwetsbaarder wordt met de stortvloed aan nieuwe exploits. Je moet ervan uitgaan dat zo’n lek misbruikt kan worden, maar dan wel gedetecteerd wordt. De vraag is hoe zo’n onbekend lek er aan de binnenkant uitziet.’
Expert Hans Taal, verantwoordelijk voor de security services verkopen bij IBM Global Services, ziet dat applicaties nog steeds in productie genomen worden zonder een test op de kwetsbaarheden in de applicatiecode. ‘Controle en het vervolgens doorvoeren van de aanbevolen correcties zou een standaard stap moeten zijn in het applicatieontwikkelproces van alle web- en mobiele-applicaties. Ongeacht welke middleware of tooling wordt gebruikt, applicaties zouden in preproductiefase getest moeten worden op mogelijke exploits. Ik beveel iedereen aan om alle infrastructuurcomponenten regelmatig te laten scannen, zodat je niet vooraf hoeft te investeren in kennis en tools, maar wel precies ziet waar de meest belangrijke kwetsbaarheden zitten en hoe deze te corrigeren zijn.’
Nieuw probleem
‘Het lek geldt voor veel versies van Ruby on Rails’, meent expert Bas Steelooper, senior technical consultant bij Xobit IT Services. ‘Het is een lek wat het mogelijk maakt om SQL-injectie uit te voeren. Dit is een techniek waarmee door het niet afvangen van invoercommando’s, andere commando’s uitgevoerd kunnen worden. Hierdoor zou bijvoorbeeld de database uitgelezen kunnen worden, waardoor gegevens op straat kunnen komen te liggen. Indien je een webwinkel hebt en hier vatbaar voor bent, zou dat dus persoonsgegevens, en betalingsgegevens kunnen betreffen. Een probleem is wel dat de nieuwe versie die hiervoor uitgebracht is, weer een ander probleem heeft gecreëerd. In een bugreport is te lezen dat mensen niet kunnen upgraden naar de nieuwe versie. Dit houd in dat deze mensen vatbaar blijven voor dit lek. Zij zullen hun website offline moeten halen.’
Volgens expert Nienke Ryan, managing director bij Eset NOD32/SpicyLemon, is het netjes dat DigiD de boel heeft dichtgegooid, al had het volgens haar wel iets sneller gemogen. Toch waarschuwt zij wel voor risico’s voor anderen. ‘Als zij niet gepatched hebben en zij draaien op Ruby on Rails, dan kunnen zij kwetsbaar zijn. Maar je kunt niet zeggen dat ze automatisch kwetsbaar zijn omdat ze erop draaien. Daar zitten haken en ogen aan. Door het lek konden delen van een query worden veranderd, NULL-waarden gegenereerd worden, de WHERE-tak van een query worden genegeerd en kon in beperkte mate code worden geïnjecteerd om onveilige code op te starten.’
Comvalius zegt iets over ‘session keys’ en ‘default key’. De 2 CVE’s waar het om gaat gaan over input parsing, en melden niets over keys en dergelijke. Hebben we het hier wel over hetzelfde?
De overige experts lijken voorbij te gaan aan CVE-2013-0156, en alleen in te gaan op de falende null check bij SQL query generatie. De andere CVE is nog een stukje gevaarlijker, en waarschijnlijk ook relevant geweest in het geval van DigiD. Daarmee valt willekeurige code op de server uit te voeren, wat iets meer is dan een SQL query manipuleren.
Raymond lijkt in de war met CVE-2012-5664 (http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/). Dat heeft echter niet zoveel te maken met het offline gaan van DigiD en was een lek een week eerder.
MikeN heeft gelijk. Zie ook [https://www.nsslabs.com/blog/ruby-rails-%E2%80%9Csql-injection%E2%80%9D-vulnerability-cve-2013-0156]. Door de fouten in input parsing kon je SQL injecteren.
Behalve SQL injection was het ook mogelijk om ‘symbols’ te injecteren. Daarmee kun je willekeurige Ruby objecten creeren en code laten uitvoeren, zie https://community.rapid7.com/community/metasploit/blog/2013/01/09/serialization-mischief-in-ruby-land-cve-2013-0156?x=1.
Ooit een presentatie van Ruby on rails gehad. Ik vond direct al de typecasting van Ruby on rails een zwak punt. Nu blijkt wel waarom. Java is hier stricter in. Gelukkig maar.