S . G . D . S . N Agence nationale de la sécurité des systèmes d'information

Paris, le 16 janvier 2009 No CERTA-2009-ACT-003

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-03

Gestion du document

Le 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-003.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-003/

1 Une mauvaise gestion du DNS

1.0.1 Présentation

Cette semaine le CERTA a traité un incident lié à une entrée DNS obsolète. L'adresse IP du site Internet d'une administration française a changé sans que le responsable du service DNS ne prenne en compte cette modification. De ce fait, les requêtes à destination de ce site n'affichaient plus les pages demandées. Pire encore, l'adresse IP d'origine ayant été réattribuée le site Web a donné l'apparence de présenter un tout autre contenu provoquant un problème d'image pour cette administration.

Le CERTA recommande de contrôler régulièrement les enregistrements DNS afin de supprimer les entrées inutiles et appliquer les modifications. Les changements d'adressage doivent être planifiés et contrôlés avant de libérer les anciennes adresses.

1.1 Documentation

• Note d'information CERTA-2008-INF-002, « Sur le bon usage du DNS » :

  http://www.certa.ssi.gouv.fr/site/CERTA-2008-INF-002/
  

• Note d'information CERTA-2007-INF-001, « Conseils pour la gestion des noms de domaine » :

  http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-001/
  

2 Le retour de la tempête

2.1 Contexte

2.2 Description

• un javascript ;
• un code exécutable (Waledac) proposé au téléchargement dès lors que l'internaute clique sur la page.

Figure 1: Capture d'écran de la carte de voeux électronique

Une fois un poste infecté, Waledac récupère par différents biais un maximum d'adresses méls en local, et renvoie la même e-card à tous ces contacts. En outre, le poste infecté fait alors partie d'un réseau de machines compromises (botnet) utilisables pour tous types d'actions (DDoS, téléchargement et installation d'exécutables, etc.).

2.3 Contre-mesures

Fort heureusement, même si le code en lui même n'est pas facile à analyser, il n'en reste pas moins aisé de le détecter. En effet, le nom de l'exécutable des souches actuelles sont toutes formées sur le schéma suivant : [préfixe]card[suffixe].exe, sachant que [prefixe] et [suffixe] peuvent être vides.

De plus, une fois installé, le code ne cache pas son activité :

• le processus [prefixe]card[suffixe].exe est présent dans la liste des processus ;
• la clef de registre suivante est créée :

  HKLM\SOFTWARE\Microsoft\Windows\CurrentVerion\Run\PromoReg
  

En revanche, partant du principe que, une fois installé, le code peut télécharger et installer d'autres programmes malveillants, le désinfection du poste passe par une réinstallation complète de celui-ci. Sachant que le meilleur moyen pour ne pas être infecté est de ne jamais cliquer sur une carte de vux électronique, même venant d'expéditeurs connus, et plus particulièrement ne jamais cliquer sur une pièce jointe ou sur un lien contenu dans un courriel suspect.

3 Forme de phishing originale

Une forme originale de filoutage a fait l'objet de discussions sur plusieurs sites de l'Internet cette semaine. Cette technique ne repose plus sur le classique courriel invitant l'utilisateur à se connecter sur un site frauduleux imitant un site officel mais se fait au cours de la navigation. En effet, il est possible pour une personne malintentionnée, via différentes méthodes (JavaScript, xul, ...), de déterminer quels sont les sites qu'un utilisateur est en train de visiter sur les différents onglets de son navigateur.

On peut alors imaginer que, si l'utilisateur est en train de consulter via l'un de ses onglets le site d'un établissement financier ou un site commercial, la personne malveillante veuille l'exploiter. Il est alors possible de faire apparaitre une fenêtre, en JavaScript par exemple, imitant la charte graphique du site visé afin de forcer l'utilisateur à entrer de nouveau ses identifiants et mots de passe sous le prétexte d'une session expirée. Il est alors facile d'intercepter ces derniers, l'utilisateur pensant à une demande légitime du site sur lequel il était connecté.

Le CERTA profite de l'exposé de ce scénario malveillant afin de rappeler quelques règles :

• n'activer l'exécution de code dynamique (Flash, JavaScript, ...) que sur les sites de confiance ;
• toujours se déconnecter proprement des sites nécessitant une authentification ;
• limiter sa navigation à un seul site lorsque celui est sensible (banques, commerces en ligne, extranet, ...) afin d'éviter des fuites d'information ;
• naviguer sur l'Internet avec un compte utilisateur aux droits limités ;
• toujours appliquer les correctifs sur l'ensemble des applicatifs (système d'exploitation, navigateur, logiciels, ...).

4 Systèmes embarqués et politique de mots de passe

4.1 Présentation

Plusieurs constructeurs proposent des équipements multimédia ou de stockage disposant de fonctionnalités avancées comme de la connectivité réseau filaire ou pas. On peut par ce biais accéder directement au contenu stocké dans l'équipement via différents protocoles : FTP, SMB, NFS, etc. Ces solutions peuvent être intéressantes car elles permettent de mutualiser un espace de stockage sur lequel on pourra réaliser des opérations de sauvegarde ou de duplication des données s'y trouvant. Il peuvent aussi constituer une zone d'échange pratique à utiliser.

En fonction de la nature des données stockées et de sa position dans le SI, le contrôle d'accès à ce type de ressources devra être irréprochable. Or les différentes solutions rencontrées n'offrent pas toutes les même niveaux de sécurité. Ainsi on pourra trouver, dans le pire des cas, des équipements proposant tous ces services activés avec un accès anonyme en lecture/écriture.

D'autres présenteront également l'intégralité de leurs services par défaut protégés par un mot de passe faible car disponible dans la documentation ou issu d'une dérivation d'un paramètre de l'équipement comme son adresse MAC. Dans ce dernier cas, on pourrait penser qu'utiliser l'adresse physique du périphérique réseau est une bonne idée mais il faut garder à l'esprit que les trois premiers blocs de l'adresse MAC varient seulement en fonction du constructeur. Ainsi dans l'adresse : 00:DE:AD:00:BE:EF, la partie 00:DE:AD représente le constructeur. La partie pseudo-aléatoire ne dépend plus que des trois blocs suivants (00:BE:EF dans l'exemple). Si l'attaquant a connaissance de la marque de l'équipement, il devient alors plus facile pour lui de trouver le mot de passe.

4.2 Recommandations

Concernant ces équipements, il faudra s'attacher entre autres, aux points suivants :

• s'assurer que l'on peut mettre à jour le système embarqué, et si oui, appliquer les mises à jour ;
• configurer l'équipement avec des mots de passe robustes chaque fois que cela est possible car certains ne permettent pas de changer le mot de passe ;
• désactiver les services non-utilisés et en préférer un seul ;
• définir une politique d'accès précise à l'équipement.

5 Rappel des avis émis

Dans la période du 09 au 16 janvier 2009, le CERTA a émis les avis suivants :

• CERTA-2009-AVI-010 : Vulnérabilité dans Asterisk
• CERTA-2009-AVI-011 : Multiples vulnérabilités dans les produits BlackBerry
• CERTA-2009-AVI-012 : Plusieurs vulnérabilités de SMB dans Windows
• CERTA-2009-AVI-013 : Vulnérabilités des produits Oracle
• CERTA-2009-AVI-014 : Multiples vulnérabilités dans IBM DB2
• CERTA-2009-AVI-015 : Vulnérabilité dans Avira Antivir
• CERTA-2009-AVI-017 : Vulnérabilités dans Cisco IOS
• CERTA-2009-AVI-018 : Vulnérabilité dans les produits Cisco ONS

Gestion détaillée du document

15 janvier 2009

version initiale.