MISC N°
Numéro
45

La sécurité de Java en question !

Temporalité
Septembre/Octobre 2009
Article mis en avant

Résumé

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.

Dans ce numéro...


« 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.

Magazines précédents

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Body