Risques de désérialisation liés à l’utilisation de BinaryFormatter et des types associés

  • Article

Cet article s’applique aux types suivants :

Cet article s’applique aux implémentations .NET suivantes :

  • .NET Framework, toutes les versions
  • .NET Core 2.1 à 3.1
  • .NET 5 et versions ultérieures

Avertissement

Le type BinaryFormatter est dangereux et n’est pas recommandé pour le traitement des données. Les applications doivent cesser d’utiliser BinaryFormatter dès que possible, même si elles pensent que les données qu’elles traitent sont dignes de confiance. BinaryFormatter n’est pas sécurisé et ne peut pas être sécurisé.

Vulnérabilités de désérialisation

Les vulnérabilités de désérialisation sont une catégorie de menace dans laquelle les charges utiles de requête sont traitées de manière non sécurisée. Un attaquant qui tire parti de ces vulnérabilités sur une application peut provoquer un déni de service (DoS), la divulgation d’informations ou l’exécution de code à distance à l’intérieur de l’application cible. Cette catégorie de risque fait systématiquement partie du Top 10 de l’OWASP. Les cibles incluent les applications écrites dans divers langages, notamment C/C++, Java et C#.

Dans .NET, les applications qui utilisent le type BinaryFormatter pour désérialiser des données sont la cible à risque la plus importante. BinaryFormatter est largement utilisé dans l’écosystème .NET en raison de sa puissance et de sa facilité d’utilisation. Toutefois, cette même puissance permet aux attaquants d’influencer le flux de contrôle au sein de l’application cible. Les attaques réussies peuvent permettre à l’attaquant d’exécuter du code dans le contexte du processus cible.

En guise d’analogie plus simple, supposons que l’appel de BinaryFormatter.Deserialize sur une charge utile équivaut à interpréter cette charge utile comme un exécutable autonome et à la lancer.

Failles de sécurité de BinaryFormatter

Avertissement

La méthode BinaryFormatter.Deserialize n’est jamais sécurisée lorsqu’elle est utilisée avec une entrée non approuvée. Nous recommandons vivement aux consommateurs d’utiliser l’une des alternatives décrites plus loin dans cet article.

BinaryFormatter a été implémenté avant que les vulnérabilités de désérialisation soient une catégorie de menace bien comprise. Par conséquent, le code ne suit pas les bonnes pratiques modernes. La méthode Deserialize peut être utilisée comme vecteur pour permettre aux attaquants d’effectuer des attaques DoS contre les applications consommatrices. Ces attaques peuvent entraîner l’absence de réponse de l’application ou la fin inattendue du processus. Cette catégorie d’attaque ne peut pas être atténuée avec un SerializationBinder ou tout autre commutateur de configuration BinaryFormatter. .NET considère ce comportement comme étant inhérent et ne proposera pas de mise à jour de code pour modifier ce comportement.

BinaryFormatter.Deserialize peut être vulnérable à d’autres catégories d’attaques, comme la divulgation d’informations ou l’exécution de code à distance. L’utilisation de fonctionnalités, comme un SerializationBinder personnalisé, peut être insuffisante pour atténuer correctement ces risques. Il existe la possibilité qu’une vulnérabilité nouvelle soit découverte pour laquelle .NET ne peut pas pratiquement publier de mise à jour de sécurité. Les consommateurs doivent évaluer leurs scénarios individuels et considérer leur exposition potentielle à ces risques.

Nous recommandons aux consommateurs de BinaryFormatter d’effectuer des évaluations des risques individuels sur leurs applications. Il incombe entièrement au consommateur de déterminer s’il convient d’utiliser BinaryFormatter. Si vous envisagez de l’utiliser, vous devez évaluer les risques liés aux conséquences en matière de sécurité, techniques, de réputation, juridiques et réglementaires.

Alternatives préférées

.NET propose plusieurs sérialiseurs prêts à l’emploi qui peuvent gérer les données non approuvées de façon sécurisée :

Alternatives dangereuses

Évitez les sérialiseurs suivants :

Les sérialiseurs précédents effectuent tous une désérialisation polymorphe sans restriction et sont dangereux, tout comme BinaryFormatter.

Les risques liés à l’hypothèse que les données sont dignes de confiance

Souvent, un développeur d’applications peut croire qu’il traite uniquement des entrées de confiance. Le cas d’une entrée sécurisée est vrai dans de rares circonstances. Mais il est beaucoup plus courant qu’une charge utile dépasse une limite d’approbation sans que le développeur s’en rende compte.

Prenons l’exemple d’un serveur local, où les employés utilisent un client de bureau à partir de leurs stations de travail pour interagir avec le service. Ce scénario peut être considéré naïvement comme une configuration « sécurisée » où l’utilisation de BinaryFormatter est acceptable. Toutefois, il présente un vecteur pour les programmes malveillants qui accèdent à la machine d’un seul employé pour pouvoir se propager dans l’entreprise. Ce programme malveillant peut tirer parti de l’utilisation de BinaryFormatter par l’entreprise pour passer latéralement de la station de travail de l’employé au serveur principal. Il peut ensuite exfiltrer les données sensibles de l’entreprise. Ces données peuvent inclure des secrets commerciaux ou des données client.

Considérez également une application qui utilise BinaryFormatter pour conserver l’état de sauvegarde. Cela peut sembler à première vue un scénario sûr, car la lecture et l’écriture de données sur votre propre disque dur représentent une menace mineure. Toutefois, le partage de documents par e-mail ou sur Internet est courant, et la plupart des utilisateurs finaux ne perçoivent pas l’ouverture de ces fichiers téléchargés comme un comportement risqué.

Ce scénario peut être exploité pour avoir un effet néfaste. Si l’application est un jeu, les utilisateurs qui partagent des fichiers de sauvegarde sans le savoir se mettent en danger. Les développeurs eux-mêmes peuvent également être ciblés. L’attaquant peut envoyer un e-mail au support technique des développeurs, en joignant un fichier de données malveillant et en demandant au personnel du support technique de l’ouvrir. Ce type d’attaque peut lui donner un accès à l’entreprise.

Un autre scénario est celui où le fichier de données est stocké dans le stockage cloud et synchronisé automatiquement entre les machines de l’utilisateur. Un attaquant qui est en mesure d’accéder au compte de stockage cloud peut empoisonner le fichier de données. Ce fichier de données est automatiquement synchronisé avec les appareils de l’utilisateur. La prochaine fois que l’utilisateur ouvre le fichier de données, la charge utile de l’attaquant s’exécute. Ainsi, l’attaquant peut tirer parti d’une compromission de compte de stockage cloud pour obtenir des autorisations d’exécution de code complètes.

Prenons l’exemple d’une application qui passe d’un modèle d’installation de bureau à un modèle « cloud-first ». Ce scénario inclut des applications qui passent d’une application de bureau ou d’un modèle client riche à un modèle web. Les modèles de menace présentés pour l’application de bureau ne sont pas nécessairement applicables au service cloud. Le modèle de menace pour l’application de bureau peut ignorer une menace donnée s’il n’est « pas intéressant pour le client de s’attaquer lui-même ». Mais cette même menace peut devenir intéressante quand on considère qu’un utilisateur distant (le client) attaque le service cloud lui-même.

Notes

En termes généraux, l’objectif de la sérialisation est de transmettre un objet dans ou hors d’une application. Un exercice de modélisation des menaces marque presque toujours ce type de transfert de données comme franchissant une limite d’approbation.

Voir aussi