1 Les incidents traités cette semaine

1.1 un scénario d’attaque de bout en bout

1.1.1 Présentation

Cette semaine, le CERTA a participé au traitement d’incident relatif à la compromission d’un serveur web. Le premier jour de traitement, cet incident ressemblait à un banal cas de filoutage : un site Web compromis et des pages frauduleuses déposées à distance. La compromission semblait venir du mot de passe du compte FTP utilisé pour mettre à jour le site Web. Or un jour plus tard, le CERTA apprend que la victime a reçu plus tôt cette semaine un courriel semblant venir de son hébergeur lui demandant de mettre à jour ses identifiants de connexion. Le problème est que ce courrier était malveillant et qu’il a redirigé la victime vers une page frauduleuse reprenant celle de l’hébergeur. Sans prêter suffisamment d’attention ni respecter les principes de sécurité élémentaires, la victime a cliqué sur le lien du courrier et renseigné ses identifiants de connexion. Dans cette campagne de filoutage, les identifiant volés ont été exploités rapidement. L’une des premières actions des individus malveillants a été de modifier le mot de passe de la victime afin d’empêcher cette dernière de mettre fin rapidement aux méfaits réalisés par la suite par les attaquants.

Comme souvent, le filoutage commence par un courrier électronique contenant un message prétendument important et un lien (une URL) frauduleux. Un des conseils très souvent rappelé par le CERTA est de ne jamais cliquer sur un lien présent dans un courriel. Il est préférable de se rendre soi-même sur le site désiré, en recopiant l’adresse réticulaire (URL) à la main.

Le CERTA rappelle une nouvelle fois que les campagnes de filoutage (ou phishing) ne concerne pas uniquement le milieu bancaire. Toute information personnelle peut intéresser et peut être exploitée par des personnes malveillantes, que ce soit pour usurper l’identité, réaliser de l’ingénierie sociale, du chantage ou encore voler des fonds.

1.1.2 Documentation

1.2 Défiguration de masse en 1 clic

1.2.1 Présentation

Cette semaine le CERTA a analysé les journaux des connexions d’un serveur Web mutualisant plus d’une centaine de sites Web (140 en tout). Tous ces sites ont été défigurés par la même personne en l’espace de quelques secondes. Les journaux des connexions, bien qu’en partie effacés par l’attaquant, montrent qu’à la suite de l’exploitation d’une vulnérabilité PHP, présente sur l’un des sites, l’attaquant a déposé ce qu’il est commun d’appelé un PHP Shell. Ce petit fichier se présente sous la forme d’une page écrit en langage PHP et offre la possibilité d’exécuter des commandes système à distance via le navigateur Internet. Il devient donc trivial en une ou deux lignes de commande Shell de modifier toutes les pages des sites Web présents et d’effacer ses traces.

Le CERTA rappelle que les CMS et leur composants sont des applications qu’il convient de mettre à jour et de suivre en terme de sécurité. PHP est un langage puissant , mais les variables ne doivent jamais être utilisées avant d’être contrôlées. Enfin le CERTA rappelle que l’hébergement mutualisé comporte des risques qu’il faut prendre en compte au préalable.

1.2.2 Documentation

2 Exploitation d’une vulnérabilité dans Ovidentia

Cette semaine a été marquée par l’exploitation d’une vulnérabilité du gestionnaire de contenu Ovidentia. Cette faille permet de réaliser des injections SQL et a fait l’objet de l’avis CERTA-2008-AVI-423. Un outil permettant d’exploiter facilement la vulnérabilité a été publié sur l’Internet. Celui-ci laisse des traces aisément repérables dans les journaux. Celles-ci sont du type :

GET /index.php?tg=contact&idx=modify&item=-99999 suivi de l’inclusion SQL

Les prochaines versions 6.7.0 d’Ovidentia devraient inclure le correctif à ce problème. En attendant, une version corrigée du fichier contact.php a été mise à disposition sur le site du produit (voir avis CERTA). Il s’agit d’appliquer un simple remplacement de ce fichier afin de se protéger de ces attaques. À noter que la convention de nommage du produit Ovidentia est un peu particulière puisque la version 6.6.97 en téléchargement est en fait la version 6.7.0 bêta. La dernière version stable en téléchargement est la version 6.6.5. Il est important de préciser que les versions proposées actuellement en téléchargement sont vulnérables, et qu’il faut donc appliquer le correctif après installation.

Le CERTA recommande aux administrateurs de serveur Web de rechercher dans leurs journaux d’éventuelles attaques à l’encontre du produit Ovidentia.

3 Fichiers de session avec Adobe

3.1 Présentation

Certains sites présentent, directement ou non, des animations Flash. Celles-ci peuvent déposer des fichiers sur le disque. Les fichiers de sessions Flash portent le nom de LSO (Local Shared Objects) ou Flash cookies. Ils sont pris en compte depuis la version 6 d’Adobe Flash et peuvent contenir tous types d’information comme des dates, des mots de passe, des pseudonymes, etc.

Ils permettent par exemple de conserver :

  • le niveau sonore et l’activation du son lors de la précédente visite ;
  • l’animation d’introduction si ce n’est pas la première visite ;
  • la dernière page visitée d’un site développé en Flash ;
  • garder le résultat du score le plus élevé d’un joueur ;
  • etc.

Le fichier LSO a une extension .sol. Ce format est assez simple. Un fichier se compose d’un en-tête de 16 octets et du bloc de données constitué de déclarations de variables :

  • la longueur du nom de la variable ;
  • le nom de la variable ;
  • le type de variable ;
  • les données dont la taille dépend du type précédent ;
Les types de données peuvent être des nombres, des valeurs booléennes, des chaînes de caractères, une table, un pointeur, une date,…. Le type XML est une chaîne de caractères particulière ayant une longueur beaucoup plus importante (pas de limite particulière).

3.2 Différences avec des fichiers de session usuels

3.2.1 Rappel sur les fichiers de session HTTP

Les fichiers de session ou cookies sont des informations échangées dans les en-têtes du protocole HTTP. Elles sont positionnées par le serveur via l’en-tête set-cookie ou fournies par le navigateur via l’en-tête cookie et doivent respecter certaines conditions :

  • leur taille ne doit pas excéder 4ko ;
  • un client ne peut en stocker plus de 300 ;
  • un serveur ne peut postitionner que 20 fichiers de session maximum.

Leur principe général est de gérer des sessions à un niveau applicatif et de suivre les habitudes de navigation de l’utilisateur. Le principe semble donc identique avec les applications Flash souhaitant stocker des informations sur le poste de l’utilisateur avec les LSO.

3.2.2 Les différences

Par défaut, l’utilisateur n’est pas prévenu du stockage des informations LSO.

Par ailleurs, ces fichiers Flash ne sont pas temporaires. Il n’y a pas de date d’expiration. Un ordinateur peut en stocker plusieurs dizaines sans soucis. La taille des données stockées peut atteindre 100ko par site, en comparaison aux 4ko des fichiers de session HTTP traditionnels. Cette taille peut même être dépassée avec un signalement par une boîte de dialogue.

L’usage des informations stockées par les LSO est normalement restreint aux domaines à l’origine de leur création. Cependant, des sociétés publicitaires ont montré dès 2005 qu’elles pouvaient également lire ces informations. L’intérêt est ici de récupérer des informations sur l’utilisateur même si ce dernier nettoie régulièrement ses fichiers de session HTTP. Il s’agit du principe des « LSO tiers » qui donnent accès à l’objet pour plusieurs sites/domaines (cf. section Documentation).

3.3 Recommandations

Les navigateurs les plus courants (Internet Explorer, Opera, Mozilla Firefox) ne prennent pas en compte ces informations. Une configuration rigoureuse de ces derniers n’empêche pas le stockage de ces informations.

Un site peut déposer un fichier de session classique et un LSO. Il est important de garder la même cohérence de nettoyage pour les deux.

La gestion des LSO se fait par le biais du site Web d’Abobe via une interface dédiée. L’adresse est indiquée dans la section « documentation » de cet article.

http://www.adobe.com/go/settingsmanager

Les fichiers de session Flash (LSO) se trouvent selon les systèmes d’exploitation dans différents répertoires :

Sous Windows :
        C:\Documents and Settings\XXXX\Application Data\Macromedia\Flash Player
Sous Mac OS X :
        ~/Library/Preferences/Macromedia/Flash Player
Sous Linux :
        ~/.macromedia

Il est toujours possible de modifier les droits de ces répertoires (en particulier sous Linux) pour ne pas donner de droits d’écriture et de lecture dessus.

Une extension du navigateur Mozilla Firefox permet de visualiser les LSO. Cependant l’usage de ces applications tierces doit être fait avec parcimonie et précautions.

Il est également possible d’utiliser différents navigateurs ou différents profils d’utilisation.

L’usage des modules Flash dans les navigateurs impliquent des soucis de confidentialité et de protection de la vie privée. Les risques sont plus importants que ceux des fichiers de session HTTP mais sont paradoxalement moins bien considérés par les utilisateurs et les applications Web. Ces risques doivent être connus et pris en compte dans la politique de sécurité.

Une solution radicale consiste simplement à ne pas utiliser de module Flash associé au navigateur.

3.4 Documentation associée

Rappel des avis émis

Dans la période du 11 au 17 août 2008, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :