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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-42

Gestion du document

Référence CERTA-2011-ACT-042
Titre Bulletin d’actualité 2011-42
Date de la première version 21 octobre 2011
Date de la dernière version 21 octobre 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 Incidents de la semaine

1.1 Une défiguration n’est pas un incident mineur

Dans son activité de veille, le CERTA a repéré la défiguration du site web d’une administration. Celle-ci, prévenue, s’est classiquement retournée vers le prestataire qui a conçu le site et l’héberge. Le site a rapidement recouvré son aspect normal.



Le répit fut de courte durée pour le client. En effet, le serveur étant resté globalement vulnérable, le CERTA a repéré une page de filoutage dans le site soi-disant réparé.



Le CERTA ne répétera jamais assez qu’un incident, même d’apparence superficiel comme une défiguration, doit être traité en profondeur et de manière exhaustive.

Une intrusion est l’illustration visible de la porosité d’un site Web. Il convient de reconstruire complètement et de durcir le serveur lors de la remise en service du site. Dans la négative, des utilisations illicites plus discrètes (site warez) ou des portes dérobées peuvent persister.

Par ailleurs, la suppression pure et simple des traces de l’intrusion peut nuire à une enquête si le serveur a servi à des actions contre une autre entité. Ces traces doivent donc être conservées, au moins provisoirement.

1.2 Documentation

2 Le code malveillant Duqu

Ce code malveillant (prononcer diou-kiou) a été analysé par plusieurs organismes spécialisés dont les éditeurs d’antivirus (voir section Documentation). Le rapport Symantec a fait des analogies avec le ver Stuxnet, médiatisé en 2010. L’état actuel des analyses doit conduire à une certaine retenue dans la comparaison.

2.1 Points communs

Des blocs de code identiques se retrouvent dans Stuxnet et Duqu. La reprise de blocs de programmes, sources ou compilés, notamment pour les parties utilitaires (référence aux API systèmes, etc.) n’est pas un phénomène nouveau dans le monde des codes malveillants.

Plus intéressant, l’installation d’un pilote (driver) malveillant par Duqu est rendue moins visible par l’utilisation d’une signature qui correspond, pour sa vérification, à un certificat valide. Stuxnet a utilisé des certificats correspondant à deux sociétés différentes. Le certificat pour Duqu était produit pour la société taïwanaise C-Media Electronics Incorporated et signé par Verisign. Le détail de la production de cette signature illicite n’est actuellement pas connu. Ce certificat a été révoqué le 14 octobre 2011 selon Symantec. Des variantes se présentent comme des pilotes non signés produits par JMicron Technology Corporation, Adaptech Inc. et IBM.

Les deux codes malveillants tentent des connexions par Internet. Dans l’état des connaissances actuelles, Duqu tente de se connecter à l’adresse IP 206.183.111.97 en HTTP et HTTPS.

Il n’est pas exclu que d’autres adresses soient utilisées, par exemple dans des variantes futures.

2.2 Différences

À la différence de Stuxnet, les variantes de Duqu analysées n’embarquent pas de charge utile visant les systèmes industriels.

Cela ne doit pas faire baisser la vigilance. Duqu ouvre une porte dérobée sur le système compromis. Dès lors, l’attaquant peut utiliser l’ordinateur vulnérable pour attaquer un système informatique classique aussi bien qu’un système industriel.

Un logiciel espion a également été trouvé sur des systèmes infectés avec des fonctions de copie d’informations de configuration et de capture des frappes clavier.

2.3 Documentation

3 Fausse mise à jour flash…

Un cheval de Troie cible actuellement les utilisateurs de Mac OS X. Celui-ci se fait passer pour une mise à jour du lecteur flash.

En demandant le mot de passe de l’administrateur du système (comportement légitime lors de l’installation d’une application), celui-ci désactive les protections existantes sur le système telles que XProtectUpdater permettant de mettre à jour le moteur de détection de malwares inclus dans Mac OS X.

Le CERTA rappelle que le téléchargement de logiciels non hébergés par l’éditeur requiert la plus grande prudence de la part de l’utilisateur et ce, quel que soit le système utilisé.

Documentation

4 …et mise à jour de l’outil de configuration Adobe Flash Player

Cette semaine Adobe a corrigé une vulnérabilité dans son outil en ligne de configuration des lecteurs Flash. Cette vulnérabilité de type clickjacking permet l’activation à distance de la webcam ou du microphone du poste visitant une page Web malveillante.

Cette mise à jour repose sur une modification de l’outil de configuration du lecteur qui se situe sur le site Web d’Adobe. En effet, le CERTA profite de cette actualité pour rappeler que les moyens de modification des paramètres de configuration du lecteur ne résident pas toujours sur le poste de travail. Depuis la version 10.3 d’Adobe Flash Player, il est possible de configurer son lecteur Flash depuis le panneau de configuration Windows ou les préférences Système de Mac OS. Tout utilisateur d’une version antérieure ou d’autres systèmes d’exploitation souhaitant prendre connaissance et/ou modifier les différentes configurations d’Adobe Flash Player doit se rendre à cette adresse :

http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager01.html

Documentation

5 Élévation de privilèges d’administrateur local à administrateur de domaine (4ème et dernière partie)

Nous terminons cette série d’articles sur l’élévation de privilèges dans Active Directory. Les attaques abordées dans cette série d’articles constituent la grande majorité des moyens utilisés par les attaquants dans les incidents gérés par le CERTA. En aucun cas il ne s’agit ici d’une énumération exhaustive des attaques possibles contre Active Directory. De plus, nous nous sommes concentrés sur les aspects relatifs aux faiblesses des déploiements d’Active Directory. Nous avons volontairement exclu de notre série d’articles les vulnérabilités induites par l’absence d’une ou plusieurs mises à jour de sécurité ou bien encore par l’utilisation de systèmes d’exploitation obsolètes.

Lent : Rechercher dans le système de fichiers la présence d’informations d’authentification

Attaque :

Lors de la prise de contrôle d’une machine, a fortiori avec les privilèges d’administration, l’attaquant dispose d’un volume important d’information à sa disposition : la base de registre, le système de fichiers, l’accès au réseau de l’entreprise. Avec un minimum de méthode et de patience, il va pouvoir accéder :
  • aux mots de passe stockés dans la base de registre ou dans les fichiers de configuration d’applications (VNC, unattend.txt, etc.).
  • aux différents scripts accessibles :
    • dans le SYSVOL ;
    • les partages réseau.

Autant de précieuses sources d’informations d’identification que l’attaquant va réutiliser sur d’autres systèmes (SGBD, Application métier, …).

Prévention :

Les systèmes « exposés » (portables, serveurs exposés à l’Internet, ordinateurs de bureau) doivent être régulièrement audités afin de déterminer la liste des informations d’identification disponible sur le poste/serveur. De plus, on complètera cet audit par une évaluation de la criticité des informations disponibles sur le réseau, en lecture, par ce poste et par son utilisateur (mots de passe, documents sensibles,…).

Très lent : Attaquer les informations d’identification mises en cache

Attaque :

Sur les machines membres d’un domaine Active Directory, par défaut, le système stocke un vérificateur d’information d’authentification (à ne pas confondre avec le condensat du mot de passe). Cette information va permettre au système d’ouvrir une session pour un utilisateur du domaine même sans connectivité à l’Active Directory. Ce mécanisme requiert que l’utilisateur se soit connecté interactivement à ce poste en présence d’un contrôleur de domaine.

L’attaque consiste à extraire ces vérificateurs et à les attaquer afin de retrouver le mot de passe de l’utilisateur. Cette attaque est très lente car chaque tentative utilise de nombreuses opérations cryptographiques. De plus, contrairement au condensat du mot de passe, le vérificateur ne peut pas être utilisé pour s’authentifier sur le réseau. Il est nécessaire de « casser » le mot de passe pour s’authentifier.

Prévention :

Une politique de mots de passe forts est une mesure de prévention nécessaire et suffisante pour se prémunir de cette attaque. D’autres alternatives comme la désactivation de ce mécanisme de cache, limitent inutilement l’accès au poste de travail si aucun contrôleur de domaine n’est joignable (ordinateur nomade, problème de connectivité réseau, etc.).

Rappel des avis émis

Dans la période du 10 au 16 octobre 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 21 octobre 2011
    version initiale.