Ivanti Connect Secure : trois zero-days chaînés pour un accès root sans authentification

Trois vulnérabilités zero-day chaînées dans Ivanti Connect Secure

Le 29 octobre 2026, Ivanti a mis à jour son avis de sécurité pour Ivanti Connect Secure (ICS) en ajoutant deux nouvelles vulnérabilités, CVE-2026-111357 (CVSS 8,8) et CVE-2026-118527 (CVSS 4,3), aux côtés de CVE-2026-104935 (CVSS 8,6) déjà signalée le 13 octobre. Les trois failles sont activement exploitées en chaîne par le groupe criminel UTA0576 pour obtenir un accès root sans authentification sur les passerelles VPN ICS (Rapid7, Volexity).

Le CERT-FR a publié une alerte dédiée dès le 14 octobre 2026 (CERTFR-2026-ALE-013), mise à jour le 2 novembre pour inclure les deux nouvelles CVE. La CISA a ajouté les trois failles à son catalogue des vulnérabilités exploitées (KEV) le 30 octobre. Si votre entreprise utilise une passerelle VPN Ivanti Connect Secure, la mise à jour est prioritaire.

Ivanti Connect Secure : passerelle VPN SSL d'entreprise

Ivanti Connect Secure (anciennement Pulse Secure, racheté par Ivanti en 2020) est une passerelle VPN SSL (Virtual Private Network) déployée dans les réseaux d'entreprise pour fournir un accès distant sécurisé aux ressources internes. L'appliance est configurée avec une adresse IP publique et un nom de domaine dédié (par exemple vpn.entreprise.fr) pour que les collaborateurs distants puissent établir une connexion chiffrée vers le réseau local de l'organisation.

Dans l'architecture réseau typique, le boîtier ICS est placé en DMZ, entre le routeur d'accès Internet et le firewall interne. Le routeur effectue la translation d'adresse (NAT) et le firewall filtre les protocoles autorisés. Une fois le tunnel VPN établi, ICS agit comme un proxy d'accès : il route les flux TCP et UDP du client distant vers les ressources du réseau local, serveurs dédiés, bases de données MySQL, NAS, applications web internes et consoles d'administration. Le chiffrement TLS protège le tunnel de bout en bout, ce qui signifie que le firewall ne peut pas inspecter le contenu des paquets réseau qui transitent dans le tunnel VPN.

Cette architecture concentre un risque majeur : toute faille dans la passerelle VPN donne à un attaquant un accès direct au réseau local, au même niveau de confiance qu'un collaborateur authentifié. Depuis 2024, les passerelles Ivanti ont été ciblées par plusieurs campagnes d'exploitation zero-day successives. Chaque nouvelle chaîne d'exploitation permet de contourner l'authentification, d'exécuter du code arbitraire et de pivoter vers l'Active Directory, les serveurs virtuels, les postes sous Windows et les serveurs Linux hébergés derrière le VPN.

Détail des trois CVE exploitées

Prises séparément, CVE-2026-111357 nécessite un accès local authentifié et CVE-2026-118527 un accès distant authentifié. C'est CVE-2026-104935 qui supprime l'exigence d'authentification : en la chaînant avec les deux autres, UTA0576 obtient une exécution de code root à distance, sans identifiant. L'attaque repose sur des modifications en RAM sans écriture persistante sur le disque, ce qui complique la détection par les outils d'analyse forensique classiques.

Exploitation par UTA0576 : du VPN au vol de credentials Active Directory

Le groupe UTA0576, identifié par Volexity, a exploité cette chaîne depuis au moins le 3 octobre 2026 contre des appliances ICS en version 22.8R2.4, pourtant à jour au moment de l'attaque. L'adresse IP source identifiée dans les journaux est 108.165.147[.]64. Volexity évalue avec une confiance faible que le groupe poursuit des objectifs criminels plutôt que d'espionnage.

Après avoir obtenu un accès root sur l'appliance, l'attaquant a déployé plusieurs scripts Python dans le répertoire /tmp/ (ml.py, rq5.py, mk.py, rr.py) pour automatiser la post-exploitation. Les actions documentées par Volexity et Rapid7 incluent :

• Extraction des identifiants LDAP et des configurations DNS stockés dans l'appliance VPN ;
• Requêtes Active Directory (via les protocoles LDAP et DNS) pour récupérer les mots de passe LAPS des comptes administrateurs locaux sur les machines sous Windows ;
• Vol des clés de récupération BitLocker stockées dans l'AD ;
• Déploiement d'outils Kerberoast et de scripts LDAP personnalisés ;
• Password spraying contre les comptes Active Directory ;
• Capture de trafic réseau en clair via tcpdump (paquets TCP, connexions LDAP non chiffrées).

L'attaquant a pris des mesures anti-forensiques : suppression sélective d'entrées dans les journaux de debug et d'audit du système Linux, restauration du code modifié en RAM, nettoyage des artefacts temporaires. Ivanti précise que son outil de vérification d'intégrité (Integrity Checker Tool, ICT) peut ne pas détecter la compromission car les modifications restent en mémoire vive sans toucher le système de fichiers.

Versions affectées et correctifs

Les versions 25.1.3.x ne sont pas affectées par CVE-2026-111357 et CVE-2026-118527. Pour bloquer les trois CVE, la version minimale est ICS 25.1.1.3 ou 22.8R2.6. Les organisations encore sur la branche 22.8.x devraient planifier la migration vers la branche 25.1.x.

La CISA impose aux agences fédérales américaines une remédiation avant le 2 novembre 2026 pour CVE-2026-111357 et avant le 13 novembre 2026 pour CVE-2026-118527. En France, le CERT-FR recommande l'application immédiate des correctifs et l'investigation des appliances potentiellement compromises.

Alerte CERT-FR : recommandations pour les entreprises françaises

L'alerte CERTFR-2026-ALE-013, publiée le 14 octobre 2026 et mise à jour le 2 novembre, qualifie les risques : exécution de code arbitraire à distance, élévation de privilèges et contournement de la politique de sécurité. Les recommandations du CERT-FR :

• Isoler l'appliance du réseau local en attendant l'application du correctif. Si l'appliance est configurée dans une machine virtuelle, effectuer un snapshot du système de fichiers et de la mémoire vive (RAM) avant toute intervention ;
• Mettre à jour le firmware vers ICS 25.1.1.3 ou 22.8R2.6 ;
• Lancer l'outil d'intégrité Ivanti (ICT) pour rechercher des indicateurs de compromission, en gardant à l'esprit ses limites sur les modifications en mémoire ;
• En cas de compromission confirmée : réinitialisation usine de l'appliance, rotation de tous les secrets (identifiants LDAP/AD, certificats TLS, clés API, mots de passe des comptes d'administration), recherche de latéralisation dans le réseau et signalement au CERT-FR.

Vérification de l'infrastructure après incident

Lorsqu'une passerelle VPN est compromise, l'attaquant accède au réseau local avec les mêmes droits qu'un administrateur authentifié. L'investigation ne se limite pas à l'appliance ICS : elle doit couvrir tous les systèmes accessibles depuis la connexion VPN. Voici les vérifications prioritaires pour les administrateurs de VPS Linux et de serveurs dédiés hébergés derrière la passerelle.

Serveurs Linux (Ubuntu, Debian)

• Connexions SSH suspectes. Analysez les journaux /var/log/auth.log pour repérer des connexions depuis des adresses IP inhabituelles (analyser les échecs de connexion SSH). Listez les sessions ouvertes avec who et les processus lancés par des comptes inattendus.
• Clés SSH autorisées. Un attaquant disposant d'un accès root via le VPN peut avoir déposé ses propres clés dans ~/.ssh/authorized_keys sur chaque serveur Linux (gérer les clés SSH sur un VPS).
• Historique sudo. Vérifiez les commandes exécutées avec sudo dans les journaux système (/var/log/auth.log sur Ubuntu et Debian). L'outil auditd permet de tracer toutes les commandes exécutées avec des privilèges root, y compris les installations de paquets non prévues.
• Paquets installés. Comparez la liste des paquets installés (dpkg --get-selections sur Debian et Ubuntu) avec un état de référence pour détecter des logiciels ajoutés par l'attaquant.
• Mises à jour de sécurité. Profitez de l'investigation pour vérifier que les serveurs derrière le VPN sont eux aussi à jour (automatiser les mises à jour de sécurité sur Ubuntu).

Bases de données et applications web

• MySQL et bases de données. Si un serveur MySQL est accessible depuis le réseau local derrière le VPN, les identifiants de connexion stockés dans l'Active Directory sont potentiellement compromis. Changez les mots de passe des comptes MySQL et vérifiez les tables de privilèges (mysql.user).
• Applications web internes. Les applications web hébergées sur des serveurs derrière le VPN (panels d'administration, outils de monitoring, interfaces de gestion sur Apache ou Nginx) utilisent souvent une authentification liée à l'Active Directory. Réinitialisez les sessions actives et forcez une nouvelle authentification sécurisée.
• Protocoles non chiffrés. L'attaquant a utilisé tcpdump pour capturer du trafic en clair sur le réseau. Identifiez les services qui communiquent sans chiffrement : FTP, LDAP non TLS, connexions MySQL sans SSL. Migrez vers des protocoles sécurisés (SFTP, LDAPS, connexions chiffrées avec TLS).

Infrastructure de virtualisation et serveurs distants

• Hyperviseurs et serveurs virtuels. Si votre infrastructure repose sur de la virtualisation (VMware ESXi, Proxmox VE, KVM), un accès au réseau local permet d'atteindre les interfaces de gestion des hyperviseurs. Vérifiez les journaux de connexion et changez les mots de passe d'administration des plateformes de virtualisation.
• VPS et serveurs distants. Les VPS accessibles via le VPN doivent être audités au même titre que les serveurs physiques. Votre hébergeur peut fournir des journaux d'accès réseau complémentaires si vous suspectez une compromission.
• Surveillance de la bande passante. Une exfiltration de données après compromission génère un trafic sortant anormal. Surveillez la bande passante réseau de vos serveurs et configurez des alertes sur les transferts inhabituels (alertes de monitoring sur VPS Linux).

Renforcer la sécurité de l'accès distant à vos serveurs

Les passerelles VPN SSL comme Ivanti Connect Secure concentrent un risque structurel : elles exposent une surface d'attaque large sur Internet pour fournir un accès privilégié au réseau local. Le firewall d'entreprise laisse passer le trafic VPN chiffré sans pouvoir inspecter les paquets, et une seule faille sur la passerelle donne accès à tout le réseau interne : serveurs physiques, serveurs virtuels, bases de données, applications web, NAS.

• Segmenter le réseau. Configurez des règles de firewall entre le segment VPN et les ressources critiques du réseau local. Les serveurs de bases de données MySQL, les interfaces d'administration et les serveurs de jeu ne doivent pas être directement accessibles depuis la connexion VPN. Un pare-feu nftables configuré sur chaque serveur filtre les connexions entrantes par adresse IP source et protocole TCP/UDP.
• Chiffrer toutes les connexions internes. Même sur un réseau local considéré comme sécurisé, le chiffrement des protocoles empêche l'interception par un attaquant présent sur le réseau. Remplacez FTP par SFTP, activez TLS sur les connexions MySQL et LDAP, et utilisez HTTPS pour toutes les applications web internes. L'attaquant UTA0576 a capturé du trafic LDAP en clair : tout protocole non chiffré est une source de credentials supplémentaire pour l'attaquant.
• Multiplier les couches d'authentification. Même derrière un VPN correctement configuré, exigez une authentification SSH par clé publique (pas par mot de passe) et activez le MFA sur les panels web (sécuriser SSH sur VPS Linux).
• Détecter les comportements suspects. Un outil de détection d'intrusion comme CrowdSec sur vos serveurs repère les tentatives de password spraying et les scans de ports, même si l'attaquant entre par le VPN avec une adresse IP légitime du réseau local.
• Sauvegarder hors site. Si un attaquant obtient un accès root via la chaîne de vulnérabilités VPN, les sauvegardes stockées sur le réseau local sont compromises au même titre que les serveurs. Des sauvegardes rsync distantes ou des sauvegardes chiffrées hors site permettent de restaurer un état sain.
• Envisager des alternatives au VPN centralisé. Pour les accès d'administration à des VPS ou serveurs dédiés, un tunnel WireGuard point à point ou un réseau Tailscale évitent d'exposer une appliance VPN centralisée sur Internet. Ces solutions ne reposent pas sur un proxy intermédiaire et réduisent la surface d'attaque en supprimant le point de concentration unique.