Les utilisateurs de Dify auto-hébergé peuvent toujours partager une clé secrète publique après les mises à jour

De nombreuses installations auto-hébergées de Dify fonctionnent avec une faille de sécurité critique due à une erreur de configuration persistante. Les utilisateurs qui ont installé la plateforme d'applications IA avant la version 1.15.0 et qui ont ensuite mis à jour leur logiciel possèdent probablement encore une clé secrète par défaut, disponible publiquement dans l'historique du projet. Cette négligence permet à quiconque connaissant la clé de falsifier des jetons d'authentification et d'accéder à des données sensibles.

Ce qui s'est passé

Le problème provient de la manière dont Dify gère les fichiers de configuration lors de l'installation et des mises à niveau. Lors de la première configuration de Dify, les utilisateurs copient généralement un fichier d'environnement exemple pour créer leur configuration active. Cette opération de copie n'a lieu qu'une seule fois. Les mises à niveau ultérieures remplacent les images de conteneurs et le fichier Docker Compose, mais le fichier d'environnement local reste inchangé. Par conséquent, les paramètres de sécurité contenus dans ce fichier reflètent l'état du logiciel au moment de l'installation initiale, et non celui de la version actuelle.

Jusqu'à la version 1.14.x, le fichier de configuration exemple était livré avec une SECRET_KEY codée en dur et fixe. Cette clé était une longue chaîne commençant par sk-9f73s3lj. Bien que la documentation suggérait de générer une clé unique, la plupart des utilisateurs n'ont pas effectué cette étape. À partir de la version 1.15.0, le fichier exemple a été modifié pour laisser le champ SECRET_KEY vide, indiquant au système de générer automatiquement une clé persistante dans le répertoire de stockage. Cependant, les utilisateurs ayant installé des versions antérieures ont conservé l'ancienne clé publique dans leur configuration locale, même après avoir mis à niveau vers des versions plus récentes et plus sécurisées du logiciel.

Cette clé secrète est vitale pour la sécurité. Elle est utilisée pour signer les cookies de session, générer des jetons d'authentification JWT, créer des signatures d'URL de fichiers via HMAC-SHA256 et chiffrer les identifiants OAuth tiers. Étant donné que l'ancienne valeur de la clé est visible dans l'historique public GitHub de Dify, tout attaquant peut la lire. La possession de cette clé permet à un adversaire de signer des jetons que l'instance Dify acceptera comme valides, contournant ainsi efficacement les mécanismes d'authentification.

Détails clés

• Versions vulnérables : Toute instance Dify installée avant la version 1.15.0 qui a été mise à niveau sans que son fichier .env ait été manuellement actualisé.
• L'indicateur : La présence d'une SECRET_KEY commençant par sk-9f73s3lj dans le fichier docker/.env.
• Impact : Les attaquants peuvent signer des JWT valides, accéder aux sessions utilisateur et potentiellement déchiffrer les identifiants OAuth stockés.
• Commande de remédiation : Les utilisateurs peuvent vérifier la présence de la clé vulnérable en utilisant grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env.
• Effets secondaires de la correction : La rotation de la clé déconnectera immédiatement tous les utilisateurs, invalidera les URL de fichiers existantes et rompra les intégrations de plugins OAuth, nécessitant une nouvelle autorisation.
• Risques supplémentaires : Le même problème de configuration statique affecte les ports exposés, les paramètres CORS et les mots de passe de base de données par défaut.

Contexte

Dans les applications conteneurisées comme Dify, les variables d'environnement sont souvent gérées via un fichier .env. Ce fichier contient des secrets et des paramètres de configuration qui personnalisent l'application pour un déploiement spécifique. Lorsque les développeurs publient des mises à jour, ils fournissent souvent de nouveaux fichiers exemples (.env.example) avec des valeurs par défaut améliorées ou de nouveaux champs requis. Cependant, les gestionnaires de paquets et Docker Compose ne fusionnent pas automatiquement ces modifications dans le fichier .env actif de l'utilisateur afin d'éviter d'écraser les paramètres personnalisés. Cela incombe à l'administrateur de revoir et de mettre à jour manuellement les fichiers de configuration après les mises à niveau majeures.

La SECRET_KEY agit comme racine de confiance pour de nombreuses opérations cryptographiques au sein de l'application. Si cette clé est compromise, l'intégrité de l'ensemble du système de gestion de session est ébranlée. Dans les scénarios d'auto-hébergement, où l'opérateur est responsable à la fois de l'infrastructure et de la sécurité de l'application, maintenir une bonne hygiène dans ces fichiers de configuration est aussi critique que patcher les binaires logiciels eux-mêmes.

Pourquoi c'est important

Pour les équipes exécutant leurs propres logiciels, cet incident met en lumière un angle mort courant dans les routines de maintenance. De nombreux administrateurs supposent que tirer la dernière image Docker ou exécuter une commande de mise à niveau compose garantit une sécurité complète. En réalité, la dérive de configuration peut laisser des vulnérabilités significatives ouvertes, même sur les dernières versions logicielles. Ceci est particulièrement dangereux pour les plateformes d'IA comme Dify, qui peuvent traiter des données d'entreprise sensibles, des prompts propriétaires ou des bases de connaissances internes.

L'impact va au-delà de l'accès non autorisé immédiat. Puisque la clé chiffre les identifiants OAuth tiers, une compromission pourrait entraîner un mouvement latéral vers d'autres services connectés. De plus, la nécessité de faire pivoter la clé cause des perturbations opérationnelles. Tous les utilisateurs sont déconnectés et les intégrations doivent être rétablies. Pour les responsables IT et les ingénieurs DevOps, cela signifie que la remédiation de sécurité n'est pas seulement une correction technique, mais un événement de gestion du changement qui nécessite une communication avec les parties prenantes et un timing soigné pour minimiser les temps d'arrêt.

Ce que vous pouvez faire

• Vérifiez votre configuration : Exécutez grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env dans votre terminal. Un résultat de 1 signifie que vous êtes vulnérable.
• Générez une nouvelle clé : Si vous êtes vulnérable, sauvegardez votre fichier .env, utilisez openssl rand -base64 42 pour générer une nouvelle clé aléatoire, puis mettez à jour le fichier.
• Redémarrez les services : Appliquez la modification en exécutant docker compose up -d pour redémarrer les conteneurs avec le nouveau secret.
• Restreignez l'exposition des ports : Liez les ports nginx et de débogage à 127.0.0.1 dans votre fichier .env pour empêcher l'accès externe, en utilisant des variables telles que EXPOSE_NGINX_PORT=127.0.0.1:8080.
• Sécurisez les paramètres CORS : Définissez explicitement CONSOLE_CORS_ALLOW_ORIGINS sur l'URL spécifique de votre console au lieu de laisser la valeur par défaut joker *.
• Mettez à jour vers la dernière version : Assurez-vous d'exécuter au moins Dify 1.17.1 pour corriger d'autres avis de sécurité qui pourraient ne pas avoir d'identifiant CVE.