Compromission du serveur applicatif Tomcat via l'API JMX

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

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.

Pouvoir retracer le cheminement d’un attaquant est une chose essentielle, mais sur quel artefact peut-on construire notre analyse ?

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.

Cet article a pour ambition de vous présenter le cycle de vie d’un certificat de la demande jusqu’à la révocation. Cette démonstration mettra en lumière les mécanismes ainsi que les flux menant à l’obtention d’un certificat pour vos machines.