Découvrez un cas d’attaque
À la fin de l'année 2021, le monde de la cybersécurité a été secoué par la découverte d'une vulnérabilité majeure dans Log4j, une bibliothèque logicielle Open Source développée par l'Apache Software Foundation.
Utilisée universellement dans les applications Java, de la recherche aux services bancaires, Log4j facilite la journalisation des événements des applications. La faille découverte permettait l'exécution de code à distance (Remote Code Execution, RCE), posant un risque considérable de sécurité.
Selon une analyse de CheckPoint, l'impact global de cette faille était vertigineux, avec près de 50 % des entreprises mondiales potentiellement affectées, et en France, plus d'une entreprise sur deux était exposée. Dans les 72 heures suivant sa révélation, plus de 800 000 tentatives d'exploitation ont été enregistrées.
Un autre cas notable est celui du plug-in WordPress "X-WP-SPAM-SHIELD-PRO". Sous couvert d'améliorer la sécurité des sites WordPress, ce plug-in dissimulait en fait une backdoor (ou porte dérobée en français) permettant un accès non autorisé aux données du serveur ; y compris les informations confidentielles de l'entreprise. Il pouvait même accroître les privilèges d'un utilisateur jusqu'au niveau administrateur.
Identifiez l’attaque par désérialisation non sécurisée
La désérialisation non sécurisée est une vulnérabilité qui se produit lorsque des données non fiables sont utilisées pour abuser de la logique d'une application, causer un déni de service (DoS, Deny of Service), ou même exécuter du code arbitraire.
Je ne comprends pas très bien, peux-tu détailler cette vulnérabilité ?
Pour comprendre la désérialisation non sécurisée, il faut d’abord comprendre ce qu’est la sérialisation.
Pour cet exemple, nous allons prendre un objet, comme un nom d'utilisateur et un mot de passe, et le mettre dans la base de données. Pour pouvoir être stocké, l'objet devra être converti en flux d'octets pour être transporté à travers le réseau afin d'accéder à la base de données. C'est ce qu'on appelle la sérialisation. Lorsqu'il y a un appel pour ce même objet dans la base de données, il doit être désérialisé (conversion du flux d'octets en objet) avant son utilisation.
Ce processus de sérialisation/désérialisation des objets ne se produit pas seulement avec les bases de données. Un objet peut changer son état en un flux d'octets lorsqu'il est stocké dans un fichier, d'ordinateur à ordinateur ou en se déplaçant sur le réseau.
Ces objets peuvent être des cookies, des flux vocaux, des jetons ou des fichiers cache, par exemple.
Java dispose de bibliothèques dédiées à la sérialisation et à la désérialisation. YAML dispose de bibliothèques dédiées à la sérialisation pour différents langages de programmation.
Par exemple :
Un cookie avec un identifiant de session et des informations d'identification est envoyé par le navigateur au serveur web exécutant Java.
Ce cookie est sérialisé avec un constructeur. À partir de là, le code malveillant peut être injecté par un attaquant au moment de la sérialisation.
Le cookie est désérialisé sans constructeur.
Le constructeur est créé après la création de l'objet, sans vérification ni validation des entrées pendant le processus de désérialisation.
Du code malicieux peut être exécuté sur le serveur.
Mettez en place des vérifications concernant vos dépendances
Il est important que vous effectuez systématiquement des vérifications sur les bibliothèques ou les plug-ins avant la mise en place dans le code ou dans l’application.
Ces vérifications peuvent sembler évidentes, mais il ne faut pas passer à côté pour autant :
Date de la dernière mise à jour : Il n’est pas impossible qu’un plug-in, ou une bibliothèque, ait son développement abandonné, laissant des vulnérabilités potentiellement présentes.
Qui fournit l’élément ? Qui en est l’auteur ? Est-ce une entreprise reconnue, un indépendant qui au contraire n’est pas connu pour ses contributions ? L’auteur a-t-il une activité régulière autour de son code ?
La bibliothèque ou le plug-in est-il nécessaire ? Il serait dommage d’augmenter le risque de vulnérabilité en installant une bibliothèque ou un plug-in alors que des mécanismes gérant la même fonctionnalité sont déjà présents, dans un framework utilisé ou via un autre composant déjà en place.
Le code source est-il disponible ? Y a-t-il une possibilité d’analyser le code pour être sûr de ne pas créer d’effet de bord ?
À quelles ressources le composant a-t-il accès ? Les permissions demandées sont-elles cohérentes avec la fonction ?
En plus de vérifications, lors du développement il est très fortement conseillé que vous gardiezà jour ces bibliothèques ou plug-ins. La dette technique et les risques de sécurité qui en découlent sont réels !
La gestion du risque devrait obligatoirement tenir compte des composants tierces parties. En mettant de côté ces points de vigilance, et en laissant les fournisseurs assurer la sécurité sans prendre le soin de contrôler, vous laissez la possibilité à des personnes malveillantes d’exploiter des failles existantes.
La dépendance ou la tierce partie n’est cependant pas uniquement constituée de bibliothèques de développement. Un prestataire ou un sous-traitant doit faire l’objet des mêmes règles en matière de gestion du risque qu’une bibliothèque.
Enfin, du point de vue du RGPD (Règlement général sur la protection des données), et donc de la protection des données, l’entreprise fournissant ou utilisant une application a pour obligation de sécuriser les données des utilisateurs finaux. Pour vous aider, la CNIL a créé un guide à l’usage du développeur disponible librement.
En résumé
La désérialisation non sécurisée est la capacité d'un attaquant à changer l'état du code pendant sa conversion.
La désérialisation non sécurisée peut être évitée en créant des contrôles sur l'état du code.
Le risque ne vient pas toujours de votre code, mais potentiellement de celui d’une bibliothèque externe.
Garder à jour une bibliothèque ou une dépendance est essentiel pour réduire la surface d’attaque.
Dans le prochain chapitre, vous allez comprendre comment rendre possible la détection d’attaques et les investigations à l’aide des journaux et des alertes.
