CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2009-49
Gestion du documentLe bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-049.pdf Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-049/ 1 Incident de la semaineCette semaine, le CERTA a traité, parmi de
très nombreuses autres affaires de filoutage (phishing), un cas particulièrement
intéressant. L'analyse de cet incident montre que les
fichiers servant au filoutage ont été
déposés suite à l'exploitation d'une
vulnérabilité dans phpMyAdmin
(référence CERTA :
http://www.certa.ssi.gouv.fr/site/CERTA-2009-AVI-117/CERTA-2009-AVI-117.html). 2 L'UACL'UAC ou User Account Control est une fonctionnalité introduite avec Windows Vista, également présente dans les versions ultérieures de Windows (Windows 7, Windows 2008). Cet article a pour principal objectif de rappeler son principe de fonctionnement et de présenter un changement apparu avec Windows 7. 2.1 Rappels sur le fonctionnement de l'UACL'UAC est intimement lié à des objets associés à chaque processus appelés access tokens ou jetons d'accès. En effet, lorsqu'un utilisateur s'authentifie sur le système, un jeton est créé pour cet utilisateur qui sera associé avec tous ses processus. Ce token contient plusieurs informations, telles que le SID (Security Identifier) du compte, les SID des groupes, et les privilèges. Lorsqu'un objet tente d'être accédé par un processus, le système d'exploitation compare les éléments de son descripteur de sécurité (notamment, les entrées de sa liste de contrôle d'accès discrétionnaire ou DACL) avec les informations contenues dans le jeton du processus. A partir de Windows Vista, il existe trois types de jetons sur lesquels se base l'UAC :
Les types de jetons ne régissent pas les droits des processus, mais plutôt la manière dont l'élévation de privilèges doit s'effectuer. En règle générale et dans la configuration par défaut, le premier jeton est utilisé pour les utilisateurs standards et les deux autres jetons pour les membres d'un groupe administratif (tel que le groupe Administrateurs). Ces derniers ont en effet deux jetons, liés entre eux, car s'ils ont bien des droits élevés, ceux-ci sont toutefois plus restreints par défaut. Le premier jeton de l'administrateur est appelé jeton filtré car il n'octroie pas tous les privilèges administrateur. Les processus exécutés par l'utilisateur hériteront alors de ce token par défaut. Le deuxième jeton est uniquement utilisé pour exécuter des processus requérant des droits plus élevés. Pour accéder à ce jeton, l'administrateur doit, dans la configuration par défaut, confirmer l'action via une boîte de dialogue. C'est le « mode d'approbation d'administrateur » ou AAM, configurable dans les options de sécurité des stratégies locales. En ce qui concerne l'utilisateur standard, il n'a qu'un seul jeton. Pour exécuter un processus nécessitant des privilèges élevés, il doit, comme sur Windows XP, l'exécuter en tant qu'administrateur de la machine et donc entrer le mot de passe d'un compte d'administration. Le processus utilise alors un autre jeton standard mais qui sera associé au compte administrateur, et donc avec davantage de privilèges. Lorsque l'UAC est désactivé, un administrateur qui s'authentifie sur le système n'a qu'un seul jeton standard de type TokenElevationTypeDefault. Tous les processus sont alors exécutés avec ce jeton et ses privilèges élevés. 2.2 Les manifestesCertains programmes tels que regedit.exe et mmc.exe sont toujours exécutés en tant qu'administrateur. Cela se fait au moyen d'options que les développeurs inscrivent dans le fichier « manifeste » de l'application. Il en existe trois :
2.3 UAC et l'intégritéLes niveaux d'intégrité ont également été introduits avec Windows Vista et fonctionnent en complément de l'UAC. Leur intérêt est principalement, comme leur nom l'indique, de protéger l'intégrité du système d'exploitation. Il existe, par défaut, cinq niveaux d'intégrité : untrusted, faible, moyen, élevé, et système. Le jeton d'un utilisateur standard a un niveau d'intégrité moyen, de même que le jeton « filtré » d'un administrateur. Tous les processus exécutés auront donc par défaut un niveau d'intégrité moyen. En revanche, le deuxième jeton d'un administrateur a un niveau d'intégrité élevé, de même que son jeton standard. Les fichiers et répertoires ont également des niveaux d'intégrité. En général, la règle no write up est définie pour les répertoires et spécifie qu'un processus de niveau strictement plus bas ne peut y écrire. D'autres règles peuvent être appliquées, qui sont no read up et no execute up. Le « mode protégé » d'Internet Explorer 7 et 8 depuis Windows Vista repose sur ce principe, car il est exécuté avec un niveau faible et ne peut donc écrire par défaut que dans certains répertoires bien spécifiques. Ces vérifications d'intégrité ne remettent pas en cause le mécanisme de contrôle d'accès discrétionnaire d'un objet qui est vérifié après l'intégrité. 2.4 UIPIL'UIPI (User Interface Privilege Isolation) est un principe utilisant les niveaux d'intégrité qui empêche des processus d'envoyer certains messages (window messages) vers d'autres processus de niveau plus élevé. Cela permet d'empêcher certaines attaques de type shatter attack qui profitaient de l'envoi de messages entre processus pour exécuter du code avec des privilèges plus élevés. Certaines fonctions sont également limitées pour empêcher notamment les injections de code. 2.5 L'UAC dans Windows 7Du point de vue d'un utilisateur, l'UAC est une fonctionnalité qui engendre de nombreuses boîtes de dialogue sur lesquelles, de toute manière, on clique toujours sur « oui ». Cela est notamment dû à la mauvaise habitude qu'ont pris les développeurs avec Windows XP de créer des applications qui ne fonctionneront qu'avec des droits administrateur. En créant ce système de jetons liés, Microsoft veut forcer les développeurs à écrire des applications plus propres qui ne nécessitent pas de droits administrateur, sauf pour leur installation. Cela n'a toutefois pas suffi et, pour satisfaire ses utilisateurs, Microsoft a, dans Windows 7, baissé le niveau par défaut de l'UAC pour ne pas avertir les utilisateurs lorsqu'ils « modifient eux-mêmes les paramètres de Windows. » Par exemple, lorsque l'utilisateur active ou désactive le pare-feu, aucun consentement n'est demandé. Cela fonctionne au moyen d'une auto-élévation de la part de Windows de certains exécutables. Ceux-ci doivent être signés par l'éditeur de Windows, et se trouver dans certains répertoires spécifiques. Les exécutables doivent également avoir la propriété autoElevate dans leur manifeste. Des listes en dur existent aussi pour certains autres exécutables de Windows et les snap-in de MMC. Si cette propriété peut sembler intéressante d'un point de vue ergonomique, il a été démontré qu'elle n'est pas infaillible et qu'il existe des moyens pour des codes malveillants de profiter de l'auto-élévation pour s'exécuter avec des droits élevés. Il est donc fortement recommandé de revenir au niveau par défaut tel qu'il était sur Windows Vista, soit de toujours demander un consentement lors d'une élévation de privilèges. Pour cela, il faut aller dans : Panneau de configuration - Comptes d'utilisateurs - Modifier les paramètres de contrôle de compte d'utilisateur. et mettre le niveau à « toujours m'avertir. » Cela correspond au quatrième niveau qui est le plus élevé. 2.6 ConclusionL'UAC est une fonctionnalité qui, comme toutes les nouveautés, a été critiquée de nombreuses fois. Il a toutefois un intérêt qui réside dans le fait que, depuis Windows Vista, un compte d'administrateur est privé de ses privilèges par défaut et fonctionne de manière semblable à un compte d'utilisateur standard. L'utilisation d'un poste bureautique ne nécessite normalement en aucun cas des droits d'administrateur, si les applications sont développées convenablement. L'UAC ne doit toutefois pas se substituer à l'utilisation d'un compte standard, lorsque cela est possible. Comme lors de l'utilisation d'un compte standard, il n'empêche pas non plus l'exécution et l'installation de tous les codes malveillants. Dans tous les cas, il est fortement recommandé de le laisser activé et, sous Windows 7, au niveau maximum de demande de consentement. 3 Attaques par dictionnaireLe SANS relate la découverte d'un script permettant de lancer des attaques par dictionnaire à l'encontre du compte d'administration de WordPress. La particularité de ce script est qu'il permet la répartition des attaques depuis plusieurs machines. Le SANS préconise notamment de changer le nom du compte administrateur, d'utiliser des mots de passe forts et de restreindre les accès à l'interface d'administration. Les attaques par dictionnaire ne sont pas une nouveauté. Par contre, ce qui est original avec ce script, c'est la répartition de la charge de travail entre plusieurs attaquants, et la possibilité d'interrompre l'opération et de la reprendre ultérieurement. La détection de l'attaque dans les journaux devient ainsi plus difficile. Après SSH et FTP, c'est donc au tour d'un CMS (gestionnaire de contenu) de subir des attaques par dictionnaire. Il ne serait pas surprenant que dans un futur proche, tous les services permettant une authentification par identifiants soient concernés par des tentatives automatisées de ce type. Par conséquent, le CERTA recommande :
Documentation :
4 Réponses DNS substituées : L'ICANN met en garde !Depuis quelques années, certains opérateurs réseaux, dans le but d'offrir un « meilleur service » à leurs clients, et accessoirement de créer de nouveaux revenus via de nouveaux supports de publicité, se sont intéressés de près au DNS (Domain Name System, serveur de résolution de nom sur l'Internet). Parmi les pratiques parfois rencontrées, la substitution de « NX Domain » (pour Non-Existent Domain, domaine non existant, message normalement renvoyé par un serveur DNS quand l'enregistrement demandé n'existe pas) est ainsi apparue chez certains fournisseurs d'accès. L'idée est ainsi de re-router les connexions d'un utilisateur vers une adresse IP hébergeant par exemple un moteur de recherche. Le scénario peut être le suivant : un utilisateur fait une faute de frappe en saisissant une adresse dans son navigateur Web. En fonctionnement normal, le serveur DNS qui reçoit la requête devrait renvoyer une réponse « NX Domain » indiquant que le site n'existe pas, ce qui entraine l'apparition d'une page d'erreur sur le navigateur Web. Si le fournisseur de service (opérant le DNS de l'abonné) a mis en place une substitution de « NX Domain », il peut alors renvoyer en réponse à la requête une adresse IP valide, pointant par exemple sur le portail dudit opérateur (et pourquoi pas, sur un moteur de recherche « maison » copieusement rempli de publicités). Le problème est encore plus grave lors de l'envoi d'un message électronique, car si l'utilisateur rentre par mégarde un nom de domaine inexistant, un opérateur utilisant la substitution de « NX Domain » est alors en mesure d'aspirer ces éléments. En septembre 2003, Verisign, un des opérateurs de l'infrastructure DNS mondiale avait tenté de mettre en place de telles pratiques, mais le mécontentement global engendré avait forcé cette société à rapidement faire demi-tour (histoire disponible sur http://www.icann.org/en/topics/wildcard-history.html). Fin novembre 2009, l'ICANN est revenue une nouvelle fois sur le sujet des « NX Domain », et maintient un discours strict sur le danger de leur substitution. Avec la création prochaine de nouveaux GTLDs (Generic top-level domain), il est important de comprendre que les substitutions de « NX Domain » pourraient entrainer de nombreux problèmes, et ne doivent pas être mises en place. On notera que si l'ICANN se prononce ici spécifiquement à destination des opérateurs de GTLDs, le message est cependant identique pour tous les opérateurs de DNS, quel que soit le niveau. Parmi les problèmes signalés, citons :
Le CERTA recommande la plus grande prudence face à ces pratiques, qu'il déconseille fortement. Documentation
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
