Managed hosting door True

‘Dienst gebouwd op Ruby on Rails moet offline’

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. Dit lek treft echter niet alleen DigiD, veel meer websites en instanties zijn kwetsbaar voor hackersaanvallen als zij hun Ruby on Rails-platform niet updaten naar de meest recente versie. Dit blijkt uit rondvraag onder Computable-experts.

Uit een advies van het Nationaal Cyber Security Centrum (NCSC) blijkt wat de impact van het lek in Ruby on Rails kan zijn en om welke kwetsbaarheid het gaat. Dat een aantal hacktools onder andere ook op Ruby on Rails gebaseerd zijn, zorgt ervoor dat er veel aandacht voor het lek is en dat zowel oplossingen als aanvalshulpmiddelen ontwikkeld worden. Het is daarom zaak voor alle websites die functionaliteit op Ruby on Rails ontwikkeld hebben, om deze software te updaten naar de nieuwste versies die op 8 januari 2013 zijn vrijgegeven. Het gaat hier om de Ruby on Rails-versies 3.2.11, 3.1.10 en 3.0.19.

Twitter, Xing, Philips en Uitzending Gemist

Wereldwijd zijn bijna een kwart miljoen websites geheel of gedeeltelijk ontwikkeld op Ruby on Rails. In elk geval 52.000 webservers wereldwijd zijn voorzien van Ruby on Rails. Bekende voorbeelden hiervan zijn de social media Twitter en Xing, maar ook de website van Philips en de dienst Uitzending Gemist van de NOS zijn op het webapplicatieframework ontwikkeld. Voor beheerders van onder andere deze sites is het zaak zo snel mogelijk de software te updaten.

‘Punt is nu dat al deze honderdduizenden op Ruby on Rails gebaseerde websites niet allemaal even actief beheerd worden’, meent Computable-expert en zelfstandig ict-architect Berend van Bemmel. ‘Met een actieve beheerder zal de patch snel geïnstalleerd worden, maar een groot percentage sites wordt maar zeer marginaal of niet beheerd. Deze blijven kwetsbaar en zullen vroeger of later ontdekt worden door scripts, robots of scanners en overgenomen worden, met directe of indirecte schade tot gevolg.’

Hosting provider en applicatiebouwer

Het lek in Ruby on Rails is gevaarlijk voor iedereen die nog op de getroffen versie van het Ruby on Rails-platform draait’, zegt Computable-expert Stefan Koopmanschap, software engineer bij Ibuildings. ‘Iedereen die software heeft die gebouwd is met Ruby on Rails en die niet heeft geüpgrade naar de meest recente versie met de fix voor dit probleem, is dus automatisch kwetsbaar. Het is dus van belang de Ruby on Rails-installatie zo snel mogelijk bij te werken. Voor veel mensen zal dit betekenen dat hun hosting provider een upgrade zal moeten uitvoeren. Het gaat hier om hosting providers die centrale, beheerde versies van Ruby on Rails aanbieden. In sommige gevallen is actie van de applicatiebouwer benodigd. Zo heeft cloudprovider Engine Yard zijn klanten opgeroepen om hun applicatie opnieuw te deployen.’

Collega-expert Maarten Hartsuijker, security consultant bij Classity, erkent dit. ‘Het lek bevindt zich in Ruby on Rails en is daardoor erg gevaarlijk voor iedereen die dit framework heeft gebruikt om zijn webapplicatie mee te bouwen. Websites kunnen uiteraard preventieve maatregelen hebben getroffen zoals het uitschakelen van deze specifieke functionaliteit of specifieke intrusion prevention; maatregelen waardoor ze geen of minder last van de fout hebben. Uiteindelijk is het lek vooral gevaarlijk voor de gebruikers en bedrijven die hun gegevens aan een kwetsbare site hebben toevertrouwd.’

Webdienst direct offline halen

Expert John Veldhuis, senior system consultant bij Sophos, raadt bedrijven en website die webdiensten aanbieden aan om net als DigiD deze dienst direct offline te halen. ‘Het lek in Ruby on Rails is zeer gevaarlijk voor iedereen die het gebruikt bij een voor anderen openstaande webdienst. Het is dan ook absolute noodzaak dat wanneer je prijs stelt op de integriteit, vertrouwelijkheid en beschikbaarheid van je dienst en je gegevens, je de dienst offline haalt en pas weer aanbiedt na het dichten van de gaten.’

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4636300). © Jaarbeurs IT Media.
?

 

Reacties

Na wat andere blunders bij de (semi)overheid op ict-gebied betreft het nu dan een lek dat ze eigenlijk niet hadden kunnen voorkomen.
Zou er een lek in het .NET framework zitten, dan plukken veel websites daar ook de wrange vruchten van.

Nee, dan getuigt het alvast online zetten van de kersttoespraak maar daarna bij hoog en laag volhouden dat men de url niet zelf mag intypen (of wijzigen) want dat dit strafbaar is van een veel grotere onkunde en prutserij. Als ik mijn deur open laat staan en op vakantie ga denk je dat de verzekering dan iets vergoedt als mijn huis door insluipers wordt bezocht (breken hoeven ze immers niet).
Onmiddellijk ontslaan incapabel gepeupel.

Jammer dat niet toegelicht wordt wat de risico's zijn als het lek niet gedicht wordt en alleen aangegeven wordt dat het heel gevaarlijk is. Denk wel dat de toonzetting zal helpen om de beheerders snel tot actie te laten overgaan, mits een site actief beheerd wordt.

Dit is een interessante gebeurtenis, net als CMS-en van DotNetNuke, Joomla, Drupal, WordPress vaak niet actief beheerd worden zijn dit soort gaten gewoon dingen die gebeuren. Zoals Hans opmerkt kan dit ook bij een .NET framework gebeuren en is de impact groot.

Dit valt overigens onder een stukje governance en governance heeft weer een relatie met volwassenheid van je dienst of organisatie.

Welke frameworks worden gebruikt binnen de organisatie en wie monitort op dit soort gebeurtenissen?

Ook ontwikkelaars zouden pro-actief naar klanten moeten zijn om ze in ieder geval op de hoogte te stellen.

Vergeet ook niet het feit dat hackers er behoorlijk dicht op zitten tegenwoordig en elkaar aktief ondersteunen (tegen betaling soms) om zo snel mogelijk te reageren op gevonden lekken in frameworks.
Zo'n strijd is simpelweg niet te winnen op de lange termijn.
Maar goed, nog niet iedereen is hiervan overtuigd.

Voor zover ik het begrijp gaat het om zoiets als een SQL injection alleen dan via JSON/XML waardoor een kwaadwillende code kan plaatsen op een website die gebruik maakt van Ruby. Zoals anderen aangeven dus iets wat ook kan gebeuren als er gebruik gemaakt wordt van .NET of andere platformen. Het stemt hoopvol dat er adequaat gereageerd is op een bekende zwakheid (door hackers geopenbaard?) en deze direct is opgelost. Ik vrees echter dat we nog vaker dit soort 'verstoringen' zullen zien omdat alle kinderziekten er zeker nog niet allemaal uit 'gevaccineerd' zijn.

En zoals Henri al aangeeft gaat het inderdaad om actief beheer waarbij direct de juiste correctieve acties genomen worden om erger te voorkomen. Want hoewel NCSC waarschuwt voor serieuze fouten in Joomla draaien nog opmerkelijk veel websites op oude en dus kwetsbare versie van dit CMS framewerk. Gezien de tijd die ik nodig had om modules en templates te migreren kan ik dat wel begrijpen maar slim is het niet.

Maar mensen kiezen ook voor een framewerk omdat zelf ontwikkelen, beheren en inrichten gewoon teveel tijd en geld kost maar dat maakt ze wel afhankelijk. Bijvoorbeeld van instanties als NCSC die waarschuwt voor ernstige bedreigingen want ondertussen volstaat het niet meer om te vertrouwen op 'patch tuesday' omdat er veel meer framewerken op het web bijgekomen zijn.

Vacatures Security

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×