Faille de sécurité CVE-2024-23112 : Un contournement d'autorisation dans FortiOS et FortiProxy


Le monde des cybermenaces est en constante évolution, et il est crucial pour les organisations de garder une longueur d'avance sur les vulnérabilités potentielles. 

Un contournement d'autorisation via une vulnérabilité de clé contrôlée par l'utilisateur [CWE-639] dans FortiOS versions 7.4.0 à 7.4.1, 7.2.0 à 7.2.6, 7.0.1 à 7.0.13, 6.4.7 à 6.4.14 et FortiProxy versions 7.4.0 à 7.4.2, 7.2.0 à 7.2.8, 7.0.0 à 7.0.14 SSL-VPN peut permettre à un attaquant authentifié d'accéder au favori d'un autre utilisateur via une manipulation d'URL. Avant de continue nous devons d'abord parle de CWE-639.

Qu'est-ce que CWE-639 ?

CWE-639, ou "Contournement d'autorisation par clé contrôlée par l'utilisateur", est une faille de sécurité courante classée dans la catégorie "Gestion des accès et des identités" (CWE-350) du Common Weakness Enumeration (CWE). Cette faille survient lorsqu'un système permet à un attaquant de modifier une clé contrôlée par l'utilisateur dans une requête pour accéder à des données ou à des fonctionnalités auxquelles il n'est pas autorisé.

Comment se produit une attaque CWE-639 ?

Généralement, une attaque CWE-639 implique les étapes suivantes :

  1. Identification d'une clé contrôlée par l'utilisateur: L'attaquant identifie une clé ou un paramètre dans une requête qui est contrôlé par l'utilisateur. Cette clé peut être un identifiant de compte, un numéro de document ou toute autre valeur qui détermine les données ou les fonctionnalités auxquelles l'utilisateur est censé avoir accès.
  2. Manipulation de la clé: L'attaquant modifie la valeur de la clé contrôlée par l'utilisateur dans la requête. Cette modification peut impliquer de changer l'identifiant d'un compte en un autre, d'augmenter un numéro de document ou de falsifier d'autres informations.
  3. Exploitation de l'accès non autorisé: Une fois la clé modifiée, l'attaquant soumet la requête modifiée au système. Le système, incapable de détecter la manipulation, accorde à l'attaquant l'accès aux données ou aux fonctionnalités auxquelles il n'est pas censé avoir accès.

Exemples d'attaques CWE-639

Voici quelques exemples concrets d'attaques CWE-639 :

  • Accéder aux informations d'un autre utilisateur dans une application web: Un attaquant peut modifier l'identifiant d'utilisateur dans une requête web pour accéder aux informations d'un autre utilisateur.
  • Télécharger des fichiers non autorisés depuis un serveur web: Un attaquant peut modifier le nom de fichier dans une requête de téléchargement pour accéder à des fichiers auxquels il n'est pas autorisé.
  • Exécuter des commandes non autorisées sur un système: Un attaquant peut modifier l'identifiant de commande dans une requête de commande pour exécuter des commandes non autorisées sur le système.

Impact des attaques CWE-639

Les attaques CWE-639 peuvent avoir des conséquences graves, notamment :

  • Vol de données sensibles: Un attaquant peut accéder à des données confidentielles telles que des informations financières, des données personnelles ou des secrets professionnels.
  • Perturbation des opérations: Un attaquant peut modifier ou supprimer des données critiques, perturbant les opérations commerciales et nuisant à la productivité.
  • Escalade de privilèges: Un attaquant peut exploiter l'accès non autorisé pour obtenir des privilèges accrus dans le système, lui permettant de prendre le contrôle de l'ensemble du réseau.

Prévention des attaques CWE-639

Pour prévenir les attaques CWE-639, il est essentiel de mettre en place des mesures de sécurité robustes, notamment :

  • Validation des entrées utilisateur: Validez soigneusement toutes les entrées utilisateur pour vous assurer qu'elles sont conformes aux attentes et qu'elles ne contiennent pas de valeurs modifiées.
  • Utilisation de contrôles d'accès stricts: Implémentez des contrôles d'accès granulaires qui limitent l'accès aux données et aux fonctionnalités en fonction des privilèges légitimes de chaque utilisateur.
  • Mise à jour régulière des logiciels: Appliquez régulièrement les correctifs de sécurité pour corriger les vulnérabilités connues, y compris les failles CWE-639.
  • Sensibilisation des utilisateurs à la sécurité: Éduquez les utilisateurs sur les risques des attaques CWE-639 et encouragez-les à signaler toute activité suspecte.

   Revenons à notre sujet la faille de FortiOS, il est important de s'avoir que La fonctionnalité d'autorisation du système n'empêche pas un utilisateur d'accéder aux données ou à l'enregistrement d'un autre utilisateur en modifiant la valeur clé identifiant les données.

La récupération d'un enregistrement utilisateur se produit dans le système sur la base d'une valeur clé sous le contrôle de l'utilisateur. La clé identifierait généralement un enregistrement lié à l'utilisateur stocké dans le système et serait utilisée pour rechercher cet enregistrement afin de le présenter à l'utilisateur. 

Il est probable qu'un attaquant doive être un utilisateur authentifié dans le système. Cependant, le processus d'autorisation ne vérifierait pas correctement l'opération d'accès aux données pour garantir que l'utilisateur authentifié effectuant l'opération dispose de droits suffisants pour effectuer l'accès aux données demandé, contournant ainsi tout autre contrôle d'autorisation présent dans le système.

Par exemple, les attaquants peuvent examiner les endroits où les données spécifiques de l'utilisateur sont récupérées (par exemple, les écrans de recherche) et déterminer si la clé de l'élément recherché est contrôlable de l'extérieur. La clé peut être un champ caché dans le champ du formulaire HTML, elle peut être passée en tant que paramètre d'URL ou en tant que variable de cookie non chiffrée, puis dans chacun de ces cas, il sera possible de falsifier la valeur de la clé.

Une manifestation de cette faiblesse se produit lorsqu'un système utilise des identifiants de session séquentiels ou facilement devinables qui permettraient à un utilisateur de passer facilement à la session d'un autre utilisateur et de lire/modifier ses données.


Conditions alternatives

Référence d'objet direct non sécurisé/IDOR :

Le terme « Référence d'objet direct non sécurisé », tel que décrit dans le Top Ten de l'OWASP, est plus large que ce CWE car il couvre également la traversée de chemin (CWE-22) on en parlers un jour. Dans le contexte de la théorie de la vulnérabilité, il existe une similitude entre le concept OWASP et CWE-706 : Utilisation d'un nom ou d'une référence incorrectement résolu.

Autorisation au niveau de l'objet brisé / BOLA :

BOLA est utilisé dans le Top 10 de sécurité des API OWASP 2019 et serait identique à IDOR.

Autorisation horizontale :

« Autorisation horizontale » est utilisée pour décrire des situations dans lesquelles deux utilisateurs ont le même niveau de privilège, mais doivent être empêchés d'accéder aux ressources de chacun. Ceci est assez courant lors de l’utilisation d’un accès aux ressources par clé dans un contexte multi-utilisateurs.


 Conséquences courantes

Impact technique : mécanisme de protection contre le contournement

Les contrôles d’accès pour des données ou fonctionnalités utilisateur spécifiques peuvent être contournés.

Une élévation horizontale des privilèges est possible (un utilisateur peut afficher/modifier les informations d'un autre utilisateur)  mais aussi Une élévation verticale des privilèges est possible si la clé contrôlée par l'utilisateur est en fait un indicateur indiquant le statut d'administrateur, permettant à l'attaquant d'obtenir un accès administratif.

Exemples démonstratifs

Le code suivant utilise une instruction paramétrée, qui échappe aux métacaractères et empêche les vulnérabilités d'injection SQL, pour construire et exécuter une requête SQL qui recherche une facture correspondant à l'identifiant spécifié [1]. L'identifiant est sélectionné dans une liste de toutes les factures associées à l'utilisateur authentifié actuel.


(mauvais code)

Exemple de langage : C#

...

conn = new SqlConnection(_ConnectionString);

conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();

...

Le problème est que le développeur n’a pas pris en compte toutes les valeurs possibles de id. Bien que l'interface génère une liste d'identifiants de facture appartenant à l'utilisateur actuel, un attaquant peut contourner cette interface pour demander n'importe quelle facture souhaitée. Étant donné que le code de cet exemple ne vérifie pas que l'utilisateur a l'autorisation d'accéder à la facture demandée, il affichera n'importe quelle facture, même si elle n'appartient pas à l'utilisateur actuel.

En Conclusion

La faille de sécurité CVE-2024-23112 représente un risque important pour les organisations utilisant les systèmes FortiOS et FortiProxy. Il est crucial d'appliquer les correctifs de sécurité et de mettre en place des mesures de sécurité supplémentaires pour protéger votre réseau contre les attaques potentielles.


fortinet hacked

Commentaires

Posts les plus consultés de ce blog

Inversehacker Le systeme des Hackeurs

Pirater Git avec GitGraber part1

Tout sur APT29