Dan Geer l’avait parfaitement démontré dans son étude intitulée « CyberInsecurity: The Cost of Monopoly » : la situation de monopole (de facto) du monde Microsoft est un facteur d’incitation à l’attaque non négligeable. C’est notamment cette moindre représentativité sur le marché des systèmes qui a longtemps préservé les mondes Apple et Linux. Mais Windows demeure la cible privilégiée des attaques par fuzzing et des « framework à malware » qui sont de véritables usines à exploiter les anciens trous. Les intrusions « artisanales » sont, statistiquement parlant, toutes aussi nombreuses à être attirées par Windows.
Si une politique suivie d’application des correctifs est une des mesures pouvant minimiser ces dangers, une autre tactique consiste à masquer les signatures système aux requêtes des sondes et outils de sniffing. Si un 2000 server se fait passer pour un NetBSD, il y a peu de chances pour que les exploits lancés contre cet Unix historique et orthodoxe puissent atteindre un noyau « pur MS ». Technique ancestrale s’il en fut. Et hasardeuse, car pas une version de NT ne ressemble à la précédente. Chaque administrateur a un jour tenté de « Patcher » les exécutables ou fouiller au hasard dans la BDR. Généralement en vain.
Pour ces pionniers –et tous leurs héritiers-, voici que vient de sortir OSfuscate, accessoire de sorcellerie gratuit qui modifie la signature de réponse du DHCP et reconfigure certaines entrées de la ruche. Bien entendu, comme il s’agit d’une modification du code exécutable de Microsoft, cette mesure de prudence est légalement à considérer comme un piratage éhonté –mais n’est-il pas écrit dans les ouvrages même du « secure coding » de l’éditeur que toute indication codée « en dur » dans un exécutable était une faute impardonnable ? Pour autant qu’en ait pu juger la rédaction de Communautech, le correctif semble fonctionner sur des noyaux US conventionnels. Les captures d’écran offertes par l’auteur sont assez édifiantes. A tester, user et à abuser, donc, sur les machines installées dans les DMZ, à l’intérieur de honeypots et sur des noyaux de machines virtuelles. Backup préliminaire vivement conseillé avant toute tentative d’utilisation.