CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-41
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-2008-ACT-041.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-2008-ACT-041/ 1 Incidents traités cette semaine1.1 Des identifiants volés rendus publicsCette semaine le CERTA a traité plusieurs incidents relatifs à la divulgation sur l'Internet d'identifiants FTP compromis. Plusieurs centaines de comptes FTP et les mots de passe associés ont été découverts. Ces identifiants, provenant certainement de plusieurs sources (attaques par dictionnaires, enregistreurs de frappe, ...), semblent avoir été exploités par des individus malintentionnés pour injecter dans des pages Web légitimes sur les serveurs compromis des codes malveillants de type Neosploit. Ces compromissions étaient peu visibles et n'ont pas attiré l'attention de certains administrateurs de site Web. Le CERTA recommande de :
Dans le cas d'un compromission avérée, le CERTA recommande de suivre les règles de bonne conduite décrites dans la note d'information CERTA-2002-INF-002. Documentation
1.2 Compromission et rebondsLe CERTA a traité cette semaine un incident, somme toute assez banal, mais qui permet de faire un rappel de certaines règles de sécurité essentielles. Un serveur d'une administration a été compromis par un attaquant après une recherche exhaustive de mots de passe d'accès au service SSH, accessible depuis l'Internet. Une fois l'intrusion frauduleuse accomplie, l'attaquant a déposé un ensemble d'outils permettant d'utiliser le serveur compromis afin de conduire d'autres attaques par dictionnaire de mots de passe SSH. Dans un premier temps, cet incident aurait pu être évité si les règles de l'art dans la construction des mots de passe avaient été respectées (voir la note d'information CERTA-2005-INF-001). D'autre part, de l'aveu même de l'administrateur, le service SSH n'était utilisé que pour l'administration depuis le réseau interne. Il était donc légitime de filtrer au niveau du pare-feu les flux venant de l'Internet à destination de ce service. De même, les flux sortant à destination du port 22/tcp auraient dû être filtrés, ce qui aurait permis de bloquer les attaques conduites par rebond. En résumé, cet incident nous permet de rappeler les règles suivantes :
2 Filoutage et ingénierie socialeUne nouvelle méthode permettant la récupération des coordonnées bancaires et d'informations personnelles est apparue à la fin de cet été. Se présentant sous la forme d'un code malveillant, son installation permet d'inciter l'utilisateur victime à « activer » sa version de Microsoft Windows. Imitant parfaitement la véritable fenêtre d'activation, le code malveillant demande les coordonnées bancaires tout en précisant qu'aucune transaction ne sera effectuée. Répondant au nom de Kardphisher, ce cheval de Troie permet l'envoi des données récoltées à un serveur distant. Le CERTA rappelle qu'il est impératif de maintenir l'ensemble de son système d'information à jour (navigateur, antivirus, système d'exploitation, ...) afin de limiter l'installation « silencieuse » de ce type de programme. De plus, il ne faut jamais communiquer de coordonnées personnelles et/ou bancaires sans la certitude de la légitimité de la demande et l'assurance d'une transmission sécurisée de ces dernières vers une entité dûment authentifiée (ex: vérification des certificats). Dans le cas présent, le programme ne présente pas ces garanties. Enfin, ne jamais suivre de lien hypertexte ni ouvrir de pièce jointe provenant de courriel non sûr restent des précautions indispensables pour éviter toute installation de programme malveillant. 3 Les attaques en ClickjackingLes média ont beaucoup parlé cette semaine du clickjacking suite à l'annulation d'une présentation à la conférence OWASP 2008 sur le sujet à la demande de la société Adobe, et cela afin de lui permette de corriger les vulnérabilitées affectant ses produits. Malheureusement, les attaques de ce type ne concernant pas que les produits d'Adobe, cet article est l'occasion de voir de quoi il s'agit et comment essayer de s'en protéger. Comme son nom l'indique, il s'agit de détourner les clicks des utilisateurs pour leur faire exécuter des actions malgré eux. Ce nom ne désigne pas une vulnérabilité en particulier mais plutôt une faiblesse structurelle liée au fonctionnement du Web. Les utilisateurs font naturellement le parallèle entre appuyer sur un bouton visible et cliquer avec la souris, et n'imaginent pas qu'une multitude d'élements invisibles peuvent s'intercaler « entre » le curseur et l'élément qu'ils visualisent en-dessous. Les attaques en clickjacking se décomposent donc en deux étapes. La première concerne l'interception du click. La seconde est relative à l'utilisation de cette action à des fins malveillantes. Il existe de très nombreuses techniques pour détourner les actions de utilisateurs, que cela soit en utilisant des iframes transparentes qui recouvrent une page ou des iframes minuscules qui se déplacent avec le curseur. L'exemple suivant montre comment une section (balise DIV) peut être placée automatiquement sour le curseur (fonctionne avec Firefox).
<script language="JavaScript">
function position(e) {
document.getElementById("dd").style.left = e.pageX-20;
document.getElementById("dd").style.top = e.pageY-5;
}
document.onmousemove = position;
</script>
<div id="dd" style="position:absolute"> DIV sous la souris </div>
Une fois interceptés, les clicks reroutés sont utilisables dans le contexte de l'utilisateur et avec les droits de ce derniers, comme les attaques en CSRF (Cross Site Request Forgery). Donc tout ce que peut faire un utilisateur à l'aide d'un click, l'attaquant peut lui faire faire à son insu. Ansi un programme Flash spécifiquement réalisé pouvait utiliser un click intercepté afin d'activer le micro ou la caméra de la machine, comme si l'utilisateur les avait volontairement mis en marche dans le cadre d'une vidéo-conférence (la version 10 de Flash corrige cette vulnérabilité). Le problème peut se poser du côté serveur si des actions sont réalisables d'un simple click (achats, transferts d'argent, ajout de contact de confiance, ...). Il est donc possible de limiter, au niveau des sites, les effets des attaques en demandant une action supplémentaire à l'utilisateur (code pin, captcha, ...). Du côté du client, limiter l'utilisation des scripts et des iframe permet de réduire les risques. Des fonctionnalités de sécurité empêchant de cliquer sur des éléments « cachés » commencent à être ajoutées aux navigateurs et aux modules de sécurité. Documentation
4 Les boîtes à outils d'attaqueL'actualité a mis en avant la boîte à outils d'attaque Neosploit, mais le cas n'est pas isolé. Mpack a defrayé la chronique en juin 2007. D'autres kits sont utilisés avec plus ou moins d'écho dans les média. Certains outils sont verrouillés par leurs concepteurs, d'autres comme Neosploit ont un code source ouvert. Cela permet à des utilisateurs de traduire les interfaces utilisateur. Autre conséquence, la boîte à outils peut survivre à son équipe de développeurs. Ainsi, le 29 juillet 2008, les développeurs de Neosploit ont annoncé, par un message en russe, la fin des développements. La dernière version était alors la 3.0.7. Dès le 9 août 2008, une version 3.1 de Neosploit réapparaît. Ces boîtes à outils d'attaque comprennent deux volets qui correspondent à deux étages d'un système d'infection. 4.1 Modification de sites WebLe premier volet consiste à compromettre des sites Web, très fréquentés si possible. L'intrusion dans le site à modifier peut se faire de plusieurs manières :
Une fois entré sur un site avec des droits d'aministration, l'intrus insère dans les pages servies aux visiteurs du site des liens les orientant vers des sites malveillants. Ces liens peuvent se trouver dans beaucoup d'objets HTML. MPack faisait usage des cadres de type iframe, de taille infime (un pixel de côté) ou invisibles. Ils sont décrits dans le bulletin d'actualité CERTA-2007-ACT-025 du 22 juin 2007. Il est fréquent que le lien ne soit pas en clair mais calculé par des javascripts plus ou moins obscurcis (obfuscated). Ils sont décrits dans le bulletin d'actualité CERTA-2007-ACT-032 du 10 août 2007. Le script qui déchiffre reconstruit un lien ou un autre javascript dont l'apparence initiale est une chaîne aléatoire. Ce script est exécuté à son tour. Quelques indices peuvent trahir la présence de tels scripts :
4.2 Infection des ordinateurs des internautesL'internaute qui visite le site compromis est amené à suivre automatiquement des connexions vers des sites malveillants. Généralement le lien aboutit à un site qui lui-même renvoie vers un autre site. De rebond en rebond l'internaute est conduit jusqu'au site contenant la « charge utile ». Ce site est souvent sous le contrôle du développeur de la boîte à outils. Il contient divers codes malveillants ce qui permet d'adapter l'infection du poste de l'internaute à sa configuration :
Les codes d'exploitation des vulnérabilités au catalogue sont variées :
L'utilisateur de la boîte à outils, conducteur de l'infection, dispose de statistiques sur les ordinateurs compromis, les adresses IP, les quantités par pays, par système d'exploitation ou par code d'exploitation utilisé. 4.3 Recommandations4.3.1 Recommandations pour les administrateurs de siteLes administrateurs de site doivent veiller à leur intégrité :
4.3.2 Recommandations pour les internautesLes internautes offriront une moindre surface d'attaque en :
5 Projecteurs et fonctionnalités détournéesCertains modèles de projecteurs possèdent des fonctionnalités avancées allant au delà du simple affichage sur un écran de projection et des corrections optiques classiques (orientation, positionnement ou réglage du trapèze). En particulier, le CERTA a rencontré, lors d'une présentation, un projecteur doté d'un économiseur d'écran s'activant à chaque changement de résolution, lors d'un débranchement du câble vidéo ou au bout d'une période d'inactivité prolongée. Il s'agit bien ici d'une fonctionnalité du projecteur ne dépendant pas du tout du système d'exploitation de l'ordinateur qui y est branché. Or, si par défaut, cet économiseur affiche le logo du fabriquant, il est possible pour l'utilisateur, grâce à un menu avancé, de prendre une capture d'écran de ce qui est projeté et d'en faire ce qui sera affiché lors du déclenchement de l'économiseur. Sur le modèle manipulé, il n'était possible de stocker qu'une seule image, mais l' « intelligence » y est. Il est donc, en théorie, possible pour ce simple périphérique d'affichage de stocker les informations projetées sous forme d'image dans une mémoire qui lui est propre. On peut dès lors imaginer que, sur les modèles haut-de-gamme, on pourra stocker un nombre plus important de clichés ou même enregistrer une petite vidéo. Cette fonctionnalité peut donc avoir quelques
conséquences en termes de confidentialité. Car,
si elle est mise en Recommandations :Le CERTA recommande, lors de l'achat de ce type de matériel, de s'assurer qu'il n'embarque pas ce type de fonctionnalité en particulier s'il doit être déployé dans un environnement sensible.6 Mise à jour d'alertesCette semaine, le CERTA a mis à jour trois alertes publiées entre 2006 et 2007 :
Les vulnérabilités décrites dans les deux premières alertes ne sont pas pour autant corrigées, même si les documents apparaissent ainsi sur le site. La troisième alerte est toujours active. Les lecteurs sont invités à consulter ces alertes sur le site du CERTA pour plus de détails. Documentation
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
uvre, comment est-il
possible de s'assurer que rien n'est stocké à
l'insu de l'utilisateur ? Et lorsque le produit doit retourner
en maintenance chez le fabriquant, comment s'assurer qu'aucune
information sensible n'est stockée dans l'appareil ? Il
est à noter que cette technologie pourrait être
appliquée à tout autre type de
périphérique d'affichage comme de simples
écrans.