En fin d’année 2021, un véritable tsunami voit le jour. Une faille est trouvée dans la bibliothèque logicielle Open Source faisant partie des projets de l’Apache Software Foundation et qui permet la gestion de traces ou de logs d’application. Cette bibliothèque, c’est Log4j. Cette bibliothèque est l’une des plus utilisées dans les logiciels écrits en Java, aussi bien dans le domaine de la recherche que dans les applications bancaires par exemple. Cette bibliothèque est là pour simplifier la journalisation des événements d’une application.
La faille de sécurité de Log4j permettrait de générer un risque d'exécution de code arbitraire, ou Remote Code Execution (RCE), très facilement. Une estimation faite par la société CheckPoint montre un impact mondial extrêmement élevé. Le taux de sociétés potentiellement touchées par cette faille de sécurité est proche de 50 % dans le monde et plus d’une entreprise sur deux est impactée en France. Plus de 800 000 attaques sont référencées 72 heures après que la faille ait été dévoilée.
Autre exemple, le plug-in pour le CMS WordPress “X-WP-SPAM-SHIELD-PRO”. Derrière une belle présentation pour un plug-in de sécurité pour les sites web sous WordPress se cachait en réalité… une backdoor, ou porte dérobée en français. Cette backdoor permettait un accès aux données du serveur, avec un risque de potentiellement permettre l’accès à des données confidentielles d’entreprise, ou encore l’augmentation de privilège d’un utilisateur, lui permettant un accès administrateur.
Et des exemples comme ça, il y en a beaucoup !
Ces exemples montrent un élément-clé de la protection contre les failles : la nécessité de toujours vérifier les bibliothèques ou les plug-ins/add-ons que vous pourriez être amené à utiliser.
Des vérifications doivent être systématiquement effectuées 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é de garder à 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 être 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. La CNIL a créé un guide à l’usage du développeur disponible librement.
Découvrez la 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.
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.
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.
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 en binaire.
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 notre code, mais potentiellement de celui d’une bibliothèque externe.
Vous avez le devoir de contrôler les services tiers que vous utilisez.
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.
