MISC 45

Depuis l'origine, Java utilise différentes technologies pour protéger les postes utilisateurs contre du code malveillant. Combinées, elles permettent une réelle sécurité, rarement mise en défaut. Regardons les différentes barrières mises en place dans une JVM pour interdire l'utilisation de code malveillant.

Le 3 décembre 2008, Sun a corrigé une faille, découverte et rapportée par Sami Koivu le 1er août 2008. Le rapport de Sun était laconique : « A Security Vulnerability in the Java Runtime Environment (JRE) Related to Deserializing Calendar Objects May Allow Privileges to be Escalated ». Il n'y a là pas grand-chose pour attirer l’œil, si ce n'est l'absence de référence à toute bibliothèque native et à toute corruption mémoire (telle que le classique « buffer overflow ») comme c'est le cas pour la plupart des vulnérabilités Java.

Waledac a fait son apparition sur internet vers la fin de l'année 2008. Ce malware a d'abord attiré l'attention des chercheurs par sa ressemblance avec la célèbre famille « Storm », qui venait alors de s'éteindre. Au-delà de ce probable lien de filiation, Waledac est particulièrement intéressant en lui-même, ne serait-ce que parce que les machines du botnet qu'il constitue communiquent à l'aide d'un protocole peer-to-peer « maison », ou bien encore parce que ses techniques de protection logicielles s'avèrent particulièrement efficaces contre les antivirus. Dans cet article, nous commencerons par établir l'historique de Waledac, puis nous décrirons ses caractéristiques techniques et leur évolution dans le temps. Ensuite, nous étudierons la structure du botnet et l'algorithme de communication utilisé. Pour finir, des attaques avancées contre le botnet seront présentées et nous évoquerons les liens avec la famille « Storm » en conclusion.