1 Les incidents traités cette semaine

1.1 Sites de filoutage à répétition

Le CERTA a traité cette semaine un cas de filoutage (imitation de site bancaire) sur un serveur mutualisé. En soi, l’incident n’a rien d’exceptionnel, mais ce qui est intéressant ici, c’est le caractère répétitif. En effet, après avoir informé l’hébergeur, le premier site de filoutage a disparu. Mais d’autres sites de phishing ont progressivement peuplé le serveur.

Ainsi, le premier jour, un site de filoutage était installé. Le lendemain, deux autres sites faisaient leur apparition, dans deux répertoires différents. Le surlendemain, deux nouveaux sites étaient installés, dans d’autres répertoires encore.

L’hébergeur a sous-estimé la portée de l’incident. La présence d’un site de phishing n’est qu’une manifestation visible d’une vulnérabilité exploitable. L’existence d’un faux site bancaire divulgue publiquement la fragilité d’un serveur, ce qui peut susciter l’intérêt de nombreux intrus. Généralement, de nombreuses intrusions font suite à l’installation d’un site de filoutage, soit parce que la vulnérabilité exploitée n’a pas été correctement identifiée, soit parce qu’au moins une porte dérobée a été installée suite à une intrusion.

Il est souvent conseillé, après une intrusion, de déconnecter la machine du réseau et de faire procéder à un examen des journaux (au moins). Les victimes cherchent souvent à maintenir la continuité de service malgré l’incident, en oubliant parfois que les intrus ont souvent suffisamment de privilèges pour arrêter ou entraver le service.

1.2 Attaque par Injection SQL

Cette semaine, le CERTA a traité un incident relatif à la compromission d’un site Internet. Les individus à l’origine de cet incident, ont profité de failles de sécurité de plusieurs pages web pour insérer des directives SQL. Le but de cet injection était de polluer la base de données servant à engendrer les pages web. Une seule instruction a permis de modifier tous les champs texte de la base et d’y insérer du code javascript malveillant. L’objectif de ce code était de compromettre les navigateurs des clients du site web.

Ces attaques sont de plus en plus automatisées et il est commun de trouver dans les journaux des connexions des directives SQL « chiffrées » passées en argument.

Ainsi l’instruction suivante :

CAST(0x4400450043004C004100520045002000400054002000760061007200630068006100720028
003200350035002900 AS NVARCHAR(4000))
est traduite par le serveur comme :
CAST(DECLARE @T varchar(255) AS NVARCHAR(4000))

Pour éviter ou limiter l’impact de ces attaques, le CERTA recommande :

  • de contrôler le contenu et la validé des variables avant de les utiliser ;
  • de prévenir l’utilisation de certaines directives SQL par l’utilisateur Internet ;
  • d’utiliser un utilisateur au droits limités pour la création du site web ;
  • de surveiller régulièrement les journaux des connexions afin de mettre en évidence certaines compromissions ou tentatives.

3.5 Documentation

2 Attention aux services paradoxaux

Dans son bulletin d’actualité du 26 janvier 2007 le CERTA présentait les risques des sites Internet proposant de vérifier la sécurité des identifiants. Cette semaine, le CERTA tient à mettre en garde ses lecteurs sur les sites proposant de tester la sensibilité des employés à des attaques par filoutage. Par exemple, il existe un site Web qui propose de dupliquer le site d’une société et d’envoyer de faux courriels à certains employés afin de connaître l’impact d’une campagne de filoutage (phishing). Sous couvert d’une activité qui semble légitime, ces sites pourraient également servir à alimenter des bases de données d’utilisateurs crédules. Ces utilisateurs deviendraient alors des proies privilégiées pour de réelles campagnes de filoutage.

Le CERTA recommande d’éviter d’utiliser ce genre de service dont le but pourrait être détourné si des individus malveillants avaient accès aux bases de données des utilisateurs testés. Le CERTA tient également à rappeler que les adresses de courrier électronique nominatives sont des informations personnelles qu’il convient de manier avec précaution.

Documentation

3 Effets de bord du service pack 3 de Windows XP

Cette semaine, Microsoft a expliqué les effets de bord de l’installation du service pack 3 de Windows XP sur les différentes versions des navigateurs Internet Explorer. Ce service pack n’est toujours pas disponible pour le grand public.

3.1 Utilisateurs de Internet Explorer 6

Les utilisateurs de Internet Explorer 6 recevront des mises à jour pour ce navigateur, et aucun effet de bord n’est à prévoir.

3.2 Utilisateurs de Internet Explorer 7

Les utilisateurs actuels de Internet Explorer 7 sous Windows XP SP2 recevront également les mises à jour de ce navigateur. Toutefois, après installation du service pack 3i, il sera difficile de désinstaller Internet Explorer 7 pour revenir à la version 6. Pour ce faire, il faudra désinstaller le service pack 3, puis désinstaller Internet Explorer 7. La raison donnée par Microsoft est que le service pack 3 de Windows XP contient de nouveaux fichiers pour Internet Explorer 6, et que la désinstallatation de Internet Explorer 7 provoquerait le remplacement de certains de ces nouveaux fichiers par ceux sauvegardés par le système d’installation pendant la première installation de Internet Explorer 7. Ainsi, l’on se retrouverait dans un état dans lequel il y aurait un mélange de nouveaux et d’anciens fichiers pour Internet Explorer 6. L’installation de Internet Explorer 7 après l’installation du service pack 3 de Windows XP ne provoque pas cet effet de bord, car le système d’exploitation sauvegarderait alors les nouvelles versions des fichiers de Internet Explorer 6.

3.3 Utilisateurs de Internet Explorer 8 Bêta 1

Les utilisateurs actuels de Internet Explorer 8 Bêta 1 ne se verront pas proposer automatiquement les mises à jour de Windows XP Service Pack 3. Comme pour Internet Explorer 7, il serait alors impossible de désinstaller le nouveau navigateur. Celui-ci étant en version beta, Microsoft estime qu’il est préférable de pouvoir le supprimer.

3.4 Recommandations

Toutes les personnes susceptibles de revenir à une version antérieure du navigateur utilisé actuellement doivent impérativement le faire avant l’installation du service pack 3 de Windows XP. Le navigateur peut ensuite être réinstallé après mise à jour du système d’exploitation.

3.5 Documentation

4 Filtrage des adresses MAC

4.1 Adresses MAC ?

L’adresse MAC (Medium Access Control) est de taille 6 octets (48 bits). Elle identifie normalement de manière unique les interfaces réseau utilisées. Certaines conventions précisent que cette adresse peut être écrite en 6 groupes d’hexadécimaux séparés par le caractère « – » ou « : » afin de rendre sa lecture plus aisée.

Plusieurs protocoles ayant un fonctionnement au niveau 2 des couches protocolaires OSI l’utilisent. On peut citer par exemple :

  • Ethernet 802.3 ;
  • Wi-Fi 802.11 ;
  • Token Ring 802.5 ;
  • Bluetooth 802.15.1 ;
  • etc.

Sous Bluetooth par exemple, cette adresse porte le nom de BD_ADDRESS : elle caractérise l’interface réseau et a aussi une taille de 6 octets.

4.2 Le filtrage

Dans des environnements réseau, qu’ils soient filaires ou sans fil (WiFi, Bluetooth, etc.), il peut être intéressant de s’assurer que d’autres équipements physiques ne sont pas « branchés » illégitimement. Dans le cas du Wi-Fi par exemple, cela peut aussi éviter que des postes s’associent de façon spontanée ou accidentelle à un point d’accès qui ne leur est pas dédié.

Le filtrage se fait en général sous forme de liste blanche ou noire.

4.3 Fausses bonnes idées et recommandations

4.3.1 Modifier ses adresses MAC

Modifier une adresse MAC a été proposé par certains constructeurs d’équipements réseau, car il s’agit d’une fonctionnalité intéressante pour les administrateurs souhaitant faire des tests ou ayant des configurations particulières.

La plupart des systèmes d’exploitation permettent ainsi de modifier les adresses MAC des interfaces réseau. On peut citer à valeur d’exemple :

  • sous Linux :
                    ifconfig <interface> hw eth XX:XX:XX:XX:XX:XX
    
  • sous *BSD :
                    ifconfig <interface> link XX:XX:XX:XX:XX:XX
    
  • sous MacOS (Leopard) :
                    ifconfig <interface> lladdr XX:XX:XX:XX:XX:XX
    
  • sous Windows XP : modifier les clés de registre comme :
                    HKLM\SYSTEM\CurrentControlSet\Control\Class\
                    {4D36E972-E325-11CE-BFC1-08002BE10318}\…
    
    et ajouter la variable « NetworkAddress » avec l’adresseXXXXXXXXXXXX (REG_SZ) à l’interface voulue. Elle se trouve encherchant la chaîne « DriverDesc » sous regedit.
  • sous Cisco IOS : dans le mode de configuration d’interface :
                    mac-address XXXX.XXXX.XXXX
    

Les commandes ne sont pas toujours fonctionnelles directement, car cela peut également dépendre des logiciels matériels des cartes et des possibilités d’interaction qu’ils offrent. De petits utilitaires plus complets permettent ainsi de fonctionner avec un ensemble plus large d’équipements.

L’administrateur peut chercher à vérifier si de telles manipulations ont lieu. Plusieurs techniques s’appuient en particulier sur d’autres champs des en-têtes. Sous 802.11 (Wi-Fi) , la valeur Sequence Control intègre un numéro de séquence incrémental et peut aider à identifier différentes interfaces utilisant une adresse MAC commune.

4.3.2 Les recommandations du CERTA

L’objectif de cet article n’est pas de lister toutes les méthodes pour modifier son adresse MAC ni de détecter de telles manipulations dans un réseau.

Il faut cependant bien comprendre que le filtrage d’adresses MAC n’est pas une méthode d’authentification. Ce n’est également pas une mesure de sécurité suffisante pour contrôler l’usurpation ou l’insertion de nouveaux éléments dans le réseau. Cela fait partie des bonnes mesures à mettre en place pour améliorer la maîtrise du réseau, mais comme toute mesure de sécurité, il est également important d’en connaître les limitations.

Rappel des avis émis

Dans la période du 28 au 04 mai 2008, le CERT-FR a émis les publications suivantes :