=========================================== Réunion OSSIR groupe sécurité Windows Lundi 10 juin 2002 =========================================== Ordre du jour : 1 - Présentation de la sécurité dans .Net (Eric Mittelette / Microsoft) 2 - Présentation des solutions de sécurité SecureNT et SecureEXE (Marco Peretti / SecureWave) 3 - Présentation du produit d'authentification sonore AudioSmartCard (Philippe Guillaud / AudioSmartCard) 4 - Revue des vulnérabilités récentes de Windows 2000/XP (Nicolas Ruff / Edelweb) =========================================== 1 - .Net et la sécurité (Eric Mittelette / Microsoft) 1/ Exécution Managée -------------------- .Net est basé sur le concept de management du risque d'exécution ("Managing Software Risk"). Un contrôle permanent est appliqué au code dit "managé" qui s'exécute dans une "sandbox" (le framework .Net). Cette "sandbox" offre des services de sécurité contre l'exécution de code défaillant (mécanisme de garbage collection, prévention des stack overflow, toutes les références sont nulles ou pointent sur des objets valides, etc.). Le code .Net managé est compilé en pseudo-code, puis compilé en langage machine "just-in-time" à l'exécution pour s'exécuter dans le CLR (Common Language Runtime). Le CLR vérifie et assigne dynamiquement les permissions d'exécution de l'application, qui sont paramétrables par l'utilisateur. En cas de tentative d'exécution de code non autorisé, une exception est levée. De son côté le développeur définit dans son application une liste de permissions minimales, optionnelles et refusées. On appelle "assembly" le package contenant entre autres le code exécutable, la description de l'application et sa signature d'intégrité (si utilisée). Un assembly peut être un EXE, une DLL, un service Web, une page ASPX, etc. Les "class libraries" forment un ensemble de classes sécurisées fournies par Microsoft et permettant au développeur .Net de bénéficier de primitives puissantes (même concept que les MFC). On notera les points remarquables suivants : - L'utilisation de pseudo-code met toutes les syntaxes (C, C++, Visual Basic et même COBOL) sur le même pied d’égalité : les APIs disponibles et les performances à l'exécution sont identiques ; - Le gestionnaire d’exception est unique quel que soit le langage utilisé (fin des problèmes de compatibilité rencontrés entre Visual C++ et Visual Basic par exemple) ; - Les risques de "buffer overrun" sont limités par l'absence de "memcopy", chaque objet possède une méthode Copy() fiable ; - La notion de "Application Domains" permet d'exécuter des threads avec un jeton d'accès différent au sein d'un même processus. Toutefois l'exécution managée ne résout pas les risques de sécurité suivants : - Stockage de secrets en clair dans la base de registre ou les fichiers ; - Exécution d'application en mode Trace et Debug sur un serveur de production ; - Génération de données aléatoires (les "class libraries" contiennent toutefois un générateur pseudo-aléatoire extrêmement fiable) ; - La sérialisation d'objets vers des partenaires non fiables ; - L'exécution de code non managé (si autorisé dans la CLR). En ce qui concerne le code non managé, une protection contre le "stack overflow" a été implémentée (option /GS). Une valeur aléatoire déterminée à la compilation et baptisée "canary" est déposée au sommet de la pile lors de l'appel de fonction. Cette valeur est vérifiée au retour de la fonction. 2/ "Evidenced Based Security" ----------------------------- L'exécution de tout code managé est basée sur une politique de sécurité ("Policy") qui définit les actions à effectuer en fonction des preuves d'authenticité ("Evidence") fournies par le programme. Ces preuves peuvent être la signature cryptographique du NameSpace ("Strong Name"), une signature AuthentiCode, l'origine du code (local, intranet, internet). Les actions à effectuer (autoriser / rejeter) et les permissions accordées sont basées sur la politique de sécurité. On notera que le biclé de signature doit rester confidentiel pour garantir la validité de signature. Microsoft a prévu un mécanisme de signature différé permettant au développeur de tester son application sans posséder les clés de signature. 3/ "Code Access Security" ------------------------- L'objectif est de garantir que l’application ne peut pas obtenir plus de droits que ceux demandés par le développeur et autorisés par l'utilisateur, en bénéficiant par exemple du contexte d'exécution de son parent. Un assembly appartient à un ou plusieurs "code groups" en fonction de conditions d'appartenance définies par l'utilisateur. Un jeu de permissions différent peut être appliqué à chaque "code group". L'intersection des "code groups" est utilisée pour définir les droits accordés à l'assembly. Par défaut un assembly hérite de l'intersection des droits de l'arborescence de ses appelants (mécanisme dit de "stack walk"), toutefois il existe deux API qui interrompent le stack walk : - L'une permet à un appelant de se porter garant pour tous ses fils et petit-fils (Assert()) ; - L'autre permet de refuser explicitement une permission à tous ses fils et petit-fils (Deny()). 4/ "Assembly Permission Request" -------------------------------- Le développeur d'un assembly peut déclarer trois types d'ensembles de droits (à la compilation ou dynamiquement à l'exécution) : - Droits minimum (RequestMinimum) ; - Droits interdits (RequestRefuse) ; - Droits désirés (RequestOptimal). 5/ "Role Base Security" ----------------------- Chaque assembly s'exécute sous une identité précise ("Security Principal"). Cette identité est dynamique (des primitives Get()/Set() existent). Elle permet de déterminer l'appartenance de l'assembly à un ou plusieurs groupes d'utilisateurs, appelées Roles (primitive IsInRole()). Ce mécanisme Principal/Role peut se reposer sur la gestion des identités Windows (Comptes/Groupes) ou gérer des identités "fictives" n'ayant de sens que pour l'application. 6/ Cryptographie ---------------- .Net fournit des classes cryptographiques standard et robustes (AES, SHA-1, etc.). Une implémentation des algorithmes est proposée mais un développeur peut redéfinir ses propres implémentations. =========================================== 2 - Solution de sécurité SecureWave (Marco Peretti / SecureWave) SecureWave propose deux produits de sécurité pour Windows NT/2000/XP : SecureNT (contrôle des périphériques connectés au poste de travail) et SecureEXE (contrôle des applications exécutées sur le poste de travail). Les caractéristiques de l'approche SecureWave sont : - Protection de la station plutôt que du périmètre ; - Administration centralisée du logiciel ; - Principe de moindre privilège. Les solutions SecureWave permettent aux entreprises d’appliquer un contrôle plus strict sur l’usage de la station de travail, réduisant ainsi le coût de gestion du parc informatique. 1/ SecureNT ----------- Les périphériques de stockage de données se multiplient (PDAs, appareils photos numériques, eDisques USB, baladeurs MP3) et les stratégies de protection basées sur le verrouillage des disquettes et des CD-ROM ne suffit plus pour couvrir le risque d'entrée/sortie de données (virus, espionnage industriel). De plus les solutions de verrouillage logiciel natives sont peu efficaces (ex. FlopLock du kit de ressources techniques ne supporte pas les lecteurs USB). SecureNT offre un driver de très bas niveau qui permet de verrouiller sélectivement l'accès à tout périphérique système quel que soit son port de connexion. D'autre part tout fichier copié depuis ou vers un support amovible est archivé sur un serveur central SQL Server, permettant ainsi de conserver une trace des opérations d'entrée/sortie (très dissuasif vis-à-vis des utilisateurs malveillants). Q: Support de la technologie BlueTooth ? R: Des tests sont en cours. La technologie du port infrarouge n'est pas supportée dans cette version (attendre la prochaine version). Le support générique des périphériques inconnus est intégré depuis la version 2.5 du produit. 2/ SecureEXE ------------ SecureEXE est un driver de bas niveau permettant d'interdire l'exécution d'applications sur le poste de travail selon une politique définie par l'administrateur. Seule une liste contrôlée d'applications (fichiers EXE et DLL) définie par l'administrateur est autorisée à s'exécuter sur le poste de travail, offrant ainsi une protection efficace contre les menaces liées à l'exécution de programmes non autorisés ("exploits" et virus EXE en particulier). A la différence des "Software Restriction Policies" de Windows XP (basées sur les extensions de fichier facilement modifiables), SecureEXE utilise un hash SHA-1 pour garantir l'authenticité des fichiers exécutés vis-à-vis de la politique de sécurité. Terminal Server et Citrix MetaFrame sont supportés par le produit. Q: La principale limite des "Software Restriction Policies" en mode "tout interdire sauf ..." est la difficulté d'identifier les applications requises par le système. Comment est géré ce problème ? R: SecureEXE dispose d'un mode "learn" qui lui permet d'identifier toutes les dépendances d'une application. =========================================== 3 - Produit d'authentification sonore AudioSmartCard (Philippe Guillaud / AudioSmartCard) AudioSmartCard est une société fondée par d'anciens ingénieurs de GemPlus. Le produit AudioSmartCard est un token d'authentification forte utilisant une séquence sonore pour communiquer avec son hôte. Les avantages de cette technologie sont : - sa simplicité de mise en oeuvre ; - sa disponibilité sur la grande majorité du parc existant ; - son coût largement inférieur aux solutions avec lecteur de cartes à puce (un micro est d'ailleurs offert gracieusement avec le produit). La carte génère un "one-time password" à chaque utilisation. Elle n'est ni rechargeable ni modifiable (la carte se détruit en cas de démontage). Sa durée de vie de 2 ans (standard bancaire) à 4 ans. Elle est volontairement bridée à 16400 utilisations, ce qui est toutefois largement suffisant pour la plupart des applications. Les cartes récentes intègrent une batterie en papier originale de 2mm d'épaisseur, développée spécifiquement par NEC, qui leur permet d'être au format carte de crédit et biodégradables. Avant Windows XP, l'accès au microphone était exclusif dans les systèmes Windows, ce qui offrait une bonne protection contre la capture de séquences d'authentification par un logiciel tiers malveillant. Le coût unitaire par 10,000 est de 4$. Cette technologie originale est protégée par de nombreux brevets mondiaux. D'autre part elle est utilisable dans le cadre des projets de loi européens imposant l'utilisation d'un token pour la cryptographie forte à valeur probante (signature et horodatage). Les usages actuels de cette technologie sont les suivants : 1/ Téléphonie prépayée Application historique de AudioSmartCard, aujourd'hui minoritaire. 2/ Authentification forte AudioSmartCard est disponible en 3 niveaux de service : - Modèle 1 : Cryptoprocesseur et horloge temps réel embarquée ; - Modèle 2 : Algorithme pseudo-aléatoire robuste et chiffrement AES ; - Modèle 3 : Pseudo-aléa basé sur DES. Les portables IBM ThinkPad et NEC supportent nativement l'authentification par AudioSmartCard au niveau du BIOS (lutte contre le vol). 3/ Single-Sign On Cette application grand public (disponible chez Surcouf) utilise AudioSmartCard (ainsi qu'un code PIN) pour s'authentifier sur un serveur central où sont stockés les mots de passe Web de l'utilisateur. Les formulaires sont ensuite remplis automatiquement. Un plugin est pour l'instant nécessaire, mais sera intégré à IE 7. Le plugin est disponible pour plateforme Windows uniquement, ainsi qu'une API et le code source (sur demande). =========================================== 4 - Revue des vulnérabilités récentes (Nicolas Ruff / Edelweb) Les dernières vulnérabilités des environnements Windows 2000/XP sont passées en revue. Aucune question n'est soulevée par les participants. La prochaine réunion du groupe est fixée au 8 juillet.