1 Incidents de la semaine
Fichier de mots de passe disponible depuis l'Internet
Cette semaine, un correspondant du CERTA a signalé qu'un de ses serveurs de messagerie avait été utilisé pour un envoi massif de messages non sollicités (spam). Ces envois ont été réalisés depuis des comptes légitimes du webmail de cet organisme.
Les incidents de ce type sont malheureusement assez courants. Ils font généralement suite à l'obtention frauduleuse des identifiants de connexion via des messages faisant croire à une nécessité de mettre à jour ces informations. Les victimes sont dans ce cas redirigées vers un site Web malveillant qui collecte les données.
Cet incident est toutefois différent de ce que l'on rencontre habituellement. En effet, les attaquants ont récupéré les identifiants de connexion en recherchant spécifiquement, à l'aide de moteurs classiques tels que Google, des documents contenant des mots de passe en clair.
De tels problèmes n'ont pas de solution simple, même si la vigilance des webmestres et la sensibilisation des utilisateurs permettent d'empêcher ces négligences. Il est toutefois important de signaler ici le rôle du RSSI qui a, par la lecture des journaux de ses serveurs, permis d'identifier immédiatement l'incident et d'en découvrir l'origine.
2 Déni de service : des mesures de protection à contractualiser avec ses fournisseurs d'accès
Le déni de service est une des principales malveillances susceptibles de frapper un service exposé à l'Internet. Si la réussite d'une telle attaque n'implique pas la compromission des données d'un site, une indisponibilité peut être gravement pénalisante d'un point de vue opérationnel, par exemple lorsqu'elle touche un service d'infrastructure comme le système de nommage DNS ou des routeurs de cœur de réseau, mais également en termes financier ou d'image de marque pour une entité dont la visibilité sur Internet est cruciale.
Souvent considéré comme un risque résiduel et généralement mal appréhendé y compris par les techniciens, le déni de service doit être pris en compte aux niveaux technique et organisationnel, et suppose des procédures de traitement d'incident qui doivent être contractualisées avec les prestataires d'hébergement et les fournisseurs d'accès à l'Internet. Les méthodes de protection supposent donc des mécanismes de surveillance des sites, afin de déterminer les contre-mesures qui seront les plus adaptées à l'attaque subie. Quelques exemples types suivent.
2.1 Déni de service lié à une surcharge excessive (aspiration de contenu, effet « slashdot », ...)
Ce premier cas de figure peut sembler hors sujet mais cette situation est relativement classique. Il ne s'agit pas à proprement parler d'une attaque en déni de service, mais plutôt d'une sollicitation a priori légitime mais excessive, qui est susceptible d'engendrer un ralentissement voire une indisponibilité du site.
Les pistes d'amélioration sont notamment les suivantes :
- concevoir correctement son infrastructure, en termes de :
- dimensionnement système et réseau en tenant compte des pics de trafic prévisibles : nombre d'équipements, de liens de connectivité, de façon à assurer robustesse et redondance ;
- localisation et mutualisation de l'hébergement, afin d'évaluer les risques de dommages collatéraux susceptibles d'être causés par une attaque ou une saturation réseau. Par exemple la saturation de la bande passante du serveur Web d'un organisme ne devrait pas avoir d'impact sur son accès Internet en sortie ou sur sa messagerie électronique ;
- réaliser une répartition et un équilibrage de charge par exemple à l'aide des mécanismes suivants :
- en entrée de l'infrastructure à l'aide d'équipements spécifiques qui travailleront aux niveaux réseau et applicatifs ;
- à l'aide d'un mécanisme à jeton tournant (round robin) basé sur DNS ;
- ajuster finement les paramètres des piles réseaux de ses serveurs et les options de traitement des requêtes des serveurs HTTP, le cas échéant ;
- séparer les contenus statiques et dynamiques publiés, en privilégiant notamment des systèmes et serveurs HTTP minimalistes pour la délivrance des contenus statiques ;
- optimiser ses applications, afin d'éviter que des requêtes ne soient trop coûteuses vis-à-vis du nombre des opérations réalisées (par exemple : nombre de transactions aux bases de données, ou de procédures exécutées par les serveurs d'applications) ou encore de la taille du contenu envoyé (taille des images, contenu multimédia, ...) ;
- gérer la qualité de service de son site, par exemple en limitant la bande passante ou encore le nombre de connexions simultanées en provenance d'une même adresse, avec les limitations d'un tel mécanisme par rapport aux mécanismes de traduction d'adresses ou l'utilisation de relais applicatifs susceptibles de masquer derrière une seule adresse IP, de multiples clients. En dernier recours, un filtrage par adresse IP pourra être mis en œuvre, avec toutes les précautions d'usage que cela suppose, notamment filtrer les adresses sur la base d'une connexion TCP pleinement établie uniquement, afin de limiter les risques d'usurpation ;
- louer ponctuellement (en cas de pic de trafic annoncé) les services d'un réseau de type CDN (Content Delivery Network), qui effectuera une duplication partielle des sites et permettra une distribution géographique de serveurs cache au plus proche des clients, en combinant géolocalisation sur la base des adresses IP et aiguillage DNS sélectif. L'emploi d'une telle prestation de service devra faire l'objet d'une analyse de risques afin d'estimer sa conformité à la politique de sécurité de l'organisme (en particulier, la perte de confidentialité occasionnée par la réalisation des transactions sur une infrastructure tierce).
2.2 Déni de service par malveillance
2.2.1 Épuisement des ressources systèmes
Premier cas de figure, l'attaque s'appuie sur les protocoles HTTP ou TCP, avec un établissement de connexion complet, et consiste en l'épuisement des ressources système et non en l'épuisement de la bande passante. Dans ce cas, un filtrage réseau des adresses sources peut être effectué, afin que les connexions TCP ou requêtes HTTP successives soient filtrées en amont et n'atteignent pas les serveurs. Cette détection sera effectuée au niveau des pare-feu, qui détecteront les connexions TCP successives, ou encore au niveau des serveurs frontaux, qui détecteront les requêtes HTTP successives. Cette détection peut être complexe dans la pratique, une attaque de type slowloris sur un serveur Apache sera difficilement détectable si elle provient d'adresses IP multiples effectuant des connexions « légitimes ». Un agent de surveillance positionné au niveau du serveur Web sera donc le plus à même de détecter une attaque en cours.
Dans tous les cas, ce scénario nécessite anticipation et préparation : des indicateurs de qualité de service (taux de disponibilité des sites, mesure des temps de réponse, ...) et de fonctionnement (indicateurs systèmes, réseaux, ...) devront être définis et surveillés afin de participer à la détection d'incident.
Ce type d'attaque qui porte sur des protocoles connectés nécessite, pour l'attaquant, d'employer une adresse IP qui ne soit pas falsifiée : le filtrage temporaire des adresses incriminées est donc une solution envisageable, en prenant garde au fait que cette contre-mesure ne soit pas elle même un vecteur de déni de service pour la plate-forme. Ce filtrage peut donc être réalisé au niveau de la plate-forme même, ou encore en amont, par l'hébergeur et le fournisseur d'accès (à l'aide d'un mécanisme de routage nul ou blackhole route, par exemple, au niveau BGP, via un mécanisme de type RTBH with uRPF décrit dans le RFC 5635).
2.2.2 Épuisement de la bande passante
Second cas de figure, l'attaque s'appuie sur des protocoles non connectés, type ICMP ou encore UDP, et visent un épuisement de bande passante : la contre-mesure est dans ce cas beaucoup plus complexe, car il n'est théoriquement plus possible de filtrer les adresses IP sources à l'origine des paquets, dans la mesure où elles sont susceptibles d'être falsifiées.
Ce propos doit être modéré : les attaques en déni de service ne font pas nécessairement usage d'adresses IP falsifiées, dans la mesure où les fournisseurs d'accès ont généralement pour bonne pratique d'interdire en bordure de leurs systèmes autonomes les adresses IP sources qui ne leur sont pas attribuées. En pratique, c'est donc plutôt la multiplication des adresses IP sources, liées à l'utilisation d'un botnet, qui rendra difficile ce filtrage que le fait qu'une falsification soit potentiellement réalisée.
Toujours dans ce cas de figure, filtrer le trafic en entrée de la plate-forme hébergée est donc illusoire, dans la mesure où la bande passante allouée par l'opérateur sera déjà saturée et le déni de service sera de toute façon effectif. Les mesures de protection incombent donc au fournisseur d'accès internet, avec lequel il conviendra de contractualiser soigneusement les procédures de détection et de traitement d'incident.
Si cette attaque massive vise explicitement les adresses IP de la plate-forme, il peut être envisagé de basculer le trafic vers un site de secours qui disposerait d'un plan d'adressage IP alternatif, par l'intermédiaire du protocole DNS, en fixant des compteurs d'expiration courts, avec le risque d'un dysfonctionnement temporaire pour les clients d'opérateurs disposant d'une réponse à TTL long en cache. Si cette attaque massive suit le nom de domaine, la précédente contre-mesure sera inefficace. Dans une telle situation, la solution la plus immédiate pour l'opérateur sera de null-router les adresses IP du site ciblé par l'attaque, en bordure de son réseau (via BGP encore une fois, avec une technique de type filtre RTBH), ce qui limitera l'accessibilité du site mais permettra à l'opérateur de préserver sa propre infrastructure. Une nouvelle fois, un filtrage sur les adresses IP impliquées dans l'attaque pourra être mis en œuvre (toujours via BGP et la technique RTBH with uRPF).
D'autres solutions sont susceptibles d'être proposées par l'hébergeur et l'opérateur, mais seront de toute façon à contractualiser via le cahier de clauses techniques particulières, qui encadrera la prestation d'hébergement. En particulier, il faudra également surveiller et secourir les éventuels services annexes (DNS, en particulier) nécessaires au bon fonctionnement de la plate-forme, ou encore de prévoir un fonctionnement dégradé en mode France, afin de limiter la connectivité aux seuls internautes français afin de limiter la portée d'une attaque.
2.3 Documentation
- RFC 5635 :
http://www.ietf.org/tfc/rfc5635.txt
3 Microsoft Security Essentials
Depuis cette semaine, la version finale (1.0) de l'antivirus gratuit de Microsoft dénommé Microsoft Security Essentials est disponible en téléchargement sur le site de l'éditeur.
Basé sur le même moteur que OneCare, l'antivirus se veut basique et simple d'utilisation. Il remplace l'anti spyware gratuit Windows Defender, et fait suite à la tentative infructueuse de la part de Microsoft de vendre un produit payant pour les utilisateurs (Windows Live OneCare).
Il est à noter que l'utilisation de Microsoft Security Essentials semble nécessiter la participation à Microsoft SpyNet, l'option n'étant pour le moment pas désactivable. Ceci signifie que certaines informations sur le système, éventuellement personnelles, seront envoyées à l'éditeur (cf. déclaration de confidentialité sur le site de l'éditeur).
Enfin, le CERTA rappelle qu'un logiciel antivirus, s'il peut aider à détecter la présence de codes malveillants, repose sur une base de signatures qui doit être créée par les éditeurs à partir de souches. Dans ce sens, un antivirus sera toujours en retard dans le temps par rapport à l'apparition des codes malveillants. Les utilisateurs et administrateurs ne doivent donc pas se reposer uniquement sur de telles solutions, insister sur des mises à jour régulières des applications utilisées et l'application des bonnes pratiques en matière de sécurité des systèmes d'information.
Documentation
- Téléchargement de Microsoft Security Essentials :
http://www.microsoft.com/security_essentials/default.aspx
4 Un contrôle d'ordinateurs zombies imagé
Un botnet, ou « réseau d'ordinateur zombies », est composé de machines compromises attendant des ordres pour agir. Ainsi le contrôleur du réseau peut demander aux ordinateurs sous son contrôle de participer à des campagnes de pourriels, de mener des attaques en déni de service ou de propager du code malveillant. Cependant, pour que cela fonctionne il faut que les machines reçoivent un ordre. S'il est assez courant que celles ci utilisent l'IRC ou une requête HTTP pour attendre leurs directives, une nouvelle méthode a été abordée cette semaine. Il s'agit encore d'une requête HTTP mais qui ne charge plus du texte mais une image, ou ce qui y ressemble.
En effet, la requête demande un fichier JPEG et le serveur répond un contenu qu'il annonce comme étant une image (HTTP content-Type Header:image/jpeg), qui commence comme une image (les 32 octets d'un entête JPEG) mais qui continue avec des commandes obscurcies qui seront utilisées par le code malveillant en attente d'instruction. Ces commandes ne formant pas une image correcte, il est possible d'identifier ce type d'échange en cherchant les images malformées.
5 Chrome Frame
La société Google a publié au mois d'août 2009, une extension (plugin) nommée Google Frame destinée aux navigateurs de Microsoft Internet Explorer 6 et Internet Explorer 7. Celle-ci a pour effet d'installer dans le contexte du navigateur le moteur de rendu Webkit en plus du moteur de rendu classique d'Internet Explorer à savoir Trident. Il est ainsi possible pour l'utilisateur d'utiliser en parallèle deux moteurs de rendu.
C'est à la charge du concepteur de la page web de définir un marqueur particulier qui indiquera au navigateur d'utiliser Google Frame à la place de Trident. Ainsi, c'est le contenu de la page web qui déclenchera ou pas l'activation de tel ou tel autre moteur.
Selon Google, cela permettrait aux utilisateurs d'Internet Explorer d'effectuer une migration « en douceur » vers leur propre navigateur : Google Chrome qui utilise nativement Webkit pour fonctionner.
Il n'est pas du propos de cet article d'argumenter sur la qualité ou la robustesse de tel ou tel moteur de rendu. En revanche, il convient de noter que l'ajout ou le remplacement d'un moteur de rendu dans un navigateur n'est pas sans conséquence sur la sécurité du navigateur « accueillant ». On ne s'attardera pas non plus, ici, sur la version 6 d'Internet Explorer qui est plutôt en fin de cycle de vie. Par contre, la version 7 d'Internet Explorer est encore très fréquemment utilisée et n'a pas encore été supplantée par la version 8. On pourra donc s'interroger sur les effets de l'ajout d'un tel plugin dans ce navigateur.
De manière générale, le fait d'installer une extension dans un navigateur, quel qu'il soit, fait que sa surface d'attaque s'en trouve augmentée. Rajouter un moteur de rendu en tant qu'extension revient à ajouter toutes les vulnérabilités potentielles inhérentes à ce moteur.
Ce faisant, l'utilisateur doit également bien avoir conscience que lorsqu'une vulnérabilité touchera Google Chrome, il faudra très certainement qu'il mette à jour l'extension Chrome Frame pour Internet Explorer.
On peut aussi s'interroger légitimement sur la façon dont seront gérées les données de connexions ou les fichiers de mise en cache. Quel rôle sera dévolu à quel moteur ou quel composant ? Comment fonctionnera la manipulation des certificats et du secret dans le navigateur avec deux moteurs différents ?
Par ailleurs, le CERTA recommande souvent lors d'alertes d'utiliser des navigateurs alternatifs. Avec une telle extension, Internet Explorer présentera un risque double de ne plus être utilisable. Par ailleurs comme le choix du moteur à utiliser dépend du contenu de la page visitée, il est facile pour un attaquant de déclencher l'utilisation du composant vulnérable.
On pourrait argumenter sur le fait que l'utilisation d'une telle extension apporte à des navigateurs vieillissants des améliorations en termes de sécurité comme une boîte à sable (sandbox) par exemple. Mais, dans ce cas, ne vaut-il pas mieux utiliser un autre navigateur complet plutôt qu'une solution hybride dont on ne maîtrise pas forcément le comportement ?
