HTTPoxy : CGI vul­ne­ra­bi­lity

Pour des raisons de per­for­mance et de sécurité, de nombreux projets Web s’appuient sur des serveurs proxy. Ces pro­grammes pratiques servent en effet d’interface de com­mu­ni­ca­tion entre le client et le site Web et soulagent donc le serveur Web puisqu’ils reçoivent, éditent, traitent et répondent aux requêtes HTTP. Cependant, en raison d’une faille de sécurité connue sous le nom de HTTPoxy, cette tech­no­lo­gie peut être utilisée par les hackers afin de pirater et de voler des données. Les ap­pli­ca­tions qui sont basées sur le standard CGI (Common Gateway Interface) et con­fi­gu­rées sur les variables d’en­vi­ron­ne­ment sont notamment affectées. Certains pro­grammes peuvent lire par exemple les con­fi­gu­ra­tions de votre proxy à partir des variables, ce qui devient ra­pi­de­ment un problème lorsque les pirates ma­ni­pu­lent ces pa­ra­mètres.

Quand un serveur Web veut com­mu­ni­quer avec le client via une Common Gateway Interface (CGI), la norme RFC 3875 prévoit que les en-têtes de toutes requêtes HTTP envoyées soient stockées comme variables d’en­vi­ron­ne­ment. Le nom de cette variable est composé du préfixe « HTTP_ » et du nom de l’en-tête en ma­jus­cules. Le cas décrit ici est l’en-tête « Proxy », qui génère au­to­ma­ti­que­ment la variable HTTP_PROXY. C’est prévu par défaut comme con­fi­gu­ra­tion des pa­ra­mètres du proxy. En d’autres termes, si l’ap­pli­ca­tion CGI atteint ou exécute une requête qui comporte HTTP_PROXY, elle est redirigée via le serveur proxy approprié.

Les cir­cons­tances décrites per­met­tent à un hacker de mettre son propre serveur proxy en jeu, de l’utiliser et d’obtenir ainsi des in­for­ma­tions sensibles. Pour cela, il envoie une requête HTTP avec l’en-tête Proxy et une valeur cor­res­pon­dante (par exemple l’adresse IP du proxy), après quoi les requêtes uti­li­sa­teurs futures, entrantes ou sortantes, seront re­di­ri­gées vers lui. Selon le scénario choisi, l’attaquant peut alors renvoyer librement ses propres données ou lire di­rec­te­ment les données d’entrée de l’uti­li­sa­teur.

Cette vul­né­ra­bi­lité, dont le nom n’a pas de sig­ni­fi­ca­tion par­ti­cu­lière, est remarquée pour la première fois en mars 2001. Le pro­gram­meur Randal L. Schwartz avait découvert HTTPoxy dans la bi­blio­thèque de Perl libwww-perl et l’a transmis à Gisle Aas qui est le dé­ve­lop­peur de celle-ci. Le com­ble­ment de cette faille est intervenu avec la mise à jour 5.51 en modifiant le nom de la variable par laquelle la con­fi­gu­ra­tion du proxy peut être contrôlée dans CGI_HTTP_PROXY. La même année la vul­né­ra­bi­lité a également été détectée dans le programme de transfert de données curl. C’est pourquoi le dé­ve­lop­peur Daniel Stenberg a adapté en con­sé­quence le logiciel, de sorte que désormais seule la variante minuscule http-proxy puisse dé­ter­mi­ner le serveur proxy, tout en aver­tis­sant que cela était fon­da­men­ta­le­ment in­suf­fi­sant pour les systèmes Microsoft. Mais dans les versions actuelles de Windows, le problème n’existe plus désormais.

Environ une décennie plus tard : en juillet 2012, l’équipe Ruby a buté sur le problème HTTPoxy qui était alors depuis longtemps oublié, en im­plé­men­tant la classe NET::HTTP, un client HTTP API pour les ap­pli­ca­tions Ruby. Pour con­tour­ner le problème, HTTT_PROXY et d’autres ont été con­fi­gu­rés sous le statut d’une norme variable. Dans les années suivantes, les ap­pli­ca­tions de serveur Web NGINX (2013) et Apache (2015) sont les cas les plus im­por­tants dans lesquels des uti­li­sa­teurs attentifs ont alors informés les dé­ve­lop­peurs d’un danger potentiel.

En 2016, l’équipe de sécurité de la société de dé­ve­lop­pe­ment Vend a fi­na­le­ment constaté que la vul­né­ra­bi­lité HTTPoxy était, 15 ans après sa première dé­cou­verte, toujours une faille. PHP et d’autres langages de pro­gram­ma­tion et les bi­blio­thèques, peuvent être exploités à condition d’être combinés avec CGI ou un en­vi­ron­ne­ment d’exécution com­pa­rable à des variables. De nom­breuses ap­pli­ca­tions affectées qui per­met­tent l’uti­li­sa­tion de HTTPoxy ont été ré­per­to­riées dans le dic­tion­naire des in­for­ma­tions publiques relatives aux vul­né­ra­bi­li­tés de sécurité, les CVE (Common Vul­ne­ra­bi­lites and Exposures) :

• 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

Peu importe si vous exécutez votre propre serveur Web ou non. HTTPoxy re­pré­sente un risque lorsque vous êtes sur le World Wide Web. Si le service Web appelé peut être détourné de manière in­dé­si­rable par des requêtes HTTP externes, vos données ne sont donc pas protégées. Pour minimiser le risque de dé­tour­ne­ment de données, vous devez donc préférer les sites qui sont protégés par un cer­ti­fi­cat TLS/SSL et trans­fé­rer toutes les in­for­ma­tions de manière cryptée. De cette façon, il est encore possible de détourner les données en utilisant un proxy incorrect, mais les hackers peuvent bien moins utiliser ces dernières, voire même ne rien en tirer. En tant qu’opérateur de site Web, la con­ver­sion en HTTP est de toute façon obli­ga­toire aujourd’hui. Cependant, vous avez toujours la pos­si­bi­lité d’éviter HTTPoxy en sup­pri­mant en général sim­ple­ment la faille de sécurité. Comme l’en-tête proxy n’est pas tenu à une norme IETF (Internet En­gi­nee­ring Task Force) ou en­re­gis­tré via l’IANA (Internet Assigned Numbers Authority) comme en-tête officiel, vous pouvez l’in­ter­cep­ter sans hésiter avant qu’il n’atteigne votre ap­pli­ca­tion Web. Les serveurs et clients HTTP standards n’émettent de toute façon pas de paquets de données avec cet en-tête. Fon­da­men­ta­le­ment, vous avez deux options en plus du cryptage de l’échange de données HTTP pour empêcher les requêtes dan­ge­reuses d’atteindre votre projet Web :

1. Filtrer l’en-tête proxy sur tous les paquets entrants.
2. Bloquer au­to­ma­ti­que­ment tous les paquets entrants qui con­tien­nent un en-tête proxy

La première option est beaucoup plus fréquente et peut se faire à l’aide de n’importe quel serveur Web ordinaire, proxy ou logiciel de ré­par­ti­tion de charges (Load Balancing). Les sections suivantes four­nis­sent des in­for­ma­tions sur la façon de supprimer l’en-tête po­ten­tiel­le­ment dangereux du trafic de données sur diverses dis­tri­bu­tions Linux à l’aide des ap­pli­ca­tions serveur Web Apache Nging et du logiciel serveur proxy HAProxy.

Con­tour­ner HTTPoxy avec Apache

Le logiciel libre Apache est depuis longtemps installé par défaut sur toutes les dis­tri­bu­tions majeures de Linux et reste encore aujourd’hui le premier choix quand il s’agit d’exécuter son propre serveur Web. Un composant du programme est le module mod_headers, qui vous permet de filtrer l’en-tête proxy de toutes les requêtes HTTP entrantes. La procédure diffère lé­gè­re­ment de chaque dis­tri­bu­tion.

Ubuntu et Debian :

La première étape consiste à activer le module, ce que vous pouvez faire via la commande suivante :

Ouvrez ensuite le fichier de con­fi­gu­ra­tion principal d’Apache avec un éditeur. L’outil en ligne de commande nano qui est utilisé dans l’exemple est re­com­mandé :

Dé­ve­lop­pez main­te­nant le fichier avec l’entrée suivante :

Après avoir en­re­gis­tré le fichier, vous pouvez activer la pro­tec­tion HTTPoxy en chargeant le fichier de con­fi­gu­ra­tion spé­ci­fique avec le scripte a2enconf, puis re­dé­mar­rer le serveur :

CentOS et Fedora :

Si vous utilisez une version de la dis­tri­bu­tion Linux CentOS ou Fedora, le module mod_headers est déjà activé par défaut, vous pouvez donc sauter cette étape et il suffit d’ouvrir le fichier de con­fi­gu­ra­tion :

Insérez à la fin la nouvelle entrée :

Sau­ve­gar­dez ensuite les chan­ge­ments et re­dé­mar­rez le serveur Apache :

Modifier l’en-tête HTTP Proxy avec NGINX

NGINX est une ap­pli­ca­tion de serveur Web qui jouit d’une po­pu­la­rité gran­dis­sante. Le logiciel open-source ne nécessite que quelques étapes pour protéger les ap­pli­ca­tions CGI qui s’exécutent sur le serveur ou bien entre le client et le serveur à partir de la faille de sécurité HTTPoxy.

Ubuntu et Debian :

En règle générale, les pa­ra­mètres FastCGI (FastCGi est une op­ti­mi­sa­tion de la norme CGI) sont inclus dans Ubuntu et Debian dans les fichiers fastcgi_params ou fastcgi.conf, lorsque vous con­fi­gu­rez un Proxy NGINX FastCGI. Dans les deux fichiers, vous pouvez couper l’en-tête proxy dans les requêtes HTTP. Pour cela il suffit d’utiliser les lignes de commande suivantes :

Si vous utilisez NGINX comme un proxy HTTP con­ven­tion­nel, vous pouvez également filtrer l’en-tête. Pour ce faire, insérez la règle cor­res­pon­dante dans le fichier proxy_params qui ré­per­to­rie les pa­ra­mètres du serveur proxy :

Dans la dernière étape, re­dé­mar­rer NGINC avec cette commande :

CentOS et Fedora:

La procédure pour éviter les dangers de HTTPoxy pour les proxys FastCGI sur CentOS ou Fedorane ne diffère pas beaucoup des pro­cé­dures pour les systèmes Ubutun et Debian. Puisque les con­fi­gu­ra­tions NGINX sur ces dis­tri­bu­tions sont définies dans les fichiers fastcgi_params ou dans le fichier fastcgi.conf. Vous pouvez aussi dé­sac­ti­ver l’en-tête du proxy ici avec les commandes déjà ré­per­to­riées :

Pour protéger les proxys con­ven­tion­nels sous Fedora et CentOS, assurez-vous que l’en-tête est bloqué de partout où NGINX exécute la directive proxy_pass. Pour savoir où elles sont utilisées, vous pouvez compter sur les services de la commande de recherche grep :

Cela contient une liste des fichiers texte dans laquelle la directive est ré­per­to­riée, ou les sorties res­semblent à l’exemple suivant :

Dans ce cas, proxy_pass pourrait être ainsi dans le fichier de con­fi­gu­ra­tion NGINX. L’entrée cor­res­pon­dante dans nginx.conf doit être ajoutée comme ci-dessous :

Dans les deux cas, pour terminer le processus, vous devez re­dé­mar­rer le serveur :

Protéger votre serveur HAProxy contre HTTPoxy

Lorsque vous redirigez les requêtes HTTP à votre projet Web via un serveur HAProxy, vous pouvez supprimer l’en-tête proxy, avant même que le proxy n’envoie les demandes. Pour les dif­fé­rentes dis­tri­bu­tions Linux men­tion­nées, la procédure ne diffère pas. Tout d’abord, il est né­ces­saire d’ouvrir le fichier de con­fi­gu­ra­tion principal de l’ap­pli­ca­tion proxy, ce que vous pouvez réaliser avec la commande suivante :

De cette façon, vous ouvrez le fichier haproxy.cfg avec l’éditeur de ligne de commande nano, utilisé pré­cé­dem­ment. Si vous avez spécifié un autre ré­per­toire pour HAProxy pendant l’ins­tal­la­tion, vous devrez ajuster la commande en con­sé­quence.

Dans le fichier ouvert, vous pouvez main­te­nant insérer une directive requête HTTP pour enlever les en-têtes non désirés dans les trois sections « frontend », « backend », et « listen ». Le résultat ressemble à ceci :

En­re­gis­trez les mo­di­fi­ca­tions et re­dé­mar­rez le service HAProxy :

Pour utiliser le service, il suffit d’insérer l’URL de l’ap­pli­ca­tion Web à tester dans le champ de saisie, et de cliquer sur « Test ».