Het verhaal achter de 3.7.4 veiligheidsfix

Op 25 juli is Joomla! 3.7.4 uitgebracht, een release die onder andere twee veiligheidsproblemen oplost. Eén daarvan kan die als "Kritiek" bestempeld worden, heeft betrekking op het installatieproces van het Joomla CMS. In de eerste vermelding van deze release in het Security Centre werd verder geen bijzonderheden hierover vermeld, maar nu de oorspronkelijke melder van deze bug zijn informatie hierover heeft gedeeld bij een Def Con conference, kunnen we deze informatie ook met de Joomla Community delen.

De goede oude tijd

Tot nu toe was het installeren van een internetgebaseerde applicatie zoals Joomla! een redelijke rechtdoorzee proces: Je upload de bestanden naar je server, start het installatiebestand in de browser door de juiste URL in te geven, voert je databasegegevens en andere configuratieinstelling in en je bent klaar. Tijdens dit proces werd er niet gecontroleerd of jij de eigenaar bent voor dit proces, er was geen authenticatie. Dit was natuurlijk prima tot nu toe, omdat een aanvaller twee stukjes informatie nodig had:

1. De aanvaller moet weten wanneer de applicatie volledig is geupload maar nog niet geïnstalleerd. Normaal gezegd zal de applicatie installatie niet langer beschikbaar zijn dan enkele minuten waardoor het moeilijker voor de aanvaller wordt
2. De aanvaller moet de juiste URL van de applicatie te achterhalen om het installatieproces te kunnen starten

Maar als een aanvaller deze twee stukjes informatie kan samenvoegen zal het uitbuite hiervan relatief makkelijk zijn.

1. Start het installatieproces en gebruik een externe database die onder controle van de aanvaller staat zodat deze geen brute force aanval hoeft uit te voeren om achter de server gegevens van de eigenaar te komen
2. De aanvaller maakt gebruik van de geïnstalleerde applicatie om een backdoor te uploaden (in Joomla kan dit makkelijk verzorgt worden door een besmette extensie te uploaden)
3. De aanvaller kan de backdoor gebruiken om de applicatie terug in de originele staat terug te zetten door bijvoorbeeld configuration.php te verwijderen en de "installation" map terug te zetten zodat het lijkt alsof er niks gewijzigd is

Deze stappen kunnen in minder dan één minuut uitgevoerd worden als deze geautomatiseerd wordt door middel van een script. Dit was allemaal een theoretisch probleem omdat een aanvaller geen toegang had tot de essentiële informatie (wanneer en waar). Hierdoor heeft vrijwel geen enkel grotere internetapplicatie een verificatieproces en gaf dit ook geen probleem.

Donkere wolken aan de horizon

Helaas door een nieuw protocol dat gebruikt wordt om wijzigingen van het web te beveiligen is deze als bron van informatie te gebruiken. Het protocol, Certificate Transparency (CT) genoemd, is een real-time registratie van alle SSL certificaten die worden uitgegeven bij een "Certificate Authority" (CA). Het simpele idee achter dit protocol is het detecteren van malafide SSL certificaten, wat een verbetering van de veiligheid in belangrijke onderdeel van internet betekent.

Maar als we over dit protocol gaan verder denken heeft deze ook een neveneffect. Stel je voor dat je een website met Joomla maakt. Je hebt een domein geregistreerd en hosting geregeld, en het is 2017 dus er bestaat zoiets moois als LetsEncrypt, dus we nemen er meteen een gratis SSL certificate voor dit domein bij die direct actief is. Een paar minuten later is je domein klaar en ga je Joomla uploaden en boem! Je bent gehackt! Waarom? Omdat je hostingsbedrijf een SSL certificaat automatisch voor je nieuwe domein heeft verzorgd en vanwege het CT protocol is dit nieuwe certificaat (inclusief domeinnaam) dit direct publiek bekend gemaakt is. Een aanvaller die de CT berichten monitort heeft je domein gevonden en test elke paar seconden totdat je Joomla hebt geupload  en wanneer dit het geval is de bovenstaande exploit methode start.

Een balans vinden

Deze aanvalsmethode is een uitstekend voorbeeld van een conflict tussen beveiliging en gebruikersvriendelijkheid die wij, als security team, op regelmatige basis tegenkomen. Het verbeteren van de installatieveiligheid zou een controle op "bewijs van eigendom" worden toegevoegd die vraagt of de gebruiker een bestand, die door het installatieproces aangemaakt is, te verwijderen. Uiteindelijke vragen wij ons vaak af, is deze aanvalsmethode een aannemelijk scenario die in het echt ook zal voorkomen die een negatief effect op gebruikersgemak rechtvaardigt of is het een puur theoretisch probleem?

Met Certificate Transperency kreeg een theoretisch probleem een praktische invulling en was er een oplossing nodig die direct door het security team geïmplementeerd werd. We hebben onze oplossing met de oorspronkelijke melder gedeeld (en met andere CMS-en) en hebben een release datum gekozen die zo dicht mogelijk op de Def Con Talk zat (waar deze aanvalsmethode publiek gemaakt werd).

Tot zover is Joomla de enige grote internetapplicatie die het installatieproces aangepast heeft, en dit alles wordt verzorgd door een klein team van vrijwilligers die achter de schermen aan Joomla werkt om deze veilig te houden.