La sécurité de Java en question !

« Tout est vrai. Rien n'est vrai. C'est un roman ». (Serge Bramly) - À l'instar de ceux qui opèrent dans les rues, les groupes criminels qui, comme les pédophiles néo-nazis [1] et autres psychopathes racistes [2], sont passés à l'ère du 2.0 forment un écosystème complexe. C'est ce que nous nous proposons d'effleurer dans cet article basé sur des faits réels. Afin de présenter au lecteur un ensemble cohérent et afin de ne point heurter certains protagonistes, des noms ont été modifiés ou masqués et des faits appartenant à des « affaires » différentes ont été réunis en une même histoire. Toute ressemblance avec des personnes physiques ou morales existant ou ayant brutalement cessé d'exister ne serait donc que pure coïncidence. Ou pas.

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.

Sur les téléphones mobiles, le modèle de sécurité de Java est modifié pour tenir compte des spécificités des applications mobiles. Ce modèle présente des caractéristiques intéressantes, mais il pose des problèmes importants aux utilisateurs et aux développeurs.

Les tests d'intrusion sur applications Web nous amènent régulièrement à rencontrer les plateformes J2EE qui les hébergent. Dans certaines conditions, ces serveurs d’application peuvent être très intéressants pour un attaquant. Nous verrons pourquoi à travers cet article.

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.

Cet article présente les mécanismes de sécurité spécifiés dans les standards IEEE 802.16 qui sont plus connus sous la dénomination « WiMAX ». Deux types de WiMAX existent : le « fixe » et le « mobile » qui se positionnent sur des usages différents. Ces standards WiMAX présentent des particularités sur les mécanismes de sécurité que nous détaillerons tout au long de cet article grâce à une analyse comparative. Enfin, nous élargirons le débat sur les problématiques sécurité dans le déploiement de ces nouvelles technologies radioélectriques.

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.

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

Combien de temps pourrait résister votre machine face à un attaquant qui a un accès physique à celle-ci ? Le problème est d'autant plus d'actualité que les ordinateurs deviennent de plus en plus mobiles et nous suivent quasiment dans tous nos déplacements. La possibilité d'un vol ou même simplement d'un accès ponctuel est grande. Quant aux informations qu'ils contiennent, surtout lorsqu'il s'agit de nos ordinateurs de travail, leur criticité n'est plus à démontrer.Sur la plupart des machines, démarrer via un token USB, puis monter les disques chiffrés offre une sécurité relativement raisonnable. Encore faut-il avoir suffisamment confiance en l'utilisateur pour qu'il n'installe pas (même par inadvertance) de malwares (et particulièrement des bootkits1), faisant ainsi entrer le loup dans la bergerie.Les normes du « Trusted Computing Group » (TCG) introduisent la notion d'ordinateur de confiance, jetant les bases d'un ensemble de mesures matérielles et logicielles visant à protéger les données de votre machine contre des attaques non seulement logiques mais aussi physiques, allant même jusqu'à se défendre contre l'utilisateur lui-même lorsque celui-ci risque d'en compromettre la sécurité.Tout repose sur des puces spécifiques appelées « Trusted Platform Modules » (TPM) directement installées sur la carte-mère de l'ordinateur. Elles ont été normalisées par le TCG, puis mises en production par un certain nombre de fondeurs (ATMEL, Broadcom, Infineon, Intel, NSC...) et proposent un ensemble de services sur lequel on peut espérer construire une sécurité robuste.Cet article traite des puces TPM [3,8], de leurs capacités et de quelques logiciels de base qui permettent d'en tester le fonctionnement.