Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2009-ACT-010

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

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

République Française Paris, le 06 mars 2009
No CERTA-2009-ACT-010

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-10


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-010

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-010.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-010/

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


5 Rappel des avis émis

Dans la période du 27 février au 06 mars 2009, le CERTA a émis les avis suivants :

  • CERTA-2009-AVI-055-001 : Vulnérabilités dans Wireshark
  • CERTA-2009-AVI-076-001 : Vulnérabilités d'Adobe Flash Player
  • CERTA-2009-AVI-080 : Vulnérabilité dans Drupal
  • CERTA-2009-AVI-081 : Vulnérabilité dans VMware ESX Server
  • CERTA-2009-AVI-082 : Vulnérabilité dans Apache Tomcat
  • CERTA-2009-AVI-083 : Vulnérabilités dans PHP
  • CERTA-2009-AVI-084 : Vulnérabilités dans Cisco Unified MeetingPlace Web Conferencing
  • CERTA-2009-AVI-085 : Multiples vulnérabilités dans Opera
  • CERTA-2009-AVI-086 : Vulnérabilités de Firefox

Durant la même période, les avis suivants ont été mis à jour :

  • CERTA-2008-AVI-556-001 : Vulnérabilité dans GnuTLS

    (ajout des références aux bulletins de sécurité Gentoo, Debian, Red Hat, SuSE et Ubuntu)

  • CERTA-2009-AVI-047-001 : Vulnérabilité dans Squid

    (ajout de la référence CVE et des bulletins de sécurité Debian, SuSE et Ubuntu)


Liste des tableaux

Gestion détaillée du document

06 mars 2009
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-07-20