=========================================== Réunion OSSIR groupe sécurité Windows Lundi 6 octobre 2003 =========================================== Ordre du jour : 1 - La fuite d'information dans les documents propriétaires (Patrick CHAMBET / EdelWeb, Eric FILIOL / ESAT, Eric DETOISIEN) 2 - Retour sur les infections de l'été (Blaster, Sobig, ...) 2a - Analyse des vers RPC (Nicolas RUFF / EdelWeb) 2b - Retour d'expérience utilisateur sur les vers RPC (Stéphane ROZES / CERT-IST) 3 - Présentation de OSWIN, la base de vulnérabilités des systèmes Windows maintenue par l'OSSIR (Nicolas RUFF / Edelweb) 4 - Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== 1 - La fuite d'information dans les documents propriétaires (Patrick CHAMBET / EdelWeb, Eric FILIOL / ESAT, Eric DETOISIEN) ==================================================== Remarque préliminaire : cette présentation a déjà été publiée dans la revue spécialisée en sécurité informatique MISC n°7. Les formats de données propriétaires (DOC, XLS, PPT, MDB, PDF, etc.) partagent souvent des caractéristiques communes : - Formats complexes, souvent basés sur un modèle objet (ex. OLE pour la suite MS Office) - Non documentés, sauf par des tiers et à l'aide de "reverse engineering" - Difficiles à manipuler : la présence de contrôles d'intégrité, d'offsets absolus ou de liens entre blocs de données empêchent les manipulations "directes" Les problèmes posés par de nombreux formats propriétaires sont les suivants : - Inclusion de données statistiques (temps d'édition, nombre de révisions, nom de l'auteur, etc.) - Liens absolus vers des chemins UNC ou des sites Web - Contenus actifs ou générés dynamiquement, posant des problèmes pour la signature Exemple 1 : fichiers PDF Démonstration des fonctions "recadrage" et "masquage". Q. Ces comportements sont-ils documentés dans le produit ? R. Peut-être (à vérifier), mais ils ne sont pas intuitifs pour les utilisateurs. Exemple 2 : fichiers DOC Démonstration de l'onglet "propriétés", des données accessibles par un éditeur hexadécimal, de l'API Office, du vol de fichiers locaux via la directive INCLUDE. * Outre ces démonstrations, il a souvent été constaté que les zones de "padding" des documents Word sont remplies avec le contenu de la mémoire. Certains documents analysés contenaient même des mails en entier ! * Le mélange des directives INCLUDETEXT (lecture de fichiers locaux) et INCLUDEPICTURE (pouvant se connecter automatiquement à un site Web distant) permettrait de réaliser des attaques complexes (vol immédiat de documents, sans avoir besoin de récupérer le fichier Word "hostile" utilisé comme vecteur). Toutefois il existe une limite technique importante : la taille des URLs. * L'utilisation de directives ou de champs conditionnels (ex. REF, INCLUDE) permet de modifier dynamiquement l'apparence d'un document à l'écran ou à l'impression, ce qui complique singulièrement le problème de la signature numérique et pose de manière générale le problème de la confiance dans le contenu numérique. De plus ces "directives" ne sont pas des "macros" et ne se donc pas restreintes par les options de sécurité de Word. * Le moteur de rendu HTML de Word est celui de IE, il partage donc les mêmes bogues. Il semblerait toutefois que seules les balises "simples" soient interprétées par Word, et non les scripts et les ActiveX. A l'heure actuelle l'état des recherches dans ce domaine ne permet pas d'en dire plus. Rem. L'exemple de l'affaire Alcatel (publication d'un communiqué de presse au format DOC contenant des données masquées) montre le manque de sensibilisation des utilisateurs de direction à ce problème. Rem. Les "Word Bugs" fonctionnent également avec OpenOffice, qui supporte les mêmes fonctionnalités. Q. Les données entrées en mode révision survivent-elles à un copier/coller ? R. Oui si le document cible est en mode révision, sinon non. Q. La sauvegarde au format RTF permet-elle de supprimer les données "dangereuses" ? R. Oui. Q. Les outils présentés sont-ils disponibles ? R. Prochainement mais dans leur état actuel ils sont encore en phase de développement. Q. Existe-t-il des "Acrobat Bugs" ? R. A partir de la 5.0 ceci est théoriquement possible. Q. Ne serait-il pas plus simple de bloquer tout accès à Internet via un FW personnel ? R. Théoriquement oui, mais il est difficile d'installer un FW personnel sur chaque poste en entreprise. De plus Office utilise l'accès au Web pour l'aide en ligne, la base de cliparts et bientôt le DRM (Office 2003). Exemple 3 : WordPerfect Exemple 4 : Outlook/Exchange (fichier WINMAIL.DAT inclus dans les messages échangés) Rem. Cette présentation n'aborde pas le sujet des spywares en tout genres volontairement intégrés aux logiciels, ex. GUID unique de Windows Media Player 8.0 (désactivé dans WMP 9.0) ou composant Alexa préinstallé dans IE. Q. Pourquoi ne pas utiliser des logiciels libres tels que OpenOffice ? R. Ces logiciels ne sont pas si "compatibles" que ça et offre des fonctionnalités moindres. Certains logiciels majeurs (Office, Acrobat) sont des standard de fait du marché. Q. La conversion Word -> PDF détruit-elle les données "dangereuses" ? R. En grande partie, mais une conversion "native" via PDFWriter permet de conserver certaines propriétés du document. De plus les "Web Bugs" restent actifs. Q. Si le suivi des modifications est désactivé, les données de suivi sont-elles effacées ? R. Oui (testé). ==================================================== 2 - Retour sur les infections de l'été (Blaster, Sobig, ...) 2a - Analyse des vers RPC (Nicolas RUFF / EdelWeb) 2b - Retour d'expérience utilisateur sur les vers RPC (Stéphane ROZES / CERT-IST) ==================================================== A la suite d'une présentation factuelle sur les vers RPC de cet été, le débat qui s'en suit met en avant les points suivants : * Le scanner eEye s'est avéré efficace (peu de faux positifs et faux négatifs) et rapide. A contrario le déploiement de patches via Tivoli s'effectue au rythme de quelques centaines de machines par jour, ce qui est inacceptable pour un parc de 100 000 machines ! * La propagation d'un ver "non dangereux" a forcé le déploiement rapide du patch : en ce sens on peut dire que Blaster a eu un effet plutôt positif. * La contamination d'un centrale nucléaire dans l'Ohio par le ver SQL/Slammer a été confirmée officiellement, mais minimisée par le fait que la centrale était en maintenance. Une catastrophe majeure reste possible. * Cet incident a provoqué un revirement total de la part de Microsoft : après la chasse aux bogues ("trustworthy computing"), voici le "tout firewall". * Les portables professionnels utilisés à titre personnel posent un réel problème en entreprise. Il semble difficile d'imposer une classification par usage de connexion. De même pour les portables de prestataires, surtout lorsque ceux-ci utilisent des tunnels chiffrés avec l'extérieur, et les machines connectées simultanément à plusieurs réseaux via des accès RAS (de type abonnement Internet ou télémaintenance). Chez IBM qui nous fait part de son retour d'expérience, une opération de grande envergure a été mise en place : contact des itinérants par SMS, sas de décontamination pour les portables, distribution de CD de désinfection à l'entrée des locaux, ... * Le port TCP/135 est routé sur Internet par une large majorité de FAI. Chez les clients particuliers d'un grand FAI français qui nous fait part de son retour d'expérience, des opérations de mass-mailing et d'assistance aux utilisateurs ont été montées ; malgré celà il a fallu filtrer le port TCP/135 pour venir à bout de l'infection. * La nomenclature des souches n'est pas normalisée entre éditeurs antivirus, ainsi qu'entre fabriquants de sondes IDS, ce qui complique la tâche de l'administrateur. * Techniquement les premiers scans RPC ont commencé le 3 août mais le ver "Blaster" n'est apparu que le 10. ==================================================== 3 - Présentation de OSWIN, la base de vulnérabilités des systèmes Windows maintenue par l'OSSIR (Nicolas RUFF / Edelweb) ==================================================== Cette présentation s'effectue en trois parties : A - Installation et sécurisation de IIS 5.0 sous Windows 2000 B - Historique, contenu et objectifs de la base OSWIN C - Analyse des attaques recensées sur le serveur Web A - Sur l'installation du serveur, les techniques utilisées sont relativement "classiques" : isolation de la machine dans une DMZ dédiée, installation minimale du serveur et configuration durcie de IIS, installation de l'outil gratuit URLScan. Un gros effort de sécurisation a été réalisé au niveau de l'application ASP qui était complétement boguée initialement. On notera que le site ne contient aucune information confidentielle ni aucune zone authentifiée : le seul risque est donc un "défacement" du serveur ou de la base via une injection SQL. Toutefois ceci impacterait négativement l'image du groupe de l'OSSIR. Les failles identifiées sont le poste d'administration, qui communique de manière non sécurisée avec le serveur, et le filtrage des caractères dans les pages ASP qui fonctionne sur le principe de la "blacklist" : ainsi le caractère "|" n'est pas filtré. Aucun antivirus n'est installé sur le serveur mais le risque d'infection "directe" est quasiment inexistant grâce à l'isolation réseau complète. B - Les premières réflexions sur la base OSWIN datent de 1997, il faut rappeller que le premier bulletin de sécurité Microsoft date de 1998 et que à l'époque leur site Web n'offre pas de mécanisme de tri dans les bulletins. La base OSWIN apporte donc une information catégorisée et validée appréciable. Aujourd'hui la gestion des patches et des avis de sécurité s'est radicalement complexifiée avec l'apparition des patches cumulatifs et des avis multiples au sein d'un même bulletin. La base OSWIN ne peut pas concurrencer les professionnels de la gestion du patch, à commencer par Microsoft et ses outils (TechNet, HFNetChk, WindowsUpdate). En revanche la partie "guides de sécurité" du site offre des ressources encore d'actualité sur les systèmes NT4 et 2000. En conclusion les points notables du débat sont : * Aucun intérêt à dupliquer des bases existantes, y compris celle de Microsoft * Intérêt pédagogique des ressources de sécurisation * Mettre l'accent sur Windows XP et 2003 qui ne sont pas référencés pour le moment * Dynamiser le site en ajoutant une information critique et réactive (rubrique news) * Référencer le site sur Google C - Il est intéressant de noter les attaques que le site a subi depuis sa mise en ligne. Toutes ces attaques proviennent d'une détection du site par scan de ports, car le site n'est pas référencé à l'heure actuelle. * Beaucoup d'attaques Unicode ou recherche de backdoors Code Red * Attaque Windows Media Service ("nsiislog.dll") * Attaques plus exotiques telles que "pr.php" ou "galaxy_2096.2442", dont certaines restent inexpliquées Q. Faut-il publier les documents techniques de sécurisation du serveur sur le site de l'OSSIR ? R. A priori rien ne s'y oppose en vertu du principe "pas de sécurité par l'obscurité". ==================================================== 4 - Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== Les vulnérabilités les plus récentes des environnements Windows sont rapidement passées en revue. Les plus notables sont les vulnérabilités IE non patchées et largement exploitées sur Internet, ainsi que l'attaque "RainbowCrack". La prochaine réunion du groupe se tiendra le 3 novembre 2003. Les sujets préssentis sont : * NGSCB par Cyril VOISIN de Microsoft France. * Les risques liés aux documents propriétaires par Philippe Lagadec du CELAR. Le groupe est ouvert à toute proposition d'intervention et/ou d'hébergement.