SICHERHEITSHINWEIS
Umgehen der Authentifizierung über den vom Client bereitgestellten `Remote-User`-Header
Nur auf Systemen mit ‚HTTPBasicAuth`-Backend
- VERÖFFENTLICHUNGSDATUM:
- RELEASE-TYP:
- KRITIKALITÄT:
- RELEASE:
- 16.09.2026
- Security Patches
- Hoch
- 10.1.19 – 11.0.18 – 11.1 Beta 3
Sicherheitshinweis – kritisch
In sehr spezifischen Konstellationen können in OTOBO Umgebungen mit ‚HTTP Basic Auth‘ Rechte / fremde Sessions abgegriffen werden.
Hier finden Sie alle Details zu der mit den heute veröffentlichten Patches geschlossenen Sicherheitslücke – welche Systeme im Detail betroffen sind und konkrete Handlungsempfehlungen für die unterschiedlichen Szenarien.
Details zur geschlossenen Sicherheitslücke
Beide ‚HTTP Basic Auth‘-Authentifizierungs-Backends akzeptieren die Übergabe der Benutzeridentität durch den HTTP-Client. Fehlt der üblicherweise vom Server bereitgestellte ‚REMOTE_USER‘, greift das Backend auf den Wert des HTTP-Anfrage-Headers `Remote-User` zurück, den jeder Client setzen kann. Ein Passwort wird in diesem Szenario nicht abgefragt.
In betroffenen Systemen können unauthentifierte Angreifer mit Zugang zu einem OTOBO Endpoint ohne externes Single Sign-on (SSO) Enforcement sich folglich durch Senden eines einfachen HTTP-Headers als beliebiger User – auch als Systemadministrator – anmelden.
Die Schwachstelle kann insbesondere dort ausgenutzt werden, wo der GenericInterface Endpoint `/otobo/nph-genericinterface.pl` vom SSO ausgeschlossen ist. Hier können API-Clients, die weder Kerberos noch SAML unterstützen, das SSO umgehen und sich direkt an OTOBO authentifizieren.
Wer ist betroffen?
Betroffen sind – ausschließlich – Systeme auf die alle 3 folgenden Punkte zutreffen:
- Ein ‚HTTPBasicAuth‘-Modul ist als Authentifizierungs-Backend für Agenten und/oder Kunden konfiguriert (‚AuthModule‘, ‚Customer::AuthModule‘).
- Der Zugriff erfolgt via Reverse-Proxy oder einen Webserver, der den`Remote-User`-Header unverändert weiterleitet. (So üblich in jeder containerbasierten Umgebung sowie nginx-/Apache-/Traefik-Reverse-Proxy-Konfiguration, da hier der Proxy die Identität nur via HTTP-Header
übertragen kann.) - Mindestens ein Endpunkt ist ohne vorgeschaltetes SSO durch den Proxy erreichbar – z. B. durch den gezielten Ausschluss des GenericInterface, direkten Netzwerkzugriff auf den Anwendungsport oder Standorte, die das SSO-Modul nicht nutzen.
Installationen, bei denen der Webserver die Anfrage selbst authentifiziert und die PSGI-Variable `REMOTE_USER` setzt (beispielsweise Apache mit `mod_auth_gssapi` im CGI-, FastCGI- oder mod_perl-Modus), sind nicht direkt über die Variable – dennoch aber durch den Header-Fallback auf allen nicht derart geschützten Endpoint betroffen.
Unsere Lösung
Die Sicherheitslücke wird durch Installation der heute veröffentlichten Sicherheits-Patches OTOBO 10.1.19 [Link auf Release Note], OTOBO 11.0.18 [Link auf Release Note], OTOBO 11.1 Beta 3 [Link auf Release Note] geschlossen.
Durch die Patches erfordert der Weg über den Header nun ein aktives Opt-in.
Statt eine beliebige ‚Remote-User‘-Variable zu nutzen, wird der Header künftig ignoriert, sofern nicht – alle 2 – nachstehenden Bedingungen erfüllt sind:
- die neue Option `AuthModule::HTTPBasicAuth::TrustProxyHeader` (respektive `Customer::AuthModule::HTTPBasicAuth::TrustProxyHeader`) ist aktiviert – und
- mit der Anfrage wird ein Shared Secret übermittelt, über das sich der Reverse-Proxy identifiziert. Im HTTP Header wird der für die Variable `WebServer::ProxySecret` eingegebene Wert als `X-OTOBO-Proxy-Secret` übermittelt. Sind Container im Einsatz, kann das Shared Secret auch über die Umgebungsvariable `OTOBO_PROXY_SECRET` definiert werden.
Die Überprüfung erfolgt in Echtzeit.
Das Shared Secret funktioniert für nginx, Apache (mod_proxy) und Traefik, weil in jedem Fall durch den Proxy ein einzelner Request Header gesetzt wird, der alle potenziell durch den Client übermittelten Werte überschreibt. Weiterhin empfehlen wir außerdem, den OTOBO Anwendungsport für nicht vertrauenswürdige Netzwerke unzugänglich zu halten.
Bestehende klassische Apache SSO-Implementierungen funktionieren wie bisher: Durch den Webserver selbst gesetzte ‚REMOTE_USER‘ werden weiterhin übernommen.
Auch die im Standard enthaltenen ningx-Templates und Apache-Beispielskonfigurationen wurden aktualisiert. Sie enthalten nun sichere Defaults – explizit auch sichere Beispielkonfigurationen für Ausnahmen für die REST API Schnittstelle („GenericInterface“) – sowie alle nötigen Informationen um einen sicheren Betrieb zu gewährleisten.
Nach dem Update
Kein To Do für Systeme ohne `HTTPBasicAuth`-Authentifizierungs-Backend
Das `WebServer::ProxySecret`-Setting wird nur durch `Kernel::System::Auth::HTTPBasicAuth` und `Kernel::System::CustomerAuth::HTTPBasicAuth`, und nur mit aktiver `TrustProxyHeader` Option ausgelesen. Umgebungen, in denen die Authentifizierung via DB, LDAP, OpenIDConnect, Radius oder ähnliche Backends erfolgt, sind nicht betroffen. Hier muss kein Secret definiert werden.
To Do für Systeme, die `HTTPBasicAuth` mit dem `Remote-User`-Header nutzen
(Reverse-Proxy SSO)
Der Fix für Systeme, die `HTTPBasicAuth` mit dem `Remote-User`-Header (Reverse-Proxy SSO) nutzen, ist bewusst auf „Fail-Closed“ ausgelegt: In betroffenen Systemen wird die User-Authentifizierung ausgesetzt, bis die neue Konfiguration vorgenommen wurde.
Schritte zum Wiederherstellen der SSO-Funktionalität:
1. Aktivieren von `AuthModule::HTTPBasicAuth::TrustProxyHeader` (und/oder der Kunden-Variante).
2. Konfiguriren von `WebServer::ProxySecret` (oder der Umgebungs-Variablen `OTOBO_PROXY_SECRET`).
3. Konfigurieren des Reverse-Proxy: Entfernen von Clients übermittelter Remote-User-Headern und Versenden des Secrets via `X-OTOBO-Proxy-Secret`. In den im Standard enthaltenen Templates sind diese Anpassungen bereits enthalten.
To Do für User unserer offiziellen Docker-HTTPS-/Kerberos-Stacks
Docker-User, die unsere offiziellen HTTPS-/Kerberos-Stacks nutzen, setzen lediglich das `OTOBO_PROXY_SECRET` in der .env-Datei; die Übermittlung an nginx und den OTOBO Container erfolgt automatisch.
Workaround – wenn ein Update nicht sofort möglich ist
Allen Benutzern, die Ihre Systeme nicht sofort updaten können, empfehlen wir dringend bis zum Update folgende Schritte durchzuführen:
- Entfernen des ‚Remote-User‘-Header (alle Schreibweisen) aus eingehenden Client-Anfragen und für alle Standorte auf dem Reverse-Proxy.
- Sicherstellen, dass der Anwendungsport für nicht vertrauenswürdige Netzwerke unzugänglich ist.
- Wo möglich, für betroffene Endpunkte temporär die ‚HTTPBasicAuth‘-Option deaktivieren.
Credits
Wir danken Mokrane ABDELMALEK für die verantwortungsvolle Meldung dieser Schwachstelle. Die viele Jahre alte Vulnerability wurde im Rahmen des VDP-Programms an der Universität Gent identifiziert.
Zu den Release Notes
OTOBO 10.1.19 – Security Patch
OTOBO 11.0.18 – Security Patch
OTOBO 11.1.0 (Beta3) – Security Patch
Bitte aktualisieren Sie Ihr System schnellstmöglich
Danke an die Community und alle Mitwirkenden!
Update, Upgrade oder Fragen?
Wir sind da.
Support-Kunden melden sich einfach über das Portal oder rufen kurz an. Noch kein Support-Vertrag? Vielleicht ist jetzt der richtige Zeitpunkt.
Unternehmen
OTOBO | Simplify work and create exceptional service experiences.
Die Source Code Owner und Maintainer hinter OTOBO.
Software
Service Management-Plattform
OTOBO Demo
OTOBO Download
OTOBO Dokumentation
Security-Problem melden:
security@otobo.org
