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-2011-ACT-014

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 08 avril 2011
No CERTA-2011-ACT-014

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2011-14


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-2011-ACT-014

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-2011-ACT-014.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-2011-ACT-014/

1 Vulnérabilité dans certaines implémentations de IPComp

Le protocole d'encapsulation IPComp (décrit dans la RFC3173) est utilisé pour compresser la charge utile transportée par un datagramme IP.

Une faille dans les implémentations de piles IPComp provenant de NetBSD et du projet KAME permet à une personne malveillante de réaliser un déni de service via un débordement de la pile du noyau. Il semble également possible d'exploiter dans certains cas cette vulnérabilité pour exécuter du code arbitraire à distance.

Cette implémentation étant reprise dans de très nombreux produits, il convient de vérifier pour chacun d'entre eux si la pile IPComp est activée, et si celle-ci est vulnérable.

Les distributions NetBSD et FreeBSD ont déjà rendu public des correctifs pour leur noyau respectif sous la forme de modification du code source.

Le CERTA recommande aux utilisateurs de produits embarquant un noyau BSD de filtrer le protocole IPComp si celui-ci n'est pas nécessaire et de vérifier avec le fabricant la présence ou non de cette vulnérabilité.

2.2 Documentation

2 Attaques par contournement, scénario qui se généralise

Le CERTA constate des intrusions indirectes. Généralisation d'un phénomène, ou simplement meilleure observation de celui-ci, la question mérite d'être posée. Toutefois les nombreuses attaques directes militent pour la première hypothèse.

Dans un billet sur son blog, la société RSA décrit le déroulement de l'attaque qui a permis à des intrus de voler des informations sensibles liées à l'un de ses produits, le token SecurID. La description correspond au schéma auquel des correspondants du CERTA sont confrontés. L'attaque se fait par approche progressive vers les données convoitées. Le cas de RSA sert au jalonnement de la description.



Sur les processus critiques visés, les utilisateurs sont probablement sensibilisés et des outils de protection sont mis en place. L'attaquant cherche un point plus faible, un utilisateur sans rôle particulier.

L'entrée dans le système d'information utilise l'ingénierie sociale pour inciter à ouvrir un courriel piégé exploitant une vulnérabilité non corrigée, ou tout juste corrigée, avec l'espoir que le déploiement des correctifs aura été asssez lent pour laisser des postes vulnérables. Le piège est généralement personnalisé pour ne pas être detecté par les outils de protection (antivirus, IDS...). Un autre vecteur peut être une clef USB déposée près de l'entrée de la société ou de l'organisme cible.

Dans le cas de RSA des utilisateurs ordinaires ont reçu, en deux vagues, des courriels intitulés « 2011 Recruitement Plan », (prévision de recrutement 2011), avec un fichier excel joint, lequel embarquait un objet Flash exploitant la vulnérabilité CVE-2011-0609, corrigée par Adobe le 21 mars 2011. Le piége a consisté en l'installation d'une version du code malveillant PoisonIvy. Il a suffi d'un seul utilisateur ouvrant la pièce jointe pour ouvrir les portes aux intrus.



Une fois dans la place, comme à Troie, l'agresseur peut sévir. Le schéma classique est d'installer un logiciel malveillant capable de prendre des ordres ou de télécharger une charge active. Les défenses périmétriques étant généralement restrictives, ces ordres ou ces téléchargements utilisent un canal plus probablement ouvert. Il s'agit souvent du protocole HTTP ou HTTPS. Il est donc important de restreindre et de surveiller les flux sortants (source/destination, volume, horaire...). Un attaquant plus subtil utilisera des canaux cachés.

Il faut determiner la localisation de la tête de pont par rapport à la cible finale. Cette phase passe par une cartographie et un relevé technique sur le SI (plan d'adressage, version des systèmes...).

L'agresseur peut également préparer des accès (toujours illégitimes) de secours anticipant la découverte de l'intrusion initiale. Il peut également préparer des outils de collecte et de sortie des données pillées.

Selon les privilèges de l'utilisateur qui s'est fait berné et les protections des informations ciblées, l'attaquant utilisera les droits de ce dernier ou devra se servir d'un programme malveillant qui permettra à son cheval de Troie d'acquérir des droits d'administration.

Ces agissements rencontrés dans des attaques récentes montrent des attaquants déterminés et motivés. La réaction doit être globale et non limitée au déploiement de mesures techniques non administrées.

2.1 Recommandations

La défense en profondeur, combinant les aspects organisationnels, humains et techniques, demeure un principe de base face à ces attaques. Il en résulte des recommandations complémentaires :
  • élaborer une politique de sécurité des SI, connue de tous et qui reprendra des points ci-dessous ;
  • sensibiliser tous les utilisateurs à la SSI ;
  • cloisonner le système d'information ;
  • appliquer la politique des moindres privilèges, par exemple en limitant les comptes d'administration des postes et des domaines en nombre et dans leur usage, et en gérant de manière restrictive les droits d'accès sur les ressources ;
  • inclure la SSI dans l'informatisation des processus métier et dans le cycle de vie des applications ;
  • mettre en place des procédures de déploiement des mises à jour et des palliatifs ;
  • journaliser les accès réseau et les transactions, et les analyser (idéalement en continu) ;
  • prévoir des procédures en cas d'incident et de suspicion ;
  • utiliser des mots de passe forts ou des moyens d'authentification renforcée ;
  • répéter les mises en garde sur les supports amovibles (clefs USB, ordiphones et autres) ;
  • réévaluer les risques et amender la politique de sécurité.

2.2 Documentation


3 Rappel des avis émis

Dans la période du 01 au 07 avril 2011, le CERTA a émis les avis suivants :

  • CERTA-2011-AVI-182 : Vulnérabilité dans Juniper IVE
  • CERTA-2011-AVI-183 : Vulnérabilité dans Claroline
  • CERTA-2011-AVI-184 : Vulnérabilité dans IBM AIX
  • CERTA-2011-AVI-185 : Multiples vulnérabilités dans HP Operations for Unix
  • CERTA-2011-AVI-186 : Vulnérabilité dans HP Network Node Manager i
  • CERTA-2011-AVI-187 : Vulnérabilité dans Joomla!
  • CERTA-2011-AVI-188 : Vulnérabilité dans Novell File Reporter
  • CERTA-2011-AVI-189 : Vulnérabilités dans logrotate
  • CERTA-2011-AVI-190 : Vulnérabilité dans le client DHCP ISC
  • CERTA-2011-AVI-191 : Vulnérabilité dans xrdb (XOrg)
  • CERTA-2011-AVI-192 : Vulnérabilités dans WordPress
  • CERTA-2011-AVI-193 : Vulnérabilité dans la glibc
  • CERTA-2011-AVI-194 : Vulnérabilité dans Oracle Solaris

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

  • CERTA-2011-AVI-079-005 : Vulnérabilité dans plusieurs implémentations de Java (ajout de la référence au bulletin IBM swg21474615 Tivoli Directory Server)
  • CERTA-2011-AVI-164-001 : Vulnérabilité dans Xpdf sur Linux (ajout de la référence CVE CVE-2011-1554)


Liste des tableaux

Gestion détaillée du document

08 avril 2011
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-03-23