CERTA
Centre d'Expertise gouvernemental de
Réponse et de Traitement des Attaques informatiques
|
CERTA Centre d'Expertise gouvernemental de |
|
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-40
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-040.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-040/ 1 Incidents traités cette semaine1.1 Défiguration invisibleCette semaine, le CERTA a traité un cas de défiguration « invisible ». L'apparence de la page compromise n'avait subi aucune modification, cependant du code avait bel et bien été inséré dans le code source de la page HTML. L'insertion de code se présentait sous la forme de liens hypertexte intégrés dans un paragraphe. La balise associée au paragraphe avait un attribut désactivant son affichage. L'interêt d'une telle défiguration est à rechercher du côté de l'indexation par les moteurs de recherche. En effet, le fait d'ajouter une multitude de liens vers un même site permet d'améliorer la position de ce dernier dans les résultats des moteurs de recherche. Cet incident montre l'interêt pour un administrateur de vérifier régulièrement les journaux d'événements de son serveur web mais également de contrôler l'intégrité des fichiers présents sur le serveur afin de détecter rapidement toute compromission. Cette compromission était en effet invisible à l'oeil nu et seul un contrôle des journaux ou de l'intégrité de la page permettait une détection efficace de cette intrusion. 1.2 Application des correctifs et contrôlesDébut août, le CERTA avait prévenu l'administrateur d'un site Web de la présence d'une page illicite sur son site. L'administateur en congés a rapidement supprimé la page indésirable et a mis à jour à son retour certaines applications dont le gestionnaire de contenu Joomla!. Cette semaine, le CERTA a recontacté cette personne pour l'informer de la présence d'une autre page défigurant son site. Le problème est que cette page était déja présente sur le site lors du premier avertissement. Une analyse un peu plus poussée a permis de découvrir d'autres pages illicites, des shell scripts et des utilisateurs aux droits élevés illégitimement inscrits dans Joomla!. La faille de sécurité exploitée concerne la page de changement de mots de passe de la version 1.5.6 de Joomla! et a fait l'objet de l'avis CERTA-2008-AVI-214 et d'un article du bulletin d'actualité CERTA-2008-ACT-033. Lorsqu'un système est compromis, il doit être entièrement vérifié. En effet, lorsqu'un attaquant réussit à s'introduire dans un système, sa première action est souvent de pérenniser son contrôle sur la machine en installant d'autres portes dérobées. Le CERTA recommande la mise en place d'une vérification régulière de l'intégrité des systèmes. Cela permet de détecter d'éventuelles modifications non désirées, mais aussi en cas de compromission d'avoir une methodologie et une empreinte du système dans un état sain, ce qui permet de retrouver rapidement ce qui a été changé. Il existe des outils dédiés à ce type d'opérations, la difficulté étant de définir les limites de la surveillance. Il est important de sauvegarder sur un support séparé les résultats des prises d'empreintes, afin qu'elles ne soient pas compromises et restent utilisables. 1.3 Le site précédent oublié1.3.1 DescriptionCette semaine le CERTA a informé le propriétaire d'un site d'un contenu frauduleux présent sur ce dernier. Le site hébergeait des pages de filoutage (ou phishing). Une fois prévenu, le responsable du site a pris la décision de supprimer les pages frauduleuses et n'a pas cherché à en comprendre l'origine. Un tel comportement est rarement sans conséquence, en effet deux jours plus tard de nouvelles pages frauduleuses sont apparues. Cette fois l'administrateur a pris la décision de fermer définitivement le site, celui-ci étant une ancienne version non-utilisée d'un site qu'il administre sur un autre serveur. Cet incident soulève plusieurs problèmes :
Le CERTA rappelle que lors d'une compromission il est impératif d'en comprendre la cause et de ne pas se limiter à traiter les conséquences. De plus lorsqu'un site Internet n'est plus utile, il est plus prudent de le fermer afin de ne pas permettre à des tiers de profiter de ses ressources. 1.3.2 documentation
1.4 Nom de domaine et machine compromise1.4.1 PrésentationLe CERTA a rencontré, cette semaine, le cas d'une machine compromise semblant appartenir à une administration. Celle-ci hébergeait un gestionnaire de contenu (CMS) dont la version non mise-à-jour comportait sans doute une vulnérabilité. Par ailleurs, le CMS n'était pas configuré et laissait voir son type et l'accès à son interface d'aministration. Après analyse, le CERTA a pu mettre en évidence que l'enregistrement DNS pointant vers cette machine, n'avait plus lieu d'être depuis plusieurs mois. En effet, l'adresse IP associée à la machine a été réatribuée à une autre entité ne faisant pas partie de l'administration. Pourtant l'enregistrement DNS et l'autorité pour la zone est toujours l'administration. Dans le cas présent, on a donc un domaine pointant sur une machine et une IP qui n'appartient plus à l'entité responsable de la zone DNS. De surcroit, l'enregistrement dans la base RIPE (interrogeable par la commande « whois » ou via http://www.ripe.net) lui aussi référençait encore l'ancien propriétaire de la classe d'adresse IP donc l'administration. Ceci soulève deux problèmes : le premier est que le contenu légitime du site n'a plus aucun rapport avec le domaine recherché. Il est tout à fait envisageable que cette machine héberge dans le futur un contenu pouvant nuire à l'image de l'administration concernée. Le second est que dans le cas d'une compromission comme ici, c'est l'image du propriétaire du domaine (donc de l'administration) qui est mise en cause et pas nécessairement celle du popriétaire réel de la machine. Cette situation s'apparente à celle du « déménagement d'un site » évoquée dans le bulletin d'actualité CERTA-2007-ACT-037 du 14 septembre 2007. 1.4.2 RecommandationsLorsqu'une classe d'adresses IP publique est abandonnée suite à une fin de contrat ou autre, il est nécessaire d'entreprendre les démarches suivantes :
1.5 WebDAV1.5.1 PrésentationCette semaine, le CERTA a traité un incident relatif à la défiguration d'un site Internet de l'administration, une personne ayant ajouté plusieurs pages à la racine du site web. L'analyse des journaux a révélé que les fichiers ont en fait été ajoutés au moyen d'une requête PUT après identification par l'attaquant du service WebDAV sur le serveur. Ce service qui est une extension du protocole HTTP 1.1 est supposé faciliter la publication de documents sur des sites. Il est notamment installé et activé par défaut dans IIS 5.0, contrairement aux versions plus récentes pour lesquelles il est désactivé. Le CERTA recommande la désactivation de ce service quelle que soit la version d'IIS utilisée. Il est possible de désactiver WebDAV dans IIS 5.0 en ajoutant la valeur suivante dans la base de registre : Clé : HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters Nom de la valeur : DisableWebDAV Valeur (DWORD) : 1 Le CERTA en profite également pour rappeler qu'il existe un outil fourni par Microsoft pour aider à sécuriser des serveurs IIS. Cet outil appelé IIS Lockdown Tool est disponible à l'adresse suivante : http://support.microsoft.com/?scid=kb%3Bfr%3B325864 1.5.2 Documentation
2 L'obligation de dénoncerUn employé d'une société de maintenance informatique s'est vu confier un ordinateur, en vue de réparation. Lors de son intervention, il a découvert sur ce matériel des photos pornographiques à caractère pédophile. Sans hésitation, il a supprimé ces fichiers, effectué le dépannage et restitué l'ordinateur au client. Ce n'est que plus tard qu'il a informé son employeur de sa découverte, lequel l'a alors licencié pour faute grave, en raison de la non dénonciation de ce délit. L'employé s'est alors retourné vers le Conseil des Prud'hommes, considérant que son licenciement s'était effectué sans cause réelle et sérieuse. La Cour de Cassation (Cass soc. n^ 07-40670 du 21 mai 2008) a confirmé que le licenciement était justifié: « Dès lors qu'un salarié ayant découvert que l'ordinateur qui lui avait été confié avait été utilisé pour recueillir des images à usage pédophile, qui constitue une infraction prévue par l'article 227-23 du Code Pénal, et n'avait pas immédiatement retenu ce matériel, sauvegardé les fichiers litigieux puis informé l'autorité judiciaire et son employeur, mais avait pris l'initiative, avant de prévenir celui-ci, de supprimer ces fichiers et de restituer l'appareil au client, contrevenant ainsi aux dispositions impératives de la loi et ne permettant plus aux services de Police de procéder utilement à la moindre recherche, les juges du fond ont pu caractériser un licenciement pour faute grave. » Si le cas énoncé se situe dans la sphère privée, la fonction publique est d'autant plus concernée par cette problématique. En effet, l'article 40-1 du Code de Procédure Pénale prévoit que « toute autorité constituée, tout officier public ou fonctionnaire qui, dans l'exercice de ses fonctions acquiert la connaissance d'un crime ou d'un délit est tenu d'en donner avis sans délai au Procureur de la République... » ; le fait de faire obstacle à la manifestation de la vérité est prévu par l'article 434-4 du Code Pénal. En conclusion, en cas de découverte d'infractions, quelles qu'elles soient, dans le cadre de vos obligations professionnelles, pensez :
3 Rumeurs et TCP3.1 Les faitsLa presse s'est faite l'écho cette semaine d'une
vulnérabilité pouvant affecter les mises en Les chercheurs ont présenté par ailleurs d'autres travaux en septembre concernant une méthode appelée "SYN Cookie". Le lien entre cette précédente présentation et la future annonce n'est pas établi. Sans participer à ce phénomène d'amplification, devenu courant avant certaines conférences, le CERTA reste attentif aux conséquences de cette annonce. L'objet de cet article est de clarifier l'usage des SYN Cookies et de préciser l'état actuel des informations disponibles. 3.2 Qu'est-ce qu'un SYN Cookie ?Les attaques visant à perturber les serveurs opèrent de manière très variée et ciblent différentes couches protocolaires. Certaines ont consisté depuis la fin des années 1990 à envoyer plusieurs trames TCP de demande de connexion (SYN). Elles restent encore d'actualité. Pour se prémunir de celles-ci plusieurs solutions
sont possibles. Le standard RFC 4987 ("TCP
Syn Flooding Attacks and Common Mitigations") en
précise certaines. L'une d'elles s'appelle le TCP
SYN Cookie et a été proposée par D.J.
Bernstein. Elle est mise en La solution consiste à s'assurer de l'adresse émettrice avant d'allouer des ressources système pour la connexion. Il s'agit de ne plus affecter pour chaque nouvelle demande de connexion un numéro de séquence ISN (Initial Sequence Number) aléatoire mais une valeur non prévisible prenant en compte certaines caractéristiques de la demande en cours. La machine ne stocke pas toutes les informations. Elle récupère ces informations, dont l'ISN, à la réponse de son correspondant. Si ce dernier n'existe pas, peu de ressources auront été finalement allouées. L'inconvénient majeur est que toute l'information négociée au moment de la demande de connexion TCP, le three-way handshake, se trouve dans le SYN Cookie. Les autres informations qui peuvent être échangées dès l'établissement de la connexion sont perdues. C'est également un avantage pour une machine attaquante qui voudrait envoyer des trames sans elle-même puiser trop de ses propres ressources. Le SYN Cookie est construit, comme l'indique le code source syncookie.c du noyau Linux 2.6.18 ci-dessous, à partir des données suivantes :
L'ensemble de ces valeurs est utilisé pour construire un numéro de séquence non prévisible sous forme d'empreinte irréversible (hash). Le condensat s'appuie sur le Secure Hash algorithm SHA-1. La machine utilisant ce SYN Cookie n'allouera temporairement aucune ressource pour la demande de connexion. Si la machine distante répond, alors les données récupérées dans la nouvelle trame, dont le SYN Cookie, seront utilisées pour attribuer les ressources d'une session TCP établie.
Test pour vérifier la valeur de la SYSCTL associée :
labo:ven oct 03# cat /proc/sys/net/ipv4/tcp_syncookies
0
/* Fichier source syncookie.c
* Syncookies implementation for the Linux kernel
* $Id: CERTA-2008-ACT-040.ltx,v 1.2 2008/10/31 15:00:42 pouget Exp $
*/
static __u32 secure_tcp_syn_cookie(__u32 saddr, __u32 daddr, __u16 sport,
__u16 dport, __u32 sseq, __u32 count,
__u32 data)
{
/*
* Compute the secure sequence number.
* The output should be:
* HASH(sec1,saddr,sport,daddr,dport,sec1) + sseq + (count * 2^24)
* + (HASH(sec2,saddr,sport,daddr,dport,count,sec2) % 2^24).
* Where sseq is their sequence number and count increases every
* minute by 1.
* As an extra hack, we add a small "data" value that encodes the
* MSS into the second hash value.
*/
return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +
sseq + (count << COOKIEBITS) +
((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
& COOKIEMASK));
}
Parmi les informations initialement perdues, on retrouve en particulier des options comme :
Ces dernières servent à contrôler les
problèmes de congestion et de perte. Les mises en L'utilisation des SYN Cookies présente donc des inconvénients. Un contributeur de l'un des premiers correctifs en 1997 se pose d'ailleurs la question de l'intérêt d'ajouter le support pour IPv6, actuellement en débat : http://lwn.net/Articles/277216/ De : Andi Kleen A : linux-kernel AT vger.kernel.org Sujet : Re: [PATCH] Add IPv6 support to TCP SYN cookies (...) Syncookies are discouraged these days. They disable too many valuable TCP features (window scaling, SACK) and even without them the kernel is usually strong enough to defend against syn floods and systems have much more memory than they used to be. So I don't think it makes much sense to add more code to it, sorry. (...) 3.3 Exploitation d'une méthode approchante dans le cadre de dénis de serviceIl n'est pas improbable que la vulnérabilité annoncée exploite la fonctionnalité mentionnée ci-dessus des SYN Cookies, ou du moins une méthode approchante, mise en place par l'attaquant. Sans être révolutionnaire, il s'agit d'utiliser un minimum de ressources du côté du poste attaquant. Rien n'est cependant sûr à la date de rédaction de cet article. Néanmoins, on peut imaginer le scénario suivant, où la machine cliente parvient à créer par ce biais beaucoup de connexions TCP établies du côté du serveur. La subtilité réside alors dans la facilité à maintenir la connexion ouverte ou d'attendre qu'un minuteur marquant la durée de session n'expire. Certains outils dits tarpit emploient de telles techniques (par exemple présenter une taille de fenêtre TCP nulle à une demande de connexion). Des idées ont été également suggérées dans de précédents articles de recherche (cf. section 3.5). 3.4 Que faut-il retenir ?Il est important, avant de mettre en La faille qui fait actuellement l'objet de rumeurs n'est pas documentée. En tout état de cause, cette faille ne remet pas en cause les bonnes pratiques à mettre en place pour prévenir les dénis de service ainsi qu'une politique de filtrage rigoureuse et précise du trafic autorisé.
|
||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
)
uvre du protocole de transport TCP de certains
systèmes. Des chercheurs finlandais ont annoncé
avoir trouvé une vulnérabilité qu'ils
présenteront au cours d'une conférence
mi-octobre, mais aucun détail n'est à ce jour
connu. Les rumeurs et suppositions sont apparues et ont
été ainsi amplifiées dans la presse.
uvre dans la
majorité des systèmes d'exploitation Linux et
BSD.
uvre actuelles de SYN Cookies n'activent donc cette
méthode que quand le nombre de demandes en cours atteint
un nombre important, défini par la variable
net.ipv4.tcp_max_syn_backlog. Cette dernière
vaut 1024 par défaut.
uvre
des mesures de sécurité, de bien comprendre leur
fonctionnement. Dans le cas des SYN Cookies, il s'agit d'une
méthode de protection contre une classe d'attaques en
déni-de-service qui présente certains avantages
mais également des inconvénients. Ces derniers
doivent être connus et acceptés.