1 Incidents traités cette semaine

1.1 Présentation des faits

Cette semaine, le CERTA a été informé d’un cas de filoutage ciblant les clients d’une banque française. Le site Internet frauduleux reproduisant celui de la banque était hébergé à l’étranger. Le site frauduleux a été fermé dans les meilleurs délais.

Le site malveillant avait été déposé à la suite d’une compromission d’un site Internet légitime. De plus, ce dernier utilisant un certificat HTTPS, les pages frauduleuses ont donc également « bénéficié » de ce chiffrement. Or le CERTA entend trop souvent la fausse information « si le site utilise HTTPS, il est légitime ». En réalité, un tel certificat est associé au domaine (ou FQDN) ou à l’adresse IP pour lesquels il a été émis (cf. documentation).

Le CERTA rappelle qu’une des précautions pour ne pas se retrouver sur un site frauduleux est de ne pas cliquer sur un lien présent dans un courrier électronique. Il est préférable, pour se rendre sur un site Internet, de recopier soi-même à la main l’adresse dans le navigateur. Cette précaution et bien d’autres liées à la messagerie sont décrites dans la note d’information CERTA-2000-INF-002.

1.2 Documentation

2 De l’intérêt de déployer des solutions de sécurité

2.1 Incidents signalés cette semaine

La société SonicWALL a signalé cette semaine sur son site un problème concernant leurs serveurs en charge de la gestion des licences (Sonicwall License Manager Server). Les produits de la société qui ont cherché à établir une connexion vers le serveur de gestion de licences distant ont reçu des réponses erronées provoquant la réinitialisation de leur clé de licence.

Les conséquences de ce dysfonctionnement ne sont pas toutes connues. Certaines passerelles de filtrage de messagerie n’ont plus accompli leur rôle et ont transféré sans contrôle tout trafic de l’Internet vers les serveurs de messagerie. Le même comportement a été signalé pour des équipements de type pare-feu qui ont transféré sans contrôle les trames en transit. Les protections sont ainsi désactivées (anti-spam, antivirus, filtrage liste noire, etc.). Les utilisateurs, eux, ne se rendent pas forcément compte rapidement de ce problème.

2.2 Remarques générales

Cet article n’a évidemment pas pour objectif de jeter la pierre sur des produits en particulier. Cet incident reste envisageable avec d’autres solutions de sécurité et d’autres constructeurs.

Il offre l’occasion de rappeler deux principes fondamentaux à bien vérifier avant de déployer toute solution de sécurité :

  • il faut connaître le comportement de l’équipement et sa manière de réagir dans un contexte anormal, y compris en cas de panne : un élément d’analyse de trafic en panne doit-il par défaut tout laisser transiter, ou au contraire, bloquer toute activité afin de protéger le réseau ? En d’autres termes, est-ce que la politique de sécurité prend en compte le dysfonctionnement d’un équipement de sécurité ? Le comportement en cas de défaillance dépend du contexte mais il doit être choisi en connaissance de cause ;
  • il ne faut pas pas utiliser d’équipements de sécurité dépendant opérationnellement d’un élément tiers non maîtrisable. De manière plus précise, il faut déterminer si les dépendances fonctionnelles de l’équipement de sécurité nuisent ou limitent la sécurité. C’est par exemple le cas de plusieurs éléments mettant en œuvre des mécanismes de « phone home ». La communication dépend de nombreux facteurs externes, comme la disponibilité du serveur distant ou du chemin pour la communication.

2.3 Documentation associée

3 Apache : des lignes étonnantes dans les journaux

Cette semaine, le CERTA a cherché à détailler l’explication de certaines lignes présentes dans les journaux de serveurs Apache. Ces lignes se retrouvent sous la forme d’une requête GET pour une URI absolue (http://un_url.tld) qui n’a rien à voir avec le serveur interrogé, et qui obtient pourtant en réponse un code 200 (OK). Par exemple :

 « GET http://nimportequoi.tld » 200 13 « – » « – »
La page servie est en fait l’index par défaut (au niveau desjournaux cela peut se vérifier car, quelque soit l’URI, la taille ne varie pas et correspond à cellede la page d’index).

Les requêtes d’URI absolues sont normalement faites à destination de serveurs mandataires. On peut obtenir des traces similaires en configurant un navigateur avec un serveur mandataire pointant sur un serveur WWW (port 80). Toutes les requêtes arriveront alors sous la forme absolue. Cependant on peut se demander pourquoi Apache, n’étant pas configuré en serveur mandataire, répond avec un code 200. La lecture du code source montre en fait que :

  • ce qui se trouve avant « // » n’est pas utilisé ;
  • ce qui se trouve entre « // » et le premier « / » sert à initialiser une variable host (hostinfo) ;
  • ce qui se trouve ensuite est le chemin d’accès à la ressource.

Donc dans :

http://nimportequoi.tld/repertoire/fichier.html
  • http: est tronqué ;
  • //nimportequoi.tld/ initialise la variable host à nimportequoi.tld ;
  • /repertoire/fichier.html pointe le fichier demandé.

La variable host n’est utilisée qu’avec les requêtes du type CONNECT ou lorsqu’il y a plusieurs vhost, sinon elle est ignorée. Donc pour une URI de la forme http://nimportequoi.tld/, le serveur ne traite que le « / » final, soit la racine du site et, selon sa configuration, retourne normalement la page par défaut avec un code 200.

Ces lignes sont donc le résultat d’un fonctionnement normal. Cependant, si elles s’avèrent génantes, par exemple en levant des alertes sur un système de détection d’intrusion, il est possible de contourner le problème en utilisant, entre autres, le module apache mod_rewrite pour renvoyer un code 403 (interdit) pour les requêtes d’URI absolues. Il faut néanmoins garder à l’esprit que ce module peut également soufrir de vulnérabilités.

La RFC HTTP 1.1 définissant les URI absolues et précisant la nécessité de traiter (section 5.1.2) est accessible à l’adresse suivante :

http://www.ietf.org/rfc/rfc2616.txt

4 Fonctionnement de tcpdump

L’outil de capture de trames tcpdump offre la possibilité de définir des filtres de capture. Il utilise pour cela la syntaxe des filtres BPF (BSD Packet Filter). Cette dernière permet de définir certains critères de filtrage sur le type d’élément à filtrer (machine hôte, réseau, port, etc.), la direction des échanges (source vs. destination) ou le protocole recherché (tcp, ip, arp, etc.).

$tcpdump [OPTIONS] ip and not net 192.168

Cet exemple permet de récupérer toutes les trames IPv4 qui ne concernent pas les adresses du réseau 192.168.X.X.

Les règles de filtrage demandées sont fournies à l’application de filtrage, qui doit alors construire une décision à partir de celles-ci.

A valeur d’exemple, un article publié récemment sur un bloc-notes fait justement remarquer que le filtre « ip or vlan » n’est pas équivalent à vlan or ip« . L’utilisateur voulait capturer les trames, quelles aient un tag VLAN (IEEE 802.1Q) ou non.

Tcpdump cherche les deux informations « ip » ou « vlan ». Or, en fonction du type de trames, l’information sur le type de protocole dans l’en-tête Ethernet se trouve à l’octet 12 ou l’octet 16 (décalée par la présence du champ « tag » inséré). tcpdump cherche dans le second cas (« vlan or ip ») s’il trouve un tag à l’octet 12. Si ce n’est pas le cas, il cherche l’information IP à l’octet 16 et non 12. Cela n’est donc jamais le cas si des trames n’utilisent pas IEEE 802.1Q.

Les options -d, -dd ou -ddd de tcpdump permettent de mieux comprendre quelles sections du paquet ont correctement validé la requête de filtrage. Elles retournent les différentes instructions appliquées (récupération de valeurs dans la trame et comparaison faite).

Cette option est donc un bon moyen pour vérifier et corriger les erreurs de filtrage.

Cette nouvelle rappelle également qu’un outil de filtrage n’a de valeur que si son fonctionnement est bien compris. Dans les autres cas, cela peut conduire à de mauvaises interprétations ou à des filtres effectifs qui ne correspondent pas à ceux désirés. Il est donc impératif de tester et vérifier par la pratique que les règles appliquées correspondent aux règles attendues.

5 Bulletins Microsoft du mois de décembre

Microsoft a annoncé cette semaine la publication de huit nouvelles mises à jour de sécurité le mardi 9 décembre.

Six vulnérabilités sont considérées comme « critiques » par l’éditeur. Celles-ci concernent Windows, Internet Explorer, Visual Basic, Word et Excel. Les failles permettraient l’exécution de code arbitraire à distance.

Deux vulnérabilités touchant Sharepoint et des composants Windows Media sont considérées comme « importantes » par l’éditeur. La première permettrait une élévation de privilèges et la deuxième une exécution de code arbitraire à distance.

Toutes les versions de Windows, Office et Internet Explorer encore officiellement supportées par l’éditeur semblent concernées par ces mises à jour.

Le CERTA recommande l’application de ces correctifs dès que possible.

5.1 Documentation

6 Compromission via DHCP

6.1 Rappel sur le protocole

Le protocole DHCP (Dynamic Host Configuration Protocol) permet de fournir les paramètres de configuration réseau à un ensemble de machines d’un même réseau. Ce système est défini dans la RFC 2131 et fonctionne sur le protocole de transport UDP, qui ne fournit donc aucune authentification ni contrôle des données envoyées.

De nombreuses options peuvent être intégrées à une requête DHCP, comme vendor class indentifier, sname ou file qui permettent de récupérer des informations sur le serveur ou l’infrastructure réseau.

De plus, une interception ou une modification des trames du serveur DHCP peut affecter l’ensemble du parc informatique sans que celui-ci ne soit infecté ni même vulnérable à une attaque.

Un exemple parmi beaucoup d’autres peut être l’usurpation d’identité d’un serveur d’annuaire eDirectory dans un réseau Novell Netware.

6.2 Les risques

Il peut donc être intéressant pour une personne malveillante de compromettre le processus d’envoi des configurations réseau via un serveur DHCP. Par exemple, le code malveillant DNSChanger, dont nous parlions déjà dans le bulletin d’actualité CERTA-2008-ACT-047, injecte des paquets d’offres DHCP sur le réseau avec une option DNS falsifiée comme le montre l’exemple ci-dessous :

Option : (t=6, l=8) Domain Name Server
   option : (6) Domain Name Server
   Length : 8
   value : 55FF702455FF7024
   IP Address : xxx.xxx.xxx.xxx
   IP Address : yyy.yyy.yyy.yyy

Cette pollution a pour effet de rediriger le trafic DNS de l’ensemble des machines obtenant leur configuration DHCP vers des serveurs illégitimes. Ce type d’attaque permet d’intercepter tout ou partie des requêtes envoyées sur l’Internet. Cela peut être interessant pour attaquer les utilisateurs de sites commerciaux ou d’organismes bancaires afin d’effectuer des attaques par filoutage en toute discrétion.

6.3 Les recommandations

Afin de limiter les risques liés à une telle modification des paramètres envoyés par un serveur DHCP, il est possible :

  • de surveiller/filtrer le trafic DNS afin de s’assurer que celui-ci s’effectue vers des serveurs légitimes ;
  • de contrôler la cohérence des configurations réseau des clients ;
  • d’opter pour des systèmes de mise à disposition de configuration réseau plus sûrs nécessitant par exemple une authentification.

6.4 Documentation

7 Serveur Web sur téléphone mobile

7.1 Présentation

Un grand constructeur de téléphones mobiles propose depuis peu une solution originale pour transformer certains modèles de téléphones en véritable serveur web. Il suffit d’y installer une application puis d’enregistrer un nom de domaine paticulier sur le site du constructeur pour accéder à distance à une interface web complète permettant de réaliser de nombreuses tâches. En fait, l’application installée est un serveur HTTP dérivé d’Apache auquel a été ajouté le support du langage Python (mod_python). D’après les développeurs du projet, il est possible, à partir des données personnelles présentes sur le téléphone et par l’intermédiaire du serveur, de publier un site Internet. Outre cette fonctionnalité d’hébergement, il est aussi possible, via une interface d’administration présente sur le serveur, d’exécuter un certain nombre de tâches d’administration sur le téléphone :

  • envoi de SMS ;
  • prise de photos (si l’appareil en est capable) ;
  • gestion et partage de contacts.
  • etc.

L’accès à l’interface se fait via le portail du constructeur qui garantit la sécurité du lien entre son portail et le téléphone lors des opérations d’administration. Le serveur web sur le téléphone est, quant à lui, accessible depuis l’Internet de façon très classique.

Cette « fonctionnalité » mise en avant par le constructeur comme une petite révolution n’est pas sans poser certains problèmes de sécurité.

En effet, à partir du moment où le téléphone est utilisé comme serveur web, il devient sujet aux mêmes menaces que tout autre équipement assurant les mêmes fonctions.

On pourra donc, par exemple, imaginer réaliser sur eux des dénis de service assez facilement puisque ils disposent, tout de même, de ressources système bien en deçà de n’importe quel ordinateur PC récent.

De la même façon, le téléphone devra disposer d’une politique de mise à jour rigoureuse pour son serveur HTTP mais également pour le contenu Web (blog, page personnelle, …) sous peine de subir des attaques (défiguration, hébergement de contenu illicite) à l’insu du propriétaire, voire de participer à des attaques de type DDoS (Déni de service distribué).

7.2 Recommandations

La sécurité actuelle de tels services est aujourd’hui inconnue sinon faible. Il faut donc s’assurer de ne pas les interconnecter à des réseaux informatiques et à ne pas augmenter les risques de compromission (de ces derniers ou de leur environnement de synchronisation) en leur installant des services qui les exposent davantage.

Rappel des avis émis

Dans la période du 24 au 30 novembre 2008, le CERT-FR a émis les publications suivantes :