S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 27 juin 2008
N° CERTA-2008-ACT-026
Affaire suivie par: CERT-FR
le 27 juin 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-26

Gestion du document

Référence CERTA-2008-ACT-026
Titre Bulletin d’actualité 2008-26
Date de la première version 27 juin 2008
Date de la dernière version 27 juin 2008
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Incident de la semaine

Résilience DNS et déni de service

Le CERTA a traité cette semaine, un incident qui pouvait laisser croire à un déni de service sur plusieurs serveurs web simultanément. Mais après une rapide vérification, il n’en était rien. En effet, une première analyse a permis de constater que les serveurs prétendument indisponibles étaient hébergés par une seule et même entité.

Rapidement, on pouvait constater que le serveur DNS principal de cet hébergeur était injoignable tandis que leur  »secondaire » fonctionnait très bien. L’indisponibilité constatée venait donc du fait que la résolution de nom ne fonctionnait plus pour les domaines concernés.

Cependant, l’hébergeur mettant à disposition un serveur secondaire pour la zone, la résolution aurait du fonctionner tout de même. D’ailleurs en interrogeant ce serveur DNS secondaire, on obtenait bien une résolution de nom satisfaisante.

Une investigation plus approfondie fut donc nécessaire et permis de mettre en évidence le fait qu’en utilisant différents serveurs DNS chez différents FAIs, la résolution fonctionnait ou pas. Ainsi, en utilisant les DNS d’un FAI X, les sites étaient résolus alors qu’avec le FAI Y, la résolution ne fonctionnait pas.

Il semble donc que certains serveurs DNS mettant en cache les enregistrements des zones pour lesquelles ils ne sont pas autorités, ne le fassent qu’en se basant sur un seul des serveurs DNS autorités de ces zones.

Ainsi, si ce DNS autorité particulier vient à tomber, les caches ne consulteront pas le second pour obtenir des enregistrements valides. À expiration du délais de conservation en cache, le domaine sera considéré comme inexistant par ce serveur cache DNS.

C’est exactement, ce que le CERTA a constaté dans le cadre de cet incident. En fonction du serveur DNS public utilisé pour résoudre les noms de domaines des machines ‘en déni de service’, les serveurs web étaient joignables ou pas.

Ceci montre bien que la constatation d’un déni de service sur des machines distantes est hautement subjective. Il peut très bien arriver que ce soit un équipement de l’observateur lui-même ou dans la chaîne de routage de l’information qui soit à l’origine du prétendu déni de service. Auquel cas, il n’y a en aucun cas un déni de service pour le reste de l’Internet. Seul, le recoupement entre plusieurs points de mesures pertinents permet de déterminer de façon fiable si il y a ou pas un réel déni de service.

2 Des protocoles anodins ?

2.1 Introduction

Il existe une multitude de protocoles déployés de nos jours, quel que soit leur positionnement dans les couches du modèle de référence OSI (Open System Interconnection). Ils apparaissent pour répondre à la nécessité de nouvelles technologies et de besoins opérationnels. Il n’est pas toujours évident pour un administrateur réseau de s’y retrouver et d’avoir une compréhension complète des activités qui semblent circuler dans son système.

À cette multitude de protocoles, il ne faut pas négliger certaines vicissitudes des plus anciens d’entre eux. Le CERTA revient dans ce bulletin en particulier sur l’un d’eux : ICMP (Internet Control Message Protocol).

Ce protocole ne se limite pas qu’à la seule fonction de « ping » (ECHO Request et Reply, de type 8 et 0), mais il permet aussi, comme le précise les standards RFC 792 et 1122 (pour ICMPv4) :

  • le signalement d’erreurs bénignes (soft errors) ;
  • le signalement d’erreurs graves (hard errors).

Parmi les signalements possibles, il peut s’agir :

  • de l’impossibilité d’atteindre le destinataire (type 3) ;
  • de la gestion des flux et des congestions réseau (type 4, code 0) ;
  • de la découverte du MTU (Maximum Transfer Unit) d’un chemin réseau (RFC 1191, type 3 et code 4) ;
  • etc.

Des fonctions similaires sont apportées par la version ICMPv6 dans ses RFC respectifs.

2.2 Détails concernant la gestion des erreurs

Le standard initial ne précise malheureusement pas le comportement à adopter lors de la réception de messages de signalement d’erreurs ICMP. Il précise uniquement que des actions doivent être prises.

Pour faciliter la compréhension de l’erreur, une partie de la trame initiale ayant provoqué la dite erreur est reprise dans le paquet ICMP (l’en-tête IP et les 64 premiers bits du reste en général). Il peut s’agir du début d’en-tête TCP, ce qui permet finalement de récupérer l’ensemble (IP source, port source, IP destination, port destination) qui caractérise la session posant problème.

Le port source diffère souvent à chaque nouvelle session mais peut rester relativement prévisible. Il faut également noter que le numéro de séquence TCP peut être également inclus dans les données ICMP (64 premiers bits de l’en-tête TCP).

2.3 Exemple de risques

Certaines mises en oeuvre de TCP / IP réagissent de manière dangereuse à la réception de telles trames. Elles peuvent ne pas vérifier, par exemple, la cohérence de la réception ICMP par rapport au contenu de la trame ou le suivi du numéro de séquence.

On peut donc imaginer le scénario suivant.

Forger un paquet IP avec les caractéristiques suivantes :

IP source : une adresse quelconque, qui sera consid�r�e comme un noeud interm�diaire
IP destination : l’adresse d’une machine A
Type ICMP : Type 3, Code 2 (Protocol Unreachable)
Valeurs TCP/IP reprises dans la trame ICMP :
        adresse IP source : celle de la machine A d’o� proviendrait l’erreur
        adresse IP destination : l’adresse d’une machine B (par exemple un serveur web)
        port source : XXX
        port destination : port cible, par exemple 80/tcp

Ce scénario peut provoquer sous certaines conditions la rupture de communication TCP entre la machine A et le serveur web B. L’une des raisons est que le routeur réceptionnant le paquet ne va pas nécessairement vérifier la cohérence du contenu dans la trame ICMP. La seule difficulté réside à prévoir le port source utilisé dans la communication initiale. Ce n’est pas une tâche impossible.

Un scénario identique peut être appliqué avec la classe ICMP (type 4, code 0, ICMP Source Quench) pour modifier le comportement dans le réseau et tricher sur les bandes passante disponibles. D’autres sont envisageables.

Le lecteur comprendra ici que plusieurs malversations sont envisageables. Des outils sont disponibles sur Internet et en mettent certaines à disposition par simple « clicks ».

2.4 Recommandations

2.4.1 Filtrage ICMP

Les trames ICMP ne peuvent pas être considérées a priori comme de confiance. Leur filtrage doit être fait de la manière la plus rigoureuse possible en fonction des besoins.

Ce filtrage doit prendre en compte non seulement le protocole, mais toutes les spécificités de son en-tête pour restreindre les trames autorisées à circuler.

L’opération de filtrage s’effectue au niveau des postes utilisateurs ou dans les équipements réseaux.

2.4.2 Mises à jour

Des mises à jour sont parfois fournies par les constructeurs. Il faut donc vérifier régulièrement les nouvelles disponibilités et appliquer avec toutes les précautions d’usage ces mises à jour sur les systèmes, y compris les boitiers routeurs ou pare-feux. Certains correctifs vérifient maintenant, par exemple, la pertinence du numéro de séquence TCP retourné dans la trame ICMP. Elle doit correspondre plus ou moins à celle attendue des données envoyées mais dont la réception n’a pas été confirmée (ACK). Une personne malveillante devra alors déterminer à la fois le port source de la communication et une valeur de séquence adéquate. Cette vérification est effectuée par des systèmes d’exploitation depuis quelques années (BSD). Elle n’est cependant pas suffisante dans le cas où les trames peuvent être interceptées (réseau Wi-Fi ouvert, hub, etc.).

2.4.3 Configurations par défaut

Il est de bon usage de modifier les configurations par défaut, et en particulier les ports d’écoute comme pour les proxy web.

2.5 Documentation

3 NetBios sous Mac OS X Leopard

Dans un but d’interopérabilité maximale, Apple a activé par défaut le support du protocole NetBios sur la dernière version de son système d’exploitation Mac OS X Leopard (Mac OS version 10.5). Ce protocole développé à l’origine par IBM et Sytec servant essentiellement au partage de ressources sur un réseau est utilisé majoritairement par Microsoft pour son système d’exploitation Windows. NetBios comprend, en particulier, un service de nommage permettant d’identifier de façon unique sur un réseau différentes machines ainsi que leurs services associés (partage de fichiers, d’imprimantes, …).

Or ce service de nommage fonctionne sur un principe d’inondation réseau (broadcast) pour découvrir d’autres machines disponibles. Ceci occasionne du trafic sur le réseau car les machines s’annoncent et s’enquièrent régulièrement.

Le service de nommage de Netbios peut servir à une personne malintentionnée pour collecter des informations sur les machines présentes sur le réseau via quelques requêtes judicieusement choisies.

Jusqu’à la version 10.4 ou Tiger de Mac OS X, il est assez aisé de désactiver la mise en œuvre du protocole Netbios en ajustant les services démarrés dans Applications/Utilitaires/Format de répertoire. Il suffit dans ce menu de décocher la case SMB/CIFS. Il n’en va pas de même pour la version 10.5 (Leopard). L’utilitaire Format de répertoire n’est plus présent dans les Applications. Il convient donc de manipuler les fichiers de configuration du serveur samba intégré à Mac OS X. Pour ce faire, on éditera le fichier /etc/smb.conf et on rajoutera dans la section [Global] les deux lignes suivantes :



On pourra également désactiver, si cela n’est pas déjà fait, le service de nommage nmbd en tapant la ligne suivante :

Les modifications ne seront prises en compte qu’au prochain redémarrage.

Dans une optique de défense en profondeur, il est rappelé que le pare-feu dans Mac OS X Leopard n’est pas activé par défaut et que l’on peut remédier à cela en cochant la case : Définir l’accès de certains services et applications dans le menu : Préférences Système/Sécurité/Coupe-feu.

4 Vulnérabilité non corrigée de Mac OS X

Une vulnérabilité non corrigée dans le système d’exploitation Apple a été découverte la semaine dernière. Cette faille permet d’effectuer une élévation de privilège en local sur les machines installées avec Mac OS X dans sa version 10.5.

Cette vulnérabilité exploite une faiblesse de l’agent ARD (Apple Remote Desktop), utilitaire permettant une prise de contrôle à distance de la machine. Afin de déterminer si une machine est vulnérable il suffit de lancer la commande suivante :

osascript -e ‘tell application « ARDAgent » to do shell script « whoami »‘

Si cette commande retourne root, cela signifie que l’élévation de privilège est possible. De nombreux codes malveillants exploitant cette vulnérabilité circulent sur l’Internet. Des personnes malveillantes ont profité de cette faille de sécurité pour développer des chevaux de Troie et autres codes malveillants l’exploitant. L’installation de ces codes nécessite néanmoins une action de l’utilisateur afin de lancer leur exécution.

Il existe un moyen de se protéger de cette vulnérabilité. Il suffit de lancer la commande suivante :

sudo chmod u-s
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

Cette commande permet de retirer le bit définissant l’utilisateur (ici root) lançant l’application. Après cette opération, si la première commande est relancée, elle doit retourner le nom de l’utilisateur connecté à la machine.

Le CERTA tient donc à alerter ces lecteurs et recommande les actions suivantes :

  • appliquer le correctif détaillé ci-dessus ;
  • ne pas cliquer sur un lien ou un fichier non sûr ;
  • ne pas utiliser de compte avec des droits d’administration lorsque cela n’est pas nécessaire.

5 Un « mode protégé » pour Mozilla Firefox

Windows Vista a apporté une nouveauté qui est le « mode protégé » d’Internet Explorer 7. Ceci correspond à l’exécution du processus iexplore.exe en mode d’intégrité faible. Dans ce mode, à cause de la règle par défaut NoWriteUp (NW dans icacls) qui est utilisée, Internet Explorer ne peut que écrire dans des objets ayant un niveau également faible. Ces objets sont d’autres processus ou des fichiers, par exemple. Les répertoires usuels (favoris, historique, fichiers temporaires, etc.) ont justement un niveau faible pour permettre cela. Deux processus supplémentaires (appelés broker processes) sont également utilisés : IEInstal.exe et IEUser.exe. Le premier s’exécute en mode d’intégrité élevée et sert notamment pour installer des contrôles ActiveX, le second s’exécute en mode d’intégrité moyen et permet notamment à un utilisateur de sauvegarder des fichiers en dehors de « zones faibles » .

Une couche de compatibilité (virtualisation propre à Internet Explorer) redirige également les tentatives d’écriture par des modules additionnels, par exemple. Ainsi des tentatives d’écriture vers des répertoires de niveau moyen ou vers la ruche HKCU sont redirigées vers un répertoire et une clé spécifiques :

« Documents and Settings\%USERPROFILE%\AppData\Local\Microsoft\WindowsTemporary
Internet Files\Virtualized »

« HKCU\Software\Microsoft\Internet Explorer\InternetRegistry »

Enfin, Internet Explorer étant « virtualisé » (pas la version 64 bits), ce schéma existe aussi pour les actions de l’utilisateur (sauvegardés dans le VirtualStore) :

« %USERPROFILE%\Appdata\Local\VirtualStore ».

En ce qui concerne Mozilla Firefox, il était annoncé qu’il ait également un « mode protégé » avec la version 3 mais cela ne semble finalement pas être le cas. Il est toutefois possible de s’en rapprocher en forçant le programme à se lancer en niveau faible et en changeant les niveaux d’intégrité des répertoires utilisés. L’exemple ci-dessous concerne Mozilla Firefox 2.0.0.14 :

Pour toujours exécuter Firefox en mode d’intégrité faible (nb : toutes les commandes sont à exécuter dans une invite de commandes en tant qu’administrateur) :

icacls « %ProgramFiles(x86)%\Mozilla Firefox\firefox.exe » /setintegritylevel low

Remarque : attention, les mises à jour de Firefox peuvent remettre l’exécutable en niveau moyen par défaut.

Le niveau d’intégrité du répertoire contenant le profile de l’utilisateur dans lequel Firefox a besoin de pouvoir écrire doit également être changé :

icacls « %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\<profile> »
/setintegritylevel (ui)(ci)low

Puisqu’il est maintenant impossible de sauvegarder des fichiers dans des « zones moyennes », il est préférable de créer un répertoire de sauvegarde par défaut (modifiable dans Outils – options – Général) de niveau faible :

mkdir « %USERPROFILE%\Desktop\Save-low »

icacls « %USERPROFILE%\Desktop\Save-low\  /setintegritylevel (ui)(ci)low

Mozilla Firefox utilisant le répertoire « %USERPROFILE%\

5.1 Documentation

Rappel des avis émis

Dans la période du 16 au 22 juin 2008, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 27 juin 2008
    version initiale.