HTTPoxy

Zahl­rei­che Web­pro­jek­te greifen aus Gründen der Per­for­mance und Si­cher­heit auf Proxy-Server zurück. Diese prak­ti­schen Programme fungieren als Kom­mu­ni­ka­ti­ons­schnitt­stel­le zwischen Client und Website und entlasten den Webserver, indem sie HTTP-Anfragen ent­ge­gen­neh­men, be­ar­bei­ten, wei­ter­lei­ten und be­ant­wor­ten. Aufgrund einer als HTTPoxy bekannten Si­cher­heits­lü­cke kann diese Technik von An­grei­fern jedoch zum Da­ten­dieb­stahl miss­braucht werden. Betroffen sind An­wen­dun­gen, die sich auf den CGI-Standard (Common Gateway Interface) stützen und dadurch kon­fi­gu­rier­ba­re Variablen – so­ge­nann­te Um­ge­bungs­va­ria­blen – mit sich bringen. Einige Programme können aus be­tref­fen­den Variablen zum Beispiel auch Ihre Proxy-Kon­fi­gu­ra­tio­nen lesen, was schnell zum Problem wird, wenn Kri­mi­nel­le diese Ein­stel­lun­gen ma­ni­pu­lie­ren.

Wenn ein Webserver via Common Gateway Interface mit dem Client eines Nutzers kom­mu­ni­ziert, sieht der RFC-Standard 3875 vor, dass die Header aller ver­schick­ten HTTP-Anfragen als Um­ge­bungs­va­ria­blen ge­spei­chert werden. Die Be­zeich­nung dieser Variablen setzt sich aus dem Präfix „HTTP_“ und dem Namen des Headers in Groß­buch­sta­ben zusammen. Im hier ge­schil­der­ten Fall geht es um den Header „Proxy“, der au­to­ma­tisch die Variable HTTP_PROXY erzeugt. Diese ist stan­dard­mä­ßig für die Kon­fi­gu­ra­ti­on der Proxy-Ein­stel­lun­gen vor­ge­se­hen. Erreicht die CGI-Anwendung also eine Anfrage, die HTTP_PROXY umfasst, oder führt sie eine solche aus, wird diese über den ent­spre­chen­den Proxy-Server um­ge­lei­tet.

Die ge­schil­der­ten Umstände erlauben es einem Angreifer nun, seinen eigenen Proxy-Server ins Spiel zu bringen und auf diese Weise an ver­trau­li­che In­for­ma­tio­nen zu gelangen. Zu diesem Zweck sendet er einen HTTP-Request mit dem Header Proxy und einem ent­spre­chen­den Wert (zum Beispiel der IP-Adresse des Proxys), woraufhin künftige Nut­zer­an­fra­gen – eingehend oder ausgehend – auf diesen um­ge­lei­tet werden. Je nach gewähltem Szenario kann der Angreifer dann nach Belieben eigene Daten zu­rück­sen­den oder auf direktem Wege Ein­ga­be­da­ten der User mitlesen.

Erstmalig fiel die Schwach­stel­le, deren Name keine spezielle Bedeutung hat, im März 2001 auf. Der Pro­gram­mie­rer Randal L. Schwartz hatte HTTPoxy in der Perl-Bi­blio­thek libwww-perl entdeckt und dies Gisle Aas mit­ge­teilt, dem Ent­wick­ler der Bi­blio­thek. Dieser schloss die Si­cher­heits­lü­cke umgehend im Update 5.51, indem er den Va­ria­blen­na­men, über den die Proxy-Kon­fi­gu­ra­ti­on gesteuert werden kann, in CGI_HTTP_PROXY abänderte. Im gleichen Jahr machte man die Schwach­stel­le auch im Da­ten­trans­fer­pro­gramm cURL aus, woraufhin der Ent­wick­ler Daniel Stenberg die Software da­hin­ge­hend anpasste, dass diese fortan nur noch die klein­ge­schrie­be­ne Variante http_proxy zur Be­stim­mung des Proxy-Servers hinzuzog – unter dem gleich­zei­ti­gen Hinweis, dass dies für Microsoft-Systeme im Grunde genommen nicht aus­rei­chend ist. In aktuellen Windows-Versionen soll das Problem jedoch nicht mehr bestehen.

Rund ein Jahrzehnt später stieß das Ruby-Team im Juli 2012 bei der Im­ple­men­tie­rung der Klasse NET::HTTP, einer HTTP-Client-API für Ruby-An­wen­dun­gen, auf die längst ver­ges­se­ne HTTPoxy-Pro­ble­ma­tik. Um das Problem zu umgehen, nahm man HTTP_PROXY unter anderem den Status als Stan­dard­va­ria­ble. In den folgenden Jahren gesellten sich unter anderem auch die Webserver-An­wen­dun­gen NGINX (2013) und Apache (2015) zu den pro­mi­nen­ten Fällen, bei denen auf­merk­sa­me User die Ent­wick­ler über eine po­ten­zi­el­le Ge­fah­ren­la­ge in Kenntnis setzten.

2016 stellte das Si­cher­heits­team der Ent­wick­ler­fir­ma Vend schließ­lich fest, dass die HTTPoxy-Si­cher­heits­lü­cke auch 15 Jahre nach der ersten Ent­de­ckung noch in PHP und diversen anderen Pro­gram­mier­spra­chen sowie Bi­blio­the­ken aus­nutz­bar ist – sofern diese in Kom­bi­na­ti­on mit CGI bzw. einer ver­gleich­ba­ren Lauf­zeit­um­ge­bung mit kon­fi­gu­rier­ba­ren Variablen zum Einsatz kommt. Viele be­trof­fe­ne An­wen­dun­gen, die die Aus­nut­zung von HTTPoxy er­mög­li­chen, wurde in den of­fi­zi­el­len Spe­zi­fi­ka­tio­nen für Si­cher­heits­lü­cken, den so­ge­nann­ten CVEs (Common Vul­nerabi­li­ties and Exposures), auf­ge­lis­tet:

• CVE-2016-5385: PHP
• CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
• CVE-2016-5388: Apache Tomcat
• CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
• CVE-2016-6287: CHICKEN’s http-client
• CVE-2016-1000104: mod_fcgi
• CVE-2016-1000105: Nginx cgi script
• CVE-2016-1000107: Erlang inets
• CVE-2016-1000108: YAWS
• CVE-2016-1000109: HHVM FastCGI
• CVE-2016-1000110: Python CGI­Hand­ler
• CVE-2016-1000111: Python Twisted
• CVE-2016-1000212: lighttpd

Un­ab­hän­gig davon, ob Sie einen eigenen Webserver betreiben oder nicht, stellt HTTPoxy für Sie ein Risiko dar, wenn Sie im World Wide Web unterwegs sind. Kann der auf­ge­ru­fe­ne Web­ser­vice durch externe HTTP-Requests un­er­wünscht um­ge­lei­tet werden, sind in­fol­ge­des­sen auch Ihre Daten nicht in sicheren Händen. Um das Risiko des Da­ten­ver­lus­tes zu mi­ni­mie­ren, sollten Sie daher Seiten be­vor­zu­gen, die durch ein TLS-/SSL-Zer­ti­fi­kat geschützt sind und alle In­for­ma­tio­nen in ver­schlüs­sel­ter Form über­tra­gen. Auf diese Weise ist zwar weiterhin die Umleitung der Daten über einen falschen Proxy möglich, Kri­mi­nel­le schlagen aus diesen ge­si­cher­ten In­for­ma­tio­nen aber deutlich weniger bzw. im Op­ti­mal­fall gar keinen Profit. Als Betreiber einer eigenen Seite gehört die Um­stel­lung auf HTTPS heute ohnehin zum Pflicht­pro­gramm. Sie haben aber immer auch die Option, HTTPoxy generell zu vermeiden, indem Sie die Schwach­stel­le ganz einfach be­sei­ti­gen. Da der Proxy-Header weder in einem IETF-Standard fest­ge­hal­ten noch bei der IANA als of­fi­zi­el­le Kopfzeile re­gis­triert ist, können Sie ihn ohne Bedenken abfangen, bevor er Ihre Web­an­wen­dung erreicht. Stan­dard­kon­for­me HTTP-Clients und Server senden von sich aus ohnehin keine Da­ten­pa­ke­te mit diesem Header. Grund­sätz­lich haben Sie neben der Ver­schlüs­se­lung des HTTP-Da­ten­aus­tauschs zwei Mög­lich­kei­ten, um die ge­fähr­den­den Requests von Ihrem Web­pro­jekt fern­zu­hal­ten:

1. Sie filtern den Proxy-Header aus allen ein­ge­hen­den Pakten heraus.
2. Sie blo­ckie­ren au­to­ma­tisch alle ein­ge­hen­den Pakete, die einen Proxy-Header enthalten.

Erstere Variante ist we­sent­lich ver­brei­te­ter und lässt sich mithilfe jeglicher ge­wöhn­li­cher Webserver-, Proxy- oder Load-Balancing-Software be­werk­stel­li­gen. In den folgenden Ab­schnit­ten finden Sie In­for­ma­tio­nen darüber, wie Sie den po­ten­zi­ell ge­fähr­li­chen Header mithilfe der Webserver-An­wen­dun­gen Apache und NGINX sowie der Proxy-Server-Software HAProxy auf ver­schie­de­nen Linux-Dis­tri­bu­tio­nen aus dem Verkehr ziehen.

HTTPoxy mit Apache umgehen

Die freie Software Apache ist auf allen gängigen Linux-Dis­tri­bu­tio­nen stan­dard­mä­ßig in­stal­liert und für viele bis heute die erste Wahl, wenn es darum geht, einen eigenen Webserver zu betreiben. Be­stand­teil des Programms ist unter anderem das Modul mod_headers, das es Ihnen er­mög­licht, den Proxy-Header aller ein­ge­hen­den HTTP-Requests aus­zu­fil­tern. Die Vor­ge­hens­wei­se un­ter­schei­det sich leicht von Dis­tri­bu­ti­on zu Dis­tri­bu­ti­on.

Ubuntu und Debian:

Im ersten Schritt gilt es, das Modul zu ak­ti­vie­ren, was Sie mit dem folgenden Befehl erledigen:

Öffnen Sie an­schlie­ßend die zentrale Kon­fi­gu­ra­ti­ons­da­tei von Apache mit einem Editor, wobei das im Beispiel genutzte Kom­man­do­zei­len-Tool nano sehr zu empfehlen ist:

Erweitern Sie diese Datei nun am Ende um den folgenden Eintrag:

Nachdem Sie die Datei ge­spei­chert haben, ak­ti­vie­ren Sie den HTTPoxy-Schutz, indem Sie die spe­zi­fi­zier­te Kon­fi­gu­ra­ti­ons­da­tei per a2enconf-Skript laden und den Server im Anschluss neu­star­ten:

CentOS und Fedora:

Nutzen Sie eine Version der Linux-Dis­tri­bu­tio­nen CentOS oder Fedora, ist das mod_headers-Modul stan­dard­mä­ßig bereits aktiviert, weshalb Sie diesen Schritt über­sprin­gen und gleich die Kon­fi­gu­ra­ti­ons­da­tei öffnen können:

In diese fügen Sie am Ende den neuen Eintrag

ein. Ab­schlie­ßend speichern Sie die Än­de­run­gen und führen einen Neustart des Apache-Servers durch:

HTTP-Proxy-Header mit NGINX entfernen

NGINX ist als Webserver-Anwendung mitt­ler­wei­le eine eta­blier­te Größe, die sich zu­neh­men­der Be­liebt­heit erfreut. Mithilfe der Open-Source-Software sind ebenfalls nur wenige Schritte notwendig, um CGI-An­wen­dun­gen, die auf dem Server laufen bzw. zwischen Client und Server aus­ge­führt werden, aus­rei­chend vor der HTTPoxy-Si­cher­heits­lü­cke zu schützen.

Ubuntu und Debian:

Für ge­wöhn­lich sind FastCGI-Parameter (bei FastCGI handelt es sich um eine Op­ti­mie­rung des CGI-Standards) unter Ubuntu und Debian in den Dateien fastcgi_params oder fastcgi.conf enthalten, wenn Sie einen NGINX-FastCGI-Proxy ein­rich­ten. In beiden Dateien können Sie den Proxy-Header in HTTP-Requests abstellen. Nutzen Sie dafür einfach folgende Be­fehls­zei­len:

Sofern Sie NGINX als kon­ven­tio­nel­len HTTP-Proxy nutzen, können Sie den Header ebenfalls her­aus­fil­tern. Zu diesem Zweck fügen Sie die ent­spre­chen­de Regel in die Datei proxy_params ein, in der die Parameter für den Proxy-Server auf­ge­führt sind:

Im letzten Schritt starten Sie NGINX mit diesem Befehl neu:

CentOS und Fedora:

Die Vor­ge­hens­wei­se bei der Bannung der HTTPoxy-Gefahr für FastCGI-Proxys, die Sie mit CentOS oder Fedora betreiben, un­ter­schei­det sich nicht von der Prozedur, die für Ubuntu- und Debian-Systeme von Nöten ist. Da die NGINX-Kon­fi­gu­ra­tio­nen auch auf diesen Dis­tri­bu­tio­nen entweder in der Datei fastcgi_params oder in der Datei fastcgi.conf fest­ge­legt sind, schalten Sie den Proxy-Header hier ebenfalls mit den bereits auf­ge­führ­ten Befehlen aus:

Um kon­ven­tio­nel­le Proxys unter Fedora und CentOS zu schützen, müssen Sie si­cher­stel­len, dass der Header überall dort blockiert wird, wo NGINX die Direktive proxy_pass ausführt. Um her­aus­zu­fin­den, wo diese zum Einsatz kommt, können Sie auf die Dienste des Such­be­fehls grep zu­rück­grei­fen:

Sie erhalten eine Auf­lis­tung der Text­da­tei­en, in denen die Direktive auf­ge­führt wird, wobei die Ausgabe in etwa wie in dem folgenden Beispiel aussieht:

In diesem Fall wäre proxy_pass also in der NGINX-Kon­fi­gu­ra­ti­ons­da­tei gesetzt. Den ent­spre­chen­den Eintrag in der nginx.conf sollten Sie daher fol­gen­der­ma­ßen ergänzen:

Zum Abschluss steht in beiden Fällen der Neustart des Servers an:

So sichern Sie HAProxy-Server gegen HTTPoxy ab

Wenn Sie HTTP-Anfragen über einen HAProxy-Server auf Ihr Web­pro­jekt wei­ter­lei­ten, können Sie den Proxy-Header entfernen, noch bevor der Proxy die Requests ver­schickt. Für die ver­schie­de­nen genannten Linux-Dis­tri­bu­tio­nen un­ter­schei­det sich die Vor­ge­hens­wei­se dabei nicht. Zunächst gilt es, die zentrale Kon­fi­gu­ra­ti­ons­da­tei der Proxy-Anwendung zu öffnen, was Sie mit dem folgenden Kommando tun:

Auf diese Weise öffnen Sie die Datei haproxy.cfg mit dem bereits oben genutzten Kom­man­do­zei­len-Editor nano. Haben Sie bei der In­stal­la­ti­on ein al­ter­na­ti­ves Ver­zeich­nis für HAProxy angegeben, müssen Sie den Befehl natürlich ent­spre­chend anpassen.

In der ge­öff­ne­ten Datei können Sie nun für die drei Sektionen „frontend“, „backend“ und „listen“ eine HTTP-Request-Direktive einfügen, die die un­er­wünsch­te Kopfzeile entfernt. Das Ergebnis sieht fol­gen­der­ma­ßen aus:

Speichern Sie die Än­de­run­gen ab und starten den HAProxy-Dienst neu:

Um den Service in Anspruch zu nehmen, müssen Sie einfach nur die URL der zu über­prü­fen­den Web­an­wen­dung in das Ein­ga­be­feld einfügen und auf „Test“ klicken.