Les attaques sur les infrastructures VPN d'entreprise exploitent des vecteurs distincts des attaques génériques : vulnérabilités des daemons, faiblesses de configuration IKE, interception pré-tunnel, mouvement latéral post-authentification. Cette page documente ces vecteurs et les mesures défensives correspondantes.
Le concentrateur VPN est une cible à haute valeur : il agrège l'ensemble des connexions distantes et, s'il est compromis, donne accès au réseau interne sans credentials utilisateur. Les CVE critiques publiées ces dernières années illustrent la réalité de ce vecteur.
| CVE | Produit | CVSS | Type | Impact |
|---|---|---|---|---|
| CVE-2023-27997 | Fortinet FortiGate SSL-VPN | 9.8 | Heap buffer overflow | RCE sans authentification |
| CVE-2024-3400 | Palo Alto GlobalProtect | 10.0 | Command injection OS | RCE root sans authentification |
| CVE-2024-21887 | Ivanti Connect Secure | 9.1 | Command injection | RCE authentifié (chaîné avec CVE-2023-46805) |
| CVE-2023-46805 | Ivanti Connect Secure | 8.2 | Authentication bypass | Chaîné avec CVE-2024-21887 → RCE sans auth |
| CVE-2022-42475 | Fortinet FortiOS SSL-VPN | 9.3 | Heap buffer overflow | RCE sans authentification — exploitation active |
Les CVE de score CVSS ≥ 9.0 sur des équipements VPN sont activement exploitées dans des délais de 24 à 72 heures après publication du PoC public. Le délai standard de patching de 30 jours est inadapté pour cette catégorie. Objectif : moins de 48 heures pour CVSS ≥ 9.0, moins de 7 jours pour CVSS ≥ 7.0 sur les équipements exposés à Internet.
IPsec/IKEv2 propose une liste de suites cryptographiques lors de la négociation initiale. Si le concentrateur accepte des suites faibles pour des raisons de compatibilité (3DES, MD5, groupes DH 1024 bits), un attaquant MITM sur le segment réseau peut forcer la négociation vers ces suites et compromettre ultérieurement le trafic.
Configuration défensive — allow-list explicite en StrongSwan :
ike=aes256gcm16-sha384-ecp384! — le ! refuse tout ce qui n'est pas dans la listeesp=aes256gcm16-ecp384! — PFS activé sur la Phase 23des, md5, modp1024, modp1536 dans les propositionsIKEv2 supporte la fragmentation des messages (RFC 7383) pour traverser les MTU restrictifs. Des implémentations vulnérables ont été exposées à des attaques par fragmentation (réassemblage de paquets forgés). S'assurer que la version du daemon est à jour et que la fragmentation IKEv2 est activée (préférable au fallback sur la fragmentation IP).
Certaines implémentations IKEv2 révèlent par leur comportement (délai de réponse, message d'erreur) si un identifiant existe ou non dans la base. Cette énumération permet à un attaquant de constituer une liste de comptes valides avant une attaque par credential stuffing. Vérifier que les messages d'erreur d'authentification ne distinguent pas "identifiant inconnu" de "mot de passe incorrect".
En configuration split tunnel, les règles de routage du client définissent quels flux entrent dans le tunnel et lesquels sortent directement. Sur un réseau local hostile, un attaquant peut envoyer des réponses ARP ou DHCP forgées pour rediriger du trafic censé sortir directement vers sa propre machine — interception avant que le tunnel ne puisse le capturer. Les clients VPN qui ne verrouillent pas les règles de routage via des règles iptables/nftables ou des politiques réseau OS sont vulnérables.
Mitigation : passer en full tunnel sur les réseaux non maîtrisés (Wi-Fi public, hôtels, réseaux clients), ou s'assurer que le client VPN verrouille les règles de routage de façon non contournable.
Un attaquant déploie un point d'accès Wi-Fi avec le même SSID qu'un réseau légitime (hôtel, entreprise cliente, salon professionnel). Les appareils configurés pour se connecter automatiquement à ce SSID s'y connectent sans avertissement. L'attaquant est en position MITM entre le terminal et Internet. Si le tunnel VPN n'est pas établi immédiatement au démarrage de la connexion réseau, le trafic initial sort non protégé.
Mitigation : mode always-on avec kill switch. Le terminal bloque tout trafic réseau tant que le tunnel VPN n'est pas établi. Sur iOS, le profil MDM permet de configurer always-on IKEv2 nativement. Sur Android, WireGuard supporte always-on nativement dans les paramètres VPN système.
Entre le démarrage du système et l'établissement du tunnel VPN, le trafic sort sur le réseau local non protégé — y compris les requêtes DNS initiales, qui révèlent les domaines consultés. Sur un réseau hostile, cette fenêtre de quelques secondes peut suffire. Kill switch avec démarrage automatique du tunnel élimine cette fenêtre. Sur Linux systemd, le service WireGuard ou StrongSwan peut être configuré pour démarrer avant la connexion réseau utilisateur.
Les endpoints IKEv2 (UDP/500) et OpenVPN (TCP/443 ou UDP/1194) sont continuellement sondés par des scanners automatisés. Des couples identifiant/mot de passe issus de fuites de données (Have I Been Pwned référence plus de 12 milliards de credentials compromis) sont testés de façon automatisée. Sans MFA, la compromission d'un compte sur un service tiers sans rapport suffit à ouvrir un accès réseau si l'utilisateur réutilise son mot de passe.
Une fois authentifié dans le VPN, un attaquant avec des credentials valides peut tenter de se déplacer vers d'autres systèmes du réseau interne — Active Directory, serveurs de fichiers, bases de données, systèmes de sauvegarde. Ce vecteur est documenté dans les rapports d'incidents ransomware comme étape intermédiaire entre la compromission des credentials VPN et le déploiement du ransomware.
Microsegmentation : cloisonner le réseau interne en zones — les utilisateurs VPN n'accèdent qu'aux ressources dont ils ont besoin, pas à l'ensemble du réseau. VLAN distincts par profil utilisateur (commercial, technique, admin), avec filtrage inter-VLAN explicite. ZTNA : approche structurelle qui remplace l'accès réseau par l'accès applicatif granulaire — voir la page Architecture.