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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-10

Gestion du document

Référence CERTA-2009-ACT-010
Titre Bulletin d’actualité 2009-10
Date de la première version 06 mars 2009
Date de la dernière version 06 mars 2009
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 Infections par un bot

Le CERTA a été informé de l’infection de nombreuses machines par un code malveillant qui se caractérise par les éléments suivants :

  • connexion à un serveur IRC sur le port 6667/tcp ;
  • sondages de nombreux réseaux sur le port 22/tcp (SSH).

Une telle activité n’est pas nouvelle, mais, jusqu’à présent, elle était plutôt associée à des machines fonctionnant sous une distribution Linux quelconque. Or il s’agit, pour les incidents de cette semaine, de machines infectées fonctionnant sous Windows. Pour un de ces incidents, le code malveillant a été retrouvé sous le nom :

C:\WINDOWS\security\lsass.exe

Une différence fondamentale entre les distributions Windows et Linux est qu’il n’y pas de client SSH installé par défaut dans le système d’exploitation de Microsoft. Par conséquent, les connexions sortantes en SSH émanant de tels postes peuvent être un révélateur de compromission pour l’administrateur du réseau. La mise en place de règles spécifiques de filtrage en sortie ainsi qu’une lecture régulière des journaux d’événements réseaux permettent de mettre facilement en évidence les incidents de ce type.

1.2 De l’importance des remontées d’information

Une personne travaillant dans une administration a été contactée par un utilisateur. Ce dernier lui a signalé qu’une page d’un site Web provoquait un erreur de son antivirus au cours de la navigation. Le site en question n’est pas directement géré par la personne (autre ville, autre service), mais elle a transféré cette donnée pour information au CERTA et à sa chaîne fonctionnelle SSI.

L’analyse du site par le CERTA montre que ce dernier est effectivement compromis. L’intégralité des pages a été modifiée par l’insertion d’une ligne discrète de type iFrame. La navigation sur ces pages force ainsi le navigateur à se connecter à l’insu de l’utilisateur à une série de sites conduisant in fine à des codes JavaScript exploitant des vulnérabilités Flash et PDF du navigateur.

Cet incident permet de rappeler l’importance des remontées d’incidents. Certains événements peuvent paraître anodins mais permettent de révéler un problème de sécurité important. Il ne faut donc pas s’appuyer sur un sentiment trop hâtif et il ne faut pas hésiter à transférer l’information. C’est là tout l’intérêt d’une chaîne fonctionnelle SSI où chacun est acteur de la sécurité de l’ensemble.

2 Retour sur la vulnérabilité PDF

Le 23 février 2009, le CERTA a émis une alerte concernant une vulnérabilité portant sur le format PDF et plus particulièrement Adobe Reader.

La vulnérabilité de type débordement de mémoire permet à un utilisateur malintentionné d’exécuter du code arbitraire à distance. Le savoir-faire est disponible sur l’Internet et des cas d’exploitation ont d’ores et déjà été signalés. Les codes d’exploitation peuvent avoir recours à du code JavaScript Adobe. Il est donc préférable de s’assurer que l’interprétation de JavaScript n’est pas activée par défaut dans la configuration Adobe.

Au delà de l’application Adobe Reader, de nombreux autres lecteurs alternatifs de fichiers au format PDF sont affectés au moins par un déni de service.

La surface d’attaque liée à cette vulnérabilité peut être étendue, en plus de l’ouverture de fichier avec l’application vulnérable, à l’explorateur de fichiers de Microsoft Windows. Cela est dû à l’installation d’une extension par Adobe Reader. Cette extension est appelée par l’explorateur de fichiers notamment pour l’affichage en mode miniature des icônes et lors de la sélection du fichier par l’utilisateur. D’autres scénarios peuvent être envisagés.

L’application faisant appel à cette extension, « Adobe PDF Shell Extension », devient alors vulnérable à un fichier PDF spécialement construit.

Un contournement provisoire pour les systèmes Windows a été proposé dans l’alerte CERTA-2009-ALE-001 afin de restreindre la surface d’attaque sur le système. Une clé de registre permet de désactiver l’utilisation de l’extension « Adobe PDF Shell Extension ».

Comme tout contournement, il peut avoir des effets de bord non contrôlés et il convient de le tester au préalable.

Ce contournement n’empêche pas la compromission par ouverture d’un fichier malveillant.

4.3 Documentation

3 Les metatag HTML

3.1 Le contexte

Les données meta tag du format HTML permettent de définir certaines propriétés d’une page HTML. Ainsi il est possible via les propriétés meta content de définir, par exemple, les droits d’accès et de référencement pour les robots des différents moteurs de recherche.

3.2 Les exemples

Grâce aux meta tag, il est possible de bloquer toute indexation par les robots, la recherche des liens dans les pages ou la mise en cache de site. L’exemple ci-dessous montre la portion de code à ajouter :

<META content=noindex,nofollow,noarchive name=robots>

A l’inverse, les meta tag permettent également d’autoriser une indexation de l’ensemble du site et des documents s’y trouvant. L’extrait HTML suivant illustre ces propriétés :

<META content=index,follow,all name=robots>

Des politiques de référencement sont utilisées par des sites malveillants afin de :

  • rester discret et freiner les tentatives de découverte de réseau se cachant derrière un code malveillant ;
  • faciliter l’indexation afin d’accroitre le nombre de visite sur le site et ainsi augmenter la rapidité de propagation d’un code malveillant.

3.3 Les recommandations

Que votre politique d’indexation soit l’une ou l’autre des solutions exposées ou une position intermédiaire, il est important de prêter attention à ces données qui ne sont pas visibles de l’extérieur. En effet, une modification de ces informations peut entraîner une rupture de la visibilité sur l’Internet ou provoquer une atteinte à la confidentialité de certaines données si elles sont indexées puis mises en cache alors qu’elles ne le devraient pas. Le CERTA recommande régulièrement de contrôler l’intégrité des pages d’un site web. Si cette solution n’est pas applicable, des contrôles plus ciblés sur ce type de données ou sur le fichier .htaccess, par exemple, peuvent être des indicateurs de compromission et peuvent éviter une fuite d’information involontaire.

4 Toujours plus d’idées pour le filoutage

4.1 Présentation générale

Un navigateur a plusieurs manières d’identifier le type de fichier que lui envoie un serveur. Il peut s’appuyer :

  • sur l’extension du fichier ;
  • sur le type MIME retourné par le serveur (Content-Type) dans l’en-tête HTTP ;
  • sur la signature du fichier, et en particulier les premiers octets pouvant caractériser un en-tête de format connu.

La question est donc la suivante : comment réagit un navigateur quand ces informations sont incohérentes entre elles ? Prend-il l’initiative de choisir arbitrairement l’une d’elles comme fiable ?

4.2 Détails pour Internet Explorer

Les réponses varient selon les navigateurs. Un article récent rappelle le comportement d’Internet Explorer dans ce cas précis. Il adopte une méthode appelée MIME sniffing (ou plus précisément FindMimeFromData). Dans le cas d’une requête directe vers le fichier du serveur, il ne tient pas compte des informations précédentes mais s’appuie sur des tests effectués sur les 256 octets, au maximum, du fichier téléchargé.

Cette mesure a été initialement prise par méfiance des sites Web fournissant de fausses informations sur le type de contenu.

Ainsi, dans une réponse à une requête pour récupérer le fichier certa.jpg, le serveur peut répondre avec Content-Type: image/jpeg bien que le navigateur Internet Explorer interprétera finalement le contenu comme du HTML si le fichier s’avère ne pas être une image. D’autres navigateurs peuvent, eux, avoir des comportements différents et refuser d’interpréter une image inexistante.

Cette astuce peut être utilisée dans le cas de filoutage. L’utilisateur reçoit un courriel avec un lien pointant vers un fichier d’extension .jpg. Le serveur annonce également un type de contenu équivalent. En fonction du navigateur et de la configuration de celui-ci, une page de filoutage apparaîtra ou pas à l’écran.

Cette fonctionnalité peut être désactivée par clé de registre sous Windows XP SP2 par exemple.

Ce problème met plus largement en avant les disparités entre navigateurs. Celles-ci peuvent être exploitées par des personnes malveillantes pour adapter leurs actions en fonction des navigateurs.

4.3 Documentation

Rappel des avis émis

Dans la période du 23 février au 01 mars 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 06 mars 2009
    version initiale.