Behebung von Sicherheitslücken in der NGINX-LDAP-Referenzimplementierung

NGINX | 11. April 2022

Am 9. April 2022 wurden Sicherheitslücken in der NGINX-LDAP-Referenzimplementierung öffentlich bekannt gegeben. Wir haben festgestellt, dass nur die Referenzimplementierung betroffen ist. NGINX Open Source und NGINX Plus sind selbst nicht betroffen, und wenn Sie die Referenzimplementierung nicht verwenden, sind keine Abhilfemaßnahmen erforderlich.

Die NGINX-LDAP-Referenzimplementierung verwendet das Lightweight Directory Access Protocol (LDAP), um Benutzer von Anwendungen zu authentifizieren, die über NGINX als Proxy bereitgestellt werden. Sie wird als Python-Daemon zusammen mit der zugehörigen NGINX-Konfiguration unter https://github.com/nginxinc/nginx-ldap-auth veröffentlicht. Ihr Zweck und ihre Konfiguration werden in unserem Blog ausführlich beschrieben.

Bereitstellungen der LDAP-Referenzimplementierung sind von den Sicherheitslücken betroffen, wenn eine der folgenden Bedingungen zutrifft. Im Folgenden erläutern wir diese Bedingungen und mögliche Abhilfemaßnahmen näher:

  1. Befehlszeilenparameter werden zur Konfiguration des Python-Daemons verwendet
  2. Es gibt ungenutzte optionale Konfigurationsparameter
  3. Die LDAP-Authentifizierung hängt von der Mitgliedschaft in einer bestimmten Gruppe ab

Hinweis: Die LDAP-Referenzimplementierung wird als Referenzimplementierung veröffentlicht und beschreibt die Funktionsweise der Integration sowie alle Komponenten, die zur Überprüfung der Integration erforderlich sind. Sie ist keine für den Produktivbetrieb geeignete LDAP-Lösung. Beispielsweise werden der Benutzername und das Passwort, die für die Beispiel-Anmeldeseite verwendet werden, nicht verschlüsselt. In Sicherheitshinweisen wird ausdrücklich darauf hingewiesen.

Mildernder Umstand 1: Zur Konfiguration des Python-Daemons werden Befehlszeilenparameter verwendet

Die LDAP-Referenzimplementierung wird hauptsächlich mithilfe mehrerer proxy_set_header-Direktiven konfiguriert, wie in der Beispielkonfiguration und der Dokumentation beschrieben. Die Konfigurationsparameter können jedoch auch in der Befehlszeile festgelegt werden, mit der der Python-Daemon (nginx-ldap-auth-daemon.py) initialisiert wird.

Wenn Konfigurationsparameter in der Befehlszeile angegeben werden, kann ein Angreifer einige oder alle davon außer Kraft setzen, indem er speziell präparierte HTTP-Anfrage-Header übermittelt. Um dies zu verhindern, stellen Sie sicher, dass alle nicht benötigten Anfrage-Header während der Authentifizierung ignoriert werden, indem Sie dem Block location = /auth-proxy in der NGINX-Konfiguration (nginx-ldap-auth.conf im Repository) die folgende Konfiguration hinzufügen.

location = /auth-proxy {
    # ...
    proxy_pass_request_headers off;
    proxy_set_header Authorization $http_authorization; # If using Basic auth
    # ...
}

Minderungsmaßnahme für Bedingung 2: Nicht verwendete optionale Konfigurationsparameter

Wie bei Bedingung 1 kann ein Angreifer speziell präparierte HTTP-Anfrage-Header übermitteln, um bestimmte Konfigurationsparameter zu überschreiben, sofern diese nicht in der Konfiguration festgelegt wurden. Beispielsweise könnte die LDAP-Suchvorlage überschrieben werden, wenn sie nicht ausdrücklich in der Konfiguration festgelegt ist. Dagegen schützt man sich auf dieselbe Weise wie bei Bedingung 1, indem man die folgende Konfiguration zum Block location = /auth-proxy in der NGINX-Konfiguration hinzufügt.

location = /auth-proxy {
    # ...
    proxy_pass_request_headers off;
    proxy_set_header Authorization $http_authorization; # If using Basic auth
    # ...
}

Abmildernde Bedingung 3: Die Mitgliedschaft in einer LDAP-Gruppe ist erforderlich

Der Python-Daemon bereinigt seine Eingaben nicht. Daher kann ein Angreifer einen speziell präparierten Anfrage-Header verwenden, um die Prüfung der Gruppenmitgliedschaft (memberOf) zu umgehen und so eine erfolgreiche LDAP-Authentifizierung zu erzwingen, selbst wenn der zu authentifizierende Benutzer nicht den erforderlichen Gruppen angehört.

Um dieses Risiko zu mindern, stellen Sie sicher, dass der Backend-Daemon, der das Anmeldeformular bereitstellt, alle Sonderzeichen aus dem Benutzernamenfeld entfernt. Insbesondere muss er die öffnende und die schließende Klammer – ( ) – sowie das Gleichheitszeichen (=) entfernen, da diese Zeichen für LDAP-Server jeweils eine besondere Bedeutung haben. Der Backend-Daemon in der LDAP-Referenzimplementierung wird zu gegebener Zeit entsprechend aktualisiert.

Danksagungen

Wir danken Lucas Verney, valodzka und @_Blue_hornet dafür, dass sie uns auf diese Sicherheitslücken aufmerksam gemacht haben.


Teilen
Schlagwörter: F5 NGINX, News, Tech, 2022

Über den Autor

Liam Crilly
Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.