Comment protéger votre serveur contre la vulnérabilité HTTPoxy

Qu’est-ce que HTTPoxy?

Le 18 juillet 2016, une vulnérabilité d’application CGI, appelée HTTPoxy, a été divulguée. Un attaquant peut exploiter des déploiements vulnérables en passant un en-tête HTTP + Proxy + avec sa requête, qui modifiera l’URL utilisée par l’application lors du contact avec les services de support. Cela peut être utilisé pour divulguer des informations d’identification, modifier les réponses à l’application, etc.

Cette vulnérabilité est due à une collision de noms entre la variable d’environnement + HTTP_PROXY +, fréquemment utilisée pour spécifier l’emplacement d’un service proxy backend, et l’en-tête du client HTTP + Proxy +. La spécification CGI demande que les en-têtes fournis par le client soient transmis à l’environnement avec un préfixe + HTTP_ + pour le nommage. Cette confusion entre en conflit avec des variables de configuration telles que + HTTP_PROXY +, qui commencent également par + HTTP_ +. Si une application CGI ou une bibliothèque utilise cette variable sans traitement supplémentaire, il est possible qu’elle finisse par utiliser la valeur fournie par le client lors de la tentative de connexion au service proxy.

Comme cette vulnérabilité a des répercussions sur diverses implémentations de type CGI, un certain nombre d’identificateurs de vulnérabilité de sécurité ont été créés: 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 et http: // www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000110[CVE-2016-1000110] (Au moment de la rédaction de cet article, ces informations sont réservées, mais non renseignées).

La vulnérabilité HTTPoxy est connue sous certaines formes depuis 2001, mais elle n’a jamais été reconnue comme un problème répandu jusqu’à récemment. Bien que cela puisse affecter de nombreux déploiements, l’atténuation est assez simple et directe.

Serveurs et applications vulnérables

HTTPoxy est une vulnérabilité générale trouvée par de nombreuses implémentations de CGI. Une application ou un serveur peut correctement implémenter la spécification CGI tout en restant vulnérable.

Pour qu’un déploiement soit vulnérable, il doit:

* Utilisez la variable d’environnement + HTTP_PROXY + pour configurer les connexions proxy *: soit dans le code de l’application lui-même, soit dans les bibliothèques utilisées. C’est une méthode assez standard de configuration de serveurs proxy utilisant l’environnement.
* Effectuer des requêtes sur les services backend via HTTP *: étant donné que la collision de noms est spécifique au préfixe + HTTP_ +, seules les requêtes effectuées par l’application à l’aide de HTTP seront affectées. Les demandes utilisant HTTPS ou tout autre protocole ne sont pas vulnérables.
* Utiliser dans un environnement CGI ou similaire *: les déploiements dans lesquels les en-têtes de clients sont traduits en variables d’environnement préfixées + HTTP_ + sont vulnérables. Toute implémentation conforme de CGI ou de protocoles associés tels que FastCGI le fera.

Comme vous pouvez le constater, une combinaison de facteurs de déploiement et spécifiques à une application est nécessaire pour qu’un déploiement soit vulnérable. Pour vérifier si votre déploiement est affecté, Luke Rehmann a créé un site simple pour vérifier la vulnérabilité des sites accessibles au public.

Informations spécifiques à la langue

Les applications PHP en particulier doivent être auditées, car les déploiements de type CGI sont beaucoup plus courants dans l’écosystème PHP que dans d’autres langages. De plus, l’utilisation généralisée de la méthode + getenv + dans les bibliothèques populaires amplifie ce problème, car il n’est pas immédiatement évident que cela retourne une entrée utilisateur non normalisée, pas seulement des variables de configuration. Les bibliothèques spécifiques actuellement affectées sont Guzzle (version 4.0.0rc2 et supérieure), Artax et la classe StreamContextBuilder de Composer.

Python et Go ont également été jugés vulnérables lors du déploiement à l’aide de CGI. Ces langages sont plus couramment déployés à l’aide d’autres méthodes non vulnérables. Toutefois, si vous utilisez CGI, les bibliothèques qui lisent naïvement la variable + HTTP_PROXY + sans modifier leur comportement sont vulnérables.

Comment vaincre la vulnérabilité

Heureusement, HTTPoxy est relativement simple à corriger. La vulnérabilité peut être adressée à partir de la couche serveur Web ou de l’application ou de la bibliothèque:

Les applications ou les bibliothèques peuvent ignorer la variable + HTTP_PROXY + quand elles se trouvent dans un environnement CGI.
Les applications ou les bibliothèques peuvent utiliser une variable d’environnement différente pour configurer les connexions proxy.
Les serveurs Web ou les mandataires peuvent annuler l’en-tête + Proxy + reçu dans les demandes des clients

Si vous utilisez une bibliothèque vulnérable, vous devez atténuer la menace côté serveur jusqu’à ce que des correctifs soient disponibles pour résoudre le problème. Si vous êtes un auteur de bibliothèque ou d’application et que votre projet repose sur la variable + HTTP_PROXY + pour configurer un serveur proxy, envisagez d’utiliser une autre variable qui ne se heurtera pas lors de son exécution dans un environnement de type CGI. Ruby et quelques autres projets utilisent + CGI_HTTP_PROXY + à cette fin.

Puisque l’en-tête + Proxy + n’est pas un en-tête HTTP standard, il peut être ignoré sans risque dans presque tous les cas. Cela peut être effectué sur le serveur Web ou l’équilibreur de charge utilisé pour diriger les demandes vers l’application elle-même. Parce que l’en-tête HTTP + Proxy + n’a pas d’objet légitime légitime, il peut presque toujours être supprimé.

Tout serveur Web, équilibreur de charge ou proxy commun peut supprimer les en-têtes appropriés.

Supprimer l’en-tête du proxy HTTP avec Apache

Si vous exécutez le serveur Web HTTP Apache, le module + mod_headers + peut être utilisé pour supprimer l’en-tête de toutes les demandes.

Serveurs Ubuntu et Debian

Pour activer + mod_headers + sur les serveurs Ubuntu ou Debian, tapez:

sudo a2enmod headers

Ensuite, ouvrez le fichier de configuration global:

sudo nano /etc/apache2/apache2.conf

Vers le bas, ajoutez:

/etc/apache2/apache2.conf

. . .
RequestHeader unset Proxy early

Enregistrez et fermez le fichier.

Vérifiez la configuration pour les erreurs de syntaxe:

sudo apache2ctl configtest

Redémarrez le service si aucune erreur de syntaxe n’est signalée:

sudo service apache2 restart

Serveurs CentOS et Fedora

Le module + mod_headers + devrait être activé par défaut pour les installations conventionnelles. Pour supprimer l’en-tête + Proxy +, ouvrez le fichier de configuration globale:

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

Vers le bas, ajoutez:

/etc/httpd/conf/httpd.conf

. . .
RequestHeader unset Proxy early

Enregistrez et fermez le fichier lorsque vous avez terminé.

Recherchez les erreurs de syntaxe en tapant:

sudo apachectl configtest

Si aucune erreur de syntaxe n’est signalée, redémarrez le service en tapant:

sudo service httpd restart

Suppression de l’en-tête du proxy HTTP avec Nginx

Dans Nginx, l’atténuation est également triviale. Vous pouvez facilement assainir l’environnement pour tout environnement de type CGI exécuté sur le serveur ou en amont.

Serveurs Ubuntu et Debian

Sur les serveurs Ubuntu et Debian, les paramètres FastCGI sont généralement inclus à partir des fichiers + fastcgi_params + ou + fastcgi.conf + lors de la configuration d’un proxy FastCGI. Vous pouvez supprimer l’en-tête + HTTP_PROXY + dans ces deux fichiers:

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 ne recherchez pas l’un des fichiers lors de la configuration de vos proxys FastCGI, veillez à inclure cette même ligne dans l’emplacement même du proxy:

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

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

       . . .
   }
}

Si vous utilisez Nginx pour le proxy HTTP conventionnel, vous devez également effacer l’en-tête HTTP + Proxy +. Les en-têtes de proxy HTTP sont définis dans le fichier + / etc / nginx / proxy_params +. Vous pouvez ajouter la règle pour supprimer l’en-tête + Proxy + de ce fichier en tapant:

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

Encore une fois, si vous ne sourcez pas ce fichier à partir de la configuration de bloc de votre serveur, vous devrez l’ajouter à l’emplacement même du proxy:

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

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

       . . .
   }
}

Recherchez les erreurs de syntaxe en tapant:

sudo nginx -t

Si aucune erreur n’est signalée, redémarrez le service:

sudo service nginx restart

Serveurs CentOS et Fedora

Nginx sur CentOS et Fedora utilise également les mêmes fichiers + fastcgi_params + et + fastcgi.conf + pour configurer le proxy FastCGI. Désactivez l’en-tête + HTTP_PROXY + dans ces deux fichiers en tapant:

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 ne recherchez pas l’un de ces fichiers lors de la configuration de vos proxys FastCGI, veillez à inclure cette même ligne dans l’emplacement même du proxy:

/etc/nginx/nginx.conf

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

       . . .
   }
}

Si vous utilisez Nginx pour le proxy HTTP conventionnel, vous devez également effacer l’en-tête HTTP + Proxy +. Vous devez simplement ajouter une règle pour supprimer l’en-tête + Proxy à n’importe quel emplacement où vous exécutez un` + proxy_pass`. Si vous ne savez pas où + proxy_pass + est utilisé, vous pouvez facilement rechercher dans votre répertoire de configuration:

grep -r "proxy_pass" /etc/nginx

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

Tous les résultats non commentés (comme dans l’exemple ci-dessus) doivent être modifiés pour inclure + proxy_set_header Proxy" "; +:

/etc/nginx/nginx.conf

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

       . . .
   }
}

Recherchez les erreurs de syntaxe en tapant:

sudo nginx -t

Si aucune erreur n’est signalée, redémarrez le service:

sudo service nginx restart

Suppression de l’en-tête du proxy HTTP avec HAProxy

Si vous utilisez HAProxy pour diriger le trafic sur vos serveurs d’applications, vous pouvez supprimer l’en-tête + Proxy + avant de transférer le trafic.

Ouvrez le fichier + / etc / haproxy / haproxy.cfg + pour le modifier:

sudo nano /etc/haproxy/haproxy.cfg

Vous pouvez définir la directive + http-request + dans les sections + frontend +, + backend + ou + listen + de votre configuration.

/etc/haproxy/haproxy.cfg

frontend www

   . . .

backend web-backend

   . . .

listen appname 0.0.0.0:80

   . . .

Celles-ci n’ont pas besoin d’être définies dans chacune des sections, mais il n’est pas inutile de les inclure. Enregistrez et fermez le fichier lorsque vous avez terminé.

Vérifiez la syntaxe en tapant:

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

Si aucun problème n’est détecté, redémarrez le service en tapant:

sudo service haproxy restart

Conclusion

La vulnérabilité HTTPoxy est ouverte depuis assez longtemps et peut affecter un grand nombre d’applications déployées sur le Web. Heureusement, il est facile de corriger en utilisant les fonctionnalités de modification d’en-tête natives de tout serveur Web.

TOC

Comment protéger votre serveur contre la vulnérabilité HTTPoxy

Qu’est-ce que HTTPoxy?

Serveurs et applications vulnérables

Informations spécifiques à la langue

Comment vaincre la vulnérabilité

Supprimer l’en-tête du proxy HTTP avec Apache

Serveurs Ubuntu et Debian

Serveurs CentOS et Fedora

Suppression de l’en-tête du proxy HTTP avec Nginx

Serveurs Ubuntu et Debian

Serveurs CentOS et Fedora

Suppression de l’en-tête du proxy HTTP avec HAProxy

Conclusion

Related