Même intervenant que sur la meilleure session sécurité de l’an passé, et celle-ci est encore de très haut niveau. Je n’ai pas noté son nom, car je suis arrivé un peu à la bourre, mais vous pourrez le retrouver facilement sur le site des Tech Days si cela vous intéresse. Le nom de l’article reprend mot pour mot le titre de la session dont je fais le compte-rendu rapide.
APT veut dire Advanced Persistant Threat. En gros, c’est pour désigner un type d’attaque informatique qui fait intervenir plusieurs vecteurs, et dans laquelle l’attaquant parvient à prendre le contrôle durable d’une infrastructure, en posant par exemple des rootkits sur plusieurs machines, de façon à réinfecter une machine dès qu’elle est nettoyée, ou en planquant des services malveillants de façon qu’ils soient plus difficilement détectables, l’idéal étant bien sûr que la victime ne se rende carrément pas compte qu’elle est infectée, ni même qu’elle a été attaquée. Au passage, dans le milieu de la sécurité, la blague a la mode est “les deux types d’entreprise sont celles qui ont été attaquées, et celles qui ne le savent pas”.
Intéressant concept de watering hole : le trou d’eau autour duquel se rassemblent les bêtes pour s’abreuver est un lieu particulier de vulnérabilité, et il a l’avantage de les rassembler toutes en un seul endroit. Il semble que des sites comme http://www.lequipe.fr soient des points d’eau pour de nombreuses entreprises… Du coup, si ce site est compromis par une page vérolée, cela pourrait d’après l’intervenant provoquer un crash du CAC 40 
.
A la question “pourquoi y a-t-il autant de failles”, la réponse de l’intervenant est toute empreinte de bon sens : “parce que tout le monde développe en Java au lieu d’en ADA”. C’est sûr qu’avec de mauvais outils (du point de vue de la sécurité), un développeur ne peut pas faire tout le temps des miracles. Plutôt que de compter sur lui pour ne jamais oublier de valider la donnée, toujours canoniser les syntaxes, etc., ça serait plus simple avec des langages où la sécurité était dès le début partie prenante…
Etonnamment, cette année, on a entendu parler plusieurs fois d’attaques de type Pass The Hash, alors que ce genre d’attaque existe depuis bien longtemps. Pour expliquer rapidement de quoi il s’agit, lorsqu’on tape un mot de passe dans Windows, il est transformé en un condensat, plus souvent appelé par son nom anglais “hash” (ce qui rend quand même le nom de l’attaque plus marrant). Ceci permet de ne pas avoir le mot de passe en clair, mais simplement une chaîne qui ne peut pas être re-transformée en le mot de passe original, mais qui pourra être validée par Windows comme celle qui correspond au hash du vrai mot de passe, ou pas et dans ce cas-là, pas d’accès.
Le souci est qu’avec LM ou NTLM, les méthodes d’authentification préhistoriques de Windows, il suffit d’envoyer le hash pour s’identifier correctement. Il ne s’agit pas d’un challenge-response ou d’une méthode évoluée comme Kerberos. Or, comme il est difficile de forcer l’utilisation de Kerberos dans tous les clients Windows, on se retrouve à se trimballer encore ce genre de protocole, qui, si un attaquant trouve le hash en mémoire, est éminemment vulnérable.
Les smartcards ne sont pas nécessairement la panacée en termes de sécurité. Elles fonctionnent avec des mots de passe aléatoires, mais utilisant toujours le hash LM qui est stocké en mémoire et sensible aux mêmes attaques. Il faut donc empêcher l’accès des attaquants à la machine de toute façon, car tant que la session n’est pas fermée, il peut se loguer sur une autre connexion, et analyser la mémoire pour le retrouver et l’exploiter très simplement avec des outils trouvables facilement sur internet.
Il est à noter d’ailleurs que le mot de passe Windows est en mémoire en clair, ne serait-ce que pour le SSO, le RDP, et plus particulièrement le HTTPBasic qui en ont besoin. Plus particulièrement, parce que pour les premiers besoins qui sont Microsoft, on pourrait imaginer des moyens qui ne le rendraient pas nécessaire. Mais pour HTTPBasic, on est coincé : l’envoi du mot de passe se fait par un simple encodage Base64 du user suivi du mot de passe, donc il FAUT l’avoir quelque part. En pratique, il n’est pas vraiment en clair, et il faut décrypter la mémoire, mais si on est sur la session, on a la clé !
L’outil Mimikatz a des drivers signés Microsoft, ce qui lui permet de retrouver ces mots de passe, et ne pas être rejeté par la sécurité interne de Windows. Pour ces problèmes de “vrais faux certificats”, voir le rapport d’expertise sur intrusion chez Diginotar sur http://www.rijksoverheid.nl. Dans le même genre, l’outil Cachedump permet de retrouver les mots de passe ActiveDirectory stockés pour l’autorisation de login hors connexion.
Simple Assembly Explorer, Xenocode : outils à tester…
Pour empêcher la messagerie de bloquer un ZIP contenant un EXE, on peut lui mettre un mot de passe, la plupart décident alors qu’il vaut mieux le laisser passer malgré qu’elle ne puisse pas analyser le contenu. Office utilise par défaut VelvetSweatshop comme mot de passe…
Explorer est en général largement autorisé dans les pare-feu, et constitue donc une cible idéale pour une prise de contrôle.
Certains sites web sont suffisamment astucieux pour ne montrer des pages vérolées que si le client qui les accèdent est celui qu’elles veulent infecter, tout en présentant à tous les autres une version saine. Le traitement peut se faire par exemple de façon à ne montrer un code menaçant que lorsqu’on les appelle depuis un domaine précis, de façon a réduire la détection. Il faut d’ailleurs savoir qu’il n’est même plus nécessaire d’utiliser des cookies pour pister un utilisateur : les user agent sont tellement divers et variés qu’en les utilisant comme complément de l’adresse IP et de la résolution d’écran, on a une identification individuelle quasiment aussi efficace.
Une technique utilisée par certains antivirus pour contourner les analyses d’accès aux API sensibles consiste à ne pas appeler l’adresse mémoire de la fonction directement, mais l’adresse + 5. En effet, toutes les fonctions Windows commencent par un MOV EDI qui sert au patch dynamique. En pratique, ceci est très rarement utilisé par Microsoft, mais maintenant que c’est connu, les antivirus vont ajuster le tir.
Quand un malware utilise les commentaires d’un bitmap pour envoyer les commandes, le proxy ne le voit pas, et en plus purge les logs toutes les heures, perdant ainsi l’attaque !
Au passage, d’ailleurs, le conférencier explique que tous les moyens de détection basés sur les heures de modification des fichiers sont inefficaces de manière inhérente, car les pirates utilisent désormais souvent l’API SetFileTime pour faire croire que les fichiers qu’ils mettent en place ont été installés en même temps que l’OS.
L’Alternate Data Stream de NTFS est également oublié souvent par les détecteurs d’attaques. Pour info, il s’agit des $$DATA qu’on voit parfois apparaître dans les noms de fichiers. Un fichier peut en effet, en NTFS, embarquer plusieurs canaux d’information, même si en pratique, on n’en utilise quasiment jamais qu’un seul, à savoir celui correspondant au contenu.
Un virus peut contourner l’antivirus qui fonctionne par émulation en s’exécutant sur une socket, car les antivirus n’émulent pas encore le réseau, même local.
Et pour achever de nous faire rendre compte que dans le domaine de la sécurité, le jeu du chat et de la souris est bien parti pour durer encore quelques décennies au moins, une dernière information sur le fait que Nortel est reste piraté pendant 10 ans, car ça coutait trop cher de nettoyer tout le réseau par rapport aux dégâts effectifs causés par le pirate, dont ils tentaient de suivre tout de même l’activité, mais sans être capable de le virer de manière définitive.
Bref, excellente session où on apprend plein de choses en termes de sécurité. Pour les personnes qui ont besoin d’être au courant, je la recommande chaudement. Elle se passe normalement à chaque TechDays.
