1 Des incidents traités cette semaine
1.1 Collecter le maximum d'informations
Cette semaine, le CERTA a traité un incident suite à la découverte dans des journaux de tentatives d'exploitations de php include par un site de l'administration. L'analyse du serveur a montré qu'il était lui-même vulnérable à ce type d'attaque. L'exploitation a résulté en l'exécution de bots IRC et l'utilisation du serveur comme plate-forme pour la recherche et la compromission d'autres machines.
Aucune porte dérobée n'a été installée sur le serveur et seuls des scripts d'automatisation de la recherche de sites vulnérables ont été téléchargés sur la machine. Les bots IRC s'exécutaient dès la réalisation du php include et n'étaient donc pas présents sur le disque.
Une copie de la mémoire vive, du swap et des résultats de commandes simples lancées par l'administrateur (netstat, lsof, ...) sur le serveur compromis ont été déterminants pour l'analyse de cet incident, car ils ont permis de rapidement préciser :
- la localisation immédiate de la page vulnérable au php include ;
- le type de bot IRC exécuté et son fonctionnement ;
- au moins une partie des commandes réalisées par l'attaquant ;
- les scripts qui ont été téléchargés.
Les copies de partitions classiques sont souvent les seuls éléments envoyés au CERTA pour analyse. Cet incident montre l'utilité d'autres éléments qui peuvent être déterminants, notamment l'exécution de commandes élémentaires sur la machine compromise, la copie de la mémoire vive, et la copie de la mémoire d'échange (swap). Il est cependant important de limiter les interactions avec la machine compromise pour ne pas effacer de traces ; il faut donc utiliser des commandes ou des outils peu intrusifs sur le système, qui sont également maîtrisés, et si possible après avoir effectuer une copie physique des disques. Le CERTA reste à la disposition de ces correspondants en cas de difficulté pour effectuer ces opérations.
Une note d'information présente les bons réflexes à avoir en cas d'intrusion sur un système d'information :
http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002/
1.2 Les dangers de l'hébergement mutualisé
Cette semaine le CERTA a traité un incident impliquant un serveur mutualisant l'hébergement de sites Internet. L'adresse IP de ce serveur a été observée dans plusieurs tentatives d'attaques par injection de code arbitraire sur des sites web. Apres avoir pris connaissance de ces attaques, le CERTA a contacté le responsable du serveur d'où proviennent les attaques en lui fournissant des traces issues des journaux des connexions de certains sites web ciblés.Le serveur à l'origine de l'attaque mutualise plusieurs dizaines de sites web rendant difficile l'identification de l'origine de l'attaque :
- il peut y avoir un site hébergé compromis ;
- il peut y avoir l'exploitation d'une faille d'un service du serveur ;
- il peut y avoir un mot de passe faible donnant accès à l'un des sites hébergés ;
- ...
La solution de l'hébergement mutualisé doit être considérée avec précaution, comme abordée dans la note d'information CERTA-2005-INF-005. Pour éviter ce type de compromission, le CERTA rappelle que les connexions sortantes d'un serveur web peuvent être filtrées. Afin de ne pas compromettre la sécurité de l'ensemble des sites web mutualisés, il convient de maîtriser la sécurité de chaque site : par l'application et le suivi des correctifs de sécurité, l'analyse régulière des journaux des connexions, une politique de mot de passe adéquate, ...
Documentation
- Note d'information du CERTA sur les bonnes pratiques concernant l'hébergement mutualisé :
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-005/
2 Alerte QuickTime et le protocole RTSP
2.1 Historique
Le CERTA a publié cette semaine une alerte concernant Apple QuickTime. Elle mentionne le protocole permettant d'établir et de contrôler des flux synchronisés de médias continus, RTSP (pour Real Time Streaming Protocol).
La vulnérabilité concerne l'interprétation des trames de réponse retournées par le serveur, au cours d'une tentative de connexion. Des codes d'exploitation sont largement diffusés sur l'Internet. Ils fonctionnent sur plusieurs systèmes d'exploitation, comme Windows XP SP2 ou Mac0S Tiger et Leopard (versions PowerPC et Intel).
Les échanges se font en principe via les ports TCP et UDP 554, comme l'indique l'IANA dans la liste qu'elle maintient :
http://www.iana.org/assignments/ports-numbers
Cependant, cela ne signifie par que tout trafic passant par ces ports correspond au protocole RTSP, et réciproquement, que tout trafic RTSP circule par ces ports. Le serveur peut être configuré pour écouter sur un port quelconque. Le client, lui, se connecte au serveur de la manière suivante :
rtsp://Mon_Addresse_de_Serveur_Multimedia/MonFichier:Port_de_connexion
Le filtrage des connexions sortantes est donc une bonne mesure, mais n'est pas suffisante.
Si ce protocole n'est pas utilisé, il convient alors de configurer les applications pour ne pas l'interpréter par défaut, et surtout de ne pas l'associer à une version de QuickTime vulnérable. Le CERTA rappelle à cette occasion que l'alerte du 04 janvier 2007 CERTA-2007-ALE-001 impliquait ce même protocole ainsi que l'application Apple QuickTime. La vulnérabilité était différente et consistait en un manque de contrôle sur les liens, ou URLs de type rtsp://....
Les navigateurs Internet Explorer 7 et Firefox v. 2.0.0.10 ne gèrent plus par défaut ce protocole. En revanche, ce n'est pas le cas de tous les navigateurs (cf. Safari). Un utilisateur peut également cliquer suite à une sollicitation quelconque sur un fichier de type .qtl malveillant qui pourrait également chercher à communiquer avec le serveur distant.
Pour ces raisons, l'alerte CERTA-2007-ALE-017 cite plusieurs contournements provisoires, qui consistent surtout à désactiver la gestion du protocole : cela peut se faire au niveau de l'interface de configuration de QuickTime, ou des bases de registres pour le système Windows.
http://www.certa.ssi.gouv.fr/site/CERTA-2007-ALE-017/
2.2 Recommandations
De manière générale, il est important de configurer avec soin toute application avant son utilisation. Il faut être très méfiant vis-à-vis des installations par défaut. Elles tendent en principe à « faciliter » la vie de l'utilisateur, mais sont souvent très laxistes en terme de sécurité. A valeur d'illustration, plusieurs applications proposent à leur installation d'être systématiquement associées à plusieurs types d'extension (formats de fichiers). Si ces derniers ne sont pas utilisés, comme cela peut être le cas de certains formats multimédias, alors l'association entre l'extension et l'application ne doit pas être autorisée.
3 Compte administrateur et sudo sous MacOS
Plusieurs systèmes d'exploitation comme MacOS X ou Ubuntu utilisent une technique permettant de ne pas fixer un mot de passe pour le compte root ou compte « super-utilisateur ».
Une personne malintentionnée ne pourra ainsi pas attaquer ce mot de passe soit par un dictionnaire soit par force-brute.
Il est cependant indispensable de garder la possibilité pour un simple utilisateur d'effectuer des tâches administratives comme les mises-à-jour, la configuration d'un service réseau ou l'activation d'un composant matériel. Dans ce cas, des droits administrateur sont requis. Or sans mot de passe, il est impossible de se connecter en tant que super-utilisateur. C'est pourquoi les systèmes d'exploitation précédemment cités mettent en œuvre des techniques utilisant la commande sudo. C'est-à-dire qu'un utilisateur particulier de l'ordinateur (souvent l'utilisateur courant) aura le droit par le biais de cette commande d'effectuer des actions normalement réservées au seul compte root.
Ce qui pourrait paraître pour une bonne solution ici n'en est pas forcément une. En effet, cette commande sudo n'est souvent pas suffisamment bornée et permettra par exemple à l'utilisateur privilégié d'exécuter successivemnt de nouveaux « shell » ou invites de commande en tant que root sans entrer de nouveau le mot de passe. Cette élévation de privilèges reste ainsi valable pendant plusieurs minutes. L'utilisateur pourra alors exécuter toutes les commandes du système pendant ce temps imparti.
On a donc juste déplacé le problème car celui qui connaît le mot de passe de l'utilisateur est virtuellement déjà super-utilisateur. On pourrait avancer que l'utilisateur doit retaper son mot de passe lors de l'utilisation de la commande mais là encore, le choix qui a été fait par défaut concernant ce comportement n'est pas parfait. Il est fréquent qu'un délai soit autorisé entre deux commandes sudo pendant lequel aucun mot de passe n'est nécessaire. Ainsi on tape son mot de passe une seule fois au départ puis pendant une minute par exemple il n'est plus nécessaire pour utiliser sudo. On peut imaginer dès lors une attaque en deux temps où un utilisateur malintentionné invite, par le biais d'un tutoriel par exemple, à une commande anodine en tant que super-utilisateur puis à exécuter un script « magique » qui vous apporte la dernière fonctionnalité à la mode...En guise de nouvelles fonctions il a alors tous les privilèges pour installer ce qu'il veut, y compris une porte dérobée sur l'ordinateur...
Il est à noter, par ailleurs, que le problème se pose sur les systèmes précédemment cités mais qu'il est transposable aux systèmes d'exploitation de type Windows qui, par défaut, donnent des droits administrateur au compte courant.
3.1 Recommandations :
Il existe des solutions pour parer à ce type de problème mais la démarche reste toujours identique :- utiliser des mots de passe robustes ;
- créer un compte standard ne pouvant pas utiliser sudo pour toutes les tâches quotidiennes (surf, messagerie, bureautique...) ;
- n'utiliser le compte privilégié que lorsqu'il est nécessaire d'effectuer des tâches administratives indispensables.
4 Actualité Microsoft
Microsoft a fait l'objet de nombreux articles dans l'actualité cette semaine. Le CERTA revient tout particulière sur les éléments suivants :
4.1 Vulnérabilité Macrovision
Le CERTA tient à mettre en garde les utilisateurs de l'application Macrovision SafeDisc 4.x de l'exploitation en cours d'une vulnérabilité permettant à un utilisateur local malintentionné d'élever ces privilèges. Un correctif est disponible chez l'éditeur et a fait l'objet de la publication de l'avis CERTA-2007-AVI-480. Il est donc important d'appliquer le correctif ou de prendre les mesures nécessaires afin d'empêcher l'utilisation de cette vulnérabilité par toute personne malveillante.
4.2 Le protocole WPAD
Le protocole WPAD ((Web Proxy Automatic Discovery)) permet à un poste client d'obtenir automatiquement les informations de connexion au serveur mandataire. Une vulnérabilité datant de mars 2007, pour laquelle le CERTA avait émis l'avis CERTA-2007-AVI-276 fait l'objet, à la date de rédaction de ce bulletin, de plusieurs articles dans la presse spécialisée. Cette vulnérabilité a été corrigée par Microsoft et mentionnée dans son bulletin KB934864 du 23 mars 2007. Le problème évoqué dans les médias est que le service WPAD peut être activé par défaut dans certaines versions de Microsoft Windows. Il est fortement recommandé que le navigateur soit configuré afin de ne pas rechercher automatiquement les informations relatives au serveur mandataire. L'option « Détection automatiquement les paramètres réseaux » ne doit pas être active. Celle-ci est accessible via les « paramètres réseaux » de l'onglet « connexions » de la fenêtre « options Internet » disponible dans le « panneau de configuration » de Microsoft Windows. Le CERTA rappelle qu'il est important de maintenir tous les applicatifs installés et le système d'exploitation à jour.
4.3 Microsoft FTP Client
Le logiciel (Microsoft FTP Client) a fait l'objet de nombreuses discussions relatives à une vulnérabilité permettant un dépassement de mémoire tampon. Le service ne gère pas correctement les informations fournies avec les commandes de type mget, dir ou ls. Cette vulnérabilité permet une exécution de code arbitraire avec les privilèges de l'utilisateur connecté. L'exploitation de cette vulnérabilité ne serait exploitable que lorsque l'utilisateur lance de son propre chef un script ou tape une commande particulière caractérisée par sa longueur excessive. L'impact reste donc limité mais le CERTA rappelle qu'il est important de ne pas exécuter un script inconnu et de vérifier préalablement les actions entreprises par celui-ci avant de le lancer.
Documentations
- Avis CERTA-2007-AVI-480 du 07 novembre 2007 :
http://www.certa.ssi.gouv.fr/site/CERTA-2007-AVI-480/
- Avis CERTA-2007-ACT-013 du 30 mars 2007 :
http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-013.pdf
5 Découverte de trafic pair-à-pair
La politique de sécurité appliquée pour certains réseaux spécifie que le trafic pair-à-pair est à éviter, notamment s'il n'est pas utilisé dans le cadre du travail. L'objectif de ce court paragraphe n'est pas de justifier ou non cette politique. Ce débat est largement médiatisé.
Il est en revanche important de se poser les bonnes questions, si jamais un tel trafic est bien en désaccord avec la politique de sécurité, et est détecté. Une première réaction de l'administrateur consiste bien souvent à couper les connexions impliquées, comme les ports. Les adresses IP de source ou destination peuvent faire l'objet de nouvelles règles de filtrage particulières.
Il faut également s'assurer que :
- le logiciel client sur le poste de l'utilisateur est proprement désinstallé, et ne laisse pas des portes ouvertes rémanentes ;
- l'utilisateur est sensibilisé à cette action ;
- il faut comprendre quelles informations ont pu être échangées. Cela implique de vérifier la configuration du logiciel client sur le poste de l'utilisateur avant sa désinstallation.
Ce dernier point est important. Une mauvaise configuration (par défaut ou intentionnelle) peut mettre en partage sur le réseau pair-à-pair des données plus sensibles que celles initialement voulues par l'utilisateur. Elles sont devenues publiques.
Il est donc important de traiter ce type de violation de la politique de sécurité comme tout autre incident : le traitement doit être complet.
6 Moteurs de recherche : la chance m'accompagne...(I'm feeling (un)lucky)
Quoi de plus inoffensif qu'un moteur de recherche, pense-t-on souvent. L'utilisateur tape les mots-clés de sa recherche, puis le résultat du moteur s'affiche avec les réponses que le moteur estime pertinentes. Les sites affichés sont « référencés » par le moteur de recherche, qui utilise avant d'afficher son choix une moulinette complexe basée sur la visite régulière de sites, et l'indexation de l'information trouvées sur les pages.
Il est possible de voir, à la fin du mois de novembre, plusieurs techniques d'exploitation des moteurs de recherche à des fins malveillantes. Ces techniques consistent à forcer le référencement de sites contenant du code malveillant, afin que ces sites soient dans les premières réponses d'une requête courante. Cela peut se faire en trompant les robots des moteurs de recherche qui visitent les pages sur l'Internet. Par exemple, cette semaine, le fait de chercher sur le site www.google.com les mots "christmas" "gift" et "sold" retournait à l'utilisateur plusieurs sites malveillants parmi les dix premières réponses.
Ces sites malveillants peuvent avoir plusieurs comportements :
- téléchargement d'un fichier malveillant (virus, cheval de troie, etc.) ;
- exploitation d'une faille du navigateur ;
- utilisation détournée de la consultation du site (pour augmenter un compteur de visite) ;
- etc.
Google a enlevé ces sites dangereux « trop » référencés. Le problème est bien entendu indépendant du moteur de recherche, et le scénario reste valable pour les autres. Il faut cependant bien comprendre ici que les sites de moteurs de recherche n'apportent pas de garantie sur les résultats affichés. Ces derniers sont le fruit d'une décision arbitraire du moteur qui peut faire l'objet d'un biais exploité par des personnes malveillantes.
Ces techniques ne sont pas nouvelles, mais peuvent devenir problématiques dès lors que les principes de sécurité de base ne sont pas respectés. Ainsi, il est vivement recommandé de prendre l'habitude de naviguer sur Internet en ayant désactivé par défaut toute interprétation de code dynamique (Javascript, Java, ActiveX, ...). Une fois que le site visité est considéré comme sûr, ce code dynamique peut être réactivé si nécessaire. Certains moteurs de recherche présentent également au préalable un extrait du contenu du site, qui reste intéressant à regarder. Par ailleurs, il est toujours envisageable d'utiliser des moteurs de recherche alternatifs, afin de croiser les informations retournées.
