RabbitMQ unter Bedrohung: zwei Zugangskontrollausfälle enthüllen OAuth-Geheimnisse und ermöglichen es Ihnen, die Kontrolle des Brokers zu übernehmen

Miggo-Sicherheitsforscher haben in RabbitMQ zwei Zugangskontrollversagen entdeckt und gemeldet, die auf Versionen aus der Linie 3.13.0 Einfluss nehmen und gemeinsam die Vertraulichkeit und Isolation von Business-Messaging-Infrastruktur-Tendern gefährden können. Einer der Fehler ermöglicht es einem nicht authentifizierten Angreifer, das OAuth-Geheimnis vom Broker wiederherzustellen, was in Einstellungen, die dazu konfiguriert sind, dieses Geheimnis zu verwenden, dazu führen kann, dass ein Administrator-Token erhalten kann und somit in der Gesamtkontrolle über Schwänze, Nachrichten, Benutzer und die Konfiguration des Brokers. Der andere Defekt ermöglicht es jedem authentifizierten Benutzer, Warteschlangen und Wechsel in einem virtuellen ausländischen Host aufzulisten und Nachrichtenzähler und Verbraucher zu konsultieren, ohne die Berechtigungen zu respektieren.

Das Vorhandensein eines veralteten und zugänglichen HTTP-Endpunktes, der sensible Informationen zurückgibt, unterstreicht einen klassischen Ausfall: eine administrative Route, die nicht die gleiche Berechtigung wie andere kritische Punkte anwendet. Die Exposition eines geheimen OAuth ist besonders ernst weil es ein Informationsleck in eine volle Angriffskapazität verwandelt, indem das Geheimnis für gültige Anmeldeinformationen ausgetauscht wird. In mehrstufigen Umgebungen, in öffentlichen Wolken oder wenn die Management-Schnittstelle (standardmäßig im Port 15672) aus unzuverlässigen Netzwerken zugänglich ist, wird das Risiko multipliziert.

RabbitMQ hat Korrekturen in den Zweigen 4.3.0, 4.2.6, 4.1.11, 4.0.20 und 3.1.15 veröffentlicht, um diese Probleme zu lösen, und die Betreuer haben gleichzeitig andere kritische Schwachstellen im Zusammenhang mit der TLS-Authentifizierung und der JWKS-Validierung angesprochen, die JWTs von einem AitM-Angreifer akzeptiert werden können. Es ist wichtig, offizielle Updates zu überprüfen und umzusetzen; die Sicherheitsseite und die Projektversionshinweise sind der Ausgangspunkt für die Überprüfung von Versionen und Patches: https: / / www.rabbitmq.com / security.html und die Management-Plugin-Dokumentation, die den Port und Endpoints beschreibt: https: / / www.rabbitmq.com / management.html.

Wenn es nicht möglich ist, sofort zu parken, gibt es dringende Minderungsmaßnahmen, die das Belichtungsfenster reduzieren. Drehen Sie das OAuth-Geheimnis im Zusammenhang mit der Verwaltung. oauth _ kunden _ geheimnis in jeder Anlage, deren Management-Schnittstelle von unzuverlässigen Netzwerken zugänglich ist; ein begangenes Geheimnis muss vorbeugend ungültig gemacht werden. Beschränken Sie den Zugriff auf die Management-Schnittstelle (Port 15672) durch Firewall-Regeln oder Netzwerksegmentierung und betrachten Sie die gezielte Sperrung der verletzlichen Route (z.B. WAF-Regeln, die GET / api / auth leugnen), bis das Patch angewendet wird. Separate Kunden von virtuellen Hosts und setzen strenge Zugriffssteuerungen durch virtuellen Host um die betroffene Oberfläche zu enthalten.

Neben der technischen Minderung wird empfohlen, die Protokolle zu überprüfen und nach Missbrauchszeichen zu suchen: Ausgabe von ungewöhnlichen administrativen Token, Verbindungen von externen IP-Adressen zum üblichen Bereich und unerwartete administrative Operationen in Warteschlangen und Austausch. Wenn verdächtige Aktivität erkannt wird, gehen Sie auf den Widerruf von betroffenen Anmeldeinformationen, die Rotation von Geheimnissen und, falls erforderlich, die Wiederherstellung von Backups vor dem Eindringen durchgeführt. Nähere Informationen zu CVE-Eingängen und Schweregrade finden Sie in der Datenbank NIST-Verwundbarkeit: CVE-2026-57219 und CVE-2026-57221.

Aus betrieblicher Risikoperspektive erinnern diese Fehler daran, dass Messaging-Broker sind nicht nur Daten-Transport-Komponenten: Metadaten und Anmeldeinformationen enthalten, die, falls vorhanden, Seitenbewegungen und persistente Kontrolle zulassen innerhalb der Infrastruktur. Entwicklungs- und Betriebsteams sollten die Management-Schnittstellen mit der gleichen Härte wie die öffentlich-belichteten APIs behandeln: starke Authentifizierung, konsequente Autorisierung in allen Endpunkten und Minimierung des Strahlradius durch Segmentierung und weniger privilegierte Prinzipien.

Für Manager, die Cloud- oder Multi-Tenant-Umgebungen verwalten, ist die Kombination von Fehlern - die Leckage des geheimen und Informationslesens zwischen Mietern - besonders beunruhigend, weil sie die Eskalation von legitimem Zugang zu einem Mieter zur Kontrolle des gesamten Brokers erleichtert. Überprüfen Sie die Netzwerkzugriffsrichtlinien, wenden Sie gegebenenfalls gegenseitige Authentifizierungssteuerungen (mTLS) an und überwachen Sie die JWKS-Antworten und Zertifikatseinstellungen nach der Anwendung von Updates, um neu gemeldete TLS / JWKS Sicherheitslücken zu beheben.

Schließlich halten Sie eine Update-Cadence- und Sicherheitstests aufrecht: Nehmen Sie administrative Endpoints-Scans in regelmäßige Bewertungen ein, führen Penetrationstests, die sich auf die Verwaltung des Brokers und Dokumentantwortverfahren für die Rotation von Geheimnissen und Restauration nach Engagement konzentriert. Die Kombination von sofortigen Patch, temporären Minderungen und organisatorischen Veränderungen, wie administrative Schnittstellen belichtet und geschützt werden, wird die Wahrscheinlichkeit von Schwachstellen, wie sie zu schweren Ereignissen führen, deutlich verringern.