S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 25 mars 2011
N° CERTA-2011-ACT-012
Affaire suivie par: CERT-FR
le 25 mars 2011

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-12

Gestion du document

Référence CERTA-2011-ACT-012
Titre Bulletin d’actualité 2011-12
Date de la première version 25 mars 2011
Date de la dernière version 25 mars 2011
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 CDN et protection contre les DDOS

Il est souvent d’usage de dire que les CDN pour Content Delivery Network permettent de se prémunir des attaques par déni de service distribué.

Le concept de CDN est relativement simple, il consiste, pour un site donné, en la mise en cache de son contenu sur de nombreuses machines (le CDN à proprement parlé). L’usage particulier des DNS permettra d’aiguiller un client vers le cache le plus proche en terme de temps et de nombre de sauts. Si le cache consulté dispose déjà de la page, c’est lui qui distribue le contenu sinon il s’adresse d’abord au serveur source (« le vrai serveur ») afin d’obtenir la page et la délivre ensuite au client.

L’idée est évidemment de supporter une charge plus importante en distribuant largement le contenu au sein du CDN qui pourra le fournir efficacement et localement au client.

Cependant, il y a quelque temps, des chercheurs ont montré qu’il pouvait y avoir un biais dans ce système. En effet, comme tout système de cache, le CDN fonctionne bien dans le cas de contenus statiques comme des pages en HTML simple, des images ou vidéos. Si le site source est dynamique, cela se complique…

En effet, pour chaque requête spécifique, un nouvelle mise en cache aura lieu. Ainsi, si l’on prend une requête GET avec quelques paramètres, il suffit que l’un de ces paramètres varie pour qu’une nouvelle mise en cache ait lieu suivant la règle « une requête = un contenu spécifique ». Une nouvelle requête au serveur source sera alors engendrée. Dans ce cas précis, le CDN n’est plus d’une grande utilité puisque pour chaque requête de client, on a une requête sur le serveur source.

Un botnet utilisant ce genre de technique serait à même d’annuler en partie les effets bénéfiques de l’utilisation d’un CDN. Cependant, il est alors possible d’identifier la présence de ces machines zombies dans un réseau car elle vont occasionner un important trafic à destination de la cible avec des requêtes variant très peu mais toujours sur la même page.

Ces même chercheurs ont d’ailleurs montré qu’il était possible d’améliorer la technique d’attaque pour que ce défaut particulier du botnet soit supprimé et que l’attaque en DDOS exploite à son avantage et de façon optimale la présence du CDN.

2 Correction de l’alerte CERTA-2011-ALE-002 : produits Adobe

Comme prévu par Adobe, la vulnérabilité annoncée la semaine dernière (voir l’alerte CERTA-2011-ALE-002) concernant les logiciels Adobe Flash Player, Adobe Reader et Adobe Acrobat a été corrigée pour ces produits. Pour rappel, cette vulnérabilité permet l’exécution de code arbitraire à distance via des documents spécialement conçus.

Compte tenu du fait que cette vulnérabilité est actuellement exploitée activement sur l’Internet, le CERTA recommande vivement l’installation de ces mises à jour.

4.3 Documentation

3 Vrais faux certificats SSL

Le CERTA a émis un avis (CERTA-2011-AVI-169) à propos de l’émission, et de la révocation par certains navigateurs, de certificats SSL. Un compte d’une autorité d’enregistrement (RA) affiliée à l’autorité de certification (CA) Comodo présentait une vulnérabilité. Cette brèche a été exploitée par des attaquants qui ont émis frauduleusement neuf certificats sur sept domaines différents. L’un de ces faux certificats a été utilisé pour monter une attaque trompant les internautes.

L’incident a été detecté le 15 mars 2011. L’autorité de certification immédiatement révoqué ces certificats. Elle a également contacté des éditeurs de logiciels pour la mise en liste noire de ces certificats. La mise à jour des listes de révocation (CRL) et des serveurs de vérification OCSP ne suffit pas à se prémunir contre l’utilisation de ces certificats :

  • l’utilisateur d’un navigateur peut avoir désactivé ces modes de contrôle de validité des certificats ;
  • le comportement du navigateur, en l’absence de réponse du serveur OCSP ou du serveur de CRL peut être de considérer que le certificat n’est pas révoqué ;
  • l’attaquant qui exploite la fraude précédente en s’interposant entre des internautes et le vrai serveur peut également s’interposer entre le navigateuret le serveur, OCSP ou de CRL.

Les navigateurs suivants ont fait l’objet de mises à jour :

  • Chrome ;
  • Firefox et Seamonkey ;
  • Iceweasel ;
  • Internet Explorer.

Au-delà des navigateurs, d’autres logiciels clients peuvent être touchés : messagerie, messagerie instantanée…

4 SCADA – Publications de vulnérabilités

4.1 Actualité

Cette semaine a vu se mutiplier les publications de vulnérabilités des systèmes industriels, ou d’outils les exploitant :

  • un chercheur détaille et publie des preuves de faisabilité visant Siemens Technomatix FactoryLink, Iconics GENESIS32 et GENESIS64, 7-Technologies ICSS et Realwin Realflex SCADA. L’impact des ces exploitations va de la divulgation d’informations à l’exécution de code arbitraire à distance. Plusieurs vulnérabilités ne sont pas corrigées ;
  • un outil de test d’exploitation de vulnérabilités, récentes ou non, dont une non corrigée, avec la même diversité d’impacts, vise par exemple Moxa DMT, TRACE MODE Data Centre, Ecava IntegraXor et GE Fanuc Real-Time Portal ;
  • l’ICS-CERT, alter ego de l’US-CERT pour les systèmes industriels, publie six bulletins relatifs aux vulnérabilités de plusieurs de ces produits.

Cette actualité montre que les systèmes industriels deviennent un terrain d’attaques informatiques qui se banalise. Des preuves de faisablité, détournables en code d’exploitataion, sont publiées. Des outils, dits de test, mais utilisables de manière hostile, sont téléchargeables.

La réactivité des éditeurs et des intégrateurs de systèmes industriels sera mise à rude épreuve.

4.2 Recommandations

Face à ces menaces qui se « démocratisent », le CERTA recommande, dans la mesure des possibilités des systèmes et des contraintes règlementaires et industrielles, au moins l’application des mesures classiques d’hygiène informatique :

  • inventaire des produits utilisés et des versions en exploitation ;
  • suivi des informations des éditeurs sur ces logiciels, dont les vulnérabilités ;
  • mise à jour des logiciels ;
  • à défaut, mise en place des mesures d’atténuation de la menace ;
  • cloisonnement de l’architecture et des flux réseau, filtrage et journalisation associés ;
  • surveillance des interconnexions ;
  • séparation des rôles, notamment entre administrateur, programmeur de système et exploitant ;
  • utilisation des fonctions d’authentification offertes (SCADA, protocoles, automates) ;
  • utilisation de mots de passe forts et remplacement des mots de passe usine ;
  • sensibilisation de tous les personnels ;
  • protection des accès physiques et traçabilité ;
  • attention particulière aux opérations de maintenance ;
  • politique restrictive vis-à-vis des supports amovibles et désactivation des automatismes qui leur sont liés…

4.3 Documentation

Rappel des avis émis

Dans la période du 14 au 20 mars 2011, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 25 mars 2011
    version initiale.