1 Mots de passe et incidents
Le CERTA traite régulièrement des incidents liés à l'utilisation frauduleuse d'identifiants de connexion. Nous distinguons trois catégories principales d'incidents : - les mots de passe faibles ;
- les mots de passe mal protégés ;
- la capture des mots de passe.
1.1 Les mots de passe faibles
La fragilité des mots de passe est un problème fréquemment rencontré. De nombreux utilisateurs conçoivent leur mot de passe en se basant entre autres sur des mots du dictionnaire, des dates ou des noms propres. Il arrive parfois que le mot de passe soit tout bonnement le nom du compte. Ce phénomène survient souvent avec les comptes de test ou encore au moment de la création des profils utilisateur. Cette faiblesse expose les machines à des accès frauduleux, notamment suite à des attaques dites « par dictionnaire ». Ces attaques sont assez courantes, les services SSH et FTP ayant été particulièrement ciblés ces dernières années.
Quelques mesures peuvent être mises en place pour prévenir ce risque. L'une d'entre elles consiste à forcer le changement de mot de passe lors de la première connexion de l'utilisateur et à appliquer des règles de construction particulières (utilisation obligatoire de plusieurs groupes différents parmi les majuscules, minuscules, chiffres et caractères spéciaux, longueur minimum, etc.). L'administrateur peut également tester régulièrement la robustesse des mots de passe à l'aide de certains outils.
1.2 Les mots de passe mal protégés
Les mots de passe sont parfois stockés « en clair » dans certains fichiers qui sont accessibles par tous. Le CERTA a traité quelques cas d'incidents d'accès frauduleux rendus possible car le mot de passe était en clair dans un fichier accessible depuis l'Internet. Il est extrêmement important d'éviter de stocker les mots de passe dans des fichiers. Si ce n'est pas possible, alors il convient de mettre des droits très restrictifs sur ces fichiers.
Il est important de garder à l'esprit que les mots de passe sont parfois stockés « accidentellement » dans des fichiers. C'est le cas avec les historiques d'interpréteur de commandes lorsque les identifiants sont passés en paramètres d'une ligne de commande et avec les journaux de connexion lorsque l'utilisateur saisit par erreur son mot de passe au lieu du nom de compte.
1.3 La capture des mots de passe
Un grand nombre d'applications ont un mécanisme d'authentification faible car il repose sur l'envoi du mot de passe « en clair ». C'est le cas, entre autres, pour TELNET ou FTP. Le mot de passe peut être intercepté par des utilisateurs sur le même réseau local (notion beaucoup plus large dans le cas d'un réseau sans-fil) qui feraient usage d'un renifleur réseau (sniffer).
Il est suggéré, quand c'est possible, de chiffrer l'authentification. Par exemple, pour les serveurs Web, il est possible d'utiliser le protocole HTTPS. Les attaques par capture seront beaucoup plus complexes à réaliser. De même, le remplacement de TELNET par SSH, et de FTP par SCP, SFTP ou FTPS est une bonne chose.
Enfin, la capture est possible directement sur le poste de l'utilisateur si un enregistreur de frappes clavier ou de mouvement de la souris est installé, que la phase d'authentification soit chiffrée ou non. Il n'y a pas de réelle parade à ce type d'attaques, une fois l'enregistreur installé. L'hygiène informatique et comportementale doit prévenir l'installation d'un tel code malveillant.
Documentation
Note d'information CERTA-2005-INF-001 « Les mots de passe » :
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-001/
2 Les cadres pour photos numériques WiFi et autres « gadgets » autonomes
Après les lapins communicants Nabaztag discutés dans le bulletin d'actualité CERTA-2006-ACT-052, de nouveaux périphériques multimédia réseaux autonomes voient le jour. Parmi ceux-ci, il y a les cadres photo numériques. Ces nouveaux appareils se présentent sous la forme d'un cadre contenant un écran LCD et permettant de faire défiler des photos ou des films. Alors que les versions les plus répandues nécessitent que les médias à afficher soient chargés dans la mémoire de l'appareil via soit une connexion directe à un ordinateur, soit un support amovible (clef USB ...), les derniers modèles sont dits « communicants » et peuvent automatiquement récupérer les fichiers sur un ordinateur en se connectant au réseau local, voir même sur Internet. Les "e-lapins" ne s'installaient qu'au domicile d'une catégorie d'utilisateurs restreints, mais ce type d'objets décoratifs pourrait séduire un plus large public.
Outre le fait que ces appareils peuvent présenter les mêmes risques que tout support de données amovibles en USB, comme décrits dans la note d'information CERTA-2006-INF-006, ces cadres sont également des machines , avec un système d'exploitation et une interface réseau (WiFi). Bien que succinctes, ces machines possèdent donc les même caractéristiques qu'un vrai ordinateur (des services, de l'espace de stockage..). Seulement, pour celles-ci, il est difficile de contrôler l'état des mises à jour des correctifs de sécurité, et ses activités.
Certains cadres pour photos numériques WiFi offrent deux modes pour récupérer les photos :
- ils se connectent à un serveur Internet dédié, et récupèrent les photos que l'utilisateur aura laissées sur son espace personnel sur ce même site ;
- ils se connectent à l'ordinateur, sur lequel une application dédiée a été installée et permet le partage derépertoires.
Dans les deux configurations, il est difficile actuellement de comprendre les interactions exactes qui ont lieu.
Associer un cadre à une machine d'un réseau revient donc à donner à une machine inconnue et non maîtrisée un accès aux réseaux interne et externe. Par ailleurs, pour plus de simplicité et de convivialité, l'utilisateur est encouragé à partager des images présentes sur son ordinateur avec le cadre, et donc ouvrir un accès privilégié à un utilisateur virtuel inconnu.
Ce type de périphériques WiFi au contenu inconnu a tendance à « gadgétiser » l'utilisation du réseau et à faire baisser de façon drastique le niveau de sécurité et la prise de conscience du degré de risque.
Le CERTA est revenu à plusieurs reprises dans ces dernières publications sur les risques liés aux pilotes des interfaces sans-fil. Il s'agit d'une problématique importante, et difficile à gérer. Il est donc normal d'apporter le plus grand doute sur ces appareils WiFi qui ne font aucune mise à jour, et qui présentent par ailleurs les même caractéristiques qu'une machine.
Le CERTA déconseille fortement de les relier à un réseau professionnel. Il invite également ses correspondants à auditer régulièrement les bâtiments à la recherche de « gadgets » communiquants, qu'ils soient sous forme de cadre ou de lapin, et à sensibiliser les utilisateurs aux risques de leur utilisation.
3 Fausses mises à jour Microsoft
De nombreux codes malveillants exploitent des techniques d'ingénierie sociale de façon à tromper l'utilisateur afin qu'il réalise lui-même une action qui le mènera à compromettre son ordinateur.
Parmi ces techniques, ils existent les fausses mises à jour pour Microsoft Windows. En général, ces codes malveillants se propagent par messagerie électronique en usurpant une adresse électronique provenant de Microsoft. Tout en prétextant une mise à jour critique, ils incitent l'utilisateur à "double cliquer" sur la pièce jointe ou à suivre un lien. En fait de mise à jour, l'internaute naïf installe un code malveillant.
L'une des dernières variantes de ces codes malveillants utilise l'interface que Microsoft présente à l'utilisateur. Elle peut apparaître en visitant un site (fenêtre surgissante). Ainsi, cette boîte de dialogue ressemble à s'y méprendre à la véritable boîte de dialogue de mise à jour de Microsoft Windows.
L'application ou/et l'annonce de mise à jour pour Microsoft Windows ne se fait jamais par messagerie électronique et ce pour au moins deux raisons :
- les risques liés à l'utilisation de la messagerie électronique dont l'usurpation d'identité ;
- l'existence du mécanisme de mise à jour automatique dans Microsoft Windows.
C'est pourquoi dès la réception d'un message électronique annonçant la publication de mise à jour de sécurité pour Microsoft Windows, il est recommandé de :
- ne pas suivre le lien proposé ;
- ne pas ouvrir une pièce jointe au message ;
- réaliser l'opération "Windows Update" manuellement.
Il est possible de vérifier la véracité de tels messages de mise à jour en se rendant sur le site de l'éditeur :
http://www.microsoft.com/technet/security/current.aspx
4 Les cadres incorporés, ou IFRAME
4.1 Présentation générale
Un IFRAME est un élément proposé par HTML 4.0, qui permet d'afficher dans une page Web, un cadre, contenant du code HTML local ou distant. Parmi les attributs offerts avec l'élément, il y a :
- src : la source du contenu à insérer dans le cadre ;
- name : le nom du cadre, permettant de construire des liens vers celui-ci ;
- frameborder : variable servant à activer ou désactiver la bordure ;
- longdesc : description du contenu du cadre ;
- scrolling : variable donnant la possibilité ou non d'utiliser la roulette de la souris ;
- ainsi que toutes les options pour gérer le cadre, comme sa visibilité, sa largeur, sa longueur, sa position dans la page, les marges, etc.
Cet élément est très semblable fonctionnellement à un autre élément, nommé OBJECT. Cependant, ce dernier est inclus, lui, dans le type de documment « HTML Strict » (la déclaration se fait normalement dans les premières lignes du document HTML). Le contenu de l'élément IFRAME ne devrait être affiché, en revanche, que par les navigateurs qui ne reconnaissent pas le cadre ou qui sont configurés pour ne pas les afficher, comme en illustre l'exemple suivant :
<_IFRAME http://www.certa.ssi.gouv.fr width="400" height="500"
scrolling="auto" frameborder="1">
Si vous lisez ce message, cela signifie que votre navigateur
ne reconnait pas les cadres,
ou que votre configuration en empeche l'affichage.
Vous pouvez n�anmoins visualiser la page en vous rendant sur :
<_A href="http://www.certa.ssi.gouv.fr"> la page CERTA </_A>
</_IFRAME>
Les fonctionnalités sont multiples, et il est également possible d'imbriquer des jeux d'encadrement (cf. l'élément FRAMESET).
4.2 Des défigurations de sites
Plusieurs incidents ont été récemment signalés. Le mode opératoire est le suivant :
- plusieurs sites sont défigurés en très peu de temps. Cette phase de défiguration massive est généralement dûe à une vulnérabilité nouvellement trouvée sur une application Web ou sur une administration laxiste (cf. Section 1);
- la défiguration du site, loin d'être évidente, consiste au simple ajout d'un élément IFRAME dans la page. Celui-ci passe donc assez inaperçu.
- les utilisateurs qui naviguent sur une des pages défigurées se voient redirigés par le champ "src" de l'IFRAME (directement ou après quelques redirections) vers une page malveillante. Celle-ci contient un ensemble de vulnérabilités choisies en fonction du poste de l'internaute. Lorsque le navigateur de l'utilisateur interprète à son insu cette page, ces vulnérabilités compromettent le système s'il n'est pas à jour ou s'il est configuré de manière trop laxiste ;
- cette contamination permet d'obtenir un ensemble de machines compromises zombis (botnet), utilisées pour lancer des attaques en déni de service. Mais, elle permet aussi de dérober différents types de données et d'informations depuis les machines compromises.
4.3 Les recommandations du CERTA
4.3.1 à l'administrateur
Pour l'administrateur du site, il faut garder à l'esprit que l'utilisation de ce genre de cadres peut être dangereuse par nature. En effet, il s'agit d'intégrer dans une page légitime un contenu extérieur non maîtrisé. Défigurer la page vers laquelle l'IFRAME pointe permet de défigurer tous les sites ayant l'élément IFRAME.
L'intégrité, sur les sites relativement statiques, doit être rigoureusement surveillée, par exemple avec des techniques d'empreintes (MD5, SHA1, etc.), ces dernières n'étant pas stockées sur le même serveur. Une simple surveillance de l'aspect visuel des pages n'est clairement pas suffisant, pour plusieurs raisons :
- cette tâche peut difficilement être faite sur l'ensemble des pages d'un site conséquent ;
- cette tâche est purement humaine et visuelle : l'administrateur risque ainsi de ne pas apercevoir de minimes défigurations, comme un changement de commentaire d'une figure, ou une phrase de texte.
- tout changement dans le code de la page, et non visible, ne sera pas détecté. Le cas des IFRAME en est un excellent exemple.
L'administrateur du réseau doit aussi prévenir ce genre de compromission, en limitant par exemple l'usage des IFRAME à certains sites, ou en appliquant quelques règle simples. Une source "src" écrite avec une adresse IP n'est pas courante par exemple, sauf dans le cas des attaques précédemment décrites. Dans l'exemple ci-dessous, le format du champ "src" est peu commun, ainsi que le style, et l'IFRAME n'a aucun contenu pour les navigateurs ne reconnaissant pas le cadre :
<_IFRAME XX.XX.XX.XX/index.php (...) style=display:none"> </_IFRAME>
L'option de style aurait tout aussi bien pu être "visible:hidden", voir ne rien chercher à dissimuler.
4.3.2 à l'utilisateur
Il est toujours possible de refuser l'affichage des cadres IFRAME, même si cette solution peut perturber la navigation de plusieurs sites. Sous Firefox, cela se fait par le biais de l'adresse « about:config » dans la barre d'adressage, en modifiant la variable browser.frames.enabled à false. Sous Internet Explorer, il est possible, dans l'onglet « Sécurité » qui spécifie les niveaux de sécurité de la zone Internet, de personnaliser l'option « Lancement des programmes et des fichiers dans un iFrame ».
De manière générale, les incidents cités ci-dessus ont surtout posé problème aux utilisateurs qui n'avaient pas les dernières mises à jour appliquées sur leur système d'exploitation. La méthode décrite ne fait qu'attirer les utilisateurs de manière artificielle vers des codes exploitant des vulnérabilités connues. C'est pourquoi le CERTA insiste encore et à nouveau sur l'importance d'avoir un système à jour, surtout quand celui-ci est connecté à l'Internet.
5 MOSEB : Month of search engine bugs
Dans la lignée des month of browser bugs, month of PHP bugs et autres initiatives divulguant des failles sur des applications spécifiques en un mois, juin 2007 est consacré à des vulnérabilités trouvées sur des moteurs de recherche : le MOSEB, ou month of search engine bugs. A la date de rédaction de cet article, 20 moteurs de recherche différents ont fait l'objet de publication de vulnérabilités, soit un par jour avec parfois plusieurs failles les concernant.
Parmi ces moteurs de recherche, on rencontre les plus connus tels que google.com, yahoo.com, lycos.com et msn.com.
Les failles sont toutes des injections indirectes de code ou cross-site scripting (XSS), et détaillées avec des exemples d'exploitation qui montrent les risques de ce type de vulnérabilité : injection de code html, redirection, exécution de code sur le poste de l'internaute, etc.
Des exemples intéressants de vulnérabilités concernent les moteurs de recherche locaux, comme Google Custom Search Engine et le moteur local d'Altavista. Les risques sont les mêmes que pour les autres moteurs, mais l'étendue est plus grande. Les attaques en cross-site scripting sont en effet alors possibles sur tous les sites implémentant ces moteurs locaux sans protection supplémentaire.
Certaines failles ont d'ores et déjà été corrigées. Ce month of search engine bugs nous montre cependant qu'un site offrant un moteur de recherche n'est pas nécessairement de confiance pour deux raisons principales :
- il retourne du contenu (les pages ou les adresses de pages indexées, les images, etc.) qui ne dépend pas de lui. Ce contenu peut être malveillant.
- il prend comme données d'entrée les requêtes de l'utilisateur, ce qui peut favoriser les attaques de type injection de code indirecte (XSS).
Tout lien associé à une page proposant un moteur de recherche est donc à suivre avec précaution, la première étant la désactivation du Javascript.
