HTTPoxy : CGI vulnerability

Pour des raisons de performance et de sécurité, de nombreux projets Web s’appuient sur des serveurs proxy. Ces programmes pratiques servent en effet d’interface de communication 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 technologie peut être utilisée par les hackers afin de pirater et de voler des données. Les applications qui sont basées sur le standard CGI (Common Gateway Interface) et configurées sur les variables d’environnement sont notamment affectées. Certains programmes peuvent lire par exemple les configurations de votre proxy à partir des variables, ce qui devient rapidement un problème lorsque les pirates manipulent ces paramètres.

Qu’est-ce que HTTPoxy ?

Quand un serveur Web veut communiquer 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’environnement. Le nom de cette variable est composé du préfixe « HTTP_ » et du nom de l’en-tête en majuscules. Le cas décrit ici est l’en-tête « Proxy », qui génère automatiquement la variable HTTP_PROXY. C’est prévu par défaut comme configuration des paramètres du proxy. En d’autres termes, si l’application CGI atteint ou exécute une requête qui comporte HTTP_PROXY, elle est redirigée via le serveur proxy approprié.

Les circonstances décrites permettent à un hacker de mettre son propre serveur proxy en jeu, de l’utiliser et d’obtenir ainsi des informations sensibles. Pour cela, il envoie une requête HTTP avec l’en-tête Proxy et une valeur correspondante (par exemple l’adresse IP du proxy), après quoi les requêtes utilisateurs futures, entrantes ou sortantes, seront redirigées vers lui. Selon le scénario choisi, l’attaquant peut alors renvoyer librement ses propres données ou lire directement les données d’entrée de l’utilisateur.

Une faille de sécurité inévitable ?

Cette vulnérabilité, dont le nom n’a pas de signification particulière, est remarquée pour la première fois en mars 2001. Le programmeur Randal L. Schwartz avait découvert HTTPoxy dans la bibliothèque de Perl libwww-perl et l’a transmis à Gisle Aas qui est le développeur de celle-ci. Le comblement de cette faille est intervenu avec la mise à jour 5.51 en modifiant le nom de la variable par laquelle la configuration du proxy peut être contrôlée dans CGI_HTTP_PROXY. La même année la vulnérabilité a également été détectée dans le programme de transfert de données curl. C’est pourquoi le développeur Daniel Stenberg a adapté en conséquence le logiciel, de sorte que désormais seule la variante minuscule http-proxy puisse déterminer le serveur proxy, tout en avertissant que cela était fondamentalement insuffisant 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 implémentant la classe NET::HTTP, un client HTTP API pour les applications Ruby. Pour contourner le problème, HTTT_PROXY et d’autres ont été configurés sous le statut d’une norme variable. Dans les années suivantes, les applications de serveur Web NGINX (2013) et Apache (2015) sont les cas les plus importants dans lesquels des utilisateurs attentifs ont alors informés les développeurs d’un danger potentiel.

En 2016, l’équipe de sécurité de la société de développement Vend a finalement constaté que la vulnérabilité HTTPoxy était, 15 ans après sa première découverte, toujours une faille. PHP et d’autres langages de programmation et les bibliothèques, peuvent être exploités à condition d’être combinés avec CGI ou un environnement d’exécution comparable à des variables. De nombreuses applications affectées qui permettent l’utilisation de HTTPoxy ont été répertoriées dans le dictionnaire des informations publiques relatives aux vulnérabilités de sécurité, les CVE (Common Vulnerabilites 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 CGIHandler
  • CVE-2016-1000111: Python Twisted
  • CVE-2016-1000212: lighttpd

Comment se protéger ainsi que votre serveur de HTTPoxy ?

Peu importe si vous exécutez votre propre serveur Web ou non. HTTPoxy représente un risque lorsque vous êtes sur le World Wide Web. Si le service Web appelé peut être détourné de manière indésirable par des requêtes HTTP externes, vos données ne sont donc pas protégées. Pour minimiser le risque de détournement de données, vous devez donc préférer les sites qui sont protégés par un certificat TLS/SSL et transférer toutes les informations 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 conversion en HTTP est de toute façon obligatoire aujourd’hui. Cependant, vous avez toujours la possibilité d’éviter HTTPoxy en supprimant en général simplement la faille de sécurité. Comme l’en-tête proxy n’est pas tenu à une norme IETF (Internet Engineering Task Force) ou enregistré via l’IANA (Internet Assigned Numbers Authority) comme en-tête officiel, vous pouvez l’intercepter sans hésiter avant qu’il n’atteigne votre application Web. Les serveurs et clients HTTP standards n’émettent de toute façon pas de paquets de données avec cet en-tête. Fondamentalement, vous avez deux options en plus du cryptage de l’échange de données HTTP pour empêcher les requêtes dangereuses d’atteindre votre projet Web :

  1. Filtrer l’en-tête proxy sur tous les paquets entrants.
  2. Bloquer automatiquement tous les paquets entrants qui contiennent 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épartition de charges (Load Balancing). Les sections suivantes fournissent des informations sur la façon de supprimer l’en-tête potentiellement dangereux du trafic de données sur diverses distributions Linux à l’aide des applications serveur Web Apache Nging et du logiciel serveur proxy HAProxy.

Contourner HTTPoxy avec Apache

Le logiciel libre Apache est depuis longtemps installé par défaut sur toutes les distributions 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èrement de chaque distribution.

Ubuntu et Debian :

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

sudo a2enmod headers

Ouvrez ensuite le fichier de configuration principal d’Apache avec un éditeur. L’outil en ligne de commande nano qui est utilisé dans l’exemple est recommandé : 

sudo nano /etc/apache2/apache2.conf

Développez maintenant le fichier avec l’entrée suivante : 

<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>

Après avoir enregistré le fichier, vous pouvez activer la protection HTTPoxy en chargeant le fichier de configuration spécifique avec le scripte a2enconf, puis redémarrer le serveur :

sudo a2enconf httpoxy
sudo service apache2 restart

CentOS et Fedora :

Si vous utilisez une version de la distribution 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 configuration : 

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

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

RequestHeader unset Proxy early

Sauvegardez ensuite les changements et redémarrez le serveur Apache :

sudo service httpd restart

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

NGINX est une application de serveur Web qui jouit d’une popularité grandissante. Le logiciel open-source ne nécessite que quelques étapes pour protéger les applications 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 paramètres FastCGI (FastCGi est une optimisation de la norme CGI) sont inclus dans Ubuntu et Debian dans les fichiers fastcgi_params ou fastcgi.conf, lorsque vous configurez 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 : 

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

Si vous utilisez NGINX comme un proxy HTTP conventionnel, vous pouvez également filtrer l’en-tête. Pour ce faire, insérez la règle correspondante dans le fichier proxy_params qui répertorie les paramètres du serveur proxy : 

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

Dans la dernière étape, redémarrer NGINC avec cette commande : 

sudo service nginx restart

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 procédures pour les systèmes Ubutun et Debian. Puisque les configurations NGINX sur ces distributions sont définies dans les fichiers fastcgi_params ou dans le fichier fastcgi.conf. Vous pouvez aussi désactiver l’en-tête du proxy ici avec les commandes déjà répertoriées : 

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

Pour protéger les proxys conventionnels 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 : 

sudo grep -r "proxy_pass" /etc/nginx

Cela contient une liste des fichiers texte dans laquelle la directive est répertoriée, ou les sorties ressemblent à l’exemple suivant :

/etc/nginx/nginx.conf.default:        #    proxy_pass http://127.0.0.1;

Dans ce cas, proxy_pass pourrait être ainsi dans le fichier de configuration NGINX. L’entrée correspondante dans nginx.conf doit être ajoutée comme ci-dessous :

proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";

Dans les deux cas, pour terminer le processus, vous devez redémarrer le serveur : 

sudo service nginx restart

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 différentes distributions Linux mentionnées, la procédure ne diffère pas. Tout d’abord, il est nécessaire d’ouvrir le fichier de configuration principal de l’application proxy, ce que vous pouvez réaliser avec la commande suivante : 

sudo nano /etc/haproxy/haproxy.cfg

De cette façon, vous ouvrez le fichier haproxy.cfg avec l’éditeur de ligne de commande nano, utilisé précédemment. Si vous avez spécifié un autre répertoire pour HAProxy pendant l’installation, vous devrez ajuster la commande en conséquence.

Dans le fichier ouvert, vous pouvez maintenant 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 : 

frontend name
    http-request del-header Proxy
…
backend name
    http-request del-header Proxy
…
listen name
    http-request del-header Proxy

Enregistrez les modifications et redémarrez le service HAProxy : 

sudo service haproxy restart

Contrôle de sécurité avec HTTPoxy Vulnerability Checking Tool

Après avoir effectué la configuration de votre proxy à l’aide des options de protections énumérées contre HTTPoxy, vous devriez vérifier si elles sont correctement utilisées. Pour cela, il existe des applications comme HTTPOXY Vulnerability Checking Tool de Luke Rehmann. Ce service Web gratuit vérifie les URL et recherche les vulnérabilités HTTPoxy en envoyant une requête HTTP avec les en-têtes proxy à l’URL qui redirige vers un autre serveur. Si l’outil ne reçoit pas de réponse du serveur, l’en-tête a été bloqué avec succès.

l’outil Web HTTPOXY Vulnerability Checking Tool
Vérification HTTPoxy réussie avec Vulnerability Checking Tool, disponible sur httpoxy.rehmann.co

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

Cet article vous a-t-il été utile ?