Misc 98

IoT Corner

p. 06  PiRanhaLysis : rendre l'analyse IoT facile et reproductible

Malware Corner

p. 12  Émulation du bootloader de NotPetya avec Miasm

Forensic Corner

p. 22  Votre SIEM à portée de main avec ElasticSearcb/ElastAlert

Dossier

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

Code 

p. 67  Comprendre le fonctionnement des CORS

Cryptographie

p. 72  Attaques par canaux auxiliaires sur AES – Partie 2

Organisation & juridique

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/