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-2011-ACT-009

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 04 mars 2011
No CERTA-2011-ACT-009

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2011-09


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-2011-ACT-009

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-009.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-2011-ACT-009/

1 Compromission d'un site sous Joomla!

Le CERTA a traité cette semaine le cas d'une compromission de site fonctionnant avec Joomla!. Les incidents de ce type sont fréquents, et découlent généralement de l'exploitation d'une vulnérabilité dans un module optionnel. Dans le cas abordé cette semaine, il s'agit d'une autre méthode d'attaque : les attaques par dictionnaire. Ces dernières se caractérisent dans les journaux par des traces du type :

<IP attaquant> - - [01/Mar/2011:02:41:23 +0100] "POST /administrator/index.php HTTP/1.1"  
200 4646 - - -
<IP attaquant> - - [01/Mar/2011:02:41:23 +0100] "POST /administrator/index.php HTTP/1.1" 
200 4646 - - -
<IP attaquant> - - [01/Mar/2011:02:41:24 +0100] "POST /administrator/index.php HTTP/1.1" 
200 4646 - - -
...
<IP attaquant> - - [01/Mar/2011:02:41:25 +0100] "POST /administrator/index.php HTTP/1.1" 
303 5 - - -
<IP attaquant> - - [01/Mar/2011:02:41:26 +0100] "GET /administrator/index.php HTTP/1.1" 
200 22374 - - -

Une fois connecté au panneau d'administration, l'attaquant a accès à des scripts permettant le dépôt de fichiers. Il lui devient notamment possible d'installer une porte dérobée sous la forme d'un interpréteur de commandes écrit en PHP.

Dans l'incident traité, l'attaquant a, après avoir déposé sa porte dérobée, tenté d'étendre la compromission à tout le serveur en exploitant plusieurs vulnérabilités du noyau Linux.

Recommandations

Le CERTA recommande à tous les utilisateurs de services informatiques de lire la note d'information CERTA-2005-INF-001 relative aux mots de passe (voir la section « Liens utiles »). Il est, de plus, conseillé aux administrateurs de site Web de lire régulièrement leurs journaux d'accès, et de vérifier que seuls des administrateurs légitimes naviguent sur les pages des différents panneaux d'administration. Enfin, il est recommandé de restreindre l'accès aux pages d'administration (par exemple à des adresses IP spécifiques).

2 NoScript à l'origine de requêtes « étranges »

NoScript est un module complémentaire pour navigateurs Web (Mozilla FireFox, SeaMonkey et autres navigateurs basés sur Mozilla) qui ajoute des fonctionnalités de sécurité.

Il permet par exemple d'établir des listes blanches de domaines pour lesquels l'exécution de code JavaScript ou Adobe Flash sont autorisés. Il intègre également des mécanismes de détection d'exploitation de failles de type injection de code indirecte à distance, ou « XSS ».

Un autre élément utilisé par NoScript est ABE pour Application Boundary Enforcer. Il se propose d'améliorer les mécanismes de défense contre les injections de code indirectes, en instaurant dans le navigateur des protections supplémentaires que l'utilisateur peut configurer. Celui-ci va pouvoir par exemple interdire toute requête à des serveurs Web situés dans le réseau local du poste, qui proviennent d'un site externe à ce dernier.

L'intérêt est de pouvoir bloquer par exemple des scripts qui tenteraient de scanner le réseau interne ou de réaliser des injections de requêtes illégitimes par rebond (Cross-Site Request Forgery) sur ces derniers.

# LOCAL repr�sente les adresses IP locales.
Site LOCAL              # Pour les sites sur des adresses locales
Accept from LOCAL       # on accepte seulement les requ�tes provenant de celles-ci
deny                    # et on rejette toutes les autres

On évite également ainsi qu'un script installé sur un site malveillant tente de se connecter à l'interface administrateur d'un routeur domestique, celle-ci utilisant souvent des identifiants de connexion par défaut, ou très faibles, ou encore possèdant des vulnérabilités.

Le mot-clé LOCAL regroupait initialement les adresses locales, par exemple 127.0.0.1 et le réseau 192.168.0.0/24. Il est facile de connaître le réseau local du poste, en demandant son adresse IP. Or, il a été présenté en été 2010, que bon nombre des routeurs domestiques étaient capables de répondre à une requête adressée à leur adresse IP publique mais provenant de l'interface interne. Un script malveillant peut donc tenter de communiquer avec le routeur depuis un poste sur le réseau interne en contournant les protections présentées ci-dessus.

Depuis la version 2.0rc5 de NoScript, une nouvelle fonctionnalité à été ajoutée à ABE, relative à la règle concernant le réseau local décrite ci-dessus. Pour interdire ce dernier type d'attaque, le module effectue une requête anonymisée au site https://secure.informaction.com/ipecho/ afin de déterminer l'adresse publique utilisée par le routeur, et l'ajouter à la liste des adresses représentées par le mot-clé LOCAL. Tous les postes utilisant l'extension NoScript avec le module ABE activé vont donc effectuer quotidiennement des requêtes à cette adresse.

Comme il arrive que certains routeurs changent d'IP publique très régulièrement, il convient de faire cette vérification plus fréquemment. Toutefois, pour éviter de surcharger le serveur à l'adresse secure.informaction.com par un grand nombre de requêtes, les développeurs de NoScript ont décidé de mettre en place un système de cache.

Par intervalles de quelques minutes, une requête est envoyée à l'adresse IP publique précédemment détectée, et une signature de la réponse est enregistrée. Si cette signature est modifiée, NoScript détecte que l'adresse publique utilisée par le routeur a changé, et effectue une nouvelle connexion à l'adresse secure.informaction.com pour trouver la nouvelle adresse IP publique.

Un routeur reliant un parc comprenant des postes d'utilisateurs, dont le navigateur Web utilise l'extension NoScript en version 2.0rc5 ou postérieure, va donc voir une augmentation significative de requêtes HTTP à destination de son adresse IP publique, sur son interface de réseau local.

Si un serveur Web est installé sur le routeur et configuré pour écouter sur son interface interne, celui-ci enregistrera dans ses journaux des requêtes du type :

XX.YY.ZZ.TT   "GET / HTTP/1.1" 200 370 "-" "Mozilla/5.0 (ABE, http://noscript.net/abe/wan)"
avec XX.YY.ZZ.TT, l'adresse IP publique du routeur/serveur.

Pour demander à NoScript de ne plus effectuer ces requêtes, il suffit de décocher l'option WAN IP LOCAL dans la rubrique NoScript Option Advanced ABE. Attention, car dans ce cas, l'adresse IP publique ne sera alors plus considérée comme une adresse locale, et le routeur sera de nouveau exposé aux attaques indiquées ci-dessus.

Documentation


3 Rappel des avis émis

Dans la période du 25 février au 03 mars 2011, le CERTA a émis les avis suivants :

  • CERTA-2011-AVI-111 : Vulnérabilité dans F-Secure Policy Manager
  • CERTA-2011-AVI-112 : Multiples vulnérabilités dans SumatraPDF
  • CERTA-2011-AVI-113 : Multiples vulnérabilités dans MuPDF
  • CERTA-2011-AVI-114 : Vulnérabilité dans Citrix XenApp et XenDesktop
  • CERTA-2011-AVI-115 : Vulnérabilité dans RT
  • CERTA-2011-AVI-116 : Vulnérabilité dans Citrix Secure Gateway
  • CERTA-2011-AVI-117 : Vulnérabilité dans IBM Lotus Connections
  • CERTA-2011-AVI-118 : Vulnérabilité dans IBM Tivoli Common Reporting
  • CERTA-2011-AVI-119 : Vulnérabilité dans Foxit Reader
  • CERTA-2011-AVI-120 : Vulnérabilité dans Samba
  • CERTA-2011-AVI-121 : Vulnérabilité dans Avahi
  • CERTA-2011-AVI-122 : Vulnérabilité dans Sybase Afaria Data Security Manager
  • CERTA-2011-AVI-123 : Vulnérabilité dans HP Web Jetadmin
  • CERTA-2011-AVI-124 : Vulnérabilité dans PEAR
  • CERTA-2011-AVI-125 : Multiples vulnérabilités dans Wireshark
  • CERTA-2011-AVI-126 : Multiples vulnérabilités dans Google Chrome
  • CERTA-2011-AVI-127 : Multiples vulnérabilités dans les produits Mozilla
  • CERTA-2011-AVI-128 : Vulnérabilité dans Alcatel OmniPCX Enterprise
  • CERTA-2011-AVI-129 : Vulnérabilités dans libpango
  • CERTA-2011-AVI-130 : Vulnérabilité dans Alcatel OmniVista

Durant la même période, les avis suivants ont été mis à jour :

  • CERTA-2011-AVI-079-004 : Vulnérabilité dans plusieurs implémentations de Java (ajout de la référence au bulletin de sécurité HP c02729756)
  • CERTA-2011-AVI-103-001 : Vulnérabilité dans ISC Bind (révision des versions affectées, ajout des références Novell (Suse) et Ubuntu)


Liste des tableaux

Gestion détaillée du document

04 mars 2011
version initiale.


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-08-21