ARM & Sécurité

Si beaucoup de technologies que nous utilisions il y a vingt ans sont toujours présentes, la typologie des menaces de même que leur perception par les utilisateurs et le grand public se sont profondément transformées.

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 !

Ces dernières années, on a pu observer une évolution croissante des environnements conteneurisés et notamment de l’usage de Docker. Les arguments mis en avant lors de son utilisation sont multiples : scalabilité, flexibilité, adaptabilité, gestion des ressources... En tant que consultants sécurité, nous sommes donc de plus en plus confrontés à cet outil. Au travers de cet article, nous souhaitons partager notre expérience et démystifier ce que nous entendons bien trop régulièrement chez les DevOps, à savoir que Docker est sécurisé par défaut.

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

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.

Smartphones, IoT, IVI... : découvrez comment les futures générations de processeurs ARM permettront de durcir vos programmes contre les corruptions mémoires.

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.

Le fuzzing guidé par la couverture de code tel qu’AFL est une technique efficace pour la recherche de vulnérabilités. Cet article va présenter un nouveau type de fuzzing, le fuzzing dirigé, et ses applications pratiques au niveau du source et du binaire.

Les fonctions Serverless sont aujourd’hui une nouvelle tendance du cloud. Rapides et peu onéreuses, elles ne requièrent aucun entretien des infrastructures sous-jacentes par le client. Cependant, ce service entraîne un changement de modèle d’architecture, rendant les solutions de protection classiques inadaptées. Ce papier sensibilise aux nouvelles menaces du cloud et suggère différentes règles à suivre pour s’en prémunir.

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