Une campagne observée contre des passerelles SonicWall Gen6 SSL-VPN rappelle un point souvent sous-estimé en production : un correctif appliqué partiellement, une remédiation incomplète ou une validation post-patch absente peuvent neutraliser une mesure de sécurité aussi structurante que l’authentification multifacteur. Selon les éléments relayés par BleepingComputer et fondés sur les communications de l’éditeur, des attaquants ont exploité des équipements SonicWall exposés sur Internet pour combiner brute force d’identifiants VPN et contournement de MFA lorsque la correction n’avait pas été menée jusqu’au bout.

Le sujet concerne prioritairement les organisations qui utilisent SonicOS 6.5 sur appliances Gen6 avec le module SSL-VPN activé, notamment lorsque l’accès distant est publié directement sur Internet, sans restriction d’origine, et avec des comptes locaux ou des annuaires d’entreprise insuffisamment protégés contre les tentatives répétées. L’impact concret est élevé : accès VPN non autorisé, compromission de comptes, pivot interne, puis déploiement d’outils post-intrusion. Dans plusieurs incidents récents sur des appliances réseau, ce type d’accès initial a ensuite servi à déposer des utilitaires d’administration à distance, des scripts de collecte d’identifiants ou des implants plus persistants.

Le point important n’est pas seulement l’existence d’une faille ou d’un défaut de remédiation, mais le fait que la MFA peut donner une impression de protection résiduelle alors qu’elle ne joue plus pleinement son rôle si la chaîne de correction n’est pas complète. Pour les équipes infra, SOC, RSSI et exploitants mutualisés, y compris chez des hébergeurs et infogéreurs opérant sur des environnements exposés chez OVH, Scaleway ou o2switch, la priorité est double : vérifier la version réellement exécutée et valider que les mécanismes de MFA, de verrouillage de compte, de journalisation et d’exposition Internet sont cohérents après mise à jour.

À la date de rédaction, SonicWall a communiqué sur la nécessité d’appliquer les correctifs complets recommandés par l’éditeur et de revoir la configuration des accès distants. La couverture médiatique évoque un contournement de MFA lié à un correctif incomplet, mais l’enjeu opérationnel dépasse la simple mise à niveau logicielle : il faut aussi vérifier les politiques d’accès, les comptes compromis potentiels et les traces d’exploitation antérieure. Lorsque des identifiants VPN ont déjà été forcés ou réutilisés, le patch seul ne suffit pas.

La source originale à citer dans le cadre de cette alerte reste la communication et la documentation de SonicWall, complétées par l’article de veille publié par BleepingComputer. En environnement français, il est également pertinent de surveiller les relais éventuels du CERT-FR si des indicateurs ou recommandations complémentaires sont publiés.

Versions affectées

Le périmètre communiqué concerne les équipements SonicWall Gen6 utilisant SSL-VPN, avec un risque particulier lorsque les correctifs précédents n’ont pas été appliqués complètement ou lorsque la remédiation a été limitée à une partie de la chaîne de protection. Les informations diffusées publiquement insistent davantage sur l’état de remédiation que sur une unique fenêtre de versions simple à résumer.

Produits principalement concernés

  • Appliances SonicWall Gen6 exécutant SonicOS 6.5 avec SSL-VPN exposé.
  • Déploiements où la MFA est activée mais où le correctif, la mise à niveau ou la reconfiguration associée n’a pas été menée intégralement.
  • Environnements publiés directement sur Internet, notamment via des interfaces d’administration ou d’accès distant accessibles sans filtrage d’IP source.

État vulnérable

  • Appliances non corrigées selon les recommandations de SonicWall.
  • Appliances partiellement corrigées, par exemple après mise à jour incomplète, redémarrage non finalisé, configuration MFA non revalidée, ou conservation de paramètres historiques incompatibles avec la remédiation attendue.
  • Appliances où des comptes locaux ou intégrés à un annuaire restent exposés à des tentatives répétées sans verrouillage effectif.

État corrigé

  • Appliances mises à jour vers la version explicitement recommandée par SonicWall pour le modèle concerné.
  • Configuration SSL-VPN revue après patch : politique MFA active, tests de connexion validés, restrictions d’accès appliquées, journaux vérifiés.
  • Rotation des secrets et réinitialisation des comptes potentiellement compromis lorsque des tentatives de brute force ont été observées.

La difficulté pratique, sur ce dossier, est que de nombreuses équipes se contentent de vérifier le numéro de version affiché dans l’interface ou l’état “up-to-date” d’un équipement. Or ici, le risque provient précisément d’un écart entre patch appliqué et remédiation réellement effective. Il faut donc contrôler trois éléments séparément : la version, la configuration de MFA, et l’exposition réseau.

Concernant les identifiants de vulnérabilité, les publications médiatiques n’associent pas toujours l’incident à un CVE-ID unique de manière stable dans leurs titres. En exploitation et en gouvernance, il faut donc s’appuyer d’abord sur l’advisory officielle SonicWall et sur les notes de version de l’éditeur pour le modèle exact. Si un CVSS est explicitement publié pour le correctif sous-jacent, il doit être repris dans l’inventaire interne et dans le suivi de remédiation. En l’absence d’un score unique consolidé dans la communication publique sur ce cas précis, le niveau de risque opérationnel doit être considéré comme élevé dès lors que l’équipement est accessible depuis Internet et protège l’accès au SI.

Pour les équipes qui gèrent un parc hétérogène, il est recommandé de dresser une matrice simple :

  • modèle de l’appliance,
  • version exacte de SonicOS,
  • état d’activation de SSL-VPN,
  • mode de MFA utilisé,
  • date réelle de patch,
  • preuve de test post-correctif,
  • exposition Internet directe ou indirecte.

Cette approche est essentielle dans les structures multi-sites ou multi-tenants, où plusieurs boîtiers peuvent partager une même politique de sécurité théorique mais diverger dans les faits. Une appliance oubliée, un site secondaire moins surveillé ou un accès de secours resté ouvert suffit souvent à invalider la posture globale.

Vecteur d’attaque

Le scénario d’attaque décrit est particulièrement parlant parce qu’il ne repose pas nécessairement sur une exploitation “spectaculaire” au sens classique du terme. Les attaquants commencent par un travail opportuniste d’exposition : recherche d’interfaces SSL-VPN SonicWall accessibles publiquement, identification des bannières, des certificats et parfois des chemins spécifiques permettant de confirmer le type d’équipement. Cette phase peut s’appuyer sur des moteurs de recherche d’actifs, des scans Internet ou des listes d’adresses déjà connues dans des campagnes antérieures.

Une fois la cible identifiée, l’étape suivante consiste à tester des identifiants. Cela peut prendre plusieurs formes :

  • brute force classique sur des comptes exposés,
  • password spraying avec quelques mots de passe courants sur un grand nombre d’utilisateurs,
  • réutilisation d’identifiants issus de fuites antérieures,
  • test de comptes techniques ou historiques insuffisamment surveillés.

Dans un fonctionnement normal, la présence de la MFA doit empêcher qu’un mot de passe seul suffise. Le problème observé ici est qu’en cas de remédiation incomplète, cette barrière peut être contournée ou ne pas s’appliquer comme prévu. Autrement dit, l’attaquant n’a pas besoin de casser la MFA au sens cryptographique : il exploite une situation où le service VPN accepte un chemin d’authentification qui n’impose pas correctement le second facteur.

Sur le plan opérationnel, cela ressemble à la séquence suivante :

  • découverte d’une interface SSL-VPN SonicWall Gen6 exposée,
  • test automatisé d’identifiants valides,
  • acceptation d’une session ou d’une étape d’authentification alors que la MFA devrait bloquer,
  • ouverture du tunnel VPN,
  • reconnaissance interne, mouvement latéral et déploiement d’outils post-exploitation.

Pourquoi un patch incomplet annule la protection attendue

Dans les infrastructures réelles, un correctif n’est pas un bloc monolithique. Il peut inclure :

  • une mise à jour du binaire ou du firmware,
  • une migration de paramètres,
  • une revalidation des profils d’authentification,
  • une purge ou reconstruction de certains états internes,
  • un redémarrage complet des services,
  • une revue manuelle des exceptions d’accès.

Si une seule de ces étapes manque, le système peut rester dans un état intermédiaire. C’est particulièrement vrai sur les passerelles de sécurité, où coexistent des couches d’authentification locales, LDAP, RADIUS, OTP, certificats, politiques de groupes et exemptions héritées. Une MFA “active” dans l’interface n’est pas toujours synonyme de MFA “enforcée” sur tous les chemins d’accès.

Un exemple simplifié de logique de contrôle que l’on s’attend à voir côté service ressemble à ceci :

1. Vérifier l'identifiant et le mot de passe
2. Déterminer la politique applicable à l'utilisateur ou au groupe
3. Exiger un second facteur si la politique l'impose
4. Autoriser la session seulement après validation du second facteur

Dans un état dégradé ou incohérent, on peut se retrouver avec une logique effective plus proche de :

1. Vérifier l'identifiant et le mot de passe
2. Basculer sur une ancienne politique ou une exception héritée
3. Considérer la MFA comme optionnelle ou déjà satisfaite
4. Ouvrir la session

Ce type d’écart est difficile à détecter sans test réel après changement. Un tableau de bord vert ne le révèle pas forcément.

Scénario d’intrusion concret

Une PME industrielle publie son accès distant via une appliance SonicWall Gen6. La mise à jour a été faite après lecture d’un bulletin, mais sans recette complète. La MFA est supposée protéger les comptes VPN. Un attaquant récupère une liste de couples email:motdepasse provenant d’une fuite ancienne visant un service SaaS tiers. Il teste ces identifiants sur le portail SSL-VPN. Un compte réutilisant son mot de passe est accepté. En théorie, la MFA devrait interrompre la connexion. En pratique, l’appliance, restée dans un état de remédiation incomplet, autorise l’ouverture de session.

L’attaquant accède alors au réseau interne, interroge l’Active Directory, repère un partage de scripts d’administration et récupère des informations d’inventaire. Dans les heures suivantes, il dépose un outil de prise en main à distance, crée une tâche planifiée sur un serveur intermédiaire et exfiltre des données de configuration. À ce stade, le problème initial n’est plus seulement “VPN exposé” : c’est une compromission d’accès de confiance qui contourne les défenses périmétriques classiques.

Impact

L’impact métier et technique est significatif, même si l’attaque initiale semble triviale. Une passerelle VPN compromise offre un point d’entrée privilégié, souvent perçu par le SI comme une connexion légitime. Les conséquences observables incluent :

  • accès non autorisé à des segments internes sans exploitation locale supplémentaire,
  • compromission de comptes utilisateurs ou techniques,
  • contournement des politiques de sécurité fondées sur la confiance accordée au VPN,
  • déploiement d’outils post-intrusion comme des agents RMM, des scripts PowerShell, des collecteurs d’identifiants ou des utilitaires de tunneling,
  • mouvement latéral vers serveurs de fichiers, contrôleurs de domaine, consoles d’administration,
  • préparation d’un chiffrement ou d’une exfiltration dans des chaînes d’attaque plus longues.

Pour un RSSI, le point clé est qu’un échec de MFA sur un accès VPN doit être classé comme un incident d’authentification critique, au même niveau d’attention qu’une faille d’exécution de code sur un équipement exposé. La valeur offensive est comparable : dans les deux cas, l’attaquant obtient un accès initial à fort rendement.

Comment patcher

La remédiation doit suivre la documentation officielle de SonicWall pour le modèle exact et la branche logicielle concernée. Il ne s’agit pas d’un paquet système que l’on corrige via apt, dnf ou composer, mais d’une mise à niveau de firmware SonicOS et d’une revue de configuration sur l’appliance. La source de vérité reste l’advisory officielle SonicWall et les notes de version associées.

Étapes de correction recommandées

  • Identifier précisément le modèle Gen6 et la version courante de SonicOS.
  • Télécharger depuis le portail SonicWall la version corrigée recommandée pour ce modèle.
  • Sauvegarder la configuration complète avant intervention.
  • Appliquer la mise à jour de firmware selon la procédure éditeur.
  • Redémarrer complètement l’équipement si l’éditeur le demande.
  • Revalider manuellement les paramètres SSL-VPN, la MFA, les groupes d’accès et les profils d’authentification.
  • Tester avec un compte de recette que la connexion sans second facteur est bien refusée.
  • Faire une rotation des mots de passe pour les comptes exposés si des tentatives suspectes ont été observées.

Exemple de procédure opératoire

Les interfaces SonicWall varient selon les modèles, mais une séquence d’exploitation typique ressemble à ceci :

1. Export de sauvegarde de configuration
2. Vérification de l'espace disponible et de l'intégrité de l'image firmware
3. Téléversement de l'image corrigée depuis le portail SonicWall
4. Sélection de l'image comme firmware de démarrage
5. Redémarrage contrôlé de l'appliance
6. Contrôle de version après reboot
7. Vérification des paramètres MFA et SSL-VPN
8. Test d'authentification réel avec et sans second facteur

Quand l’équipement est intégré dans une architecture haute disponibilité, il faut en plus vérifier la cohérence entre nœuds. Une erreur fréquente consiste à mettre à jour le nœud principal sans finaliser la synchronisation ou la bascule sur le secondaire. Dans ce cas, une partie du trafic peut continuer à être traitée par un composant restant dans l’état vulnérable.

Points de contrôle post-correctif

  • La version affichée correspond-elle exactement à celle recommandée par l’éditeur ?
  • Le service SSL-VPN est-il toujours nécessaire sur Internet ?
  • La MFA est-elle imposée à tous les groupes autorisés ?
  • Des exceptions historiques subsistent-elles pour certains comptes ou plages IP ?
  • Le verrouillage après échecs répétés est-il actif et testé ?
  • Les journaux montrent-ils encore des connexions validées sans second facteur attendu ?

Commandes et actions de remédiation complémentaires

Comme il s’agit d’une appliance, il n’existe pas de commande universelle du type apt upgrade. En revanche, les équipes d’exploitation ont généralement besoin de commandes système autour de l’équipement pour réduire immédiatement l’exposition. Exemples utiles côté infrastructure :

  • Restreindre temporairement l’exposition réseau via pare-feu amont : iptables, ACL routeur, règles cloud ou filtrage hébergeur.
  • Vérifier l’écoute du service depuis un bastion de contrôle : curl -k https://vpn.example.tld/
  • Tester l’accessibilité Internet depuis l’extérieur : nmap -sV -Pn vpn.example.tld
  • Archiver les journaux avant remédiation pour analyse forensique.

Exemple de blocage temporaire côté frontal Linux si un reverse-proxy ou un filtrage amont protège l’appliance :

# Autoriser seulement une plage d'administration temporaire
iptables -A INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

En environnement cloud ou virtualisé, l’équivalent peut être fait via groupes de sécurité ou ACL réseau. L’idée n’est pas de “réparer” SonicWall par une commande externe, mais de réduire immédiatement la surface d’attaque tant que la validation complète n’est pas terminée.

Détection

La détection doit partir du principe qu’une partie des équipements exposés a pu faire l’objet de tentatives massives d’authentification avant même que l’équipe ne prenne connaissance du problème. Il faut donc rechercher à la fois des signes de brute force et des indices de connexions réussies anormales.

Indicateurs de compromission et signaux faibles

  • Hausse soudaine du volume d’échecs d’authentification sur SSL-VPN.
  • Tentatives répétées depuis un même ASN, un même pays ou des plages IP inhabituelles.
  • Succès d’authentification immédiatement précédés d’un grand nombre d’échecs.
  • Connexions réussies sur des comptes rarement utilisés ou inactifs.
  • Sessions VPN ouvertes à des horaires atypiques pour l’utilisateur concerné.
  • Absence apparente d’événement MFA alors qu’une session a pourtant été accordée.
  • Création ou déploiement rapide d’outils d’administration à distance après connexion VPN.

IoC à rechercher côté SI

Les IoC ne se limitent pas à l’appliance elle-même. Une fois connecté via VPN, l’attaquant agit sur le réseau interne. Les équipes SOC et systèmes doivent donc corréler plusieurs sources.

  • Journaux SonicWall montrant des séquences login failed répétées suivies d’un login success.
  • Événements d’authentification Active Directory pour des comptes VPN depuis des adresses inhabituelles.
  • Ouverture de sessions sur des serveurs administratifs peu après une connexion VPN.
  • Exécution de powershell.exe, cmd.exe, wmic.exe, psexec.exe ou outils RMM depuis des hôtes joints récemment au VPN.
  • Création de tâches planifiées, nouveaux services ou dépôts de binaires dans C:\ProgramData\, C:\Windows\Temp\ ou répertoires utilisateurs.
  • Connexions sortantes vers des domaines ou IP de commande et contrôle après authentification VPN.

Exemples de requêtes et contrôles

Si les journaux sont centralisés dans un SIEM, une recherche simple peut être formulée autour de la relation entre échecs et succès rapprochés. Exemple conceptuel :

source="sonicwall" AND ("SSLVPN login failed" OR "SSLVPN login success")
| stats count by src_ip, username, action
| where action="success" AND count > 0

Sur un agrégateur de logs Linux recevant les événements, on peut filtrer rapidement :

grep -E "SSLVPN|MFA|login" /var/log/sonicwall/*.log

Pour repérer des accès inattendus à partir d’adresses publiques précises, une recherche orientée IP reste utile :

grep "203.0.113.45" /var/log/sonicwall/*.log

Si l’environnement est adossé à un annuaire, il faut aussi vérifier les comptes verrouillés, les échecs Kerberos ou LDAP et les réinitialisations de mot de passe récentes. Dans de nombreux incidents, la compromission ne s’arrête pas au portail VPN : l’attaquant exploite ensuite des privilèges annexes, des partages réseau ou des secrets présents sur les postes des utilisateurs nomades.

Mesures immédiates si le patch ne peut pas être appliqué tout de suite

  • Limiter l’exposition Internet à une liste d’IP source autorisées si possible.
  • Désactiver temporairement SSL-VPN si le service n’est pas indispensable à court terme.
  • Forcer la rotation des mots de passe des comptes ayant accès au VPN.
  • Désactiver les comptes inactifs ou historiques.
  • Renforcer le verrouillage après plusieurs échecs d’authentification.
  • Surveiller en temps réel les journaux de connexion et les accès internes post-VPN.
  • Restreindre les droits réseau des utilisateurs VPN aux seuls segments nécessaires.

Ces mesures compensatoires sont particulièrement importantes dans les structures où la maintenance des boîtiers de sécurité est sous-traitée ou mutualisée. Il n’est pas rare qu’un prestataire applique la mise à jour logicielle mais ne réalise pas les tests fonctionnels de sécurité, ou qu’un site distant reste en retard de validation. Dans ce contexte, les RSSI doivent demander une preuve de remédiation, pas seulement une déclaration de patch.

Comparaison avec des failles antérieures de passerelles VPN

Ce cas s’inscrit dans une tendance plus large observée depuis plusieurs années sur les équipements d’accès distant : les passerelles VPN, pare-feu et solutions de télétravail concentrent à la fois l’exposition Internet, la confiance d’authentification et la valeur opérationnelle pour un attaquant. On a déjà vu des campagnes massives viser des équipements Pulse Secure, Fortinet, Cisco, Citrix ou encore des appliances de sécurité dont les correctifs tardaient à être appliqués.

La différence ici est instructive : il ne s’agit pas seulement d’une faille brute de type exécution de code ou divulgation de fichiers. Le problème met en lumière la fragilité des hypothèses de sécurité après patch. Une organisation peut croire que “la MFA couvre le risque”, alors que la chaîne de remédiation laisse subsister un chemin de connexion où ce second facteur n’est plus effectivement exigé. Cette situation est souvent plus dangereuse qu’une faille visible, car elle crée une fausse assurance.

Pour les équipes de gouvernance, cela plaide pour une évolution des processus :

  • passer d’un suivi “patch installé” à un suivi “contrôle de sécurité validé”,
  • exiger des tests d’acceptation sécurité après chaque mise à jour de passerelle exposée,
  • revoir régulièrement l’inventaire des services publiés sur Internet,
  • intégrer les boîtiers réseau dans les scénarios de chasse et de forensic, au même niveau que les serveurs applicatifs.

Dans l’écosystème français, cette approche est d’autant plus utile que beaucoup d’organisations opèrent des architectures hybrides entre sites on-premise, hébergement mutualisé, IaaS et services managés. Une passerelle VPN oubliée chez un prestataire, un site de secours chez un hébergeur ou un boîtier d’agence mal maintenu peuvent devenir la porte d’entrée la plus simple. Les recommandations de durcissement réseau et de validation post-changement restent donc essentielles, y compris hors contexte SonicWall.

En pratique, la priorité est claire : vérifier immédiatement les appliances SonicWall Gen6 exposées, confirmer la version corrigée recommandée par l’éditeur, tester réellement l’application de la MFA et réduire l’exposition Internet tant que le doute subsiste. Si des tentatives de brute force ou des succès anormaux apparaissent dans les journaux, il faut traiter l’événement comme une compromission potentielle, avec rotation des secrets, revue des accès et investigation interne. Pour renforcer durablement le durcissement des accès distants, une revue des bonnes pratiques de segmentation, de journalisation et de contrôle post-patch reste indispensable ; plusieurs ressources complémentaires sont à retrouver dans la catégorie /categorie/pratiques.

Rubrique Serveurs
Partager
Retour aux actualités