S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 02 mai 2008
N° CERTA-2008-ACT-018
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2008-18

Gestion du document

Référence CERTA-2008-ACT-018
Titre Bulletin d'actualité 2008-18
Date de la première version02 mai 2008
Date de la dernière version02 mai 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 Les incidents traités cette semaine

1.1 Compromissions successives

Cette semaine, le CERTA a participé au traitement d'un incident relatif à la compromission d'un site internet. Lors de cet incident, la prise de contact a été très rapide car ce site avait hébergé des pages de filoutage (phishing) quelques jours plus tôt. Le propriétaire du site n'étant pas familier de l'administration Web pensait s'appuyer naturellement sur son hébergeur pour résoudre le problème. Or le contrat qui le liait à celui-ci ne mentionnait pas d'assistance ni de diagnostic en cas de compromission.

Le CERTA rappelle que les sites internet nécessitent des applications qui évoluent dans le temps. Des correctifs de sécurité sont régulièrement publiés afin de corriger des vulnérabilités qui peuvent être triviales à exploiter par des attaquants.

Le CERTA rappelle également que, lors de la signature d'un contrat d'hébergement, il ne faut pas négliger les aspects de sécurité ; certaines clauses peuvent être ajoutées afin d'obtenir un niveau de service et une bonne réactivité de son hébergeur en cas d'incident.

Documentation associée

1.2 Actions et réactions

Cette semaine, le CERTA a informé le responsable d'un site web de la compromission de ce dernier. Le propriétaire n'a pas pris de mesure particulière malgré des problèmes évidents :

  • ajout de fichiers et création de dossiers ;
  • utilisation d'une version ancienne et vulnérable de Joomla!.

Le responsable du site préférait reporter la faute sur son hébergeur, étant persuadé que la compromission venait de celui-ci.

Ce comportement peut mettre en péril l'intégralité du serveur ainsi que tous les éventuels sites co-hébergés. Il est donc important de comprendre les raisons techniques qui ont conduit à la compromission et de prendre les mesures nécessaires pour éviter que cela ne se reproduise.

L'administrateur du site compromis a dans le cas présent accepté de revoir la sécurité de son site.

2 Alerte CERTA-2008-ALE-005

Des codes malveillants exploitant une vulnérabilité non corrigée de Microsoft portant sur le moteur de base de données Jet Database Engine se propagent sur l'Internet. Ces codes se présentent sous la forme d'un fichier au format Word auquel est associé un fichier de base de données caché sous une extension .doc. Cette propagation s'effectue via des courriels comportant en pièce jointe les fichiers infectés.

Dans la version rencontrée, ces courriels contiennent une pièce jointe au format .rar. Une fois ouverte, celle-ci révèle plusieurs fichiers semblant être au format « word » : certains le sont effectivement (par exemple questions.doc) et d'autres sont les bases de données associées (par exemple ˜$questions.doc) qui est en réalité un fichier .mdb (Microsoft Access Database). Ce type de fichiers fait partie de ceux référencés par Microsoft comme « non sécurisés ».

Les codes malveillants rencontrés sont mal reconnus par les antivirus mais nécessitent des droits d'administrateur pour s'exécuter correctement.

Le CERTA préconise d'appliquer les mesures de contournement proposées dans l'alerte du 26 mars 2008 dans l'attente d'un correctif.

4.1 Documentation

3 Bandeau de publicité et niveau de confiance

Un expert en sécurité a récemment détaillé la problématique de l'utilisation de bandeaux de publicité dans des sites officiels.

Cette pratique très courante consiste à placer dans un site un cadre (ou frame) pointant vers un bandeau hébergé sur un serveur tiers.

Le problème est qu'il est tout à fait possible d'inclure dans ce cadre publicitaire, en plus de l'image, du javascript ou bien une applet flash (cf. le bulletin d'actualité CERTA-2008-ACT-016). Dès lors, on comprend que le niveau de confiance d'un site officiel repose en partie sur celui qui héberge le bandeau de publicité.

Or le chercheur a observé que de nombreux bandeaux étaient hébergés par un nombre restreint de sociétés spécialisées dans le domaine. Malheureusement, elles sont parfois peu regardantes sur la sécurité et la qualité du contenu hébergé. Une faille a d'ailleurs été identifiée par le chercheur, mettant en évidence qu'il était possible d'injecter via ces bandeaux du code malveillant dans le contexte d'un site tout à fait officiel.

Une autre technique dangereuse a également été mise en évidence : certains fournisseurs d'accès configurent leurs serveurs de résolution de nom (DNS) pour que, lorsqu'un domaine n'est pas trouvé par un client, soit affichée une page de publicité plutôt qu'une erreur disgracieuse. Là encore, ce type de comportement est à risque car ces pages de publicité sont fournies par le même genre d'hébergeurs que les bandeaux précédemment cités. Une simple erreur de frappe dans une barre d'adresse pourrait donc conduire à une injection de code dans le contexte du navigateur de la victime. On peut également imaginer que la page de publicité soit remplacée par une page de filoutage (phishing).

Recommandations:

Dans ce contexte, il est assez difficile de se protéger de ce type de menaces puisque l'attaque peut être conduite alors que l'utilisateur navigue sur un site officiel. Le niveau de sécurité est fixé par le serveur hébergeant la publicité.

Il existe des outils filtrant la publicité, certains sont même intégrés aux navigateurs mais le plus sûr reste encore la désactivation du support des langages comme javascript, flash, ActiveX,...dans les navigateurs. Ceux-ci sont souvent indispensables à la conduite de ce type d'attaques.

4 Les consoles retro-connectées

Entre l'exploitation d'une vulnérabilité permettant l'exécution de code arbitraire et le contrôle à distance d'une machine, il y a souvent une étape consistant à ouvrir un canal avec une console (shell) utilisable à distance. Plusieurs façons de faire sont déjà bien connues. Il est possible d'utiliser netcat, de charger un programme à l'aide de wget ou de recompiler localement un programme injecté en texte. Dans tous les cas, il s'agit de mettre quelque chose en écoute sur un port et d'attendre que la connexion soit établie depuis l'exterieur. Ces « services » en écoute sont identifiables avec la commande netstat.

Dans le cas suivant, le processus nc écoute sur le port 20000/tcp 
#nc -l -p20000
#netstat -l -t tcp 
tcp 0 0 *:20000 *:* LISTEN

Le principe peut etre inversé en faisant initialiser les connexions par la machine compromise, à destination de la machine de l'attaquant, et cela avec les mêmes outils.

Même si, la plupart du temps, ces rétro-connexions sont directement effectuées à partir des fonctions embarquées dans le code d'exploitation, il est possible de mener cette pratique à partir de commandes simples du système. Par exemple les commandes sous Linux nc MonSite.tld 13 ou cat </dev/tcp/MonSite.tld/13 établissent une connexion avec le serveur MonSite.tld sur le port 13/tcp. (la seconde nécessite cependant l'utilisation d'un bash compilé avec l'option -enable-net-redirections et ne fonctionne pas par défaut sur toutes les distributions).

Pour les machines ayant une utilisation définie, il est important de se limiter aux flux utiles. Un serveur n'a pas de raison a priori d'établir des connexions vers l'exterieur (à voir en fonction de la PSSI locale), et un poste client ne devrait pas recevoir de requêtes de connexion. Mais cela n'est pas suffisant ; les exemples ci-dessus montrent qu'une machine compromise peut initialiser une connexion vers une adresse malveillante en utilisant un port autorisé et ainsi être discrètement contrôlée à distance. Pour détecter ce genre d'incident le CERTA recommande l'analyse régulière des flux, en plus de leur limitation. Cette analyse peut reposer sur la bonne configuration des journaux existants et sur le déploiement d'équipement dédiés.

4.1 Documentation

5 Les redirections Google au service de codes malveillants

Il apparaît dans l'actualité de nombreux codes malveillants détournant des fonctionnalités du moteur de recherche à des fins malveillantes. En effet Google offre plusieurs services annexes à son moteur de recherche que des individus malveillants ne manquent pas d'utiliser et de détourner afin de tromper la vigilance des utilisateurs.

Parmi les fonctionnalités offertes par Google, il existe le service Google Adwords/Adsense qui permet de créer des liens publicitaires et commerciaux afin que le moteur de recherche les affiche lors de la recherche d'un ou plusieurs mots clés. Ces liens, plus particulièrement ceux de AdSense for domains, ont une forme assez spécifique car ils se présentent comme ceci :

http://www.google.com/pagead/iclk?sa=l&ai=YYYYYYY&num=XXXXX&
                                adurl=http://monsite/mapage.php

Des personnes malintentionnées se servent de ce service afin de rediriger les personnes vers des sites malveillants. Les utilisateurs ne prêtant pas davantage attention au lien, voient un lien Google qu'ils considèrent de confiance et cliquent sans vérifier l'intégralité du lien. Ce lien redirige en fait vers une page malveillante. Ces lignes peuvent aussi amener les utilisateurs à consulter les pages du lien sans action spécifique de leur part, grâce à un iframe ou un wget.

Les liens de ce type présentent au moins deux avantages pour quelqu'un désirant commettre des actions malveillantes :

  • il permet de contourner certains filtrages d'adresses réticulaires en s'appuyant sur l'éventuelle confiance qu'un filtre accorde aux adresses associées google.com ;
  • les utilisateurs finaux ne vérifient pas systématiquement l'intégralité de l'adresse, surtout si le lien est très long.

Le CERTA recommande donc une grande vigilance avant de cliquer sur un lien, même si celui-ci est fourni par une personne ou un site supposé de confiance. Cette technique est, entre autres, utilisée par des codes malveillants se répandant via les messageries instantanées. Par exemple, cela peut se faire sous la forme d'une demande à la liste des contacts de la personne compromise de cliquer sur un lien. Il est également possible de mettre en place une politique de filtrage en sortie, par exemple sur le serveur mandataire (qu'il soit sur l'intranet ou local sur un poste), afin de ne pas donner suite à ce type de requête de la forme http://....=http://.....

Enfin, il est recommandé d'inspecter régulièrement les journaux d'événements afin de repérer des requêtes de type http://....=http://.... signe d'une redirection qui peut être suspecte.

6 Interprétation d'URI

Les protocoles associés aux URI (Uniform Resource Identifier) les plus fréquentes que nous utilisons sont : http://, mailto:// ou ftp://.

Le standard RFC 4395 maintient les directives que des nouvelles URI doivent ou peuvent respecter. Il ne fournit cependant aucune liste des préfixes actuellement utilisé.

Plusieurs préfixes existent comme :

  • firefoxurl://
  • acrobat://
  • aim://
  • picasa://
  • gtalk://
  • etc.

Ces préfixes sont ajoutés au cours de l'installation de certains logiciels. L'installation modifie par exemple la base de registres sous Windows pour faciliter l'accès à l'application via le navigateur. Le préfixe est alors associé à une ligne de commandes permettant d'exécuter l'application avec des paramètres par défaut.

Ces fonctionnalités sont largement utilisées par plusieurs systèmes d'exploitation, parmi lesquels Windows, Mac OS X ou Linux. Cela inclut également des systèmes comme Windows Mobile ou Symbian pour les téléphones portables ou les assistants personnels.

Les attaques par injection de code indirecte peuvent profiter de ces fonctionnalités. En effet, ces liens donnent un accès direct aux applications et peuvent donc permettre d'atteindre ces dernières. Ce lien peut éventuellement comprendre des options complémentaires ou profiter d'erreurs du contrôle des paramètres fournis dans la ligne de commande.

Le CERTA rappelle à cette occasion les récentes vulnérabilités qui ont impliqué, avant corrections, le protocole res://, et ayant fait l'objet du bulletin de sécurité Microsoft MS07-035. Le bulletin d'actualité CERTA-2007-ACT-045 mentionnait également les préfixes data: et jar:.

Sans reprendre dans le détail les problèmes associés à chacun de ces préfixes, le lecteur comprendra qu'ils offrent un moyen indirect d'accéder à des applications et de nouvelles vulnérabilités potentielles par le biais d'une page Web.

Le CERTA recommande donc de contrôler ces interprétations de préfixes et de les supprimer si elles ne sont pas nécessaires. De manière générale, il faut éviter que des applications n'ayant pas de raison de communiquer puissent interagir simplement entre elles. Cela est d'autant plus important quand ces applications interagissent et interprètent des données issues de l'internet.

Documentation

7 Nouvelle version d'OpenBSD

La version 4.3 du système d'exploitation OpenBSD est sortie le 1er mai 2008, à la suite de son traditionnel cycle de 6 mois pour une nouvelle version. Cette sortie apporte son lot de nouveautés et de modifications.

La liste de l'ensemble des changements est disponible sur le site de la distribution, mais voici les principales :

  • le support des serveurs de type hppa K-class et des processeurs 88110 ;
  • ajout de SMP pour les plates-formes sparc64 et mvme88k ;
  • l'intégration de nombreux nouveaux pilotes réseau, notamment de cartes WiFi :
  • application dans la nouvelle version stable du correctif empêchant l'exploitation d'un dépassement de mémoire tampon dans le protocole ppp ;
  • intégration du correctif OpenSSL ;
  • correction du serveur DHCP afin de se protéger d'une corruption par un client malveillant.

Pour de plus amples informations, les liens vers la liste complète des modifications et la page de téléchargement sont disponibles dans la documentation.

Rappel des publications émises

Dans la période du 21 avril 2008 au 27 avril 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 02 mai 2008
    version initiale.