====================================================== Réunion OSSIR groupe sécurité Windows Lundi 13 mai 2002 ====================================================== Ordre du jour : 1 - Présentation de la haute disponibilité avec Windows 2000 (Pierre BUGNON / Microsoft) 2 - Présentation des produits ScanDo et InterDo (Yves LE ROUX / Kavado) 3 - Présentation de l'interopérabilité des implémentations de Kerberos 5 (Philippe PERRIN / ENSEIRB) 4 - Revue des vulnérabilités récentes de Windows 2000/XP (Nicolas RUFF / EdelWeb) ====================================================== 1 - Présentation de la haute disponibilité avec Windows 2000 (Pierre BUGNON / Microsoft) Il existe deux approches (pas forcément antagonistes) de la montée en charge : - Scale Up : des serveurs de plus en plus puissants. Microsoft propose Windows 2000 Advanced Server (8 processeurs max, 8 Go RAM max) et Datacenter Server (32 processeurs max, 32 Go RAM max). Les évolutions technologiques dans le domaine garantissent une amélioration constante des performances (ex. technologies Non-Uniform Memory Adressing, Cellular Multi Processing). Toutefois cette approche est limitée par le coût et on constate un tassement des performances lorsque le nombre de processeurs augmente, entre autres pour les raisons suivantes : * limitations matérielles (chipsets, fréquence du bus) ; * conception encore largement mono-processeur dans l'esprit des applications et des systèmes d'exploitation. Il est rare de trouver sur le marché des systèmes avec plus de 8 processeurs. - Scale Out : des serveurs de plus en plus nombreux. Pour connaître l'offre Microsoft, se reporter au site : http://www.microsoft.com/hpc/ (High Performance Computing) Les solutions Microsoft se basent sur l'architecture 3-tiers suivante : 1/ Equilibrage de charge IP sur la couche présentation (Network Load Balancing) Le mécanisme utilisé est celui d'une association entre une table des adresses MAC du cluster et une adresse IP virtuelle unique attribuée à toutes les machines du cluster. Il n'y a pas de routeur - donc pas de point de faiblesse, le système est redondant N fois. Ce mécanisme simple fonctionne bien avec des applications simples (serveur Web, queue de messages). 2/ Equilibrage de charge sur la couche application par DCOM puis COM+ (Component Load Balancing) Contrairement à NLB, un machine particulière fait office de routeur pour CLB. Note : le produit AppCenter est distribué indépendamment de l'OS et de COM+ pour des raisons marketing, afin de le différencier de ses concurrents (Bea, IBM, etc.) et de mettre en avant ses fonctions d'administration et d'exploitation centralisées. 3/ Clustering sur la couche données (stockage de fichiers, serveurs SQL) Windows 2000 Advanced Server supporte les clusters à 2 noeuds (4 dans la version .NET) et Windows 2000 Datacenter Server supporte les clusters à 4 noeuds (8 dans la version .NET). Tous les noeuds du cluster fonctionnent simultanément, en mode actif/actif. En matière de haute disponibilité, les facteurs limitants sont : 1/ Les erreurs applicatives Un premier problème bien connu est celui des conflits de versions entre DLLs. Le principe des DLLs était justifié à une époque où l'espace de stockage (disque et RAM) était coûteux. En pratique cette solution apporte plus de problèmes qu'elle n'en résout. Aujourd'hui la philosophie Microsoft est inverse : les DLLs devraient être spécifiques à chaque application (concept de side-by-side DLLs introduit avec Windows 2000 puis amélioré avec Windows XP). La stabilité du système est bien souvent affectée par l'installation d'applications qui remplacent des composants système. Aujourd'hui toutes les versions de Windows sont livrées avec un mécanisme d'autoprotection qui garantit l'intégrité de tout composant système sensible. Ceci peut affecter le fonctionnement des applications mais garantit que le noyau du système reste dans un état maîtrisé. Remarque : la majorité des problèmes de stabilité remontés à Microsoft par le mécanisme intégré à Windows XP sont liés aux drivers vidéo. Enfin Windows 2000 Datacenter adresse le problème du "memory leak" par un mécanisme de quota de ressources allouées aux processus. 2/ Les pannes matérielles et système d'exploitation Microsoft propose l'offre Windows 2000 Datacenter qui adressent ces problèmes de la manière suivante : * OS différent de la version poste de travail (crédibilité marketing) * OS distribué par les constructeurs (Compaq, IBM, HP, UNISYS, etc.) et non pas Microsoft * Tests de stabilité poussés (14 jours de stress-testing, équivalents à 99,9% de disponibilité - valeur minimum garantie avec Datacenter) * Garanties de stabilité de la plateforme matérielle au cours du temps Toutefois "Windows 2000 Datacenter ne se comportera comme un mainframe que si il est traité comme un mainframe". 3/ Les erreurs humaines ... L'offre Microsoft est résumée sur les sites : http://www.microsoft.com/windows2000/technologies/clustering/default.asp http://www.microsoft.com/windows2000/datacenter/ Q : comment sont diffusés les correctifs pour Windows 2000 Datacenter ? R : les correctifs sont diffusés directement par les constructeurs. Q : la réactivité des constructeurs n'est pas toujours au rendez-vous ! R : d'un autre c“té, le besoin d'application des correctifs de sécurité sur un Windows 2000 Datacenter doit être pondéré par - les considérations de haute disponibilité (les correctifs requièrent un reboot) ; - les mécanismes de sécurité externes aux serveurs. Q : est-il possible d'obtenir quelques références de clients utilisant Datacenter ? R : (hors réunion) Banque : -> Abbey National (UK) : consolidation d'applications, base de données Oracle, 15 serveurs sur un DTC -> Banco de Costa Rica -> Sakura Bank (Japon) -> Crédit Suisse First of Boston (UK) : un serveur de fichiers/d'impression, cluster base de données -> Morgan Stanley Dean Witter (UK) : 8 Datacenters -> Caisse Nationale des Caisses d'Epargne (France) : Exchange Server 2000 en cluster E-business : -> FreeMarket (Etats-Unis) : enchères sur le web, 2 milliards $, 8 serveurs sur un DTC -> MSNBC (Etats-Unis) : premier site américain d'infos sur le net, de 48 à 16 serveurs ASP : -> Ragnarok (Etats-Unis) : services bancaires sur le web, 16 Datacenters -> MarchFirst (Etats-Unis) : hébergement d'applications SQL 2000, cluster 4 noeuds -> RealTech (Allemagne) : mettre les applications SAP de ses clients sur un serveur central Et encore ... -> Coop Atlantique de Saintes (France) -> Toyota Motors (Japon) -> NTT (Japon) Des détails sur : http://www.microsoft.com/windows2000/datacenter/evaluation/casestudies/ ====================================================== 2 - Présentation des produits ScanDo et InterDo (Yves LE ROUX / Kavado) Kavado est une jeune société américaine ayant son centre de recherche et de développement en Israël, et proposant deux produits de sécurité Web distincts : InterDo et ScanDo. 1/ InterDo : les systèmes de filtrage "bas niveau" de type "firewall" ne peuvent pas lutter contre les attaques applicatives contre les serveurs Web (cf. très bonne présentation sur le sujet réalisée à la conférence Black Hat 2002 à Amsterdam). InterDo fonctionne comme un Reverse Proxy et intervient en complément du firewall du niveau TCP/IP. Seuls les flux HTTP et HTTPS sont gérés. La définition des règles de filtrage est basée sur la notion de "tunnel" (un par adresse IP). Pour chaque tunnel, InterDo effectue en tout premier lieu un filtrage des URLs non conformes à la RFC, puis passe par tout ou partie des 8 "pipes" suivants : * AllowList : "black list" / "white list" * Cookie : vérification de cohérence sur le contenu des cookies * Database : filtrage des commandes SQL * Logging : journalisation des commandes HTTP re‡ues * Navigation : vérification que les paramètres contenus dans les requêtes utilisateurs correspondent à ceux envoyés dans la page HTML source * Parameters : vérification que les paramètres contenus dans les requêtes utilisateurs correspondent à une règle définie * PathBlocking : interdictions d'accès à certains sous-répertoires ("directory traverse") * Vulnerabilities : vulnérabilités connues (mis à jour périodiquement) * SOAP et XML : en cours de développement Chaque "pipe" peut être activé individuellement, et se déclenche sur une URI (et uniquement une URI). Remarque 1 : plus il y a de "pipes" activés, plus les performances sont bien évidemment dégradées. Remarque 2 : le détail du mécanisme utilisé pour le "tracking" de session n'est pas très clair - il semblerait que InterDo "watermarke" toutes les pages sortantes. En cas d'attaque, il existe 5 niveaux d'alerte. Pour chaque niveau, une action programmable (email ou log console) est envisageable. Compte-tenu du nombre moyen d'attaques subies par tout site Web connecté à Internet, le paramétrage des actions doit être relativement fin. La définition des règles est une tƒche importante, aussi le logiciel dispose-t-il d'un mode "apprentissage" qui lui permet d'établir une liste d'URLs autorisées et de règles sur la base d'une navigation "test". Le produit est disponible sur plateforme Windows et Solaris. Q : Le produit supporte-t-il l'authentification mutuelle SSLv3 ? R : Oui, mais comme le produit fait office de reverse proxy SSL, le certificat client présenté au serveur est celui d'InterDo. La solution proposée est d'utiliser la version d'InterDo intégrée avec une NetAppliance SSL. Q : le produit supporte-t-il les pages dynamiques ? R : non, puisque le filtrage est basé sur l'URI. Q : Le produit est-il disponible sous forme de "mod" apache ? R : non. Q : le produit supporte-t-il le "virtual hosting" ? R : oui, sauf problème de licence logicielle. Q : le développement d'InterDo se base-t-il sur un développement OpenSource existant ? R : pas de réponse. Q : comment InterDo décode-t-il les requêtes Unicode (y compris les requêtes imbriquées) ? R : la journalisation des requêtes Unicode est très volumineuse. (?) Q : comment le produit se comporte-t-il face au "fragrouting" ? R : fonctionnant en Reverse Proxy, toutes les requêtes sont reconstruites avant d'être transmises au serveur et le produit n'est donc pas vulnérable au "fragrouting". Q : quel est l'intérêt de définir les règles de filtrage dans InterDo plut“t que dans une application bien programmée ? R : dans un monde idéal, aucun. En pratique beaucoup d'applications Web sont mal programmées et ne vérifient pas tous les paramètres. Q : combien de temps faut-il avant que le produit ne soit opérationnel (définition des règles) ? R : éminemment variable suivant les pipes employés ,la structure, la complexité du site et le niveau de granularité des contr“les. Sur le site Kavado, seuls 3 pipes sont activés et l'application recense 3000 attaques par jour. Q : quel est la coût du produit ? R : à partir de 20,000 $ en software ; 25,000 $ en appliance. Q : quels sont les concurrents du produit InterDo ? R : Sanctum (AppShield pour InterDo, AppScan pour ScanDo). Q : apache en reverse proxy est-il un concurrent ? R : non. 2/ ScanDo : ScanDo est un scanner de vulnérabilités Web complètement "client-based" (pas de module serveur). Il fonctionne en trois phases : * "Crawl" : le logiciel explore l'arborescence du site à partir des indications utilisateur. * "Evaluate & Attack" : le logiciel établit une liste des problèmes de sécurité potentiels. Optionnellement, le logiciel teste les scénarios d'attaque précédemment établis (destructif pour le site Web !). * "Report" : le logiciel crée différents types de rapports. ScanDo pilote le contr“le ActiveX "Internet Explorer" pour naviguer sur le site et lancer ses attaques. Q : ScanDo partageant les vulnérabilités d'Internet Explorer, est-il possible de compromettre le client en scannant un site "hostile " ? R : c'est à vérifier mais pas impossible. Q : quel est le coût du logiciel ? R : 1 machine, 2 domaine = 6,000 $ 1 machine, 7 domaines = 7,000$ licence "consultant" illimitée = 15,000 $ ====================================================== 3 - Présentation de l'interopérabilité des implémentations de Kerberos 5 (Philippe PERRIN / ENSEIRB) Dans le cadre d'un projet de fin d'étude, Philippe PERRIN et Fran‡ois LOPITAUX ont testé l'interopérabilité des implémentations de Kerberos 5 entre les systèmes suivants : * Windows 2000 * Module PAM/"SEAM" sur Solaris/Intel 8 * Distribution standard MIT * Heimdall sous Linux Le rapport complet de cette étude (100 pages) est disponible sur : http://www.phperrin.fr.st/enseirb/annee3/kerberos/kerberos.html Dans l'ensemble les tests ont été concluants dans les cas suivants : * KDC Windows 2000 ; services MIT et Heimdall ; clients Windows, MIT et Heimdall * Relation de confiance entre KDC Windows 2000 et MIT ; services MIT et Heimdall ; clients Windows, MIT et Heimdall Les écueils rencontrés ont été : * L'implémentation SEAM s'est très mal comportée, mais cela vient probablement de la plateforme (Solaris Intel et non Sparc). * Le changement de mot de passe est peu interopérable, sauf avec le client MIT qui supporte les extensions Windows. * Il existe très peu de clients "kerberisés" livrés en standard avec Windows Q : comment un client Linux localise-t-il le KDC ? R : il existe un fichier de configuration dans /etc Q : est-il possible de remplacer ce fichier de configuration par une requête DNS SRV ? R : ne sais pas. Q : existe-t-il une détection de cycle dans les chemins de confiance ? R : ne sais pas. Q : est-il possible d'utiliser un KDC Unix avec des clients Windows ? R : ce test n'a pas fonctionné mais il n'a pas été poussé très loin. Q : est-il vrai que PAM passe le mot de passe en clair sur le réseau ? R : les tests réalisés sur PAM ont été uniquement locaux. L'utilisation de la commande "kinit -f" est recommandée. Q : est-il possible d'utiliser un SAMBA Kerberisé ? R : ce test n'a pas fonctionné mais les versions de SAMBA évoluent rapidement. ====================================================== 4 - Revue des vulnérabilités récentes (Nicolas RUFF / EdelWeb) Les bulletins de sécurité MS02-14 à MS02-022 sont passés en revue, ainsi que : - l'exploit Debploit - l'advisory Guninski #53 A ce sujet un participant mentionne le logiciel DetachXP disponible sur http://www.mcdev.com/ - Deux vulnérabilités Internet Explorer documentées sur : http://spoor12.edup.tudelft.nl/skylined http://jscript.dk/adv/TL002/ Un participant signale aussi une vulnérabilité en cross-site scripting utilisant la syntaxe
. La vulnérabilité vient du fait que la plupart des serveurs FTP (ou SMTP) renvoyent les commandes en erreur (ex. "USER alert('toto')" renvoie "XXX USER alert('toto') unknown"). La prochaine réunion est fixée au lundi 10 juin 2002.