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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-14

Gestion du document

Référence CERTA-2011-ACT-014
Titre Bulletin d’actualité 2011-14
Date de la première version 08 avril 2011
Date de la dernière version 08 avril 2011
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 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

Rappel des avis émis

Dans la période du 28 mars au 03 avril 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 08 avril 2011
    version initiale.