IT / Télécom
Pare-feu Cisco ASA et FTD : une faille du VPN exploitée pour faire redémarrer l’équipement
Le VPN d’accès distant, c’est souvent par lui que passent la télémaintenance des sites, les interventions sur la supervision GTB ou le contrôle d’accès, parfois même des remontées vers un poste central. Alors quand Cisco annonce une faille de ce VPN sur ses pare-feu ASA et FTD, déjà exploitée, je préfère que vous l’appreniez ici plutôt qu’en découvrant un site injoignable un lundi matin.
Les faits
- La faille : CVE-2026-76418, publiée par Cisco le 28 octobre (avis cisco-sa-asaftd-tunnel-dos-s6mgkb75), notée 8,6 sur 10.
- L’effet : une requête forgée, sans identifiant ni mot de passe, fait redémarrer le pare-feu, et l’attaquant peut recommencer autant qu’il le veut. Cisco n’annonce ni exécution de code ni accès aux données : c’est un déni de service.
- Les conditions : une version vulnérable, le VPN SSL d’accès distant joignable, et une authentification secondaire configurée dans le tunnel group. C’est une erreur de logique dans ce cas précis qui provoque le plantage.
- L’exploitation : Cisco a eu connaissance d’attaques réelles en octobre. La CISA l’a ajoutée le 29 octobre à son catalogue des failles exploitées, avec une échéance au 1er novembre pour les administrations fédérales américaines.
- Hors champ : Cloud-delivered Firewall, Secure Access et les consoles FMC ne sont pas concernés.
Les versions corrigées
| Branche | Version corrigée minimale |
|---|---|
| ASA 9.16 et antérieures | 9.16.4.104 |
| ASA 9.18 | 9.18.4.96 |
| ASA 9.20 | 9.20.4.50 |
| ASA 9.22 | 9.22.3.200 |
| ASA 9.23 | 9.23.1.48 |
| ASA 9.24 | 9.24.1.27 ou 9.24.10.1 |
| FTD 7.0 et antérieures | 7.0.11 |
| FTD 7.2 / 7.4 / 7.6 / 7.7 | 7.2.13 / 7.4.9 / 7.6.7 / 7.7.14 |
| FTD 10.0 / 10.1 | 10.0.3 / 10.1.1 |
Vérifiez toujours votre build exact dans l’avis de Cisco avant de planifier l’intervention.
Ce que ça change sur un site
Un pare-feu qui redémarre, ce n’est pas seulement un VPN coupé. Selon l’architecture, ce sont aussi les liaisons site à site, l’accès au cloud du VMS, les remontées d’alarmes techniques, voire la transmission vers la télésurveillance quand elle passe par ce lien IP. Et comme l’attaque peut être répétée, le site peut rester isolé tant que la faille reste ouverte.
C’est un bon rappel de deux règles que je défends souvent : une transmission d’alarme ne dépend jamais d’un seul chemin (d’où la double voie IP et 4G sur les transmetteurs), et la télémaintenance doit avoir un plan B documenté.
Ce que je vérifierais
- La version exacte de chaque ASA ou FTD du parc, et si le VPN SSL d’accès distant y est actif.
- La présence d’une authentification secondaire dans les tunnel groups : c’est la condition qui expose l’équipement.
- La mise à jour, en commençant par le membre secondaire d’une paire haute disponibilité, avec un retour arrière prévu.
- En attendant, la mesure provisoire proposée par Cisco : désactiver l’authentification secondaire. Elle supprime le plantage mais affaiblit l’authentification du VPN ; je ne la garderais que quelques jours.
- Les journaux : tout redémarrage inexpliqué depuis début octobre mérite une explication.
Mon avis
Une faille qui « ne fait que » redémarrer un pare-feu peut sembler secondaire. Je ne suis pas de cet avis : sur un site où tout passe par ce boîtier, c’est une coupure complète à la demande de n’importe qui. L’ironie, c’est que la condition de la faille est une bonne pratique, l’authentification secondaire, celle-là même qu’on recommande pour durcir un VPN.
Ce que j’apprécie, c’est un avis clair, avec des conditions précises et une liste de versions facile à vérifier. Ce qui me fait tiquer, c’est la répétition : après Ivanti la semaine dernière, les équipements de périmètre restent la cible favorite. Exposer le moins de services possible sur Internet et réserver l’accès des mainteneurs à un point d’entrée unique, journalisé et à jour, ça reste la base.
Commentaires
Aucun commentaire pour l'instant : lancez la discussion.