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.

Soixante-dix pour cent des attaques viennent de l'intérieur de l'entreprise. L'affaire Kerviel en a fait une démonstration flagrante. Les projets JavaEE sont très présents dans les entreprises. Ils sont généralement développés par des sociétés de services ou des prestataires. Cela représente beaucoup de monde pouvant potentiellement avoir un comportement indélicat. Aucun audit n'est effectué pour vérifier qu'un développeur malveillant ou qui subit des pressions n'a pas laissé une porte dérobée invisible dans le code. Nous nous plaçons dans la peau d'un développeur Java pour étudier les différentes techniques d'ajout d’une porte dérobée à une application JavaEE, sans que cela ne soit visible par les autres développeurs du projet.

Dans les précédents articles à propos des clés USB, il a été montré que, grâce à quelques règles udev et quelques scripts savamment écrits, il était possible de recopier le contenu d'une clé (même effacé) et même le contenu du disque dur de la victime, en jouant avec les fichiers autorun. Tout ceci sans aucune manipulation suspecte de l'attaquant, simplement grâce à l'automatisation des scripts et la crédulité de la victime.Dans cet article, nous allons présenter une catégorie plus récente d'attaques concernant des clés USB, qui porte cette fois-ci sur un certain type de clés, disponibles à prix modique au grand public.Mots-clés : USB / U3 / autorun / CDFS / proof-of-concept