S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 12 octobre 2007
N° CERTA-2007-ACT-041
Affaire suivie par: CERT-FR
le 12 octobre 2007

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-41

Gestion du document

Référence CERTA-2007-ACT-041
Titre Bulletin d’actualité 2007-41
Date de la première version 12 octobre 2007
Date de la dernière version 12 octobre 2007
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Les sites épaves, écueils pour la navigation sur l’Internet

Deux incidents traités par le CERTA rappellent que l’abandon d’un site web n’est pas si simple.

1.1 Les mésaventures

Le schéma est le même dans les deux cas, malgré la différence d’environnement technique et organisationnel. Un organisme a développé un site web sur une première infrastructure. À la suite de diverses évolutions, il décide de faire migrer ce site vers un nouvel environnement. Cette migration se traduit par plusieurs changements, dont l’hébergeur, le nom de domaine et l’adresse réseau. Le nouveau site est mis en service avec succès, mais l’ancien est oublié …Sauf pour des internautes peu scrupuleux. Ne faisant plus l’objet de surveillance et sans mise à jour des logiciels, l’ancien site resté en ligne est une proie facile. De surcroît, les journaux de l’ancien site ne sont plus du tout consultés, ce qui contribue à maintenir les intrus plus longtemps sur le système. Selon les incidents traités, l’ancien site héberge des codes malveillants ou sert à des cyber-affrontements.

Dans chacun des incidents traités par le CERTA, l’ancien site ayant gardé un nom en rapport étroit avec l’organisme français, les méfaits commis par les intrus entachent l’image de l’organisme. La rupture de liens, contractuels ou techniques, rend difficile la gestion de l’incident.

1.2 Des recommandations

Lors d’un changement d’infrastructure, plusieurs précautions sont utiles :
  • attendre la mise en service du nouveau site avant d’abandonner l’ancien ;
  • sur l’ancien site et selon la configuration, ôter tout accès, logiciel ou script susceptible de faciliter une intrusion, par exemple :
    • accès réseau vers l’ancien serveur supprimé (ajout de filtrage, DNS, suppression d’adresse ou de machine…) ;
    • logiciel serveur web, PHP, SQL désinstallé du serveur ;
    • configuration du serveur web adaptée (nom de l’hôte virtuel retiré, port fermé…) ;
    • pages en PHP, CMS, remplacés par une page HTML statique. Cette page, qui peut contenir une directive de redirection vers le nouveau site, permettra en même temps d’informer le public légitime ;
  • une fois ce serveur « ancien » ainsi nettoyé, le nom d’hôte doit pointer vers l’adresse IP du nouveau site ;
  • une fois ce routage modifié, le nom d’hôte peut être moins surveillé et le site ancien réellement abandonné.

2 Nouveautés du côté d’Internet Explorer

2.1 Le téléchargement d’Internet Explorer 7 évolue

Depuis le 4 octobre 2007, Internet Explorer 7 de Microsoft est disponible pour tous les utilisateurs de Windows XP. Cette annonce a été publiée sur le blog du butineur de Microsoft. La mise à jour du navigateur ne requiert plus de validation de Windows Genuine Advantage (WGA). Cette mise à jour est disponible en téléchargement sur le site de Microsoft ou via les mises à jour automatiques. Jusqu’à présent l’installation d’Internet Explorer 7 n’était possible qu’après vérification de l’authenticité de la copie de Windows XP. La nouvelle version du navigateur est désormais disponible pour l’ensemble des utilisateurs de Windows XP SP2.

2.2 Microsoft : une mise à jour facultative

Microsoft publie des mises à jour prioritaires le deuxième mardi de chaque mois. L’éditeur peut également publier d’autres mises à jour à la même date. Ce fut le cas en octobre. Une mise à jour non prioritaire ajoute des certificats d’autorités de certification dans le navigateur Internet Explorer. Cinq autorités sont concernées : deux espagnoles, une finlandaise, une lettone et une turque.

Documentation

http://support.microsoft.com/kb/931125

3 Les risques des clés USB

Le CERTA rappelait la semaine dernière dans son bulletin d’actualité les risques liés à l’utilisation d’applications placées sur des supports de stockage amovibles. Le 8 octobre dernier, la région Ile de France a distribué 173 000 clés USB (Universal Serial Bus) aux lycéens et apprentis de la région. Ces clés sont présentées comme un « bureau mobile » ou un « cartable électronique ». Ce projet est observé à l’éclairage de la mise en garde publiée la semaine dernière par le CERTA dans son bulletin d’actualité. Ces clés offrent la possibilité d’utiliser des logiciels libres sous Windows comme1 :

  • OpenOffice 2.1 (version actuelle 2.3) ;
  • Sumatra 0.7 ;
  • Mozilla Sunbird 0.5 ;
  • Firefox 2.0.0.6 (version actuelle 2.0.0.7) ;
  • Thunderbird 2.0 version actuelle 2.0.0.6 ;
  • Wengophone 2.1 ;
  • Filezilla ;
  • Miranda 0.4 (version actuelle 0.7);
  • VLC Média Player 0.8 (version actuelle 0.8.6) ;
  • Coolplayer ;
  • Comice ;
  • Juice 2.1 (version actuelle 2.2) ;
  • 7zip ;
  • Fullsync 0.9 (version actuelle 0.9.1) ;
  • InfraRecorder 0.4 (version actuelle 0.43.1) ;
  • ClamWin ;
  • Truecrypt 4.3 ;
  • Keepass 1.0.8 ;
  • Locknote 1.0 (version actuelle 1.0.3).

Le CERTA attire donc l’attention sur la nécessité de mettre à jour les applications.

Ces objets peuvent être facilement perdus ou volés. Le CERTA rappelle qu’il existe des applications capables de copier l’intégralité de la mémoire de ces supports de stockage afin d’y retrouver des données, même si celles-ci ont été préalablement effacées (traces résiduelles possibles). Ces logiciels sont également capables d’insérer des codes malveillants sur le support, afin de les utiliser comme vecteur de propagation.

Il est donc nécessaire d’utiliser les outils de chiffrement des données disponibles et de minimiser les données personnelles présentes sur le support.

Les clés USB de ce projet ayant pour vocation à être utilisées sur plusieurs ordinateurs, il est important d’attacher une attention toute particulière à la non compromission de celles-ci et des systèmes sur lesquels elles sont montées.

Le CERTA tient à rappeler les précautions à prendre quant à l’utilisation de ces périphériques :

http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-040.pdf

4 Vulnérabilité dans le traitement des URI

Cette semaine le CERTA a diffusé l’alerte CERTA-2007-ALE-015. Celle-ci concerne une vulnérabilité de Microsoft Windows dans le traitement d’URIs, et ne fonctionne que sur les systèmes Windows XP et Windows Server 2003 ayant Internet Explorer 7. Windows Vista n’est pas impacté. Comme pour certaines vulnérabilités récentes, la vulnérabilité est en réalité double et concerne à la fois les éditeurs d’applications et Microsoft.

En juillet 2007, l’alerte CERTA-2007-ALE-013 portait sur cette même vulnérabilité liée à Mozilla Firefox. Il était ainsi possible, via un lien ou même un iframe spécifiquement construit, d’exécuter des commandes arbitraires sur le poste de l’utilisateur. Mozilla a rapidement corrigé le problème de son côté, du moins en partie (cf. l’article « Traitement des URI par Mozilla Firefox » du bulletin CERTA-2007-ACT-036).

Plus précisément, la vulnérabilité concerne la fonction de Windows ShellExecute() appelée par diverses applications. Cette fonction traite la chaîne qui lui est passée en argument et en extrait soit un protocole soit une extension, pour lancer ensuite le programme associé spécifié dans la base de registres. Voici deux exemples pour illustration :

  1. exemple : protocole
    • la chaîne « http://www.certa.ssi.gouv.fr » est passée en argument par l’application ;
    • la sous-chaîne « http:// » est reconnue comme protocole valide ;
    • ShellExecute va donc visualiser la clé HKEY_CLASSES_ROOT/TT> pour connaître le programme à lancer, par exemple, Internet Explorer.
  2. exemple : extension de fichier
    • la chaîne « index.htm » est passée en argument par l’application ;
    • la sous-chaîne « .htm » est reconnue comme extension ;
    • la clé HKEY_CLASSES_ROOT/TT> est alors visualisée, qui redirige vers HKEY_CLASSES_ROOT/TT> pour connaître le programme à lancer.

L’installation de Internet Explorer 7 change l’interaction entre le shell Windows et Internet Explorer lors du traitement d’URIs. Avec Internet Explorer 5 ou 6, une URI de type mailto:% lançe l’application de messagerie enregistrée dans la base de registre, alors que cette chaîne est mal formée. L’installation d’Internet Explorer 7 change cela, en rejetant la chaîne avant le lancement du programme associé. Toutefois ShellExecute tenterait ensuite, selon Microsoft, de réparer la chaîne, et lance ainsi une application en fonction de l’extension et non du protocole. Cela n’est cependant pas le cas sous Windows Vista.

En remarque,le RFC 2368 est dédié au format des URLs de type mailto. On peut y lire que les caractères réservés de type parenthèses, virgule ou signe de pourcentage % doivent être traduits (encodage). Ainsi, % ne peut apparaître dans une URL de type mailto que pour introduire un hexadécimal, ou doit sinon être converti en %25.

C’est ainsi que l’URL mailto:%../../../../windows/system32/calc.exe ».bat cause le lancement du programme de courriel si Internet Explorer 6 est installé, mais le programme calc.exe si Internet Explorer 7 est installé. A cause de l’extension .bat, ShellExecute lance la valeur enregistrée dans HKEY_CLASSES_ROOT/TT>, c’est à dire « %1 » %*. La chaîne passée en argument après traitement est difficile à déterminer, mais le résultat final est le lancement de calc.exe. Des tests internes au CERTA ont de plus montré qu’il est trivial de passer des arguments au programme exécuté. Fondamentalement toutes les URI sont touchées puisque le facteur déclenchant n’est pas le protocole choisi mais l’extension. Cela dépend toutefois de l’application appelante qui peut elle-même limiter les types d’URI autorisées.

La vulnérabilité concerne donc la fonction ShellExecute. Néanmoins toute application convenablement conçue doit également vérifier les chaînes qu’elle passe en argument ; c’est de cette manière que Mozilla a corrigé la faille touchant Firefox.

Adobe a reconnu récemment que son logiciel Adobe Reader était touché par cette vulnérabilité pour les URI de type mailto, et a publié un contournement provisoire. Le 10 octobre 2007, Microsoft a également réagi en annonçant qu’un correctif était en cours de développement, ce qui devrait corriger le problème pour toute application appelant ShellExecute sans filtrage préalable.

Documentation

5 Des injections de code indirectes : triche au compteur

5.1 Introduction

Le CERTA a mentionné dans son bulletin d’actualité CERTA-2007-ACT-040 les deux points suivants :

  • il existe plusieurs formes d’injections de code dans une page de site Web, pour des finalités différentes, incluant les défigurations, ou modifications visuelles de la page ;
  • une injection de code dans une page d’un site Web n’est pas nécessairement une défiguration.

Le CERTA revient donc sur ce dernier point, pour donner l’exemple d’injections de code originales, avec des finalités très particulières.

5.2 La mesure d’audience et la publicité

Plusieurs lignes de codes sont fréquemment ajoutées par les développeurs dans les pages Web, sans que celles-ci soient nécessaires au bon fonctionnement de la page. Les ajouts de la sorte, fréquents, peuvent être utilisés pour compter la fréquentation du site, ou pour activer des liens publicitaires.

5.2.1 Les compteurs de fréquentation

Un compteur se présente souvent sous la forme d’un webbug, i.e. d’une image non visible par l’internaute sur la page, qui envoie, à son chargement, des informations vers le site de statistique central, comme : le type de navigateur utilisé (User-Agent), la page Web visitée, la date, l’adresse IP du visiteur, etc.

D’autres méthodes existent aussi, comme le JavaScript, pour effectuer une telle opération. Il s’agit d’une forme d’espiogiciel (défini comme un outil de « collecte et transmission d’informations à l’insu de l’utilisateur », dans la terminologie CERTA-2006-INF-002).

L’exemple ci-dessous est tiré du code source de certaines pages Web, avec le service audientia. D’autres services comme xiti, cybermonitor, etc. ont une approche très semblable.

    <!– Begin WEBandSTATS Tag … –>
<!– COPYRIGHT AUDIENTIA ALL RIGHTS RESERVED. –>
<_script language=’javascript1.1′ type= »text/javascript »><!–
var SITE_ID          = « XXXXXX »;
var PAGE_URL         = escape(« http://MonSiteWeb »);
var PAGE_NAME        = « MonSiteWeb »;
(…)

var wasb = ‘?SITE_ID=XXXXXX&REFERRER=’+escape(document.referrer)+
                ‘&LOCAL_DATE=’+(new Date()).getHours();
wasb += ‘&JS_VERSION=10&PAGE_TITLE=’+escape(document.title)+
                ‘&PAGE_NAME=’+escape(PAGE_NAME);
wasb += ‘&PAGE_URL=’+PAGE_URL+’&HANDLE_PARAM=’+HANDLE_PARAM+
                ‘&GALLERY_NAME=’+escape(GALLERY_NAME);
        ‘&PARAMETERS=’+escape(PARAMETERS);
(…)


var wasImg = new Image();wasImg.src = wasa+wasb;};//–>
</_script>


<_noscript>
<_img http://apu03c0.audientia.net:80/scripts/stats.asp?SITE_ID=XXXXXX&
        PAGE_URL=&HANDLE_PARAM=NO&GALLERY_NAME=&GALLERY_PRODUCTID=
        alt= »statistiques de fr&eacute; quentation (audientia) » />
</_noscript>
<!– End WEBandSTATS Tag –>

5.2.2 Les revenus publicitaires

Suivant le même principe, les sites peuvent également servir de vitrine publicitaire. La rémunération se fait en fonction des clics que le site engendre. Plus un site redirige vers l’annonceur, plus sa « contribution publicitaire » est récompensée.

Des services permettent de compter les clics, et servent à des transactions financières. Ils fournissent également les codes à insérer dans les pages Web. Un exemple est le service Google Adsense. Le code inséré ressemble à :

<_script type= »text/javascript »><!–
google_ad_client = « pub-XXXXXXXXXXXXXXXXXXXXX »;
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = « 160x600_as »;
google_ad_type = « text_image »;
google_ad_channel = «  »;
google_color_border = « FFFFFF »;
google_color_bg = « FFFFFF »;
google_color_link = « 0000FF »;
google_color_text = « 000000 »;
google_color_url = « 191970 »;
//–>
</_script>
<_script type= »text/javascript »
http://pagead2.googlesyndication.com/pagead/show_ads.js>
</_script>

5.3 L’injection de code malveillant, comme effet secondaire

Reprenons donc les deux échantillons de code cités ci-dessus. Si une personne peut modifier le code source de la page (hypothèse malheureusement confirmée lors du traitement de défigurations), voici des scénarii possibles d’injection de codes :

  • la variable SITE_ID prend maintenant pour valeur YYYYYY ;
  • l’adresse apu03c0.audientia.net est remplacée par MonSiteMalveillant ;
  • la variable google_ad_client a pour nouvelle valeur « pub-YYYYYYYYYYYYYYY »
  • etc.

L’injection se limite donc à modifier très peu de champs de ces codes tiers dans les pages. Elle risque fort de passer inaperçue aux yeux de l’administrateur du site qui ne vérifie pas l’intégrité du code complet du site. Elle permet en revanche à une personne malveillante d’effectuer les actions suivantes :

  • fausser les compteurs de fréquentation des sites ;
  • collecter efficacement des informations sur les visiteurs du site à distance ;
  • effectuer de la fraude pour les techniques de paiement au « clic » ;
  • etc.

Il est également possible d’imaginer des actions plus furtives, qui modifient le code Javascript pour continuer à créditer occasionnellement le vrai site, afin de ne pas trop éveiller les soupçons d’un responsable de communication anxieux.

5.4 Les recommandations du CERTA

Ce type d’activité malveillante repose une nouvelle fois sur la possibilité d’injecter du code dans des pages Web. Elle met donc en évidence la nécessité du contrôle d’intégrité de celles-ci.

De manière générale :

  • il est préférable de ne pas utiliser ces services. Les statistiques peuvent souvent être directement extraites de l’analyse des journaux du site. Ces journaux fournissent bien plus d’informations, et permettent de faire une première surveillance des activités du site.
  • il est vivement recommandé de vérifier régulièrement l’intégrité des pages du site Web. Ce contrôle doit concerner le code source dans son intégralité.

6 Citrix Metaframe

La technologie de Citrix Metaframe permet à un utilisateur distant de se connecter à un bureau Microsoft Windows à distance. Ceci permet à des clients nomades d’obtenir un environnement de travail complet à partir d’une simple connexion à l’Internet. Cette connexion à un bureau se fait grâce à un programme nommé client ICA (Independent Computing Architecture).

Celui-ci utilise pour se connecter un fichier de configuration d’extension .ica. Ce fichier peut être détenu par l’utilisateur sur un support amovible. Souvent, il est mis à disposition sur un site web. Ce problème est que ce fichier de configuration comporte des informations sensibles sur la configuration à la fois du client et du serveur. Ce fichier ne doit donc pas être laissé en libre téléchargement sur un site web. Il doit, au minimum, faire l’objet de contrôles d’accès, d’autant plus que ce fichier de configuration est en texte clair et peut être modifié ou adapté après téléchargement.

Par ailleurs, le CERTA a eu connaissance d’une possible vulnérabilité dans la partie serveur Citrix. En effet, un utilisateur malintentionné, en modifiant de façon particulière un fichier de configuration .ica, pourrait contourner la phase d’authentification nécessaire à la connexion au bureau distant. Ce faisant, il obtient une session valide sans s’identifier. Il est donc impératif de bien restreindre l’accès à ce fichier de configuration aux seules personnes auxquelles il est destiné.

7 Safari pour Windows

Dans le bulletin d’actualité du 15 juin 2007 (CERTA-2007-ACT-024), il était fait mention de la version beta du navigateur Internet Safari pour Windows. L’article traitant de cette application signalait de nombreuses vulnérabilités découvertes très peu de temps après la mise à disposition de ce dernier sur l’Internet. Au cours du mois d’août 2007, de nouvelles vulnérabilités ont été corrigées par Apple :

  • CVE-2408 : Cette vulnérabilité permet à un utilisateur distant malveillant d’exécuter des applets Java arbitraires, même si dans les paramètres du navigateur Safari l’option « Activer Java » est désactivée ;
  • CVE-3742 : une vulnérabilité dans le traitement des noms internationaux de domaines (International Domain Names) permet à un utilisateur distant malintentionné d’usurper la véritable adresse réticulaire par une autre ;
  • CVE-3743 : une vulnérabilité de type débordement de mémoire peut être exploitée par un individu malveillant afin de provoquer un déni de service ou d’exécuter du code arbitraire, en incitant l’utilisateur à rajouter un marque-page (bookmark) dont le nom est spécialement construit ;
  • CVE-3944 : une vulnérabilité de type débordement de mémoire causée par une erreur dans le moteur Javascript du navigateur permet à un utilisateur malintentionné, au moyen d’une page web spécialement construite, de provoquer un déni de service ou d’exécuter du code arbitraire.

Ces vulnérabilités sont corrigées dans la version 3.0.3 du Navigateur Safari.

Malgré cette mise à jour, le navigateur Internet Safari pour Windows n’est pas encore une version finale, et par conséquent, il est recommandé de ne pas déployer cette application avant la publication d’une version stable.

Documentation

Rappel des avis émis

Dans la période du 01 au 07 octobre 2007, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 12 octobre 2007
    version initiale.