Compromission du serveur applicatif Tomcat via l'API JMX

Magazine
Marque
MISC
Numéro
73
Mois de parution
mai 2014
Domaines


Résumé
L'API JMX fournie par JAVA permet aux administrateurs de monitorer et administrer l'environnement d’exécution de la machine virtuelle JAVA. Cette API peut être activée dans le contexte du serveur applicatif Tomcat. L'API JMX offre à un auditeur de nouvelles possibilités de compromission du serveur d'application. Au cours de cet article, nous présenterons différents exemples de compromission du serveur Tomcat en utilisant l'API JMX.

1. L'API JMX et son fonctionnement

L'API JMX (Java Management Extension) se compose de plusieurs couches interagissant entre elles et permettant aux utilisateurs d'accéder aux ressources JAVA (processus, services, périphériques, éléments de configuration...).

1.2.1 Couche de services distribués

La couche de services distribués présente l'ensemble des canaux de communications permettant aux utilisateurs d'interagir avec le serveur de Mbean. Les canaux utilisables par les clients se divisent en 2 catégories, ceux interagissant avec des connecteurs et ceux interagissant avec des adaptateurs. Ces derniers ont pour objectif de convertir les requêtes reçues dans un format compréhensible par le serveur de Mbeans. [AGENTS]

Les clients permettant d'interroger le serveur de Mbeans peuvent ainsi utiliser des canaux de communication tels que RMI (Java Remote Method Invocation),IIOP (Internet Inter-ORB Protocol), SOAP (Simple Object Access Protocol) ou bien même HTTP (au travers de...

Cet article est réservé aux abonnés. Il vous reste 95% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Les taxonomies se cachent pour ne pas mourir

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

« Attention, nouveau virus ! » Nombreux sont les articles à nous alerter régulièrement, par cette métonymie, sur l’émergence d’un nouveau malware. Pourtant, le terme de virus a-t-il encore un sens aujourd’hui ? Wannacry était-il un ver, ou un ransomware ? NotPetya, un wiper, ou bien un ver ? Et plus encore, au-delà de l’utilisation de termes et expressions se pose la question de la nécessaire catégorisation des incidents de cybersécurité ; pourquoi, comment, à quelles fins ? Essai (critique) de réponse.

Les difficultés du désassemblage sur ARM

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

Cet article aborde les problèmes spécifiques à l’architecture ARM qui se posent lorsqu’on désassemble un exécutable, c’est-à-dire lorsqu’on l’analyse statiquement pour en produire une représentation en langage assembleur. En effet, les particularités de l’architecture ARM peuvent rendre le désassemblage – déjà habituellement compliqué – particulièrement ardu.

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.