🔥 CVE-2024-50562 – Fortinet SSL-VPN ou l’art de rejouer la partie même après la déconnexion

Encore une faille dans le portail Fortinet SSL-VPN.
Encore une session qui refuse de mourir.
Encore un PoC GitHub.
Et toujours autant d’entreprises qui trouvent ça “normal”. 🤡

Bienvenue dans l’épisode 874 de la série : “Le VPN SSL, ce dangereux animal de compagnie que tout le monde laisse en liberté sur Internet.”

🧨 Le bug ? Une gestion de session… comme en 2003

La vulnérabilité CVE-2024-50562 cible la gestion de session dans les portails Fortinet SSL-VPN.
Elle permet à un attaquant de rejouer un cookie de session (SVPNCOOKIE) même après déconnexion.
Traduction :

Tu te déconnectes ? On s’en fout. Si j’ai ton cookie, j’ai ton accès.

Le tout sans mot de passe, sans MFA, sans rien. Juste un petit replay HTTP, et ça passe.

Et comme d’habitude : le PoC est en ligne sur GitHub, script Python prêt à l’emploi, utilisable par n’importe quel stagiaire stagiaire SOC ou pirate de fond de cave.

🧪 Le script ? Un cauchemar pour les SOC

Le script :

• se connecte au portail Fortinet,
• récupère le cookie de session,
• le stocke,
• déconnecte l’utilisateur,
• puis rejoue le cookie… et accède de nouveau au portail, comme si de rien n’était.

Le portail ne vérifie pas que la session a expiré. Et donc on se retrouve avec une faille CWE-613 bien connue : « Insufficient Session Expiration ».
Autrement dit : ta session, c’est du chewing-gum, elle colle même après la fin.

🔎 Le PoC en détail : “Session re-jeu” made easy

Le PoC GitHub est un script Python qui exploite la mauvaise gestion des cookies dans les portails Fortinet SSL-VPN.

Fonctionnement du script :

1. Connexion via le portail (avec un vrai compte, ou un compte volontairement temporaire, ou même un cookie récupéré).
2. Capture du cookie de session SVPNCOOKIE généré.
3. Déconnexion de la session.
4. Rejeu du cookie dans une nouvelle requête HTTP.

Résultat : la session est encore active, même après déconnexion. Le portail ne vérifie pas correctement l’invalidité du cookie → faille logique de session.

Ce genre de faille est :

• Triviale à automatiser.
• Invisible pour l’utilisateur.
• Exploitée en masse dès qu’un PoC sort (car les scanners automatiques peuvent tester les portails Fortinet exposés en frontal).

💣 Fortinet & SSL-VPN : un combo toujours gagnant

Non mais sérieusement, on en parle ?

Voici le palmarès Fortinet des dernières années :

Le SSL-VPN chez Fortinet, c’est un buffet à volonté pour les attaquants. Tu veux de la session ? Prends-en. Tu veux du RCE ? On a. Et les MFA ? Ils sont en option, comme le ketchup.

📉 Et pourtant, on persiste avec le SSL-VPN

Pourquoi tant d’amour pour ce vieux dinosaure du télétravail ?

• Facile à mettre en place.
• Pas besoin de client.
• Port 443 déjà ouvert.
  Et surtout : déployé en 30 minutes par le stagiaire IT qui a vu trois tutos YouTube.

Mais à quel prix ?

• Surface d’attaque énorme.
• Portail web exposé en frontal.
• Failles logiques régulières.
• Et parfois, aucun MFA.

Alors qu’en face, IPSec existe. Oui, c’est chiant à configurer. Oui, ça demande une vraie infra.
Mais c’est nettement plus robuste, parce que ça évite les bugs de portail web du vendredi soir.

SSL-VPN, c’est le McDo de la cybersécurité : rapide, facile, pas cher — mais tu vas le regretter.

🛡️ Que faire (à part pleurer) ?

1. Patch maintenant. Fortinet a publié des versions corrigées :
   • 7.6.1
   • 7.4.8
   • 7.2.11
     …et tous les autres doivent migrer. Oui, même toi, PME oubliée du RSSI.
2. Désactive temporairement le SSL-VPN web.
   • Active IPSec si possible.
   • Ou au moins limite les IPs d’accès.
3. Ajoute du MFA. Du vrai.
   • Pas du “code par SMS” stocké dans un fichier texte.
4. Active les logs d’accès et de session.
   • Et envoie-les vers un vrai SIEM.
   • Ou au moins, surveille les connexions étranges. Genre un accès depuis l’Ukraine à 2h du matin.

👨‍⚖️ Verdict ?

Tant qu’on continuera à exposer des portails SSL-VPN comme on expose son profil LinkedIn, les attaquants n’auront même plus besoin de ransomware.
Ils prendront ce qu’ils veulent en mode session-replay et cookies recyclés.

Fortinet ou pas, la vraie question est :

Combien de temps encore allons-nous tolérer la médiocrité de configuration au nom de la simplicité ?

Spoiler : les attaquants, eux, ont déjà tranché.

🕵️‍♂️ Pourquoi une CVE 2024 sort en juin 2025 ?

👉 Parce que **la numérotation CVE reflète la date de découverte (ou de déclaration initiale), pas celle de la publication du correctif.

📆 Voici le scénario classique (probablement celui de la CVE-2024-50562) :

1. Découverte de la vulnérabilité
   Un chercheur (ici Shahid-BugB) ou un utilisateur découvre le bug. Ça peut dater de fin 2024, voire début 2025.
2. Déclaration auprès du MITRE ou d’un CNA (CVE Numbering Authority)
   → Un numéro CVE est réservé. Si c’est en 2024 : bam, c’est une CVE-2024-XXXXX. Même si rien n’est encore public.
3. Phase de coordination / Responsible Disclosure
   Fortinet (ou autre éditeur) est prévenu → il a en général 90 jours max pour patcher avant divulgation publique (selon la politique du chercheur ou de ZDI, Project Zero, etc.).
4. Fortinet publie son correctif, et communique (plus ou moins bien) sur la faille.
   → Dans ce cas : le 10 juin 2025 via l’avis FG-IR-24-339.
5. Le chercheur publie son PoC → 21 juin 2025 sur GitHub.

📌 Donc en résumé :

🧠 Pourquoi c’est important ?

• Une CVE 2024 publiée en 2025 n’a rien d’anormal : c’est une question de calendrier de divulgation.
• Mais une faille “vieille” de plusieurs mois avec un patch tardif, ça pose d’autres questions :
  • Retards côté éditeur ?
  • Bug minimisé au départ ?
  • Coordination lente ?
  • Ou simplement : priorité donnée à d’autres failles plus sexy ?

Et pendant ce temps-là, des portails vulnérables restent exposés sans le savoir.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com