Des chercheurs d’universités françaises, allemandes, luxembourgeoises et suédoises se sont penchés en profondeur sur les vulnérabilités connues de la désérialisation Java et ont maintenant refait surface avec leurs découvertes. En bref, ils ont attiré l’attention sur la manière dont les bibliothèques peuvent introduire accidentellement de graves failles de sécurité.
La sérialisation est utilisée pour convertir un objet de données en mémoire en une série d’octets pour le stockage ou la transmission. Désérialisation inverse ce processus en transformant un flux de données en un objet en mémoire.
En Java, ceci est implémenté en utilisant le java.io.Serializable interface. Mais la désérialisation n’est pas nécessairement sûre car la reconstruction de l’objet à partir de son flux d’octets n’implique pas le constructeur – le code de plan qui construit initialement l’objet pour avoir toutes les fonctions et méthodes qu’il devrait avoir. Si le constructeur avait des vérifications de validation, celles-ci ne sont pas exécutées. Ainsi, il est possible que la désérialisation crée des objets non valides ou dont les données ont été modifiées.
Les bogues de désérialisation Java peuvent être assez graves.
Par exemple, Log4Shell, la faille d’exécution de code à distance affectant la bibliothèque de journalisation Apache Log4j a été rendue possible par la désérialisation Java. En novembre 2016, une attaque de rançongiciel compromis plus de deux mille ordinateurs gérés par la San Francisco Municipal Transportation Agency (SFMTA) via un Vulnérabilité de désérialisation des collections Apache Commons.
De plus, le point d’entrée du piratage d’Equifax en 2017 qui a entraîné le vol de données personnelles de 147,7 millions d’Américains provenait d’une désérialisation de Java. défaut dans Apache Struts. Et en juillet dernier, il y avait un Atlassian Vulnérabilité Jira dans lequel un attaquant capable de se connecter à un service réseau Ehcache RMI “pourrait exécuter du code arbitraire de son choix dans Jira via la désérialisation en raison d’une vulnérabilité d’authentification manquante”.
Dans un document intitulé “An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities”, les informaticiens Imen Sayar (Université de Toulouse), Alexandre Bartel (Université d’Umeå), Eric Bodden (Université de Paderborn) et Yves Le Traon (Université du Luxembourg) décrivent comment ils ont examiné les bibliothèques de logiciels ciblées par 19 publiquement connu Exploits RCE de désérialisation Java pour comprendre comment les gadgets – des constructions de code exploitables – sont introduits dans les bibliothèques Java et comment les tentatives de se débarrasser de ces gadgets échouent parfois.
Bien que la sérialisation et la désérialisation soient utiles, observent les auteurs, ce processus présente un risque si les données désérialisées proviennent d’une source non fiable. “En effet, un attaquant pourrait créer un flux d’octets qui, une fois désérialisé sur l’hôte distant, pourrait contrôler le flux d’exécution du code Java en enchaînant des séquences de code Java appelées gadgets”, expliquent-ils.
Le terme gadget a quelques significations spécifiques dans le monde de l’exploitation des vulnérabilités. Pour leur article, les auteurs utilisent le mot pour désigner une méthode Java potentiellement exploitable accessible à l’attaquant. Une bibliothèque peut contenir des gadgets qui peuvent être chaînés, afin qu’ils puissent fonctionner dans une séquence.
Tirer parti d’une vulnérabilité de désérialisation peut impliquer une chaîne d’attaque compliquée ou cela peut être aussi simple que faire une requête GET sur un réseau.
Notre conclusion principale est que la modification d’un détail d’apparence innocente dans une classe – comme le rendre public – peut déjà introduire un gadget
Les chercheurs ont examiné 19 exploits pour les vulnérabilités dans 14 bibliothèques (certains avec plusieurs versions): beanshell, clojure, commons-beanutils, commons-collections, groovy, rome, js-rhino, spring-beans, spring-core, spring-aop, click-nodeps, javax.servlet, vaadin-serveret vaadin-shared.
“Lors de l’analyse des 19 exploits RCE, nous avons identifié plusieurs manières d’introduire un gadget dans une bibliothèque : ajouter des classes, des méthodes et des interfaces, ou modifier la signature des méthodes”, indique le document. “Notre principale conclusion est que la modification d’un détail d’apparence innocente dans une classe – comme le rendre public – peut déjà introduire un gadget.”
Étant donné que les gadgets sont nécessaires pour créer un exploit de désérialisation, la modification du code qui insère de nouveaux gadgets n’est clairement pas idéale.
Parmi les bibliothèques et leurs variantes testées, 14 ont été corrigées pour supprimer les gadgets potentiels. Cela peut se faire de différentes manières, telles que la suppression java.io.Serializable de la liste des interfaces d’une classe vulnérable, supprimer la classe vulnérable dans son intégralité ou introduire un contrôle de sécurité, entre autres techniques.
Six des bibliothèques évaluées (commons-beanutils1.9.4, rome1.0, spring-beans-3.0.0.RELEASE, click-nodeps-2.3.0-RC1, javax-servlet-api-4.0.1et vaadin-shared-7.4.0.beta1) sont répertoriés comme non corrigés. Donc, si vos applications incluent l’un d’entre eux, vous voudrez peut-être réfléchir à la manière de résoudre ce problème. Cependant, attendre un correctif n’est peut-être pas la meilleure option.
“Lors de l’étude des correctifs de ces bibliothèques, nous avons observé que le temps nécessaire pour supprimer les gadgets varie entre plusieurs mois et près de 12 ans, avec une moyenne de près de six ans”, concluent les chercheurs. “Il apparaît donc que les vulnérabilités de désérialisation n’attirent pas encore l’attention des praticiens qu’elles devraient réellement mériter.” ®
