1 Incident de la semaine

Cette 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).
La particularité de cette attaque réside dans la date de l’exploitation, qui a eu lieu plusieurs semaines avant la création des fichiers servant au filoutage. Plusieurs intrusions ont été par la suite constatées entre l’exploitation de cette vulnérabilité de phpMyAdmin et la mise en place des pages Web frauduleuses.
Cette exploitation place une porte dérobée sur le serveur en modifiant le fichier config.inc.php. Des programmes malveillants parcourent l’Internet à la recherche de fichiers config.inc.php incluant cette porte dérobée. C’est ainsi que ce serveur a été victime d’une intrusion, suivie d’une élévation de privilèges et installation d’un rootkit plusieurs jours avant la création du filoutage.
Le CERTA recommande donc de mettre à jour phpMyAdmin car cette faille est actuellement exploitée. Il est également conseillé de vérifier le contenu de vos fichiers config.inc.php.

2 L’UAC

L’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’UAC

L’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 :

  • le jeton de type TokenElevationTypeDefault qu’on appellera jeton standard ;
  • le jeton de type TokenElevationTypeLimited qu’on appellera jeton filtré ;
  • le jeton de type TokenElevationTypeFull qu’on appellera jeton élevé.

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 manifestes

Certains 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 :

  • asInvoker : l’application sera lancée avec les droits de l’utilisateur ;
  • requireAdministrator : l’application sera exécutée en tant qu’administrateur ;
  • highestAvailable : l’application sera exécutée en tant qu’administrateur seulement si l’utilisateur est administrateur.

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 UIPI

L’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 7

Du 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 Conclusion

L’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 dictionnaire

Le 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 :

  • de n’utiliser que des mots de passe forts ;
  • de supprimer les comptes inutiles ;
  • de restreindre, quand cela est possible, les interfaces de connexion aux adresses IP attendues.

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 :

  • dégradation de l’expérience utilisateur ;
  • violation de la confidentialité des données utilisateur, avec potentiel accès à des données qui n’auraient pas dû être envoyées à l’opérateur du service ;
  • abus de position de la part de l’opérateur dans la mise en place de cette pratique ;
  • risque sur la résilience globale du service DNS.

Le CERTA recommande la plus grande prudence face à ces pratiques, qu’il déconseille fortement.

Documentation

Rappel des avis émis

Dans la période du 23 au 29 novembre 2009, le CERT-FR a émis les publications suivantes :