![]() |
CERTA Centre d'Expertise Gouvernemental de |
![]() |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-24
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-024.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-024/ 1 Les incidents de la semaine1.1 Le phishing d'un site de vente en ligneCette semaine, le CERTA a traité un incident relatif au filoutage (ou phishing) d'un site de vente en ligne. Le site utilise un portail pour vendre les différents services qu'il propose. En analysant les statistiques de connexions, le responsable s'est rendu compte qu'un site qu'il ne connaissait pas le référençait (visible par le champ REFERER de l'en-tête HTTP fourni dans les journaux). En se rendant sur ce site, il a constaté qu'il reproduisait à l'identique son site légitime, utilisant le même nom de service, la même charte graphique, les mêmes images, les mêmes références clients, ... Les seuls changements portaient sur les tarifs pratiqués et les coordonnées de contacts.Le CERTA rappelle que les escroqueries, comme le phishing, ne touchent pas que les banques ou les fournisseurs d'accès. Ils peuvent viser tout service en ligne sur Internet. L'utilisateur doit donc rester vigilant et méfiant au cours de sa navigation, et ne pas fournir trop rapidement ses identifiants de connexion. L'administrateur doit, comme il a été fait ici, surveiller avec attention ses journaux de connexion afin de déceler toute anomalie ou mettre en évidence des phénomènes étranges. 1.2 Compromissions en série1.2.1 Présentation des faitsCette semaine le CERTA a participé au traitement d'un incident relatif à la compromission de plusieurs sites Internet. Ces sites étaient tous co-hébergés sur le même serveur. Il a en fait suffi à l'attaquant de profiter de la vulnérabilité d'un des sites présents pour compromettre tous les autres et mettre en péril la sécurité du serveur. En effet, la même archive de kit de filoutage a pu être déployée sur tous les sites. Il est important de souligner qu'une telle compromission de masse n'a nécessité que l'exécution d'une seule commande sur le serveur. Le CERTA rappelle qu'en matière d'hébergement mutualisé, il convient de respecter certaines bonnes pratiques, comme certaines décrites dans la note d'information du CERTA CERTA-2005-INF-005. 1.2.2 Documentation
2 A propos du contournement de MS08-033L'avis CERTA-2008-AVI-307 qui concerne des vulnérabilités corrigées dans Microsoft DirectX est décrit par Microsoft dans son bulletin de sécurité MS08-033. Dans celui-ci, Microsoft propose un contournement provisoire qui consiste à modifier les ACL (Access Control List) du fichier quartz.dll ou de désactiver cette bibliothèque dans le registre. quartz.dll est une bibliothèque contenant des fonctions pour DirectShow, une partie de DirectX. Ce contournement a également été conseillé pour d'autres bulletins concernant DirectX, par exemple MS07-064 et MS06-005. Il peut être intéressant de l'appliquer pour des administrateurs qui ne peuvent effectuer les mises à jour immédiatement. Pour restreindre les droits en modifiant les ACL, les commandes à taper sont les suivantes : Sur Windows XP (avec un compte administrateur) : Echo y| Cacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /E /P everyone:N Sur Windows Vista (sous une invite de commandes ouverte en tant qu'administrateur): Takeown.exe /f %WINDIR%\SYSTEM32\QUARTZ.DLL Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /save %TEMP%\QUARTZ_ACL.TXT Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /deny everyone:(F) Pour remettre les droits originaux : Sur Windows XP : Cacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /E /R everyone Sur Windows Vista : Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /grant everyone:(F) Icacls.exe %WINDIR%\SYSTEM32 /restore %TEMP%\QUARTZ_ACL.TXT L'autre contournement consiste à désactiver quartz.dll : Regsvr32.exe -u %WINDIR%\SYSTEM32\QUARTZ.DLL Pour le réactiver : Regsvr32.exe %WINDIR%\SYSTEM32\QUARTZ.DLL Quartz.dll étant un composant majeur de DirectShow, ces contournements ont des impacts qui peuvent être non négligeables. En effet, DirectShow est un framework (environnement de travail) multimédia utilisé par certaines applications sous Windows. Les effets de bord sont cependant différents selon le système d'exploitation. Ainsi, sur Windows XP, aucun fichier ne pourra être interprété dans une application utilisant DirectShow. Sur Windows Vista, seule la lecture des fichiers .avi et .wav avec des applications utilisant DirectShow serait concernée. Le lecteur Windows Media Player est notamment affecté par cet effet de bord. 2.1 Documentation
3 Les codes malveillants chiffrantsUne nouvelle variante d'un code malveillant a fait son apparition récemment. Cette dernière répond au nom de gpcode.ak. Elle est la dernière évolution d'un code aux manières un peu particulières : les victimes de ce programme constatent le chiffrement de l'ensemble des fichiers ayant une extension particulière (.doc, .txt, .pdf, .xls, .jpg, ...) selon les versions. Pour retrouver l'usage de ces fichiers, il est demandé de payer ($100 ou $200 ?) afin d'obtenir le programme de déchiffrement. Ce type de programme est connu sous le terme ransomware 1. Si ce type de code malveillant n'est pas nouveau cette version pose toutefois des problèmes. Les anciennes versions avaient pu être déjouées grâce à un défaut dans l'implémentation de l'algorithme de chiffrement et ainsi permettre le déchiffrement des fichiers sans avoir à payer cette rançon. Cette nouvelle variante ne fait malheureusement pas la même erreur. La taille de la clé de chiffrement (1024 bits) ainsi que l'algorithme utilisé (RSA) ne permettent pas de trouver une méthode de décryptement. Différentes initiatives, plus ou moins critiquables et critiquées, ont été lancées afin de trouver une solution à ce code malveillant. Par exemple, des projets de collaborations appelant toute personne volontaire à contribuer à la recherche d'un remède efficace ont été créés. A ce jour, aucun moyen n'est à disposition pour récupérer des données modifiées par ce code. Une signature de ce dernier est cependant disponible. Le CERTA tient à rappeler l'ensemble des bonnes pratiques afin de limiter les risques d'infection et leurs impacts :
4 Adobe 9 et autres nouveautésPlusieurs sources sur l'Internet, dont Adobe, confirment l'arrivée prochaine de la version 9 de Adobe Reader. Cette nouvelle version sera, en outre, accompagnée d'une suite de logiciels enrichissant le catalogue des produits proposés par Adobe. Concernant Adobe Reader, il sera possible parmi les nouveautés avec la prochaine version d'inclure du contenu Flash (.swf) dans un fichier au format PDF (.pdf). Le CERTA rappelle que la technologie Flash n'est pas sans risque (cf. CERTA-2008-ACT-016) et que, par conséquent, les risques liés à cette technologie pourront se retrouver également dans les fichiers PDF de dernière génération. Pour mémoire il est possible, par exemple, avec la dernière version de Flash, d'utiliser des ressources réseau (sockets) dans le contexte de la lecture d'un fichier .swf. On comprend dès lors que le format Flash n'est plus un format statique sans intéraction forte avec son environnement. Quant à la suite logicielle qui sera proposée par Adobe, elle comprendra, à l'image d'un concurrent dans le domaine, un traitement de texte en ligne, un outil de travail collaboratif en ligne, un outil d'échange de fichiers et un convertisseur ``universel'' de fichiers en PDF. Tous ces outils, bien qu'installés en partie sur la machine, utiliseront des composantes distribuées en ligne. Dans ce contexte, il devient assez difficile de savoir quelle est la part de traitement qui est faite « en local » de la part réalisée en ligne. Cela complexifie la maîtrise les informations traitées localement de celles envoyées « pour traitement » sur un serveur distant. Ce type d'outil pose des problèmes évidents de confidentialité. 4.1 RecommandationsDans un cas comme dans l'autre, le CERTA recommande la plus grande prudence vis-à-vis de ces technologies qui, certes, apportent de nouvelles fonctionnalités mais entraînent surtout d'inquiétants problèmes de confidentialité et plus généralement de sécurité.5 SNMP : une gestion dangereuse ?5.1 La gestion de réseauLa gestion des réseaux n'est pas une tâche évidente. Elle impose souvent de connaître l'état des équipements, comprendre leurs demandes, voire aussi modifier certains paramètres de configuration. Pour cela, des architectures de communication sont mises en place. Elles recourent souvent à un protocole : SNMP (pour Simple Network Management Protocol), standardisé au début des années 90. Les données utiles pour gérer des équipements (dotés d'« agents » SNMP) se présentent sous forme de variables qui peuvent être interrogées et modifiées (l'information complète étant une collection d'objets appelée MIB ou Management Information Base dont le langage respecte la SMI ou Structure of Management Information). Plusieurs versions de ce protocole existent. Le standard RFC 2570, publié en avril 1999, décrit la version la plus récente : SNMPv3. En terme de sécurité, SNMPv3 comble quelques lacunes des versions précédentes en offrant des solutions d'authentification et de chiffrement précisées dans le standard RFC 2574. La méthode s'appuie sur le principe d'utilisateurs définis par un nom, des droits d'accès et un mot de passe.
Même si cette version est celle qui est préconisée depuis son lancement, elle est loin d'être déployée dans la majorité des architectures de gestion. 5.2 Le problème actuel : CVE-2008-0960HMAC (keyed-Hashing for Message Authentication Code) peut ainsi être utilisé pour authentifier les utilisateurs. Cependant, plusieurs applications ne vérifient pas que les valeurs fournies sont de taille raisonnable, permettant à quiconque d'envoyer des condensats de 1 octet. Cela se résume à 256 valeurs de condensats différentes. En d'autres termes, l'envoi d'une trame usurpée a donc 1 chance sur 256 de passer la phase d'authentification avec succès. Cette vulnérabilité reste valable pour les variantes HMAC-SHA-96 et HMAC-MD5-96 s'appuyant respectivement sur les algorithmes Secure Hashing Algorithm-1 (SHA-1) et Message-Digest Algorithm 5 (MD5). Du code d'exploitation est déjà disponible. Cette vulnérabilité a été
initialement détectée sur les mises en
L'avis CERTA-2008-AVI-302 rappelle ainsi que les versions vulnérables de NET-SNMP sont toutes celles antérieures à 5.4.1.1, 5.3.2.1 et 5.2.4.1. L'effet « boule de neige » issu de la réutilisation de mêmes codes par plusieurs applications implique de nombreux autres produits. Parmi ceux-ci :
Une liste est maintenue à l'adresse suivante : http://www.kb.cert.org/vuls/id/878044 Cette vulnérabilité est relativement importante. Il ne faut pas oublier non plus que de tels services ne doivent pas être accessibles depuis l'Internet. En effet, il est possible de cartographier l'ensemble des équipements ayant de telles vulnérabilités par des balayages de ports à large échelle. Des personnes ont déjà lancé de telles opérations et le résultat a été rendu public. Toute interface connectée à l'Internet ne peut pas cacher simplement les services en écoute sur des ports. Il suffit d'un équipement embarqué mal configuré comme un routeur pour mettre en danger l'ensemble des communications sortantes d'un réseau. 5.3 RecommandationsPlusieurs mesures peuvent être entreprises pour limiter les risques. La première consiste à vérifier si SNMP est effectivement déployé ou activé sur les équipements ; l'usage de ce protocole n'est parfois pas clairement mentionné par les outils d'administration à distance. Cela peut se faire par le biais de balayages contrôlés dans le réseau local, par une écoute passive des trames ou en interrogeant directement la configuration des équipements. Par exemple, les équipements Cisco (IOS, CatOS ou IOS-XR) peuvent être interrogés par la commande show snmp group. L'information est visible dans le champ security model, qui signale par usm ou v3 auth que SNMPv3 est configuré. Si SNMP est effectivement utilisé, il faut alors s'assurer qu'il est correctement configuré avec l'application des différentes mesures de sécurité. De manière générale, des utilisateurs distincts sont utilisés pour la lecture et l'écriture de données. De même, le chiffrement peut s'activer ou se désactiver. Dans la configuration Net-SNMP, cela se fait avec le champ priv.
# écriture et lecture
rwuser certa1 priv
# lecture seulement
rouser certa2 priv
Il est souvent possible de journaliser les erreurs
d'authentification et d'émettre un signal
(trap) à la console d'administration quand cela
se produit. Pour Net-SNMP, il suffit également d'ajouter
dans le fichier de configuration snmpd.conf la ligne :
authtrapenable 1
# définir aussi la destination des "trap"
Parmi les autres mesures envisageables :
5.4 Documentation
|
![]() |
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||