CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-13
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-2008-ACT-013.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-2008-ACT-013/ 1 Incidents de la semaine1.1 Journaux d'administration et gestion des incidentsLe CERTA a traité cette semaine un incident lié à l'indisponibilité d'un serveur web pendant une période relativement longue. Une hypothèse envisageable est celle d'un dysfonctionnement au niveau du réseau. Malheureusement, l'administrateur n'a, à sa disposition, que les traces suivantes :
Ces traces sont intéressantes dans le cadre de l'administration, afin de détecter une surcharge éventuelle des « tuyaux » ou un dysfonctionnement matériel (surchauffe, panne matériel, etc.). Cependant, dans le cas présent, il s'agit des seuls journaux à disposition pour traiter l'incident. Cela est clairement insuffisant, car ils ne permettent pas de comprendre le problème. D'une part ceux-ci sont déjà une interprétation de données brutes indisponibles, mais ils ne permettent également pas de comprendre les dysfonctionnements réseau ou applicatifs. Il est important de ne pas confondre des traces indicatives pour la maintenance opérationnelle d'un réseau, et la politique de journalisation, qui doit, elle, être la plus complète et la plus rigoureuse possible afin de traiter au mieux un incident. Dans le cas contraire, les problèmes seront difficilement expliqués s'ils sont déjà détectés. 1.2 Détournement des outils de statistiqueCertains sites Internet laissent volontairement ou non l'accès aux pages de leurs outils de statistiques. La plupart de ces outils (exemple : Webalyzer) permettent, dans leur configuration par défaut, d'afficher les adresses réticulaires (URL) référençant le site web. Ces informations, et bien d'autres, sont collectées par le serveur web lors de l'arrivée d'un visiteur provenant d'un site référant. Certains individus malintentionnés se servent de cette fonctionnalité pour promouvoir leur site et améliorer leur référencement dans les moteurs de recherche. Ces derniers référençant les pages des outils de statistiques deviennent alors la cible de programmes automatisés recherchant les sites utilisant des outils de statistiques connus. Sur chaque site retourné, le programme va ensuite engendrer un nombre important de requêtes bien souvent erronées mais avec un champ Referer spécifiquement construit. Voici un exemple d'un tel comportement dans un journal de connexions Apache ; il peut y avoir plusieurs centaines de ces lignes par seconde. Dans cet exemple, l'adresse IP malveillante cherche à promouvoir un site pour adulte : <IP malveillante> - - [20/Mar/2008:18:01:00 +0001] "POST / HTTP/1.1" 404 301 "<URL d'un site pour adulte>" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204" <IP malveillante> - - [20/Mar/2008:18:01:00 +0001] "POST / HTTP/1.1" 404 301 "<URL d'un site pour adulte>" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204" <IP malveillante> - - [20/Mar/2008:18:01:00 +0001] "POST / HTTP/1.1" 404 301 "<URL d'un site pour adulte>" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204" <IP malveillante> - - [20/Mar/2008:18:01:00 +0001] "POST / HTTP/1.1" 404 301 "<URL d'un site pour adulte>" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204" <IP malveillante> - - [20/Mar/2008:18:01:00 +0001] "POST / HTTP/1.1" 404 301 "<URL d'un site pour adulte>" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204" Les outils d'analyse présenteront alors l'adresse réticulaire (URL) ci-dessus dans la liste des meilleurs adresses référençant le site web. Cette liste étant également indexée dans les moteurs de recherche, les sites envoyés par ces programmes automatisés voient leur référencement et leur notation augmenter dans les moteurs de recherche. Pour éviter de contribuer à ce genre de comportement le CERTA recommande :
1.3 Un nettoyage presque parfaitCette semaine, le CERTA a participé au traitement d'un incident relatif à la compromission d'un serveur web. Suite à la découverte d'un site de phishing déposé sur un serveur compromis, le CERTA a contacté l'administrateur de ce serveur afin qu'il prenne les mesures nécessaires pour interdire l'accès aux pages frauduleuses. L'administrateur a immédiatement empêché l'accès aux fichiers signalés par le CERTA afin de limiter le nombre de victimes potentielles de cet incident. Cette mesure n'était pas suffisante car les attaquants avaient également déposé un fichier dont le nom n'attirait pas l'attention. Le but de ce fichier, qui ne contenait qu'une seule ligne de code, était de rediriger les victimes vers un autre site malveillant situé dans un autre pays. Le CERTA rappelle que lors d'une compromission, quelle qu'elle soit, il convient de repartir sur des bases saines en appliquant les recommandations de la note d'information sur les bon réflexes en cas d'intrusion sur un système d'information. Les nettoyages rapides et manuels risquent de ne pas être exhaustifs, de perturber une analyse postérieure et de laisser des portes dérobées, des traces ou bien encore des signatures pour les attaquants. 5.2 Documentation
2 Configuration de PHPLe CERTA revient cette semaine sur la configuration de PHP et plus particulièrement sur la variable expose_php. La recherche de vulnérabilité étant de plus en plus automatisée, il est important de limiter les informations directement accessibles depuis l'Internet qui décrivent le système . Cette variable permet de contrôler les détails transmis par PHP en réponse à toutes les requêtes et elle est configurable dans le fichier php.ini.Dans l'exemple suivant le fichier inexistant inexistant.html est demandé. Avec la configuration par défaut ( expose_php=On) on obtient la réponse suivante : Not Found The requested URL /inexistant.html was not found on this server. Apache/2.2.3 (Debian) PHP/5.2.0-8+etch5~pu1 Server at localhost Port 80 En désactivant cette variable (expose_php=Off) on obtient la réponse suivante : Not Found The requested URL /inexistant.html was not found on this server. Apache/2.2.3 (Debian) Server at localhost Port Dans le premier cas, la simple demande d'un fichier html permet de savoir si PHP est installé ainsi que sa version. Il est intéressant de remarquer que cette variable contrôle aussi l'accès aux données cachées par les développeurs (easter egg) telles que les remerciements, accessibles en passant l'argument "?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000" à n'importe quel fichier PHP existant. 2.1 ConclusionTransmettre des informations concernant la présence de logiciels et leur numéro de version est un élément important dans la recherche de vulnérabilités. Afin de limiter ce type de divulgation, le CERTA recommande de désactiver cette variable. Documentation
3 iTunes et mise à jourAvec la dernière version de Apple iTunes pour Microsoft Windows, le système de mise à jour de la suite iTunes et Quicktime installera en plus par défaut le navigateur Safari 3.1. Le propos ici n'est pas de qualifier la qualité du dernier navigateur de Apple mais plutôt de s'interroger sur la pertinence d'une telle mise à jour. En effet, nous ne sommes pas, dans le cas présent, face à une correction de faille mais plutôt dans l'installation d'un logiciel supplémentaire optionnel. Il n'est pas essentiel de disposer de Safari pour écouter de la musique avec iTunes. Le problème n'est pas forcément la qualité du navigateur et, au contraire, il participerait plutôt à la diversité des logiciels de navigation. Mais l'installation d'un logiciel supplémentaire qui n'est pas désiré ne fait qu'accroître la surface d'attaque du système. Recommandations :Cette mise à jour lors de l'avertissement d'installation peut être tout à fait décochée pour que Safari ne soit pas installé. Si vous ne voulez pas utiliser ce navigateur, il est donc inutile de l'ajouter au nombre des logiciels à mettre à jour. 4 La méthode TRACE4.1 Rappel sur la méthodeLa méthode TRACE est définie dans le standard RFC 2616 définissant le protocole HTTP/1.1. Elle permet de journaliser les requêtes envoyées par un client à un serveur web et les réponses envoyées par ce dernier au client. Ainsi, la réponse à une requête TRACE contient en corps de message la requêtes initiale reçue par le serveur. Cette méthode est autorisée par défaut et est très utile pour effectuer des tests et corriger des erreurs lors du développement d'applications web. http://www.ietf.org/rfc/rfc2616.txt Pour vérifier si la méthode est activée : $telnet LeSiteCible.tld TRACE / HTTP/1.0 Host : test A: toto B: titi HTTP/1.1 200 OK Date Fri, 28 Mar 2008 10:40:24 GMT Server: Apache Connection: close Content-Type: message/http TRACE / HTTP/1.0 Host : test A: toto B: titi Les valeurs de la requêtes « toto » et « titi » sont inclus dans la réponse du serveur. 4.2 Les risquesIl est possible de dérober des données de session en forçant l'utilisateur à utiliser la méthode TRACE vers un site cible. Ces données peuvent être relatives aux cookies, à l'authentification, à la référence du navigateur... Via des scripts, il est donc possible de récupérer ces informations outrepassant les politiques de restriction des domaines. Si un utilisateur visite des pages malveillantes, il peut être amené à charger ce type de script et ainsi dévoiler à son insu des données sensibles le concernant. Plusieurs scanners de vulnérabilités de sites web testent par défaut si cette méthode est autorisée. De plus ces tentatives ne sont pas toujours visibles dans les journaux applicatifs. 4.3 Les recommandationsAfin de limiter les risques liés à cette méthode, le CERTA recommande de :
5 Vulnérabilité sur Microsoft Jet Database Engine5.1 PrésentationCette semaine, le CERTA a publié l'alerte CERTA-2008-ALE-005 concernant une vulnérabilité dans Microsoft Jet Database Engine. En réalité, cette vulnérabilité de type débordement de mémoire était déjà connue et c'est seulement le vecteur d'attaque qui est nouveau. Les fichiers mdb sont en effet considérés comme non sûrs (au même titre que les fichiers exécutables), et l'exécution possible de code à leur ouverture est de toute façon - qu'il y ait une vulnérabilité ou non - reconnue par l'éditeur. Toutefois, dans le cas de cette alerte, c'est via l'ouverture d'un fichier doc que se fait l'exécution de code : le fichier Word ouvre à son tour le fichier mdb en utilisant la librairie msjet40.dll vulnérable. Des cas d'exploitation ont été rapportés, ce qui a poussé le CERTA à publier une alerte. Ces exploitations reposent principalement sur le schéma suivant : la réception par courriel d'une archive zip contenant, dans un répertoire, un fichier doc et un fichier db (mdb renommé). L'ouverture du fichier doc provoque l'exécution de code arbitraire. Le principal contournement est la désactivation de
Microsoft Jet Database Engine en
exécutant la commande suivante : echo y| cacls "%SystemRoot%\system32\msjet40.dll" /E /P everyone:N Ceci a pour effet de restreindre l'accès au fichier msjet40.dll à tout le monde. La commande suivante remet les droits par défaut : echo y|cacls "%SystemRoot%\system32\msjet40.dll" /E /R everyone Les autres contournements sont plus ordinaires :
Les systèmes d'exploitation Windows Server 2003 Service Pack 2, Windows Vista et Windows Vista Service Pack 1 ne sont pas concernés par cette vulnérabilité car ils ont une nouvelle version de Microsoft Jet Database Engine (supérieure à 4.0.9505.0). Toutes les versions de Word 2000 à Word 2007 Service Pack 1 semblent touchées. 5.2 Documentation
6 Rappel des avis émisDans la période du 21 au 27 mars 2008, le CERTA a émis les avis suivants :
Pendant la même période, les avis suivants ont été mis à jour :
Gestion détaillée du document
CERTA 2012-01-04 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
