Selbst gehostete Dify-Nutzer teilen nach Upgrades möglicherweise weiterhin einen öffentlichen Secret Key

Viele selbst gehostete Dify-Installationen weisen aufgrund eines persistenten Konfigurationsfehlers eine kritische Sicherheitslücke auf. Nutzer, die die KI-Anwendungsplattform vor Version 1.15.0 installiert und ihre Software anschließend aktualisiert haben, verfügen wahrscheinlich immer noch über einen Standard-Secret-Key, der in der Projekt-Historie öffentlich verfügbar ist. Diese Nachlässigkeit ermöglicht es jedem, der den Schlüssel kennt, Authentifizierungs-Tokens zu fälschen und auf sensible Daten zuzugreifen.

Was passiert ist

Das Problem liegt darin begründet, wie Dify Konfigurationsdateien während der Installation und Aktualisierung behandelt. Wenn Nutzer Dify erstmals einrichten, kopieren sie typischerweise eine Beispiel-Umgebungsdatei, um ihre aktive Konfiguration zu erstellen. Dieser Kopiervorgang erfolgt nur einmal. Spätere Aktualisierungen ersetzen die Container-Images und die Docker Compose-Datei, aber die lokale Umgebungsdatei bleibt unberührt. Folglich spiegeln die Sicherheitseinstellungen in dieser Datei den Zustand der Software zum Zeitpunkt der Erstinstallation wider, nicht den der aktuellen Version.

Bis zur Version 1.14.x enthielt die mitgelieferte Beispielkonfigurationsdatei einen hartcodierten, festen SECRET_KEY. Dieser Schlüssel war eine lange Zeichenkette, die mit sk-9f73s3lj begann. Obwohl die Dokumentation empfahl, einen eindeutigen Schlüssel zu generieren, unternahmen die meisten Nutzer diesen Schritt nicht. Ab Version 1.15.0 wurde die Beispieldatei so geändert, dass das Feld SECRET_KEY leer gelassen wird, was das System anweist, einen persistenten Schlüssel im Speicherordner automatisch zu generieren. Nutzer, die ältere Versionen installiert hatten, behielten jedoch auch nach dem Upgrade auf neuere, sicherere Softwareversionen den alten, öffentlichen Schlüssel in ihrer lokalen Konfiguration bei.

Dieser Secret Key ist für die Sicherheit von entscheidender Bedeutung. Er wird verwendet, um Session-Cookies zu signieren, JWT-Authentifizierungs-Tokens zu generieren, Datei-URL-Signaturen über HMAC-SHA256 zu erstellen und OAuth-Anmeldedaten Dritter zu verschlüsseln. Da der alte Schlüsselwert in der öffentlichen GitHub-Historie von Dify sichtbar ist, kann jeder Angreifer ihn auslesen. Der Besitz dieses Schlüssels ermöglicht es einem Gegner, Tokens zu signieren, die die Dify-Instanz als gültig akzeptiert, wodurch Authentifizierungsmechanismen effektiv umgangen werden.

Wichtige Details

• Betroffene Versionen: Jede Dify-Instanz, die vor Version 1.15.0 installiert wurde, aktualisiert wurde, deren .env-Datei aber nicht manuell angepasst wurde.
• Der Indikator: Das Vorhandensein eines SECRET_KEY, der mit sk-9f73s3lj beginnt, in der Datei docker/.env.
• Auswirkung: Angreifer können gültige JWTs signieren, auf Benutzersitzungen zugreifen und potenziell gespeicherte OAuth-Anmeldedaten entschlüsseln.
• Befehl zur Überprüfung: Nutzer können den anfälligen Schlüssel mit grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env prüfen.
• Nebenwirkungen der Behebung: Das Rotieren des Schlüssel führt sofort zur Abmeldung aller Benutzer, macht bestehende Datei-URLs ungültig und unterbricht OAuth-Plugin-Integrationen, was eine erneute Autorisierung erfordert.
• Zusätzliche Risiken: Dasselbe statische Konfigurationsproblem betrifft exponierte Ports, CORS-Einstellungen und Standard-Datenbankpasswörter.

Hintergrund

Bei containerisierten Anwendungen wie Dify werden Umgebungsvariablen oft über eine .env-Datei verwaltet. Diese Datei enthält Geheimnisse und Konfigurationsparameter, die die Anwendung für eine bestimmte Bereitstellung anpassen. Wenn Entwickler Updates veröffentlichen, stellen sie häufig neue Beispieldateien (.env.example) mit verbesserten Standardeinstellungen oder neuen erforderlichen Feldern bereit. Paketmanager und Docker Compose führen diese Änderungen jedoch nicht automatisch in die aktive .env-Datei des Nutzers zusammen, um das Überschreiben benutzerdefinierter Einstellungen zu verhindern. Dies legt die Last auf den Administrator, Konfigurationsdateien nach großen Upgrades manuell zu überprüfen und zu aktualisieren.

Der SECRET_KEY fungiert als Vertrauensanker für viele kryptografische Operationen innerhalb der Anwendung. Wenn dieser Schlüssel kompromittiert wird, ist die Integrität des gesamten Sitzungsverwaltungssystems gefährdet. In Szenarien mit Selbsthosting, in denen der Betreiber sowohl für die Infrastruktur als auch für die Anwendungssicherheit verantwortlich ist, ist die Pflege dieser Konfigurationsdateien genauso kritisch wie das Patchen der Software-Binaries selbst.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, hebt dieser Vorfall eine häufige Blindstelle in Wartungsroutinen hervor. Viele Administratoren gehen davon aus, dass das Ziehen des neuesten Docker-Images oder das Ausführen eines compose-Upgrad-Befehls volle Sicherheit gewährleistet. In Wirklichkeit kann Konfigurationsdrift erhebliche Schwachstellen offen lassen, selbst auf den neuesten Softwareversionen. Dies ist besonders gefährlich für KI-Plattformen wie Dify, die möglicherweise sensible Unternehmensdaten, proprietäre Prompts oder interne Wissensbasen verarbeiten.

Die Auswirkungen gehen über unmittelbaren unbefugten Zugriff hinaus. Da der Schlüssel OAuth-Anmeldedaten Dritter verschlüsselt, könnte ein Kompromiss zu lateraler Bewegung in andere verbundene Dienste führen. Darüber hinaus verursacht die Notwendigkeit, den Schlüssel zu rotieren, operative Störungen. Alle Benutzer werden abgemeldet, und Integrationen müssen neu eingerichtet werden. Für IT-Leiter und DevOps-Ingenieure bedeutet dies, dass die Sicherheitsbehebung nicht nur eine technische Korrektur ist, sondern ein Change-Management-Ereignis, das Kommunikation mit Stakeholdern und sorgfältiges Timing erfordert, um Ausfallzeiten zu minimieren.

Was Sie tun können

• Konfiguration prüfen: Führen Sie grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env in Ihrem Terminal aus. Ein Ergebnis von 1 bedeutet, dass Sie verwundbar sind.
• Neuen Schlüssel generieren: Falls verwundbar, sichern Sie Ihre .env-Datei und verwenden Sie openssl rand -base64 42, um einen neuen zufälligen Schlüssel zu generieren, und aktualisieren Sie dann die Datei.
• Dienste neu starten: Wenden Sie die Änderung an, indem Sie docker compose up -d ausführen, um die Container mit dem neuen Secret neu zu starten.
• Port-Exposure einschränken: Binden Sie nginx- und Debugging-Ports in Ihrer .env-Datei an 127.0.0.1, um externen Zugriff zu verhindern, verwenden Sie Variablen wie EXPOSE_NGINX_PORT=127.0.0.1:8080.
• CORS-Einstellungen absichern: Legen Sie CONSOLE_CORS_ALLOW_ORIGINS explizit auf Ihre spezifische Konsolen-URL fest, anstatt es als Standard-Wildcard * beizubehalten.
• Auf die neueste Version aktualisieren: Stellen Sie sicher, dass Sie mindestens Dify 1.17.1 ausführen, um andere Warnhinweise zu beheben, die möglicherweise keine CVE-IDs haben.