So schützen Sie Ihren Server vor der HTTPoxy-Sicherheitsanfälligkeit

Was ist HTTPoxy?

Am 18. Juli 2016 wurde eine Sicherheitsanfälligkeit in CGI-Anwendungen, die als HTTPoxy bezeichnet wird, gemeldet. Ein Angreifer kann anfällige Bereitstellungen ausnutzen, indem er mit seiner Anfrage einen HTTP-Header "+ Proxy +" übergibt, der die von der Anwendung verwendete URL bei der Kontaktaufnahme mit den Sicherungsdiensten ändert. Dies kann verwendet werden, um Anmeldeinformationen zu verlieren, Antworten auf die Anwendung zu ändern usw.

Die Sicherheitsanfälligkeit wird durch eine Namenskollision zwischen der Umgebungsvariablen "+ HTTP_PROXY ", die häufig zum Angeben des Speicherorts eines Back-End-Proxy-Dienstes verwendet wird, und dem HTTP-Client-Header " Proxy " verursacht. Die Spezifikation https://tools.ietf.org/html/rfc3875#section-4.1.18[CGI] fordert, dass vom Client bereitgestellte Header mit dem Präfix " HTTP_ " für den Namespace an die Umgebung übergeben werden. Dieses Mangeln stößt auf Konfigurationsvariablen wie " HTTP_PROXY ", die ebenfalls mit " HTTP_ +" beginnen. Wenn eine CGI-Anwendung oder eine Bibliothek diese Variable ohne zusätzliche Verarbeitung verwendet, verwendet sie möglicherweise den vom Client angegebenen Wert, wenn versucht wird, eine Verbindung zum Proxy-Dienst herzustellen.

Da sich diese Sicherheitsanfälligkeit auf eine Vielzahl von CGI-ähnlichen Implementierungen auswirkt, wurden mehrere Kennungen für Sicherheitsanfälligkeiten erstellt: CVE- 2016-5386, CVE-2016-5386, http: //www.cve.mitre. org / cgi-bin / cvename.cgi? name = CVE-2016-5387 [CVE-2016-5387], http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016 -5388 [CVE-2016-5388], CVE-2016-1000109 und http: // www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000110[CVE-2016-1000110] (Zum Zeitpunkt des Schreibens sind diese reserviert, aber nicht ausgefüllt).

Die HTTPoxy-Sicherheitsanfälligkeit ist in einigen Formen seit 2001 bekannt, wurde jedoch bis vor kurzem nicht als weit verbreitetes Problem erkannt. Obwohl sich dies auf viele Bereitstellungen auswirken kann, ist die Schadensbegrenzung recht einfach und unkompliziert.

Anfällige Server und Anwendungen

HTTPoxy ist eine allgemeine Sicherheitsanfälligkeit, die von vielen CGI-Implementierungen gefunden wird. Eine Anwendung oder ein Server kann die CGI-Spezifikation korrekt implementieren und dennoch anfällig sein.

Damit eine Bereitstellung anfällig ist, muss sie:

  • * Verwenden Sie die Umgebungsvariable "+ HTTP_PROXY +", um Proxy-Verbindungen zu konfigurieren. *: Entweder im Anwendungscode selbst oder in Bibliotheken, die verwendet werden. Dies ist eine ziemlich standardmäßige Methode zum Konfigurieren von Proxyservern mithilfe der Umgebung.

  • * Anfragen an Backend-Dienste über HTTP stellen *: Da die Namenskollision spezifisch für das Präfix "+ HTTP_ +" ist, sind nur Anfragen der Anwendung über HTTP betroffen. Anfragen, die HTTPS oder andere Protokolle verwenden, sind nicht anfällig.

  • * Betrieb in einer CGI- oder CGI-ähnlichen Umgebung *: Bereitstellungen, in denen Clientheader in Umgebungsvariablen mit dem Präfix "+ HTTP_ +" übersetzt werden, sind anfällig. Jede kompatible Implementierung von CGI oder verwandten Protokollen wie FastCGI wird dies tun.

Wie Sie sehen, ist eine Kombination aus bereitstellungs- und anwendungsspezifischen Faktoren erforderlich, damit eine Bereitstellung anfällig ist. Um zu testen, ob Ihre Bereitstellung betroffen ist, hat Luke Rehmann eine einfache https://httpoxy.rehmann.co/[site erstellt, um öffentlich zugängliche Sites auf Sicherheitslücken zu prüfen.

Sprachspezifische Informationen

Insbesondere PHP-Anwendungen sollten überprüft werden, da CGI-ähnliche Bereitstellungen im PHP-Ökosystem viel häufiger vorkommen als in anderen Sprachen. Darüber hinaus wird dieses Problem durch die weit verbreitete Verwendung der Methode "+ getenv +" in gängigen Bibliotheken verstärkt, da nicht sofort klar ist, dass dies nicht nur Konfigurationsvariablen, sondern auch nicht bereinigte Benutzereingaben zurückgibt. Bestimmte Bibliotheken, die derzeit betroffen sind, sind Guzzle (Version 4.0.0rc2 und höher), Artax und die StreamContextBuilder-Klasse von Composer.

Andere Sprachen, die bei der Bereitstellung mit CGI als anfällig eingestuft wurden, waren Python und Go. Diese Sprachen werden häufiger mit anderen, nicht anfälligen Methoden bereitgestellt. Wenn jedoch CGI verwendet wird, sind Bibliotheken anfällig, die naiv die Variable "+ HTTP_PROXY +" lesen, ohne ihr Verhalten zu ändern.

So besiegen Sie die Sicherheitsanfälligkeit

Glücklicherweise ist HTTPoxy relativ einfach zu beheben. Die Sicherheitsanfälligkeit kann über die Webserverschicht oder die Anwendung oder Bibliothek behoben werden:

  • Anwendungen oder Bibliotheken können die Variable "+ HTTP_PROXY +" ignorieren, wenn sie sich in einer CGI-Umgebung befinden.

  • Anwendungen oder Bibliotheken können eine andere Umgebungsvariable verwenden, um Proxy-Verbindungen zu konfigurieren

  • Webserver oder Proxys können den in Clientanforderungen empfangenen "+ Proxy +" - Header aufheben

Wenn Sie eine anfällige Bibliothek verwenden, sollten Sie die Bedrohung auf dem Server so lange verringern, bis Patches zur Verfügung stehen, um das Problem zu beheben. Wenn Sie als Bibliotheks- oder Anwendungsautor für Ihr Projekt die Variable "+ HTTP_PROXY " verwenden, um ein Proxy-Backend zu konfigurieren, sollten Sie eine alternative Variable verwenden, die in einer CGI-ähnlichen Umgebung nicht kollidiert. Ruby und einige andere Projekte verwenden zu diesem Zweck ` CGI_HTTP_PROXY +`.

Da der "+ Proxy " - Header kein Standard-HTTP-Header ist, kann er in fast allen Fällen ignoriert werden. Dies kann auf dem Webserver oder im Lastenausgleich erfolgen, mit dem Anforderungen an die Anwendung selbst gerichtet werden. Da der HTTP-Header " Proxy +" keinen legitimen Standardzweck hat, kann er fast immer gelöscht werden.

Jeder gängige Webserver, Load Balancer oder Proxy kann die entsprechenden Header entfernen.

HTTP-Proxy-Header mit Apache entfernen

Wenn Sie den Apache HTTP-Webserver ausführen, kann das Modul + mod_headers + verwendet werden, um den Header für alle Anforderungen zu deaktivieren.

Ubuntu- und Debian-Server

Um + mod_headers + auf Ubuntu- oder Debian-Servern zu aktivieren, geben Sie Folgendes ein:

sudo a2enmod headers

Öffnen Sie anschließend die globale Konfigurationsdatei:

sudo nano /etc/apache2/apache2.conf

Fügen Sie nach unten hinzu:

/etc/apache2/apache2.conf

. . .
RequestHeader unset Proxy early

Speichern und schließen Sie die Datei.

Überprüfen Sie die Konfiguration auf Syntaxfehler:

sudo apache2ctl configtest

Starten Sie den Dienst neu, wenn keine Syntaxfehler gemeldet werden:

sudo service apache2 restart

CentOS- und Fedora-Server

Das + mod_headers + Modul sollte für konventionelle Installationen standardmäßig aktiviert sein. Um den Header "+ Proxy +" zu deaktivieren, öffnen Sie die globale Konfigurationsdatei:

sudo nano /etc/httpd/conf/httpd.conf

Fügen Sie nach unten hinzu:

/etc/httpd/conf/httpd.conf

. . .
RequestHeader unset Proxy early

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Suchen Sie nach Syntaxfehlern, indem Sie Folgendes eingeben:

sudo apachectl configtest

Wenn keine Syntaxfehler gemeldet werden, starten Sie den Dienst neu, indem Sie Folgendes eingeben:

sudo service httpd restart

HTTP-Proxy-Header mit Nginx entfernen

Bei Nginx ist die Abschwächung ähnlich trivial. Sie können die Umgebung problemlos für jede CGI-ähnliche Umgebung bereinigen, die auf dem Server oder im Upstream ausgeführt wird.

Ubuntu- und Debian-Server

Auf Ubuntu- und Debian-Servern werden FastCGI-Parameter normalerweise entweder aus den Dateien "+ fastcgi_params " oder " fastcgi.conf " übernommen, wenn ein FastCGI-Proxy eingerichtet wird. Sie können den Header " HTTP_PROXY +" in beiden folgenden Dateien deaktivieren:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

Wenn Sie beim Konfigurieren Ihrer FastCGI-Proxys keine der Dateien auswählen, müssen Sie dieselbe Zeile im Proxy-Verzeichnis selbst einfügen:

/etc/nginx/sites-enabled/some_site.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

Wenn Sie Nginx für herkömmliches HTTP-Proxy verwenden, sollten Sie auch den HTTP-Header + Proxy + löschen. HTTP-Proxy-Header werden in der Datei + / etc / nginx / proxy_params + gesetzt. Sie können die Regel hinzufügen, um den "+ Proxy +" - Header zu dieser Datei zu entfernen, indem Sie Folgendes eingeben:

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params

Wenn Sie diese Datei nicht über Ihre Serverblockkonfiguration beziehen, müssen Sie sie am Proxy-Speicherort selbst hinzufügen:

/etc/nginx/sites-enabled/some_site.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

Suchen Sie nach Syntaxfehlern, indem Sie Folgendes eingeben:

sudo nginx -t

Wenn keine Fehler gemeldet werden, starten Sie den Dienst neu:

sudo service nginx restart

CentOS- und Fedora-Server

Nginx unter CentOS und Fedora verwendet ebenfalls die gleichen Dateien "+ fastcgi_params " und " fastcgi.conf ", um das FastCGI-Proxying zu konfigurieren. Deaktivieren Sie den Header " HTTP_PROXY +" in diesen beiden Dateien, indem Sie Folgendes eingeben:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

Wenn Sie beim Konfigurieren Ihrer FastCGI-Proxys keine dieser Dateien verwenden, müssen Sie dieselbe Zeile im Proxy-Speicherort selbst einfügen:

/etc/nginx/nginx.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

Wenn Sie Nginx für herkömmliches HTTP-Proxy verwenden, sollten Sie auch den HTTP-Header + Proxy + löschen. Sie müssen lediglich eine Regel hinzufügen, um den "+ Proxy" -Header an einer beliebigen Stelle zu deaktivieren, an der Sie einen "+ proxy_pass" ausführen. Wenn Sie sich nicht sicher sind, wo "+ proxy_pass +" verwendet wird, können Sie ganz einfach in Ihrem Konfigurationsverzeichnis suchen:

grep -r "proxy_pass" /etc/nginx
Output/etc/nginx/nginx.conf.default:        #    proxy_pass   http://127.0.0.1;

Alle Ergebnisse, die nicht auskommentiert sind (wie im obigen Beispiel), sollten so bearbeitet werden, dass sie "+ proxy_set_header Proxy" "; +" enthalten:

/etc/nginx/nginx.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

Suchen Sie nach Syntaxfehlern, indem Sie Folgendes eingeben:

sudo nginx -t

Wenn keine Fehler gemeldet werden, starten Sie den Dienst neu:

sudo service nginx restart

HTTP-Proxy-Header mit HAProxy entfernen

Wenn Sie HAProxy verwenden, um Datenverkehr zu Ihren Anwendungsservern zu leiten, können Sie den Header "+ Proxy +" löschen, bevor Sie den Datenverkehr weiterleiten.

Öffnen Sie die Datei + / etc / haproxy / haproxy.cfg + zum Bearbeiten:

sudo nano /etc/haproxy/haproxy.cfg

Sie können die Direktive "+ http-request " in den Abschnitten " frontend ", " backend " oder " listen +" Ihrer Konfiguration festlegen.

/etc/haproxy/haproxy.cfg

frontend www

   . . .

backend web-backend

   . . .

listen appname 0.0.0.0:80

   . . .

Diese müssen nicht in jedem Abschnitt festgelegt werden, aber es tut nicht weh, sie einzuschließen. Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Überprüfen Sie die Syntax, indem Sie Folgendes eingeben:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Wenn keine Probleme gefunden werden, starten Sie den Dienst neu, indem Sie Folgendes eingeben:

sudo service haproxy restart

Fazit

Die HTTPoxy-Sicherheitsanfälligkeit ist bereits seit längerer Zeit offen und kann eine große Anzahl von Anwendungen betreffen, die im Web bereitgestellt werden. Glücklicherweise ist es einfach zu beheben, wenn die Funktionen zur Änderung des Headers für jeden Webserver verwendet werden.