Abwehr der HTTPoxy-Sicherheitslücke mit NGINX

Owen GarrettSenior Director, Produktmanagement

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, beispielsweise in bestimmten FastCGI-Konfigurationen. Zu den bislang bekanntermaßen betroffenen Programmiersprachen gehören PHP, Python und Go.

Es wurden mehrere CVEs vergeben, die bestimmte Sprachen und CGI-Implementierungen betreffen:

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

Es gibt eine neue Website mit einer Beschreibung der Sicherheitslücke, einen CERT-Sicherheitshinweis, 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 erläutert, wie Sie mit NGINX oder NGINX Plus verhindern können, dass sie auf Ihren Servern ausgenutzt wird.

Die Schwachstelle entsteht durch einen Namensraumkonflikt. Eine CGI- oder FastCGI-ähnliche Schnittstelle legt Umgebungsvariablen anhand von HTTP-Anfrageparametern fest. Diese können interne Variablen überschreiben, die zur Konfiguration der Anwendung verwendet werden.

Derzeit betrifft die einzige bekannte Ausnutzung dieser Schwachstelle Webanwendungen, die in CGI- und CGI-ähnlichen Umgebungen ausgeführt werden und bestimmte HTTP-Clientbibliotheken verwenden, um HTTP-Anfragen an andere Dienste zu senden. In diesem Fall können Angreifer interne, von der Anwendung erzeugte Anfragen potenziell an einen Server ihrer Wahl umleiten und so sämtliche in den Anfragen enthaltenen geheimen Daten abfangen, wie nachfolgend dargestellt.

HTTPoxy nutzt eine Überschneidung von Namensräumen, um auf internen Serverdatenverkehr zuzugreifen

Mit NGINX oder NGINX Plus können Sie Versuche erkennen und abwehren, diese Schwachstelle auszunutzen. So lassen sich Angriffe wirksam verhindern, und Sie gewinnen Zeit, um betroffenen Code zu überprüfen und zu aktualisieren.

Wie die HTTPoxy-Sicherheitslücke ausgenutzt wird

Um zu verstehen, wie diese Sicherheitslücke funktioniert – und wie Sie Ihre Website 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 Webanwendungsplattformen verwenden CGI oder CGI-ähnliche Schnittstellen, um Anwendungen mit einem Webserver zu verbinden. Diese Schnittstellen wandeln die Header einer HTTP-Anfrage in Umgebungsvariablen mit dem Präfix HTTP_ um. Eine Anwendung kann dann den Wert von Anfrage-Headern (wie etwa User-Agent) über ihre Umgebung abrufen.

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 Anfrage-Header Foo: bar zur Umgebungsvariablen HTTP_FOO=bar.

Einige Plattformen stellen eine Abstraktionsschicht bereit, die die Umgebungsvariablen verbirgt, wie etwa die globale PHP-Variable „$_SERVER“. Dennoch basieren diese Abstraktionen auf der üblichen Praxis von CGI und FastCGI, Umgebungsvariablen zu setzen.

Beispielsweise kann eine PHP-Anwendung im FastCGI-Modus den User-Agent-Header einer Anfrage wie folgt ermitteln:

// both methods return the same result$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – Einige Anwendungsbibliotheken werden über Umgebungsvariablen konfiguriert

Eine komplexe Webanwendung bindet Funktionen aus externen Bibliotheken ein. Beispielsweise müssen Anwendungen mitunter HTTP-Anfragen an andere Dienste stellen (ähnlich wie bei einer Microservices-Architektur) und verwenden dafür möglicherweise eine der gängigen Drittanbieterbibliotheken. Diese Bibliotheken unterstützen häufig eine Funktion namens „HTTP-Proxy“. Dabei handelt es sich um einen zwischengeschalteten Server, der die HTTP-Anfrage weiterleitet.

Eine einfache Möglichkeit, eine solche Bibliothek zu konfigurieren, besteht darin, die Konfiguration über Umgebungsvariablen festzulegen. Die weitverbreitete Bibliothek PHP Guzzle wird teilweise über eine Umgebungsvariable namens HTTP_PROXY konfiguriert, die auf die Adresse eines Proxyservers gesetzt wird. Wenn HTTP_PROXY auf diese Weise gesetzt ist, leitet die Bibliothek alle von ihr erzeugten HTTP-Anfragen an die Adresse des Proxyservers weiter. Das Go-Paket net/http und das Requests-Modul von Python vertrauen ebenfalls auf die Umgebungsvariable HTTP_PROXY und interpretieren sie auf dieselbe 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 von ihnen als vertrauenswürdig eingestufte Umgebungsvariable HTTP_PROXY überschneidet sich mit dem von CGI- und FastCGI-Schnittstellen verwendeten Namensraum HTTP_ – wie in Punkt 1 erläutert.

Indem Angreifer den Wert der Umgebungsvariable HTTP_PROXY auf eine Adresse ihrer Wahl setzen, können sie von der Anwendung erzeugte interne HTTP-Anfragen umleiten und abfangen. Diese Anfragen können vertrauliche Informationen wie Authentifizierungsschlüssel und private Daten enthalten und Informationen über weitere 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 namens HTTP_PROXY. Beachten Sie, dass nur Anfragen direkt betroffen sind, die den manipulierten Proxy-Header enthalten.

Abwehr des Angriffs mit NGINX und NGINX Plus

Die HTTPoxy-Sicherheitslücke betrifft NGINX nicht direkt, aber NGINX und NGINX Plus können eingesetzt werden, um Angriffe zu verhindern, die diese Sicherheitslücke ausnutzen.

Kommunikation mit einer vorgeschalteten FastCGI-Anwendung

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

fastcgi_param HTTP_PROXY "";

Lastverteilung und Proxying von HTTP-Datenverkehr

Beim Weiterleiten von HTTP-Anfragen an eine Upstream-Anwendung empfiehlt es sich, jeden Proxy-Header auf eine leere Zeichenfolge zu setzen, falls die Upstream-Anwendung auf einer anfälligen Plattform ausgeführt wird:

proxy_set_header Proxy "";

Erkennung von Versuchen, die Schwachstelle auszunutzen

Proxy ist kein standardmäßiger HTTP-Header, daher können alle Anfragen, die diesen Header enthalten, als verdächtig eingestuft werden. Mit NGINX oder NGINX Plus können Sie diese verdächtigen Anfragen in einem separaten Zugriffsprotokoll protokollieren, das hier badactor.log heißt:

# define 'proxylog' format in the http{} context:log_format proxylog '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    '"$http_proxy"';

# log requests with a Proxy header using the 'proxylog' format
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

Hinweis: In dem Konfigurationskontext, in dem Sie diese access_log-Direktive platzieren, überschreibt sie alle Zugriffsprotokollierungen, die auf einer höheren Ebene der NGINX-Konfiguration definiert sind.

Sicherheit gewährleisten

NGINX und NGINX Plus bieten eine effektive Möglichkeit, den HTTPoxy-Angriff zu überwachen und abzuwehren. Schützen Sie Ihre Anwendung mit den oben beschriebenen Methoden, während Sie Ihren Code überprüfen, aktualisieren und testen, um die Schwachstelle zu beseitigen.

Wenn Sie Fragen haben, hinterlassen Sie bitte einen Kommentar zu diesem Beitrag – oder wenden Sie sich als NGINX Plus-Abonnent gerne an unser Supportteam, um Unterstützung zu erhalten.

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett