SonicWall a publié une alerte urgente invitant ses clients à réinitialiser tous leurs identifiants de connexion après que des chercheurs ont découvert que des fichiers de sauvegarde de configuration de MySonicWall avaient été exposés par inadvertance sur un espace de stockage public.
Ces fichiers contenaient des mots de passe chiffrés, des clés prépartagées et des certificats TLS utilisés par les appliances SonicOS, ce qui pouvait permettre à des acteurs malveillants de déchiffrer les identifiants et d’obtenir un accès non autorisé aux réseaux des entreprises.
Portée et impact de l’incident
Le 17 septembre, SonicWall a publié un article de la base de connaissances confirmant que des fichiers de sauvegarde de configuration de pare-feu associés à certains comptes MySonicWall avaient été accessibles en ligne de manière inappropriée.
Ces fichiers de configuration stockent souvent des éléments sensibles tels que les paramètres des utilisateurs et des groupes, les clés VPN, les données DNS et les certificats SSL. Des travaux antérieurs montrent que des groupes de rançongiciels comme des acteurs étatiques ont exploité des fichiers de configuration exfiltrés pour préparer des attaques ultérieures.
Bien que SonicWall ait contenu l’exposition et collabore avec les forces de l’ordre, l’entreprise a averti les organisations utilisant sa fonctionnalité de sauvegarde cloud d’agir rapidement pour empêcher tout accès non autorisé.
Les clients dont les numéros de série ont été directement concernés voient désormais une bannière d’information lorsqu’ils se connectent à MySonicWall. Pour ceux qui ne disposent pas d’un numéro de série indiqué, mais qui avaient auparavant activé les sauvegardes cloud, des recommandations supplémentaires seront bientôt communiquées.
Mesures de confinement
Verrouiller la gestion accessible depuis le WAN
Pour réduire l’exposition avant de réinitialiser les mots de passe, SonicWall recommande de désactiver tous les services de gestion accessibles depuis le WAN.
Les administrateurs doivent désactiver l’accès HTTP, HTTPS et SSH sur les interfaces WAN, désactiver les services SSL VPN et IPsec VPN, bloquer SNMP v3 afin d’empêcher tout accès non autorisé et limiter les règles NAT ou d’accès entrantes aux adresses IP approuvées.
Dans les environnements exécutant SonicOS 6.5.5.1 ou 7.3.0, une option d’application dynamique peut bloquer temporairement les comptes jusqu’à l’application de nouveaux identifiants.
Réinitialisation des identifiants et mesures correctives
Les administrateurs doivent également réinitialiser les identifiants comme suit :
- Réinitialiser tous les mots de passe des utilisateurs locaux et des administrateurs, puis réassocier les applications d’authentification fondées sur TOTP.
- Renouveler les secrets partagés des comptes LDAP, RADIUS et TACACS+, en utilisant le hachage SHA-256 lorsque cela est applicable.
- Remplacer toutes les clés prépartagées des tunnels site à site IPsec et de GroupVPN, en veillant à mettre à jour les passerelles distantes.
- Actualiser les identifiants des interfaces WAN (par exemple, L2TP, PPPoE, PPTP et réseau cellulaire) en coordination avec les FAI.
- Mettre à jour les clés de chiffrement dans le mode IPSec Management Tunnel de Global Management System (GMS).
Les intégrations cloud, notamment Dynamic DNS, Clearpass NAC et les services d’automatisation des e-mails, doivent également recevoir des mots de passe mis à jour. Les organisations qui reçoivent de nouveaux « fichiers de préférences » de SonicWall doivent les importer, puis reconfigurer les paramètres souhaités avant de créer une nouvelle sauvegarde.
Surveillance et défense continue
Après les mesures correctives, les administrateurs doivent réactiver progressivement les services en testant chacun d’eux avec les identifiants mis à jour. Une surveillance continue est essentielle :
- Utilisez Surveiller → Journaux → Journaux système et journaux d’audit pour identifier les échecs de connexion ou les modifications anormales de configuration.
- Exportez les journaux au format CSV pour un examen détaillé, ou transmettez les données de manière sécurisée à des outils SIEM via Syslog sur TLS 1.2.
- Examinez les clés SSH et les scripts d’automatisation afin de vérifier qu’ils ne font référence qu’aux nouveaux identifiants.
Ces mesures contribuent à protéger les défenses du périmètre réseau contre l’exploitation de données de configuration qui auraient été exposées auparavant.
Implications plus larges
Cet incident souligne l’importance de sécuriser les configurations de pare-feu gérées dans le cloud et de maintenir une stricte hygiène des identifiants.
pare-feu Les sauvegardes contiennent souvent les clés du périmètre réseau d’une entreprise ; leur compromission peut donner aux adversaires un aperçu des méthodes d’authentification, des accès VPN et des intégrations de confiance.
Le renouvellement régulier des identifiants, la segmentation des accès administratifs et la surveillance des tentatives d’authentification suspectes peuvent réduire les risques liés à de futures expositions.