Minderung der HTTPoxy-Sicherheitslücke mit NGINX

Am 18. Juli 2016 wurde eine Sicherheitslücke namens „HTTPoxy“ bekannt gegeben, die einige serverseitige Webanwendungen betrifft, die in CGI- oder CGI-ähnlichen Umgebungen ausgeführt werden, wie beispielsweise einige FastCGI-Konfigurationen. Zu den bisher bekannten betroffenen Sprachen gehören PHP, Python und Go.

Es wurden eine Reihe von CVEs zugewiesen, die bestimmte Sprachen und CGI-Implementierungen abdecken:

• Apache HTTP-Server (CVE-2016-5387)
• Apache Tomcat (CVE-2016-5388)
• Gehen (CVE-2016-5386)
• PHP (CVE-2016-5385)

Es gibt eine neue Website mit einer Beschreibung der Sicherheitslücke , einen CERT-Hinweis zur Sicherheitslücke und eine Beschreibung der Entdeckung der Sicherheitslücke . Weitere Informationen finden Sie auf der persönlichen Website von Dominic Scheirlinck , einem Open-Source-Webentwickler bei Vend.

Dieser Beitrag beschreibt die Sicherheitslücke und erklärt, wie Sie mit NGINX oder NGINX Plus Versuche abwehren, die Sicherheitslücke auf Ihren Servern auszunutzen.

Die Sicherheitslücke entsteht durch einen Namespace-Konflikt. Eine CGI- oder FastCGI-ähnliche Schnittstelle legt Umgebungsvariablen basierend auf HTTP-Anforderungsparametern fest und diese können interne Variablen überschreiben, die zum Konfigurieren der Anwendung verwendet werden.

Der derzeit einzige bekannte Angriff auf diese Sicherheitslücke betrifft Webanwendungen, die in CGI- und CGI-ähnlichen Umgebungen ausgeführt werden und bestimmte HTTP-Clientbibliotheken verwenden, um HTTP-Anfragen an andere Dienste zu stellen. In diesem Fall können Angreifer möglicherweise interne Anfragen, die von der Anwendung generiert werden, an einen Server ihrer Wahl umleiten und so alle in den Anfragen enthaltenen geheimen Daten erfassen, wie unten gezeigt.

Mit NGINX oder NGINX Plus können Sie Versuche, diese Sicherheitslücke auszunutzen, erkennen und abwehren. Auf diese Weise können Sie Angriffe wirksam verhindern und haben Zeit, den betroffenen Code zu prüfen und zu aktualisieren.

Wie die HTTPoxy-Sicherheitslücke ausgenutzt wird

Um zu verstehen, wie diese Sicherheitslücke funktioniert – und wie Sie Ihre Site davor schützen können – müssen Sie wissen, wie CGI und CGI-ähnliche Schnittstellen Umgebungsvariablen festlegen und wie einige Anwendungsbibliotheken durch Umgebungsvariablen konfiguriert werden.

1 – CGI und CGI-ähnliche Schnittstellen definieren Umgebungsvariablen mit dem Namen HTTP_*

Viele Web-Anwendungsplattformen verwenden CGI oder CGI-ähnliche Schnittstellen, um Anwendungen mit einem Webserver zu verbinden. Diese Schnittstellen konvertieren die Header in einer HTTP-Anfrage in Umgebungsvariablen mit dem Präfix HTTP_ . Eine Anwendung kann dann den Wert von Anforderungsheadern (wie etwa dem User-Agent ) nachschlagen, indem sie ihre Umgebung untersucht.

Ein Client kann beliebige Umgebungsvariablen (beginnend mit HTTP_ ) in der Umgebung der Anwendung erstellen, indem er Anfragen mit dem entsprechenden Header sendet. Beispielsweise wird der Anforderungsheader Foo: bar zur Umgebungsvariable HTTP_FOO=bar .

Einige Plattformen bieten eine Abstraktionsschicht, die die Umgebungsvariablen verbirgt, wie beispielsweise die globale Variable $_SERVER von PHP. Dennoch basieren diese Abstraktionen auf der Standardpraxis von CGI und FastCGI zum Festlegen von Umgebungsvariablen.

Beispielsweise kann eine PHP-Anwendung beim Ausführen im FastCGI-Modus den User-Agent- Header einer Anforderung wie folgt ermitteln:

// beide Methoden geben das gleiche Ergebnis zurück$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – Einige Anwendungsbibliotheken werden über Umgebungsvariablen konfiguriert

Eine komplexe Webanwendung bezieht Funktionen aus externen Bibliotheken. Beispielsweise müssen Anwendungen manchmal HTTP-Anfragen an andere Dienste stellen (ähnlich wie bei Microservices) und verwenden hierfür möglicherweise eine der gängigen Drittanbieterbibliotheken. Diese Bibliotheken unterstützen häufig eine Funktion namens „HTTP-Proxy“ , einen Zwischenserver, der zum Weiterleiten der HTTP-Anfrage verwendet wird.

Eine einfache Möglichkeit, eine solche Bibliothek zu konfigurieren, besteht darin, die Konfiguration über Umgebungsvariablen zu definieren. Die weit verbreitete PHP-Bibliothek Guzzle wird teilweise durch eine Umgebungsvariable namens HTTP_PROXY konfiguriert, die auf die Adresse eines Proxyservers eingestellt ist. Wenn HTTP_PROXY auf diese Weise festgelegt ist, leitet die Bibliothek alle von ihr generierten HTTP-Anfragen an die Adresse des Proxyservers weiter. Das net/http -Paket von Go und das Requests-Modul von Python vertrauen der Umgebungsvariable HTTP_PROXY und interpretieren sie auf die gleiche Weise.

3 – Die Art der Sicherheitslücke

Die in Punkt 2 beschriebenen Bibliotheken wurden nicht im Hinblick auf CGI oder CGI-ähnliche Schnittstellen entwickelt und die Umgebungsvariable HTTP_PROXY , der sie vertrauen, überschneidet sich mit dem HTTP_- Namespace, der von CGI- und FastCGI-Schnittstellen verwendet wird, wie in Punkt 1 beschrieben.

Indem sie den Wert der Umgebungsvariablen HTTP_PROXY auf eine Adresse ihrer Wahl setzen, können Angreifer interne HTTP-Anfragen, die von der Anwendung generiert werden, umleiten und abfangen. Diese Anfragen können vertrauliche Informationen wie Authentifizierungsschlüssel und private Daten enthalten und Informationen über zusätzliche APIs und Endpunkte preisgeben, die ausgenutzt werden können.

Ein Angreifer kann dies tun, indem er eine Anfrage mit einem Proxy- Header sendet. Die CGI- oder FastCGI-Schnittstelle erstellt daraufhin für diesen Aufruf der Anwendung eine Umgebungsvariable mit dem Namen HTTP_PROXY . Beachten Sie, dass nur Anfragen, die den falschen Proxy- Header enthalten, direkt betroffen sind.

Abwehren des Angriffs mit NGINX und NGINX Plus

Die HTTPoxy-Sicherheitslücke wirkt sich nicht direkt auf NGINX aus, aber NGINX und NGINX Plus können verwendet werden, um Angriffe zu stoppen, die auf dieser Sicherheitslücke basieren.

Mit einer Upstream-FastCGI-Anwendung kommunizieren

Sie können NGINX verwenden, um die Eingabe für die Anwendung zu „bereinigen“, indem Sie den FastCGI-Parameter HTTP_PROXY auf die leere Zeichenfolge setzen. Dadurch wird der Parameter vollständig aus der FastCGI-Anfrage entfernt:

fastcgi_param HTTP_PROXY "";

Lastenausgleich und Proxying von HTTP-Datenverkehr

Beim Weiterleiten von HTTP-Anfragen an eine Upstream-Anwendung ist es ratsam, alle Proxy- Header auf eine leere Zeichenfolge zu setzen, für den Fall, dass die Upstream-Anwendung auf einer anfälligen Plattform ausgeführt wird:

proxy_set_header Proxy "";

Erkennen von Versuchen, die Sicherheitsanfälligkeit auszunutzen

Proxy ist kein Standard-HTTP-Header , daher können alle Anfragen, die diesen Header enthalten, als verdächtig angesehen werden. Sie können NGINX oder NGINX Plus verwenden, um diese verdächtigen Anfragen in einem dedizierten Zugriffsprotokoll zu protokollieren, das hier badactor.log heißt:

# Definieren Sie das Format „proxylog“ im http{}-Kontext:log_format proxylog „$remote_addr – $remote_user [$time_local]“

„$request“ $status $body_bytes_sent“

„$http_referer“ „$http_user_agent““

„$http_proxy““;

# Protokollieren Sie Anfragen mit einem Proxy-Header im Format „proxylog“
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

Notiz : Im Konfigurationskontext, in dem Sie diese access_log- Direktive platzieren, überschreibt sie jegliche Zugriffsprotokollierung, die auf einer höheren Ebene in der NGINX-Konfiguration definiert ist.

Bleib sicher

NGINX und NGINX Plus bieten eine effektive Möglichkeit, HTTPoxy-Angriffe zu überwachen und abzuwehren. Verwenden Sie die oben beschriebenen Techniken, um Ihre Anwendung zu schützen, während Sie Ihren Code prüfen, aktualisieren und testen, um die Sicherheitslücke zu beseitigen.

Wenn Sie Fragen haben, kommentieren Sie bitte diesen Beitrag. Wenn Sie NGINX Plus-Abonnent sind, können Sie sich auch gerne an unser Supportteam wenden, um Hilfe zu erhalten.