Il a publié sur son blog la manière dont la librairie JNA (Java Native Access), qui facilite l’interaction avec la mémoire et l’exécution du code natif, pourrait être utilisée pour injecter du code à distance.
Grâce à cette bibliothèque, la réservation d’un espace mémoire est rendue possible par l’objet Memory.
La structure décrit six types de situations qui semblent présenter des forteresses de prime abord, mais qui peuvent être contournées :
- l’utilisation d’une session graphique déportée type Citrix ou autre ;
- l’ensemble des applicatifs installés sur la machine est à jour ;
- un antivirus dont les définitions sont à jour est installé et actif ;
- l’accès à internet est protégé par des équipements de type WAF, proxy HTTP authentifiant ;
- un système de SRP (Software Restriction Policy) ne permet d’exécuter qu’une application : un navigateur internet ainsi que ses plugins (flash, java) ;
- ce même système ne permet l’écriture des données qu’aux seuls endroits où le navigateur a la nécessité d’écrire des fichiers temporaires (cookie, cache, etc.).
Elle va même jusqu’à fournir le code source et les lignes de commande pour perpétrer une telle action. En quelques lignes de code, un individu peut efficacement et simplement envoyer à distance une charge malveillante de type « meterpreter » de Metasploit en contournant l’ensemble de ces restrictions.
Malgré les efforts d’Oracle pour améliorer la sécurité du langage, le plugin Java reste vulnérable à de nombreux types d’attaques. Les restrictions introduites par la société, notamment le blocage des applets non signés, permettent néanmoins de limiter les risques. Pour ceux qui n’utilisent pas le plugin, les chercheurs conseillent tout simplement de le supprimer.
Source : blog Lexsi
Et vous ?
Que pensez-vous du geste de Lexsi ?
Désactiver la JNA serait-il une solution aux problèmes causés par les failles de sécurité ?