CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
N^2005-12
Gestion du document
Une gestion de version détaillée se trouve à la fin de ce document. 1 Activité en cours1.1 Ports observésLe tableau 3 montre les rejets pour les ports sous surveillance que nous avons constatés sur deux dispositifs de filtrage, entre le 10 et le 17 mars 2005. Les rejets constatés la semaine précédente sur les ports 12022/tcp et 31511/tcp ont complètement disparu. Nous remarquons une augmentation des rejets sur le port 42/tcp qui est associé au service WINS (résolution de noms Netbios), ce service faisant l'objet d'une vulnérabilité critique permettant d'obtenir les droits administrateur à distance (avis CERTA-2004-AVI-384). 1.2 Quelques attaques traitées5 cas de défiguration de site web ont été traités :
Nous n'avons pas d'information quant à la faille exploitée pour les trois autres cas. Par ailleurs, nous avons été informés de la compromission d'un serveur web sous Linux qui a été utilisé à des fins de « phishing ». Ce serveur a été compromis par l'exploitation d'une faille de phpBB. Cet incident montre bien que les failles des serveurs web ne sont pas utilisées uniquement pour des défigurations. 2 Corruption des caches DNSCes dernières semaines, des attaques par corruption de cache DNS (Domain Name System) ont été observées. Le DNS est le protocole qui permet de faire la correspondance entre le nom d'un domaine ou d'une machine et une adresse IP. Un client DNS va ainsi effectuer une requête auprès d'un serveur DNS. Le protocole de transport utilisé par le protocole DNS est UDP sur le port 53 (et dans certains cas TCP). Du côté serveur on pourra citer les serveurs DNS bind, djbdns ainsi que le serveur de Microsoft Windows. Du côté client, des utilitaires d'interrogation de serveurs DNS sont disponibles nativement sur tous les systèmes d'exploitation. Par exemple, sous Microsoft Windows, l'utilitaire nslookup permet d'interroger un serveur DNS afin d'effectuer des résolutions de noms. Sous les UNIX (GNU/Linux, BSD etc), citons par exemple les outils nslookup, host ou dig. Lorsqu'un client ou un serveur cache DNS adresse une requête à un serveur, il va mémoriser le résultat dans un cache (service Dnscache sous Windows par exemple). Ce mécanisme améliore les performances du protocole. Les attaques par corruption de cache DNS consistent à ajouter ou modifier une ou plusieurs entrées de ce cache. Lorsqu'un utilisateur demandera l'adresse IP associée à un nom de domaine (par exemple google.fr) au serveur DNS victime, l'adresse IP renvoyée sera inexacte (IP_du_serveur_Pirate au lieu de 216.239.59.104 par exemple). Le principe général de la corruption de cache DNS est l'envoi de données complémentaires malicieuses par un serveur DNS sous contrôle d'un pirate à un serveur DNS victime. Le serveur DNS victime va mettre à jour son cache de manière aveugle, en fonction des données envoyées. Lors de la prochaine requête DNS par un utilisateur interrogeant le cache DNS corrompu, l'adresse IP renvoyée sera non pas celle légitime mais celle d'un serveur sous contrôle du pirate. Une fois la victime redirigée vers le site pirate, plusieurs actions pourront être intentées comme du vol d'information (site à l'allure identique à un site bancaire par exemple), l'installation de code malveillant en exploitant une faille connue du navigateur, etc. Comme tout applicatif, il est important d'effectuer les mises à jour dès la découverte d'une vulnérabilité et la mise à disposition du correctif. Tous les serveurs DNS ne sont pas vulnérable à ces attaques. Dans le cas des serveurs DNS sous Microsoft Windows NT ou Microsoft Windows 2000 on pourra se référer à l'article 241352 de la base de connaissance Microsoft : http://support.microsoft.com/kb/q241352/ 3 Rappel des avis et des mises à jour émisDurant la période du 14 au 18 mars 2005, le CERTA a émis les avis suivants :
Pendant cette même période, les mises à jour suivantes ont été publiées :
4 Actions suggérées4.1 Respecter la politique de sécuritéQuoique puisse suggérer ce document, la politique de sécurité en vigueur dans votre service doit primer. Cette section précise néanmoins quelques mesures générales de nature à vous prémunir contre les agressions décrites dans ce document. 4.2 Concevoir une architecture robusteA la lumière des enseignements tirés de ce qui
a été présenté dans les bulletins
d'actualité, il convient de vérifier que les
applications mises en 4.3 Appliquer les correctifs de sécuritéLe tableau 2 rappelle les avis du CERTA correspondant aux applications ou codes malveillants relatifs aux ports étudiés dans les sections précédentes. 4.4 Utiliser un pare-feuL'application des correctifs sur un parc informatique important n'est probablement pas immédiat. Un pare-feu correctement configuré peut retenir certaines attaques informatiques le temps d'appliquer les correctifs. Cependant un pare-feu peut donner une illusion de protection. Cette protection est brisée par la moindre introduction d'un ordinateur nomade dans la partie protégée. On remarque qu'il y a de nombreux paquets rejetés à destination de ports légitimement utilisés par des applications de prise de main à distance. La téléadministration correspond à une demande qui grandit avec la taille du parc à gérer. Les paquets rejetés montrent le risque associé à ce type d'application. Ce risque peut être amoindri par l'usage correct d'un pare-feu. 4.5 Analyser le réseauDe nombreux paquets rejetés étudiés correspondent aux ports ouverts par divers virus/vers/chevaux de Troie. Si votre politique de sécurité autorise le balayage des ports ouverts sur les postes de travail ou les serveurs, il peut s'avérer utile de le faire régulièrement afin de découvrir les machines potentiellement contaminées avant qu'un intrus ne le fasse à votre place. 4.6 Réagir aux incidents de sécuritéOrganisez-vous pour réagir aux incidents de sécurité, en particulier, pour assurer une certaine continuité dans les équipes d'administration et de sécurité. Le CERTA a pour mission de vous aider à répondre aux incidents de sécurité informatique. Ne traitez pas les dysfonctionnements des machines à la légère. Dans certains incidents dans lesquels le CERTA intervient, les administrateurs des machines font spontanément part de petits dysfonctionnements inexpliqués et d'apparence anodine qui s'avèrent, au cours de l'analyse, être liés à un incident majeur de sécurité. N'hésitez pas à prendre contact avec le CERTA si vous constatez de l'activité sur les ports décrits ci-dessus.
,D,,2 /D//2
Liste des tableaux
Gestion détaillée du document
CERTA 2012-01-04 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
uvre (ou à
l'étude) ont une architecture qui résiste aux
incidents décrits.