1 Incident de la semaine

Cette semaine le CERTA a traité un cas de compromission de site web. Le site en question, basé sur un gestionnaire de contenu non mis à jour, présentait tous les symptômes d’une attaque réussie de type injection de code. De prime-abord, une seule page semblait touchée mais, en réalité, plusieurs centaines de pages avaient été modifiées.

Le CERTA a été sollicité pour faire l’analyse des journaux de la machine et diagnostiquer l’ampleur des dégâts commis. Cependant, l’hébergeur n’a pu fournir à la date de ce bulletin qu’un seul mois de journaux à analyser. Or, après une rapide lecture, il est apparu que la compromission initiale datait sans doute de beaucoup plus longtemps. En l’état, l’analyse n’a pas permis de mettre en évidence le point d’entrée utilisé par le ou les attaquants pour compromettre le site.

1.1 Recommandations

En l’espèce, un délai d’un mois était clairement insuffisant pour la conservation des journaux. L’expérience montre qu’il faut parfois remonter plusieurs mois en arrière pour retrouver l’origine d’une compromission. Il convient donc de conserver les journaux sur une période d’au moins un an. En matière de conservation et plus généralement sur la gestion des journaux, vous pouvez également vous référer à la note d’information CERTA-2008-INF-005.

1.2 Documentation

2 Sortie d’Adobe Reader X

Le 18 novembre dernier, la version 10 du lecteur de PDF Adobe Reader est sortie. La principale nouveauté de cette version est l’ajout d’un mode protégé, basé sur l’utilisation d’un mécanisme de « bac à sable », pour les versions Windows de cet outil.

2.1 Fonctionnement du mécanisme de bac à sable

Le mécanisme de bac à sable mis en place dans cette nouvelle version s’appuie à la fois sur les mécanismes de sécurité de Windows (plus particulièrement Windows Vista/7) et sur les implémentations existantes telles que le bac à sable de Google Chrome, ou certains mécanismes mis en place dans MS Office.

Le code responsable du rendu du PDF est exécuté à l’intérieur du processus bac à sable, les opérations effectuées sur le système par ce code sont limitées au minimum nécessaire.

Afin de limiter ces actions, Adobe Reader va appliquer les restrictions suivantes au processus bac à sable :

  • limitation du jeton d’accès de sécurité du processus ;
  • assignation de ce processus à un job object avec des restrictions ;
  • exécution du processus à un niveau d’intégrité bas (uniquement sur Windows Vista, 7 et Server2008).
 

Les actions sur le système, interdites à l’intérieur du bac à sable (écriture dans un fichier, d’une clé de registre…) sont relayées à un processus appelé broker process qui va autoriser ou non ces actions. Ce processus a le rôle d’un « proxy de confiance ». Il maintient à jour une liste de règles, décrivant les interactions autorisées sur le système, sous forme de liste blanche. Ce processus relaie donc seulement les requêtes faisant partie de cette liste. Un administrateur peut, par l’intermédiaire d’un fichier de configuration, ajouter des règles à cette liste blanche. D’autres règles sont ajoutées dynamiquement à l’exécution (par exemple lors de la sauvegarde d’un fichier, une règle est ajoutée pour pouvoir écrire dans ce fichier).

2.2 Limitations

Pour l’instant seules les opérations d’écritures sont restreintes. Le mécanisme de bac à sable ne protège pas des lectures non autorisées du système de fichiers, des accès au réseau ou encore des lectures du presse-papier. Il est cependant prévu d’étendre le contrôle des actions effectuées sur le système aux opérations de lecture.

2.3 Conclusion

En mettant à disposition un mécanisme de bac à sable, cette nouvelle version du lecteur de PDF d’Adobe présente une évolution intéressante en matière de sécurité, tout particulièrement dans Windows Vista/7.

La présence de ce mécanisme ne dispense cependant pas de maintenir à jour son lecteur PDF. Elle ne représente en effet pas une protection ultime mais simplement un élément de sécurité supplémentaire à combiner avec d’autres éléments tels que la prévention de l’exécution des données (DEP) ou l’allocation non-linéaire de mémoire (ASLR) dans une optique de défense en profondeur.

Enfin, on notera que si par défaut le mode protégé est activé, l’interprétation du JavaScript et du Flash l’est également. Le CERTA rappelle donc qu’il est fortement recommandé de désactiver par défaut l’interprétation de ces deux langages afin de limiter la surface d’attaque de l’application.

2.4 Documentation

3 Contournement de l’UAC

Cette semaine, le CERTA a été informé d’une vulnérabilité concernant Microsoft Windows permettant à un utilisateur malintentionné une élévation de privilèges en contournant l’UAC (User Account Control). Les systèmes vulnérables seraient :

  • Microsoft Windows 7 ;
  • Microsoft Windows Server 2008 SP2 ;
  • Microsoft Windows Vista SP2.

Une preuve de concept a déjà été publiée sur l’internet. Elle exploite une vulnérabilité de type dépassement de mémoire tampon dans la fonction RtlQueryRegistryValues du driver win32k.sys lors de l’accès à des valeurs de registre dont le type a été modifié.

En attendant un correctif de la part de Microsoft, le CERTA rappelle qu’il est nécessaire de ne pas exécuter de programme dont l’origine est inconnue ou suspecte.

Documentation

Rappel des avis émis

Dans la période du 15 au 21 novembre 2010, le CERT-FR a émis les publications suivantes :


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