S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 01 août 2008
N° CERTA-2008-ACT-031
Affaire suivie par: CERT-FR
le 01 août 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-31

Gestion du document

Référence CERTA-2008-ACT-031
Titre Bulletin d’actualité 2008-31
Date de la première version 01 août 2008
Date de la dernière version 01 août 2008
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 Vulnérabilité DNS, suite

1.1 Description

La semaine prochaine auront lieu les conférences annuelles en sécurité Blackhat et Defcon. Plusieurs présentations sont attendues, l’une d’elles concernant le DNS et étant à l’origine de nombreux écrits dans la pre sse spécialisée ces dernières semaines. L’objet de cet article n’est pas de présenter la vulnérabilité qui sera prochainement annoncée ni les évolutions futures de l’architecture DNS. Il propose de modérer certaines solutions qui sont proposées par certains et qui peuvent s’avérer dangereuses. Les décisions correctives doivent être prises avec réflexion et maturité et non sur le coup de la panique ou de la pression.

1.2 Solutions dangereuses

Les mises à jour des serveurs DNS s’effectue plus ou moins vite, compte-tenu des difficultés de mise à jour des machines. De s problèmes sont en particulier apparus comme des incompatibilités entre les mises à jour (qui ajoutent un aléa au choix des ports sources des transactions DNS) et certains équipements de filtrage réseau.

Une solution alternative à cette mise à jour a été évoquée : elle consiste à modifier sa configuration DNS et la faire point er vers d’autres serveurs tiers dits « non vulnérables » qui se chargeront de faire les résolutions de noms. Des sociétés ont déployé des serveurs DNS hébergés dans différents endroits du globe et offrent les services suivants :

  • des serveurs récursifs ouverts prenant en charge toute résolution de noms ;
  • des possibilités de filtrage basés sur des domaines (listes noires et catégories de domaines).
Ces services sont parfois vantés comme « LA » solution pratique et simple aux problèmes actuels DNS.

Choisir de rediriger toutes ses transactions DNS vers des serveurs inconnus est une décision qui ne peut être prise dans la panique. Pour s’en assurer, il suffit de lister les informations qui sont alors disponibles par simple examen du trafic DNS d’un organisme :

  • modèle d’antivirus déployé ;
  • périodes d’activités de la machine ;
  • états des mises à jour du système d’exploitation et des applications installées ;
  • activités des utilisateurs (lecture de messagerie, navigations…) ;
  • données personnelles (sites bancaires, sites de type webmail, réseaux sociaux…) ;
  • etc.

Changer de serveurs DNS n’est donc pas innocent. Il revient à rediriger un important volume d’informations vers une source tierce méconnue.

Le CERTA déconseille le recours à de telles solutions.

Si l’application des correctifs s’avère impossible, voici quelques éléments à considérer :

  • l’aléa des ports sources peut s’effectuer par des équipements de filtrage. Plusieurs exemples ont ainsi été do nnés dans la note d’information CERTA-2008-INF-002 (section 4.3.2) ;
  • une nouvelle version du correctif BIND a été annoncée et sera publiée dans les prochains jours (« P2 »). Un avis du CERTA sera alors émis pour signaler sa disponibilité ;
  • la fonction récursive des serveurs DNS doit être une exception maîtrisée. Cette précaution doit être prise que lle(s) que soi(en)t la(es) vulnérabilité(s) à paraître.

1.3 Documentation associée

2 Retour sur les incidents traités cette semaine

2.1 Machines en cours d’installation

Ces derniers temps, de nombreuses machines victimes de compromissions (phishing, remplacement de la page d’accueil, hébergement de code ou de script malveillant…) s’avèrent être des sites en cours de création. Ces sites, partiellement construits, sont laissés en libre accès sur l’Internet et présentent de nombreuses faiblesses :

  • identifiants d’administration triviaux : afin de simplifier les accès à la machine pendant son installation, certains administrateurs peu vigilants se contentent d’un couple d’identification très faible, comme test/test ou admin/admin ;
  • fichiers d’installation et/ou de configuration encore présents : après une installation d’un service, comme un CMS (Content Management System), les fichiers servant à l’installation ou à la configuration restent présents sur le serveur. Une personne malintentionnée peut alors s’en servir pour réinstaller le site « à sa manière » ;
  • absence de mise à jour : on observe que peu d’administrateurs se soucient malheureusement des mises à jour pendant la phase d’installation et de configuration d’une machine.

Toutes ces faiblesses regroupées sur un seul système sont une aubaine pour les personnes malveillantes.

Dans le cas d’une installation ou d’une configuration d’un système, le CERTA recommande de procéder à celle-ci de manière totalement déconnectée. Ainsi, la maîtrise du système est conservée tout au long du processus. Les mises à jour doivent se faire autant que possible lorsque la machine n’est pas encore connectée, et, seulement si cela n’est pas possible, dès que la machine est mise en ligne. Le suivi du système doit respecter l’état de l’art en matière de sécurité.

3 Le Service Pack 3 de Microsoft Windows XP

3.1 Présentation

Alors que le Service Pack 3 de Microsoft Windows XP était prévu en téléchargement automatique à partir de 10 juillet, il apparaît que cela ne soit pas vrai pour tout le monde !

En effet, la mise à jour n’est pas disponible en mise à jour automatique pour tous. Microsoft a pris la décision d’étaler dans le temps la mise à disposition de son nouveau Service Pack pour des raisons d’infrastucture. Elle devrait cependant l’être pour la France d’ici la fin de l’été.

Le CERTA rappelle qu’il est nécessaire et important de conserver son système d’exploitation ainsi que l’ensemble des applications installées à jour. Le Service Pack 3 pour Microsoft Windows XP est en revanche disponible via la mise à jour manuelle (interface Web de Windows Update).

3.2 Documentation

4 Retour sur l’alerte CERTA-2008-AVI-011

Cette alerte concerne une vulnérabilité sur un connecteur WebLogic pour Apache.

4.1 Les publications

Le 15 juillet 2008, dans son cycle de mises à jour trimestrielles, l’éditeur Oracle, nouveau propriétaire de BEA, publiait un correctif concernant les connecteurs entre les serveurs WebLogic et serveurs HTTP : Apache, Sun et Microsoft IIS. L’éditeur ne donne que peu d’informations sur la vulnérabilité corrigée. Celle-ci est exploitable à distance, sans authentification et en utilisant le protocole HTTP. L’impact n’est pas précis. Il est « partiel » en confidentialité, en intégrité et en disponibilité. La vulnérabilité fait simplement l’objet d’une entrée, CVE-2008-2579, dans le registre de vulnérabilité publiques du MITRE.

Dès le 17 juillet 2008, un code d’exploitation circulait sur l’Internet. La vulnérabilité associée est numérotée CVE-2008-3257. Ce code ne concerne que le connecteur Weblogic avec Apache. La vulnérabilité réside dans la gestion de requêtes HTTP avec méthode POST de longueur « excessive ». Le code d’exploitation permet de provoquer à distance un déni de service, et, potentiellement, une exécution de code arbitraire. L’éditeur a répondu à cette publication par des mesures de contournement correspondant aux mesures de filtrage préconisées par le CERTA dans son bulletin d’alerte.

4.2 Deux CVE impliquent-ils deux vulnérabilités différentes ?

Le MITRE, qui tient le registre CVE des vulnérabilités, est laconique. Le NIST reprend les CVE dans sa NVD (National Vulnerability Database). Le 22 juillet, il a repris le CVE-2008-3257 en ajoutant une mention. Il suggérait un possible recouvrement entre les deux vulnérabilités, voire que la vulnérabilité CVE-2008-3257 pouvait être une résurgence d’une vulnérabilité ancienne. Cette mention a jeté le trouble chez des utilisateurs du produit.

La sortie d’un code d’exploitation peu après une publication de correctif pouvait laisser croire que le code concernait la vulnérabilité qui venait d’être corrigée. Ce scénario est fréquent. Les délinquants informatiques, quand ils manquent d’informations sur une vulnérabilité, attendent la sortie du correctif et, par analyse inverse du correctif :

  • découvrent la vulnérabilité qui fait l’objet du correctif ;
  • conçoivent et publient le code d’exploitation de cette vulnérabilité.
Cette opération peut être faite en quelques heures parfois. L’exploitant d’un système d’informations peut légitimement s’interroger. Quel est le risque réel ? Suis-je déjà protégé en ayant appliqué les correctifs trimestriels ? Au contraire, doit-on mettre en place des mesures palliatives qui peuvent avoir des effets secondaires ?

Le CERTA a analysé les différentes sources d’information avec certains de ses correspondants et de ses homologues.L’éditeur mentionne dans ses bulletins que la première vulnérabilité concerne tous les connecteurs, pour les trois serveurs Web, antérieurs au 15 juillet, tandis que la deuxième ne concerne que les connecteurs pour Apache, mais jusqu’au 28 juillet. Le périmètre et la période diffèrent. Les impacts, tels que définis par le CVSS (Common Vulnerability Scoring System), sont beaucoup plus importants pour la deuxième que pour la première. Ces différence militent pour une différence réelle entre les vulnérabilités.

Le 31 juillet, le NIST a supprimé la mention qui a soulevé les questions.

4.3 Moralité

De manière générale, il faut considérer le système des CVE comme un système d’énumération et non un système de qualification absolue. Le processus de revue avant publication dans le registre limite les risques de doublon mais ne garantit pas leur inexistence. La détection et l’élimination des recouvrements entre deux entrées dans le registre sont bien plus difficiles.

Les CVE sont assez largement utilisés, par exemple pour des vulnérabilités de produits Apple, Cisco, OpenOffice.org, Oracle, Microsoft, Mozilla, et bien d’autres. Cette numérotation répandue facilite les recherches. Il faut profiter de cette qualité sans chercher les propriétés qu’elle ne garantit pas.

4.4 Documentation

5 RAID, sauvegardes et plus si affinité

Lors de traitements d’incident, le CERTA peut être amené à intervenir sur des machines équipées de disques configurés en RAID. Ce type d’architecture disque est souvent utilisée pour assurer de la tolérance de panne. Ainsi on pourra trouver, par exemple, du RAID-1 ou mirroring consistant en une synchronisation « temps-réel » des informations présentes sur chacun des 2 disques du RAID.

Le RAID-1 est composé de deux disques et autorisera la « perte » d’un des deux disques temporairement sans coupure du service. On trouve également assez fréquement du RAID-5 plus complexe mais également plus économique en espace disque puisque il consomme (1/N) disque pour fonctionner (où N est le nombre de disques fonctionnant en RAID-5, celui-ci étant toujours au moins égal à 3).

Utiliser ce type de technologie présente un avantage certain puisqu’il rend la machine plus tolérante aux pannes matérielles. Il facilite également les éventuelles copies de disque dans le cas du RAID-1 car il suffit d’extraire un disque du serveur pour avoir une copie immédiate du système.

Les choses deviennent plus problématiques si l’on utilise du RAID-5 puisque la réalisation d’une copie du contenu du serveur nécessitera l’intégralité des disques qui composent le RAID-5.

Ainsi, lorsque du RAID est utilisé, il faudra adapter la manière dont on réalisera la copie. A titre d’exemple, il ne faudra surtout pas enlever « à chaud » un disque si la machine dispose de disques en RAID-0 ou stripping. Dans cette configuration les disques étant aggrégés dans un seul volume global, si l’un d’entre eux venait à disparaître, c’est tout le volume qui serait perdu. De manière générale et sauf pour le cas particulier du RAID-1, le fait de mettre en œuvre du RAID compliquera la réalisation de copie de disque. De surcroît, le RAID compliquera également la reconstruction des volumes pour une analyse a posteriori ou pour récupérer des données.

Dans cet esprit, le RAID ne devra pas être considéré comme une solution remplaçant une véritable politique de sauvegarde mais bien comme un moyen d’éviter les coupures de services dûes à une panne de disque. Il conviendra donc de disposer d’une solution de sauvegarde adaptée.

Ainsi, si une machine est compromise, seule une sauvegarde saine permettra éventuellement de repartir sur de bonnes bases.

Enfin, la politique de sauvegarde n’est, elle non plus, pas suffisante car les restaurations ne prendront pas forcement en compte les éléments compromis. Il n’est pas rare que l’on sauvegarde les données présentes sur le système d’exploitation mais pas le système d’exploitation. Or, c’est souvent ce dernier qui sera la cible d’un attaquant ou d’un code malveillant. Les données ne seront, elles, modifiées que plus tard et ce sera souvent à cette occasion que la compromission deviendra visible.

Recommandations

Différents moyens peuvent être mis en place sur un serveur pour qu’il puisse assurer un service continu quoi qu’il arrive. Le RAID apportera une tolérance aux défaillances de disques durs. Les sauvegardes garantiront de pouvoir revenir à la version précédente suite à un incident ou une compromission. Mais une précaution supplémentaire pourra encore être prise en compte. Elle consistera en la rédaction complète d’une documentation de configuration et mise en œuvre du serveur permettant la reconstruction complète du service à partir d’une machine vierge. Cette disposition accompagnée d’une politique de sauvegarde efficace des données et de la configuration du serveur garantiront que même en cas de panne ou de compromission majeure, un retour à la normal puisse se faire dans de bonnes conditions.

Rappel des avis émis

Dans la période du 21 au 27 juillet 2008, le CERT-FR a émis les publications suivantes :


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

Gestion détaillée du document

    le 01 août 2008
    version initiale.