n8n Enterprise auf Alarm: Identitäts-Link-Versagen zwischen vertrauenswürdigen Emittern können Sie sich als ein anderer Benutzer anmelden

n8n, die Workflow-Automatisierungsplattform, hat Ende Juni einen ernsthaften Fehler behoben, der es Ihnen erlaubte, sich als ein anderer Benutzer einzuloggen, ohne Ihr Passwort zu kennen, wenn die Enterprise-Instanz die Funktion "knock Exchange" aktiviert hatte und mehr als einen externen Emitter vertraute. In technischer Hinsicht war die Ursache des Problems falsche Identität Link: das System verglichen nur die eingehende JWT-Anforderung "sub" mit lokalen Benutzern und habe nicht die "iss" (Ausgabe) betrachtetRFC 7519, und der Austauschstrom von Token, die n8n implementiert folgt RFC 8693.

In der Praxis bedeutete das Versagen, dass ein von einem Emittenten unterschriebenes legitimes Zeichen, das einen "Sub" enthalten, der dem eines vom Emittenten erstellten Benutzers entspricht, von n8n akzeptiert werden konnte, als ob es der andere Benutzer wäre. Der spezifische Angriffsvektor, der es einem Angreifer erlauben würde, einen gültigen Token zu erhalten, wird nicht in der öffentlichen Bekanntmachung erklärt; das lässt Unsicherheit, ob ein normaler Benutzer in einem der Emitter ein bestimmtes "Sub" drängen oder bekommen könnte. Die Datenbanken der öffentlichen Sicherheitslücken spiegeln unterschiedliche Bewertungen wider: Die CNA hat eine hohe Punktzahl in CVSS 4.0 zugewiesen, während NVD sie mit einer geringeren Schwerkraft in CVSS 3.1 aufgelistet. Die CISA hat den Vorfall aufgezeichnet und hat die aktive Ausbeutung auf dem Gebiet bisher nicht bestätigt.

Der technische Bereich ist jedoch ganz genau: Er betrifft nur Enterprise-Einsätze, die den Tokenaustausch ermöglicht haben und das Vertrauen mindestens zwei Rundfunkschlüssel in der Variablen N8N _ TOKEN _ EXCHANGE _ TRUSTED _ KEYS konfiguriert. Das heißt, der exponierte Bereich wird reduziert und entspricht in der Regel OEM oder integrierten Implementierungen, bei denen n8n von Partnern unterzeichnete Token akzeptiert. n8n verteilt die Anordnung in bestimmten Versionen des Produkts; wenn Ihre Umgebung eine frühere Version verwendet, sollte es als verletzlich angesehen werden, bis es aktualisiert wird.

Wenn Sie von einer n8n Enterprise-Instanz verwalten oder abhängen, sind die vorrangigen Aktionen klar und dringend: Überprüfen Sie zunächst die Version, die Sie ausführen und planen Sie das Update auf das letzter Patch mit Korrektur. Parallel dazu, wenn Sie nicht sofort parken können, reduzieren Sie die Belichtung, indem Sie die Token-Austauschfunktion deaktivieren oder die Konfiguration nur auf einen einzigen Emittenten beschränken. Suchen und überprüfen Sie die N8N _ TOKEN _ EXCHANGE _ TRUSTED _ KEYS Variable, bestätigen Sie, wer die vertrauenswürdigen Emitter sind und entfernen Sie gegebenenfalls unnötige Eingaben, bis die endgültige Lösung angewendet werden kann. Diese Minderungsmaßnahmen sind vorübergehend und, wie technische Warnungen zeigen, nicht ersetzen das Software-Update.

Weitere zusätzliche Verteidigungsmaßnahmen umfassen die Stärkung der Telemetrie und der Aufzeichnungen: die Aktivierung und Überprüfung der Authentifizierung und der Token-Austauschwebstühle auf der Suche nach ungewöhnlichem Login, die Implementierung von Alarmen für neu erstellte Sitzungen mit externen Identitäten, die Aktivierung der Multifaktor-Authentifizierung für lokale Konten mit Privilegien und die Verringerung unnötiger Genehmigungen in Workflows und Anmeldeinformationen. Wenn Ihr Einsatz externe Audits oder IMS unterstützt, exportieren Sie diese Ereignisse für eine größere Korrelation und um weitere Untersuchungen zu erleichtern.

Diese Schwachstelle kommt nicht isoliert: in den vergangenen Wochen hat n8n einen anderen Enterprise-Versagen korrigiert, der OAuth-Berechtigungen durch dynamische Anmeldeendpunkte manipulieren konnte, was darauf hindeutet, dass Bereitstellungen mit Vorschau-Funktionalitäten oder OEM-Integrationen eine bestimmte und kontinuierliche Überprüfung verdienen. Um offiziellen Mitteilungen und Patches zu folgen, sollte man sich nicht nur auf die üblichen Änderungen verlassen: die spezifische Identitätsanordnung erscheint nicht immer in den Paketwechselnotizen, und die offiziellen Informationen können im Sicherheitshinweis oder der CVE-Basis liegen. die aktive Überwachung von Lieferantenquellen und öffentlichen Sicherheitsrepositorien als NVD und Produktdokumentation in N8n Dokumentation.

Schließlich sollten Sie die Notwendigkeit prüfen, die betroffenen Nutzer zu informieren und eine forensische Analyse einzuleiten, wenn es Hinweise auf unbefugten Zugriff gibt. Obwohl es derzeit keine öffentlichen Beweise für die Massenausbeutung gibt, erlaubt der Vektor den passwortfreien Zugriff unter bestimmten Bedingungen und jede Exposition von Anmeldeinformationen oder unerwarteten Workflows sollte als potenzieller Vorfall behandelt werden. Die betriebliche Lektion ist klar: Wenn Sie externen Token vertrauen, muss der Identitäts-Link-Code das iss + Sub-Modell vollständig respektieren und die Implementierungen, die diese Überprüfung vereinfachen, sind gefährdet. Überprüfen Sie die Konfiguration, verwenden Sie Patches und verbessern Sie die Überwachung sind wesentliche Schritte, um das Problem zu mildern.