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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-41

Gestion du document

Référence CERTA-2008-ACT-041
Titre Bulletin d’actualité 2008-41
Date de la première version 10 octobre 2008
Date de la dernière version 10 octobre 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 Incidents traités cette semaine

1.1 Des identifiants volés rendus publics

Cette semaine le CERTA a traité plusieurs incidents relatifs à la divulgation sur l’Internet d’identifiants FTP compromis. Plusieurs centaines de comptes FTP et les mots de passe associés ont été découverts. Ces identifiants, provenant certainement de plusieurs sources (attaques par dictionnaires, enregistreurs de frappe, …), semblent avoir été exploités par des individus malintentionnés pour injecter dans des pages Web légitimes sur les serveurs compromis des codes malveillants de type Neosploit. Ces compromissions étaient peu visibles et n’ont pas attiré l’attention de certains administrateurs de site Web. Le CERTA recommande de :

  • contrôler régulièrement l’intégrité des fichiers présents sur les serveurs ;
  • limiter les connexions distantes aux adresses IP autorisées ;
  • désactiver les services non utiles ;
  • avoir une politique de mot de passe dits « forts » ;
  • contrôler régulièrement les journaux des connexions pour mettre en évidence des attaques et des connexions non-désirées.

Dans le cas d’un compromission avérée, le CERTA recommande de suivre les règles de bonne conduite décrites dans la note d’information CERTA-2002-INF-002.

Documentation

1.2 Compromission et rebonds

Le CERTA a traité cette semaine un incident, somme toute assez banal, mais qui permet de faire un rappel de certaines règles de sécurité essentielles.

Un serveur d’une administration a été compromis par un attaquant après une recherche exhaustive de mots de passe d’accès au service SSH, accessible depuis l’Internet. Une fois l’intrusion frauduleuse accomplie, l’attaquant a déposé un ensemble d’outils permettant d’utiliser le serveur compromis afin de conduire d’autres attaques par dictionnaire de mots de passe SSH.

Dans un premier temps, cet incident aurait pu être évité si les règles de l’art dans la construction des mots de passe avaient été respectées (voir la note d’information CERTA-2005-INF-001).

D’autre part, de l’aveu même de l’administrateur, le service SSH n’était utilisé que pour l’administration depuis le réseau interne. Il était donc légitime de filtrer au niveau du pare-feu les flux venant de l’Internet à destination de ce service. De même, les flux sortant à destination du port 22/tcp auraient dû être filtrés, ce qui aurait permis de bloquer les attaques conduites par rebond.

En résumé, cet incident nous permet de rappeler les règles suivantes :

  • utiliser des mots de passe forts ;
  • n’autoriser que ce qui est strictement nécessaire au niveau des flux entrants ;
  • appliquer la même rigueur de filtrage au niveau des flux sortants ;
  • journaliser aussi bien les flux entrants que les flux sortants.

2 Filoutage et ingénierie sociale

Une nouvelle méthode permettant la récupération des coordonnées bancaires et d’informations personnelles est apparue à la fin de cet été. Se présentant sous la forme d’un code malveillant, son installation permet d’inciter l’utilisateur victime à « activer » sa version de Microsoft Windows.

Imitant parfaitement la véritable fenêtre d’activation, le code malveillant demande les coordonnées bancaires tout en précisant qu’aucune transaction ne sera effectuée. Répondant au nom de Kardphisher, ce cheval de Troie permet l’envoi des données récoltées à un serveur distant.

Le CERTA rappelle qu’il est impératif de maintenir l’ensemble de son système d’information à jour (navigateur, antivirus, système d’exploitation, …) afin de limiter l’installation « silencieuse » de ce type de programme. De plus, il ne faut jamais communiquer de coordonnées personnelles et/ou bancaires sans la certitude de la légitimité de la demande et l’assurance d’une transmission sécurisée de ces dernières vers une entité dûment authentifiée (ex: vérification des certificats). Dans le cas présent, le programme ne présente pas ces garanties. Enfin, ne jamais suivre de lien hypertexte ni ouvrir de pièce jointe provenant de courriel non sûr restent des précautions indispensables pour éviter toute installation de programme malveillant.

3 Les attaques en Clickjacking

Les média ont beaucoup parlé cette semaine du clickjacking suite à l’annulation d’une présentation à la conférence OWASP 2008 sur le sujet à la demande de la société Adobe, et cela afin de lui permette de corriger les vulnérabilitées affectant ses produits. Malheureusement, les attaques de ce type ne concernant pas que les produits d’Adobe, cet article est l’occasion de voir de quoi il s’agit et comment essayer de s’en protéger.

Comme son nom l’indique, il s’agit de détourner les clicks des utilisateurs pour leur faire exécuter des actions malgré eux. Ce nom ne désigne pas une vulnérabilité en particulier mais plutôt une faiblesse structurelle liée au fonctionnement du Web. Les utilisateurs font naturellement le parallèle entre appuyer sur un bouton visible et cliquer avec la souris, et n’imaginent pas qu’une multitude d’élements invisibles peuvent s’intercaler « entre » le curseur et l’élément qu’ils visualisent en-dessous.

Les attaques en clickjacking se décomposent donc en deux étapes. La première concerne l’interception du click. La seconde est relative à l’utilisation de cette action à des fins malveillantes. Il existe de très nombreuses techniques pour détourner les actions de utilisateurs, que cela soit en utilisant des iframes transparentes qui recouvrent une page ou des iframes minuscules qui se déplacent avec le curseur. L’exemple suivant montre comment une section (balise DIV) peut être placée automatiquement sour le curseur (fonctionne avec Firefox).

<script language= »JavaScript »>
 function position(e) {
        document.getElementById(« dd »).style.left = e.pageX-20;
        document.getElementById(« dd »).style.top = e.pageY-5;
 }
document.onmousemove = position;
</script>
<div id= »dd » style= »position:absolute »>  DIV sous la souris  </div>

Une fois interceptés, les clicks reroutés sont utilisables dans le contexte de l’utilisateur et avec les droits de ce derniers, comme les attaques en CSRF (Cross Site Request Forgery). Donc tout ce que peut faire un utilisateur à l’aide d’un click, l’attaquant peut lui faire faire à son insu. Ansi un programme Flash spécifiquement réalisé pouvait utiliser un click intercepté afin d’activer le micro ou la caméra de la machine, comme si l’utilisateur les avait volontairement mis en marche dans le cadre d’une vidéo-conférence (la version 10 de Flash corrige cette vulnérabilité). Le problème peut se poser du côté serveur si des actions sont réalisables d’un simple click (achats, transferts d’argent, ajout de contact de confiance, …). Il est donc possible de limiter, au niveau des sites, les effets des attaques en demandant une action supplémentaire à l’utilisateur (code pin, captcha, …). Du côté du client, limiter l’utilisation des scripts et des iframe permet de réduire les risques. Des fonctionnalités de sécurité empêchant de cliquer sur des éléments « cachés » commencent à être ajoutées aux navigateurs et aux modules de sécurité.

Documentation

4 Les boîtes à outils d’attaque

L’actualité a mis en avant la boîte à outils d’attaque Neosploit, mais le cas n’est pas isolé. Mpack a defrayé la chronique en juin 2007. D’autres kits sont utilisés avec plus ou moins d’écho dans les média.

Certains outils sont verrouillés par leurs concepteurs, d’autres comme Neosploit ont un code source ouvert. Cela permet à des utilisateurs de traduire les interfaces utilisateur. Autre conséquence, la boîte à outils peut survivre à son équipe de développeurs. Ainsi, le 29 juillet 2008, les développeurs de Neosploit ont annoncé, par un message en russe, la fin des développements. La dernière version était alors la 3.0.7.

Dès le 9 août 2008, une version 3.1 de Neosploit réapparaît.

Ces boîtes à outils d’attaque comprennent deux volets qui correspondent à deux étages d’un système d’infection.

4.1 Modification de sites Web

Le premier volet consiste à compromettre des sites Web, très fréquentés si possible.

L’intrusion dans le site à modifier peut se faire de plusieurs manières :

  • à l’aide d’un compte d’administration dont l’identifiant et le mot de passe peuvent être trouvés ou achetés sur l’Internet ;
  • à l’aide d’un compte d’administration dont l’identifiant et le mot de passe sont recherchés par l’outil d’attaque (recherche par dictionnaire ou recherche exhaustive) ;
  • à l’aide d’un compte d’administration dont l’identifiant et le mot de passe ont été récupérés par un enregistreur de frappes clavier ou tout autre programme malveillant de la même teneur ;
  • à l’aide de vulnérabilités du site ou du serveur.



Une fois entré sur un site avec des droits d’aministration, l’intrus insère dans les pages servies aux visiteurs du site des liens les orientant vers des sites malveillants. Ces liens peuvent se trouver dans beaucoup d’objets HTML. MPack faisait usage des cadres de type iframe, de taille infime (un pixel de côté) ou invisibles. Ils sont décrits dans le bulletin d’actualité CERTA-2007-ACT-025 du 22 juin 2007. Il est fréquent que le lien ne soit pas en clair mais calculé par des javascripts plus ou moins obscurcis (obfuscated). Ils sont décrits dans le bulletin d’actualité CERTA-2007-ACT-032 du 10 août 2007. Le script qui déchiffre reconstruit un lien ou un autre javascript dont l’apparence initiale est une chaîne aléatoire. Ce script est exécuté à son tour.

Quelques indices peuvent trahir la présence de tels scripts :

  • des suites d’instructions comme <script>document.write(unescape(« %3Cscript%3E… ;
  • des chaînes de caractères d’apparence aléatoires ;
  • le positionnement du code, tout en bas de la page, après beaucoup de retours à la ligne ou très à droite pour ne pas être visible sur un écran de largeur ordinaire ;
  • une connexion inattendue lors de la consultation du site légitime.

4.2 Infection des ordinateurs des internautes

L’internaute qui visite le site compromis est amené à suivre automatiquement des connexions vers des sites malveillants. Généralement le lien aboutit à un site qui lui-même renvoie vers un autre site. De rebond en rebond l’internaute est conduit jusqu’au site contenant la « charge utile ».

Ce site est souvent sous le contrôle du développeur de la boîte à outils. Il contient divers codes malveillants ce qui permet d’adapter l’infection du poste de l’internaute à sa configuration :

  • système d’exploitation, version, langue ;
  • navigateur, logiciels installés comme les lecteurs mutimédia et les suites de bureautique ;
  • adresse IP, par exemple pour rester dissimulé si l’internaute trop curieux revient sur le site.

Les codes d’exploitation des vulnérabilités au catalogue sont variées :

  • contre la suite Microsoft Office ;
  • contre les lecteurs multimédia, comme Quicktime ou Windows Media Player ;
  • contre les lecteurs de fichiers PDF, en recrudescence actuellement ;
  • contre les navigateurs et les systèmes d’exploitation.

L’utilisateur de la boîte à outils, conducteur de l’infection, dispose de statistiques sur les ordinateurs compromis, les adresses IP, les quantités par pays, par système d’exploitation ou par code d’exploitation utilisé.

4.3 Recommandations

4.3.1 Recommandations pour les administrateurs de site

Les administrateurs de site doivent veiller à leur intégrité :

  • par la mise à jour des logiciels utilisés ;
  • par la configuration restrictive du système et des logiciels ;
  • par une politique rigoureuse des mots de passe d’administration (complexité, longueur, durée de vie) ;
  • par une bonne hygiène des postes utilisés pour administrer les sites ;
  • par une surveillance régulière du contenu et de la configuration ;
  • par la surveillance des journaux d’evénements et de connexion.

4.3.2 Recommandations pour les internautes

Les internautes offriront une moindre surface d’attaque en :

  • ayant un système d’exploitation, des logiciels et des extensions, notamment de navigateur, à jour ;
  • ayant une configuration restrictive du système et des logiciels (pare-feu, désactivation des fonctions non utilisées) ;
  • naviguant avec des droits limités, pas en administrateur ;
  • n’autorisant l’exécution des codes mobiles, dont les javascripts, que lorsque cela est indispensable et après s’être asuré de l’inocuité des sites.

5 Projecteurs et fonctionnalités détournées

Certains modèles de projecteurs possèdent des fonctionnalités avancées allant au delà du simple affichage sur un écran de projection et des corrections optiques classiques (orientation, positionnement ou réglage du trapèze). En particulier, le CERTA a rencontré, lors d’une présentation, un projecteur doté d’un économiseur d’écran s’activant à chaque changement de résolution, lors d’un débranchement du câble vidéo ou au bout d’une période d’inactivité prolongée. Il s’agit bien ici d’une fonctionnalité du projecteur ne dépendant pas du tout du système d’exploitation de l’ordinateur qui y est branché. Or, si par défaut, cet économiseur affiche le logo du fabriquant, il est possible pour l’utilisateur, grâce à un menu avancé, de prendre une capture d’écran de ce qui est projeté et d’en faire ce qui sera affiché lors du déclenchement de l’économiseur. Sur le modèle manipulé, il n’était possible de stocker qu’une seule image, mais l’ « intelligence » y est. Il est donc, en théorie, possible pour ce simple périphérique d’affichage de stocker les informations projetées sous forme d’image dans une mémoire qui lui est propre. On peut dès lors imaginer que, sur les modèles haut-de-gamme, on pourra stocker un nombre plus important de clichés ou même enregistrer une petite vidéo.

Cette fonctionnalité peut donc avoir quelques conséquences en termes de confidentialité. Car, si elle est mise en œuvre, comment est-il possible de s’assurer que rien n’est stocké à l’insu de l’utilisateur ? Et lorsque le produit doit retourner en maintenance chez le fabriquant, comment s’assurer qu’aucune information sensible n’est stockée dans l’appareil ? Il est à noter que cette technologie pourrait être appliquée à tout autre type de périphérique d’affichage comme de simples écrans.

Recommandations :

Le CERTA recommande, lors de l’achat de ce type de matériel, de s’assurer qu’il n’embarque pas ce type de fonctionnalité en particulier s’il doit être déployé dans un environnement sensible.

6 Mise à jour d’alertes

Cette semaine, le CERTA a mis à jour trois alertes publiées entre 2006 et 2007 :

  • l’alerte CERTA-2006-ALE-012 concernant Microsoft PowerPoint qui a été réévaluée car le risque n’inclut plus une exécution de code arbitraire ;
  • l’alerte CERTA-2007-ALE-007 concernant Windows Explorer qui a aussi été réévaluée car le risque n’inclut plus une exécution de code arbitraire ;
  • l’alerte CERTA-2007-ALE-011 concernant Microsoft IIS dont les produits affectés, la description et les contournements ont été mis à jour.

Les vulnérabilités décrites dans les deux premières alertes ne sont pas pour autant corrigées, même si les documents apparaissent ainsi sur le site. La troisième alerte est toujours active.

Les lecteurs sont invités à consulter ces alertes sur le site du CERTA pour plus de détails.

Documentation

Rappel des avis émis

Dans la période du 29 septembre au 05 octobre 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 10 octobre 2008
    version initiale.