Votre serveur web est en danger avec HTTPoxy, attention !

Responsables ITCybercriminalitéFaille de sécuritéSécuritéVulnérabilité
serveur web

HTTPoxy : potentiel danger pour votre serveur web !

serveur webUn nouveau BWAIN est arrivé !

BWAIN est un acronyme, quelque peu cynique, pour désigner un “Bug With An Impressive Name”, à savoir une nouvelle tendance qui est apparue il y a de cela 2 ans environ, avec le bien connu Heartbleed.

Heartbleed était, en réalité, une sorte de jeu de mots, étant donné que ce bug vous permettait de contourner la fonction TLS/SSL heartbeat, pour récupérer (“bleed” en anglais) en masse des données confidentielles sur des serveurs vulnérables.

Tout le monde a le droit à son quart d’heure de gloire, ainsi le bug BWAIN a certainement piqué au vif les experts en sécurité et, en retour, ils nous ont trouvé des noms de failles de sécurité plutôt amusants tels que POODLE et LOGJAM, et des plus optimistes tels que Shellshock, DROWN et ImageTragick.

Présentation de HTTPoxy

Voici donc le nouveau venu, avec un nom qui ferait plutôt penser à une maladie : HTTPoxy.

Nous sommes persuadés que vous comprendrez par vous-mêmes de quoi il s’agit, mais pour aller au bout de la démarche, nous dirons simplement que le bug en question implique des requêtes HTTP et des paramétrages proxy corrompus.

Pour comprendre HTTPoxy, vous devez connaitre avant tout les fondamentaux du système du serveur web, communément désignés par la Common Gateway Interface (CGI).

D’après la documentation officielle de la CGI :

En d’autres termes, cela signifie que si vous voulez un serveur web avec des fonctionnalités telles des moteurs de recherche, des commentaires, la capacité à trouver des tarifs au sein d’une base de données, à passer des commandes en ligne, avec des forums d’aide et ainsi de suite, ….

…vous n’avez pas besoin de programmer toutes ces fonctions au sein du serveur lui-même.

En utilisant la CGI, le serveur web peut appeler tous les autres programmes nécessaires, afin de générer le contenu web que vos visiteurs recherchent, et ensuite utiliser les sorties de ces programmes secondaires pour construire les pages web désirées.

La communication avec des scripts CGI

Les serveurs web et les programmes CGI externes, que les serveurs en question peuvent appeler, ne peuvent cependant pas fonctionner de manière complètement indépendante.

En effet, les requêtes web par exemple, intègrent en général un certain nombre d’en-têtes HTTP qui influencent le type de réponses qu’ils sont prêts à accepter, et qui de plus donnent de informations pratiques sur l’émetteur de la requête.

C’est alors pratique, si le serveur peut transmettre les en-têtes à un sous processus qui s’occupera alors des tâches relatives à la CGI.

serveur webLa technique standard pour transmettre des données d’un serveur à des scripts CGI, est d’utiliser ce qu’Unix (par exemple, BSD et OS X), Linux et Windows appellent tous “variables d’environnement“.

Cela sonne plutôt bien, cependant elles sont déjà assez anciennes : environnement fait partie du jargon informatique pour désigner ce qui est une simple liste de chaines de caractères, sous la forme NAME=VALUE, stockée en mémoire à un endroit où le processus peut y accéder.

Il s’agit d’une manière simple et pratique de configurer chaque sous processus, de manière à ce qu’il trouve aisément comment, et à quel endroit s’exécuter, et ainsi adapter son comportement en conséquence.

Si vous ouvrez une invite de commandes dans la plupart des systèmes d’exploitation, vous pouvez visualiser les paramètres de l’environnement du processus d’invite de commandes lui-même en tapant la commande : set :

serveur webLe standard CGI, à savoir un document connu sous le nom RFC 3875 déclare, comme une évidence, qu’afin d’apporter le support nécessaire aux sous processus CGI, un serveur web compatible avec la CGI doit s’assurer que tous les champs au sein des en-têtes originaux soient disponibles pour les sous programmes CGI, en les ajoutant en tant que variables d’environnement.

Bien sûr, la CGI ne peut pas ajouter aveuglement des variables d’environnement avec les mêmes noms que les en-têtes originaux, du fait des risques évidents de collisions potentielles.

De manière plus simple, un en-tête qui s’appelle Path:, serait à même d’écrire sur la variable d’environnement standard appelée PATH=, et cette situation serait alors terriblement risquée dans la mesure où PATH= désigne l’endroit où les programmes lancés peuvent aller chercher.

Un cybercriminel peut piéger une requête web avec un en-tête tel que Path: C:UsersduckDownloads, et par la même occasion duper n’importe quels programmes CGI et l’inciter à lancer des logiciels à partir d’un endroit non officiel.

Cela constituera, au final, probablement une vulnérabilité de type .

Eviter les collisions

RFC3875 essaie d’éviter les risques de collisions avec la règle suivante :

En d’autres termes, l’en-tête Path: piégé par le cybercriminel apparaîtra sous l’aspect sécurisé suivant :

HTTP_PATH=C:UsersduckDownloads

Jusque-là tout va bien !

Cependant toutes les variables d’environnement qui commencent par HTTP_ ne sont pas intrinsèquement sécurisées.

Par exemple, beaucoup de programmes compatibles web, qui intègre des fonctionnalités susceptibles d’être utilisée par des scripts CGI, traite la variable d’environnement HTTP_PROXY=, d’une manière plutôt spéciale, car ils l’utilisent pour configurer leurs propres paramètres proxy.

En d’autres termes, si j’envoie une requête web piégée, qui contient un en-tête HTTP pointant un endroit différent tel que :

Proxy: http:⁄⁄dodgy.example/crooked_proxy

… alors n’importe quel script CGI qui traitera ma requête fonctionnera avec ce jeu de variables d’environnement :

HTTP_PROXY=http:⁄⁄dodgy.example/crooked_proxy

Ainsi, chaque requête que ces scripts généreront successivement (par exemple, pour réaliser une requête au niveau d’une base de données, ou bien pour authentifier un utilisateur) ne sera pas traitée directement, mais sera à la place envoyée au serveur web example.dangereux, du fait de la configuration proxy inattendue et malveillante.

Cela peut mener à des fuites de données à une grande échelle, car les scripts qui ont l’habitude de traiter des données secrètement via des serveurs internes, peuvent accidentellement échanger des requêtes HTTP  confidentielles au niveau de serveurs externes, contrôlés par les cybercriminels, qui ont réussi à ruser en envoyant leur propre trafic via le proxy.

Au final cela explique à la fois le fonctionnement de HTTProxy et la raison du choix de ce nom.

Quoi faire ?


//
Partagez HTTPoxy : potentiel danger pour votre serveur web ! avec : http://wp.me/p2YJS1-2Qz
Billet inspiré de HTTPoxy – the disease that could make your web server spring a leak par Paul Ducklin, Sophos NakedSecurity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.