8,72 € TTC
p. 06 PiRanhaLysis : rendre l'analyse IoT facile et reproductible
p. 12 Émulation du bootloader de NotPetya avec Miasm
p. 22 Votre SIEM à portée de main avec ElasticSearcb/ElastAlert
p. 30 Préambule
p. 31 Tour d'horizon de l'authentification forte (MFA)
p. 39 Web authentification / Password reset : REX de Bug Bounty
p. 48 « WebAuthn » : enfin la fin des mots de passe ?
p. 56 OpenID Connect : présentation du protocole et étude de l'attaque Broken End-User Authentication
p. 67 Comprendre le fonctionnement des CORS
p. 72 Attaques par canaux auxiliaires sur AES – Partie 2
p. 78 La surface d'attaque : son utilité, ses limites, ses nouveaux défis
La sécurité est un succès (et un processus d’amélioration continu)
Pour rebondir sur la note d'optimisme de bon aloi de Pappy à propos des 15 ans du SSTIC [1], ne nous enfermons pas dans la posture du berger criant « au loup » en matière de sécurité des systèmes d’information, car globalement le niveau de protection des systèmes d’information n’a jamais été aussi élevé et il est en constante progression.
Au risque de passer pour un vieux con, quand je vois les jeunes s’écrier « la sécurité est un échec » parce que leur brosse à dents se connecte sur un serveur dont le certificat n’est pas certifié A+ chez SSL Lab, je mesure le chemin parcouru ces quinze dernières années. Vous n’imaginiez pas à quel point le niveau de sécurité aujourd’hui semblerait stratosphérique pour un informaticien du début des années 2000 faisant un saut de 15 ans dans le futur.
Imaginez qu’à cette époque pas si lointaine, toutes les applications clients serveurs développées en Delphi ou Access, les bouts de fichiers Excel, se retrouvaient du jour au lendemain propulsées sur le Web, écrites sur un coin de table par un collègue qui avait acheté « PHP pour les nuls » quelques jours plus tôt. Certaines tenaient sans se faire p0wner quelques semaines grâce à magic_quotes_gpc laissé activé par défaut… jusqu’à ce que quelqu’un se plaigne de la présence d'antislash sur les messages déposés dans le livre d’or.
Imaginez qu’il était possible de faire un TP sur les stack-overflows à des étudiants disposant de rudiments d’assembleurs. Pas besoin de se compliquer la vie avec l’adresse aléatoire de la stack, le bit NX ou les canaris. Un coup de gdb pour la stack, un shellcode trouvé sur le net et en trois heures tout le monde réussissait son remote exec.
Côté réseau, c’était encore l'opulence des adresses IPv4 et tout le monde se fichait des problèmes de vie privée. Il était possible dans beaucoup de structures d’être en adressage public complet afin de ne pas trop avoir à se compliquer la vie avec des vues DNS et du NAT. Les utilisateurs naviguaient l’esprit léger pendant leur pause méridienne sur les TGP (Thumbnail Gallery Post, un peu l’ancêtre de Pornhub) depuis leur IP fixe dont le reverse DNS contenait parfois, accolé au nom de domaine de l’entreprise, leur identifiant. La fonctionnalité « navigation privée » n’existait pas encore et dans l’imaginaire collectif, comme à Vegas, ce qui se passait sur Internet restait (et pour cause !) sur Internet.
Ajoutons à cela aucun chiffrement, des outils d'administration se basant uniquement sur l’adresse IP de l'administrateur (les fameux r* tellement plus pratiques que telnet, cet outil pour paranos de la sécurité) et un réseau bien à plat avec tout le monde dans un gros LAN, serveurs compris. Rappelons-nous qu’en 2000, 802.1q c’était un peu comme Shortest Path Bridge aujourd’hui, tout le monde en avait entendu parler, mais seuls les plus barbus d’entre nous y avaient goûté. Et pour faire bonne figure quelques ACL stateless sur le routeur WAN pour éviter que le port 139 soit accessible sur Internet et que le patrimoine informationnel, les mp3 sur le PC du secrétariat, soit dispersé à tous les vents.
Pour compléter, côté système, nous étions en pleine mode des pizza box (serveurs 1U) rackés à la chaîne sur lesquels tournaient dans le DC moyen au moins un exemplaire de toutes les distributions Linux de l’époque (il fallait bien les comparer) avec un niveau de mise à jour très variable. La virtualisation n’existait pas, encore moins les conteneurs, et faute d’Ansible les mises à jour, quand il y en avait, se faisaient en Expect, merveilleuse extension du non moins magnifique langage TCL. Un dialecte propre à chaque équipe système s’était aussi constitué pour la gestion du versionning des fichiers de configuration tels que « .backup », « .sos », « .derniereversionquifonctionne », « .anesurtoutpaseffacer ».
Alors je veux bien entendre que l’on croise encore des horreurs et qu’il reste des anachronismes qui nous font bondir. Qu’en 2018 il est désespérant que des langages aussi complexes et dangereux que le C soient toujours autant utilisés sur des briques critiques. Côté réseau, qu’Ethernet, ce protocole bête à manger du foin, et sur lequel il faut empiler des briques à n’en plus finir pour combler les lacunes de sécurité (l’ « arp cache poisoning » putain !) soit toujours là et qu’aucun protocole ne semble pouvoir lui succéder à moyen terme. Ou encore que des décideurs soient prompts à déranger leurs équipes en plein week-end pour leur faire patcher immédiatement une vulnérabilité médiatisée sur WPA, mais ne voient aucun problème à se ruer sur le premier portail captif disponible dans les hôtels et aéroports de tous pays.
Alors globalement, dans notre mission qui est la réduction de risque au travers de mesures techniques, il n’y a pas de quoi rougir. Des SI se font toujours pirater, et ce sera certainement encore très longtemps le cas, mais imaginons un instant le carnage que serait le cyber espace avec les besoins de sécurité actuels (à peu près tout est informatisé) ainsi que le niveau des menaces si nous étions restés au niveau de sécurité des années 2000 ?
Cédric Foll
[1] https://www.linkedin.com/pulse/diff-u-sstic2003-sstic2018-pourquoi-les-vieux-sont-encore-raynal/
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.
Vers la fin des mots de passe ? Ces dernières années ont été riches concernant les solutions d’authentification, avec notamment le développement des fameux « facteurs » supplémentaires...
Nous présentons dans cet article une étude préalable de l’outil ElastAlert en tant que SIEM dans un environnement avec stockage d’événements dans ElasticSearch. Nous aborderons les principes de fonctionnement et les principales fonctionnalités rendues par l’outil ainsi qu’un retour d’expérience de son utilisation opérationnelle.
Introduits afin d'assouplir la Same Origin Policy pour permettre au Web 2.0 de donner sa pleine mesure, les Cross Origin Ressource Sharing (CORS) souffrent de spécifications pour le moins absconses et d'une dissymétrie d'implémentation particulièrement dommageable à leur bonne mise en œuvre. En conséquence, leur activation côté serveur conduit très souvent à la création de vulnérabilités exploitables susceptibles de faire le bonheur du pentesteur.