CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2007-51
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-2007-ACT-051.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-051/ 1 Mise à jour de SquirrelMailNous avions évoqué, dans le précédent bulletin d'actualité, la compromission des versions en téléchargement de SquirrelMail. L'éditeur de ce webmail a rectifié son annonce en précisant que cette compromission a introduit une importante faille de sécurité (permettant l'inclusion de fichiers à distance) dans les sources du logiciel. Afin d'éviter toute confusion, une nouvelle version, 1.4.13, a été publiée. Tous les utilisateurs des versions 1.4.11 et 1.4.12 sont invités à appliquer cette mise à jour. Le CERTA n'a cependant pas publié d'avis de sécurité, car ces versions ne corrigent pas de problèmes de sécurité concernant l'application. Documentation :
2 Risques liés à l'utilisation d'outils de communication instantanéeLes outils de communication instantanée (on parle souvent de messagerie instantanée même si le terme « messagerie » n'est pas tout-à-fait approprié) tels que MSN, ICQ, IRC et autres, font l'objet des mêmes problèmes de sécurité que la messagerie (voir CERTA-2003-AVI-084) : propagation de vers et de canulars, phishing (hameçonnage), etc. La particularité de ces outils est leur aspect « instantané », c'est-à-dire que les utilisateurs ont tendance à réagir très rapidement aux messages reçus. Cette spontanéité fait de ces outils un très bon terreau pour la propagation de divers codes malveillants. Nous avons par exemple pu voir récemment des vers se propageant sur MSN. La mécanique de propagation était simple, elle reposait sur le carnet d'adresses (les contacts) de la victime. Cet incident a montré que les bons réflexes pour la messagerie n'étaient pas toujours appliqués sur MSN. Encore plus récemment, un message proposant des services pour MSN (en l'occurrence, vous informer des contacts qui vous ont bloqués ou supprimer de leur carnet d'adresses) a été largement diffusé par différents canaux (par MSN bien sûr, mais aussi par divers réseaux sociaux, blogs, etc.). Bon nombre de victimes étaient persuadées du bien-fondé de ce service... après avoir transmis à un site tiers leurs identifiants de connexion à MSN ! Dans ce cas précis, qui s'apparente à du phishing, de nombreuses d'adresses MSN ont pu être collectées, ainsi que les mots de passe associés à ces comptes. Les victimes doivent donc changer leur mot de passe ainsi que la question secrète, tout en gardant à l'esprit qu'un certain nombre de données personnelles éventuellement contenues dans les boîtes de messagerie associées ont déjà pu être capturées. Avec l'approche des fêtes de fin d'année, on
peut s'attendre à ce que de nouveaux codes malveillants
se propagent par l'intermédiaire de ces outils de
communication, par exemple sous la forme de cartes de v Recommandations :La vigilance et la méfiance requises pour la messagerie doivent également être de mise pour les outils de communication instantanée. Les problèmes sont ou seront les mêmes, ce sont les habitudes et les populations d'utilisateurs qui pour le moment diffèrent le plus. Certains outils de communication proposent, par leur paramétrage, des mesures de sécurité qui peuvent être mises en place. Il est important de bien examiner la configuration de ces outils. Documentation :
3 Problème avec Internet Explorer suite à la mise à jour mensuelle Windows de décembre 2007Cette semaine avant Noël, plusieurs personnes ont signalé des problèmes liés à l'installation de la mise à jour de sécurité KB942615 pour Internet Explorer relative au bulletin de sécurité MS07-069 du 11 décembre 2007. Cette mise à jour permet de protéger le système contre une vulnérabilité permettant l'exécution de code arbitraire à distance ou en local et un contournement de la politique de sécurité. Cette vulnérabilité a été détaillée dans l'avis CERTA-2007-AVI-540 du 12 décembre 2007.
3.0.1 Documentations
4 Problème de mise à jour du logiciel de messagerie ThunderbirdLe logiciel de messagerie libre Thunderbird existe à travers deux branches de développement : la branche 2.0.0.x, recommandée, et la branche plus ancienne 1.5.0.x . Une erreur dans le traitement des URI mailto: a été corrigée le 17 juillet 2007 par la fondation Mozilla, mais le mode de déploiement du correctif dans la branche 1.5.0 était insatisfaisant :
Il est donc recommandé :
Il faut enfin noter que la branche 1.5 de Mozilla Firefox n'est, elle, plus maintenue depuis la fin du mois d'avril 2007, comme il a été rappelé dans le bulletin CERTA-2007-ACT-016. Documentation :
5 Ordinateurs préinstallésIl est fréquent lorsque l'on fait l'acquisition d'un ordinateur dans le commerce ou bien lors d'un renouvellement de parc informatique de recevoir une machine disposant déjà d'un système d'exploitation évitant ainsi la fastidieuse étape de l'installation puis de la configuration du système et des logiciels appropriés. Or, cette étape est pourtant cruciale si l'on veut avoir un niveau de sécurité suffisant sur sa machine. En effet, ces ordinateurs pré-installés sont souvent configurés pour satisfaire les besoins du plus grand nombre. On trouve donc sur ce type de machines des applications parfois totalement inutiles, voire pas à jour et donc vulnérables. Il y a également des logiciels en version d'évaluation et très souvent des adaptations faites avec le système d'exploitation. Par exemple, dans l'avis CERTA-2007-AVI-556 rédigé le 19 décembre 2007, il est détaillé une vulnérabilité liée à une application spécifique à certains modèles de portables : elle concerne d'un contrôle ActiveX installé par défaut. Il est donc indispensable lors de l'achat tant d'ordinateurs de bureau que de portables de bien vérifier :
6 Les canaux cachés DNSDNS est un protocole largement utilisé pour déterminer la correspondance entre le nom d'une machine et son adresse IP associée. Un tunnel DNS se caractérise par des échanges illustrés dans la figure 1 ; à première vue, ce sont des échanges sous forme de requêtes et de réponses. La requête correspond à la demande du poste, comme par exemple pour accéder à la page d'accueil du CERTA www.certa.ssi.gouv.fr. Dans le cas présent, le poste se trouve
derrière un pare-feu, et ne peut normalement pas
communiquer vers l'extérieur. Le pare-feu n'est
cependant pas très regardant pour des protocoles
standards comme DNS, NTP ou ICMP et laisse sortir ces flux de
manière très laxiste. Ce cas de figure peut se
rencontrer dans la mise en La machine interne peut donc néanmoins émettre des requêtes DNS, qui sont soit directement envoyées vers un serveur DNS externe, soit transférées par un serveur DNS interne. La requête est généralement codée en Base32 (encodage équivalent à Base64, mais chaque caractère est codé sur 5 bits au lieu de 6, et il n'y a plus de distinction entre majuscule et minuscule). Elle concerne un sous-domaine bien particulier, géré par une personne qui en garde le contrôle (sous forme de « délégation » DNS du domaine par exemple). Le serveur est interrogé pour répondre à cette requête. Il va donc interpréter les données encodées, et les traiter. Il peut s'agir en réalité de données SSH, ou d'URL. Ce serveur a la possibilité de requérir les services d'un relais mandataire pour répondre, ou effectuer lui-même cette tâche. Sa réponse est ensuite envoyée sous forme d'un enregistrement de type TXT. Cet enregistrement est transmis de bout en bout, et doit en principe parvenir à la machine dans le réseau interne. L'administrateur de ce même réseau n'a que les trames DNS pour découvrir le contournement de la politique de sécurité mise en place au niveau du pare-feu. Le schéma est volontairement simplifié sur la figure 1 :
Cet usage est très souvent un contournement de la politique de sécurité et reste mal connu des administrateurs. Pour toutes ces raisons, le CERTA émet quelques recommandations :
Documentation
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
ux.
uvre d'un portail
captif Wi-Fi. Un autre cas de figure consiste à
simplement bloquer les ports HTTP/HTTPS courants (80,443,8080,
...) et à ne pas donner l'accès du relais
mandataire web aux utilisateurs qui ne doivent pas
naviguer.
uvre
cette architecture, y compris le tunnel SSH mentionné
précédemment, sont très accessibles et
largement documentés sur l'Internet. D'autres
enregistrements comme KEY avec DNSSEC sont
également utilisés...