CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2011-14
Gestion du documentLe 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 IPCompLe 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éraliseLe 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 RecommandationsLa 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 :
2.2 Documentation
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
