Porte dérobée dans les serveurs d'applications JavaEE

Magazine
Marque
MISC
Numéro
45
Mois de parution
septembre 2009
Domaines


Résumé

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.


1. Introduction

De nombreux employés d’une entreprise ne sont souvent pas des employés de l’entreprise elle-même mais des sous-traitants. L’entreprise confie donc son patrimoine informatique à des mains étrangères… pour lesquelles il est pratiquement impossible de garantir l’absence de malveillance (quelles qu’en soient les raisons : vengeance, pression, chantage ou autres).

Quelles sont les techniques utilisables par un développeur Java pour cacher un code malicieux ? Pour exécuter un traitement à l'insu de l'application ? Pour s'injecter dans le flux de traitement et ainsi capturer toutes les requêtes HTTP ? À toutes ces questions, nous proposons des réponses.

Deux vidéos de démonstrations sont diffusées. La première est une simple démonstration de la puissance de la porte dérobée, la seconde explique de plus comment se protéger contre ce type de menaces. Elles sont disponibles, ainsi que les outils, ici :



Articles qui pourraient vous intéresser...

Sûreté mémoire : le temps des cerises

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

L’étude et la compréhension des buffer overflow datent de 1972, et leurs premiers usages documentés de 1988 [1]. Près de 50 ans plus tard, où en sommes-nous ? Il nous faut bien admettre que la situation est déprimante : Microsoft et Google reconnaissent chacun ([2], [3]) que près de 2/3 des attaques utilisent à un moment ou un autre une vulnérabilité mémoire. Le ver Morris, qui n’était au départ qu’une preuve de concept, avait quand même coûté la bagatelle de quelques millions de dollars à l’époque… Aujourd’hui, les coûts sont abyssaux : sur le plan financier bien sûr, mais aussi pour nos vies privées, voire nos vies tout court. Face à ce problème, de nombreuses approches sont possibles : analyse statique du code, instrumentation et vérification à l’exécution, langages « sûrs »… Je vous propose d’explorer dans cet article un vieux concept remis au goût du jour, les capabilities, et tout ce qu’elles pourraient nous permettre de faire.

Zerologon pour les (mots de passe) nuls

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

ZeroLogon est LA vulnérabilité de septembre 2020 qui expose de nombreux domaines Windows à une compromission totale via un scénario d’exploitation réaliste et fiable. Mais ce qui donne à Zerologon ses lettres de noblesse c’est qu’elle repose essentiellement sur la mauvaise utilisation d’un algorithme cryptographique permettant de réaliser une attaque à clair choisi particulièrement astucieuse. Zoom sur la vulnérabilité la plus passionnante de la rentrée 2020 !

CrossDev sous Eclipse

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
112
Mois de parution
janvier 2021
Domaines
Résumé

Le développement logiciel nécessite l’utilisation d’outils pour l’écriture, la compilation et le débogage de code. La prise en main de ces outils n’est pas toujours évidente, alors lorsqu’on en maîtrise un, autant l’utiliser dans le maximum de cas. Eclipse permet cela et nous allons le voir dans le cas du développement embarqué.