S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information
|
 |
|
Paris, le 22 juin 2007
No CERTA-2007-ACT-025 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2007-25
Une gestion de version détaillée se trouve
à la fin de ce 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-2007-ACT-025.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-2007-ACT-025/
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.
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.
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.
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.
Note d'information CERTA-2005-INF-001 « Les mots de
passe » :
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-001/
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.
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 en va de même si une fenêtre apparait
étrangement à l'écran.
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
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 src="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).
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.
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 src="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.
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.
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.
6 Rappel des avis émis
Durant la période du 15 au 21 juin 2007, le CERTA a
émis les avis suivants :
- CERTA-2007-AVI-264 : Vulnérabilité dans
OpenOffice
- CERTA-2007-AVI-265 : Vulnérabilités dans
Safari
- CERTA-2007-AVI-266 : Vulnérabilité dans
Novell NetWare
- CERTA-2007-AVI-267 : Vulnérabilité de
Tomcat
- CERTA-2007-AVI-268 : Vulnérabilité dans
Apache SpamAssassin
- CERTA-2007-AVI-269 : Vulnérabilités dans
Astaro Security Gateway
- CERTA-2007-AVI-270 : Vulnérabilité dans HP
System Management Homepage
- CERTA-2007-AVI-271 : Vulnérabilités dans
IBM WebSphere Application Server
- CERTA-2007-AVI-272 : Vulnérabilité dans les
produits F-Secure
- CERTA-2007-AVI-273 : Vulnérabilités dans
VLC Media Player
- CERTA-2007-AVI-274 : Vulnérabilité dans
PHPMailer
Pendant la même période, les avis suivants ont
été mis à jour :
- 22 juin 2007
- version initiale.
CERTA
2012-01-04
|
)
