Objet: Bulletin d'actualité 2010-14

1 Exécution de programmes à partir de documents au format PDF

1.1 Description du problème

Le format de document électronique PDF (Portable Document Format) est défini par la norme internationale ISO 32000-1:2008. À la section 12.6, on découvre que le format permet de spécifier le lancement d'applications selon plusieurs critères au moyen du champ /ACTION.

La norme prescrit aux lecteurs de documents PDF qui veulent se déclarer conformes d'ouvrir effectivement les applications, mais sans préciser les modalités de cette ouverture (section 2.2).

Cette richesse fonctionnelle est à double tranchant.

Le CERTA est informé qu'avant d'exécuter effectivement une telle application :

• le lecteur Adobe Reader affiche une fenêtre d'avertissement, mais le texte de cette fenêtre est partiellement modifiable ;
• le lecteur FoxIt affiche un avertissement uniquement si le correctif datant du 02 avril 2010 est appliqué, mais le texte est aussi partiellement modifiable ;
• d'autres lecteurs, comme evince, n'exécutent pas les applications.

Cette fonctionnalité peut être exploitée de manière malveillante, en particulier en modifiant le texte d'avertissement affiché à l'utilisateur. De plus, un fichier exécutable embarqué dans le document PDF peut être lancé par certains lecteurs. Dans cette hypothèse, l'attaquant peut élargir sa capacité de nuisance. Il n'est pas limité aux programmes déjà présents sur le système.

Il est important de noter que l'inactivation des scripts dans les documents PDF, résolution sage en soi, ne protège pas contre le détournement du lancement d'exécutable à partir de fichiers PDF.

1.2 Limitations sous AdobeReader

Le lecteur AdobeReader donne une possibilité de restreindre le lancement d'applications. La solution pour un utilisateur isolé est de passer par l'interface du lecteur et de suivre l'enchaînement à partir du menu :
Edition -> Préférences -> Gestionnaire des approbations. La case Autoriser l'ouverture des pièces jointes non PDF dans des applications externes ne doit pas être cochée.

Pour un parc d'ordinateurs, le positionnement systématique (script, GPO) à 0 (zéro) de la variable bAllowOpenFile de la clef de registre suivante (pour la version 9.0 d'Adobe Reader) est plus opérationnel :

HKCU\Software\Adobe\Adobe Reader\9.0\Originals

Il est évident que ces mesures peuvent avoir des effets secondaires lorsque des documents PDF sont utilisés pour exécuter des applications tiers.

1.3 Recommandations

Afin de limiter les risques d'exploitation de ces vulnérabilités, le CERTA recommande :

• de lire attentivement les fenêtres d'avertissement lors de la lecture d'un fichier PDF et, au moindre doute, de refuser le lancement de toute action ;
• d'appliquer les correctifs sur les lecteurs de fichiers au format PDF, comme sur tous les autres logiciels. En particulier, il faut appliquer le correctif pour FoxIt mentionné dans l'avis CERTA-2010-AVI-155. Quant à Adobe Reader, l'éditeur prévoit une importante mise-à-jour le 13 avril 2010 ;
• de durcir la configuration de ces lecteurs ;
• de rester informé de l'évolution de ces logiciels ;
• sous réserve de contraintes opérationnelles, d'utiliser un lecteur qui ne lancent pas les exécutables à partir des documents PDF.
• de surveiller les journaux et les trafics, entrants et sortants, pour détecter de possibles anomalies.

Pour limiter l'impact du détournement de cette fonctionnalité, il est également important de réduire au maximum les droits accordés à l'utilisateur.

1.4 Documentation

• Avis du CERTA Vulnérabilité dans Foxit Reader du 02 avril 2010 :

  http://www.certa.ssi.gouv.fr/site/CERTA-2010-AVI-155/index.html
  

• Référence CVE CVE-2009-0836 :

  https://www.cve.org/CVERecord?id=CVE-2009-0836
  

• Référence CVE CVE-2009-4764 :

  https://www.cve.org/CVERecord?id=CVE-2009-4764
  

• Référence CVE CVE-2010-1239 :

  https://www.cve.org/CVERecord?id=CVE-2010-1239
  

• Référence CVE CVE-2010-1240 :

  https://www.cve.org/CVERecord?id=CVE-2010-1240
  

2 Fonctionnalités NTP...

Cette semaine, des chercheurs ont publié leurs travaux sur certaines fonctionnalités méconnues du protocole NTP.

En effet, il est prévue dans la norme un certain nombre de commandes auxiliaires permettant d'obtenir des informations sur le fonctionnement du serveur. Il suffit pour s'en convaincre de consulter la page de manuel de la commande ntpdc correspondant au client NTP livré avec le serveur standard ntpd.

Certains paramètres permettent d'obtenir des informations sur le type de système d'exploitation : readvar, les appariements avec d'autres serveurs NTP : peers ou listpeers, etc.

Mais il a été montré qu'il était possible également, par une utilisation particulière, d'obtenir la liste complète des clients utilisant actuellement un serveur NTP ciblé.

Ainsi si le serveur ne limite pas l'utilisation de ce type de fonctionnalités à certains clients privilégiés, n'importe qui aura accès à ces informations.

Recommandations :

Par défaut, un serveur NTP standard accessible depuis l'Internet mettra à disposition la majorité de ces directives. Il est donc recommandé de limiter l'accès à ces commandes autant que faire se peut. Pour cela plusieurs pistes sont envisageables et complémentaires :

• si cela n'est pas nécessaire, ne pas rendre public sur l'Internet le serveur NTP ou encadrer son utilisation avec une politique de filtrage réseau stricte ;
• restreindre, au niveau du fichier de configuration du serveur, l'accès à certains sous-réseaux uniquement ;
• modifier les options de compilation (ou les sources) du serveur NTP pour que ces directives ne soient pas disponibles dans le binaire ntpd final si cela est possible.

3 skipfish - scanner Web

Le scanner de vulnérabilités Web skipfish est disponible depuis quelques temps sur Google code. Il permet de cartographier un site depuis une page initiale (web crawling) à partir de laquelle il suivra tout les liens trouvés en fonction de paramètres prédéfinis. Il peut aussi tester un certain nombre d'attaques (injection SQL, XSS, inclusion de fichier ...) en se basant sur des mots-clefs. Il est fourni avec des dictionnaires de mots-clefs différents en fonction du panel des tests souhaités.

Les résultats sont présentés en HTML sous forme d'arborescences développables à la demande. Ils sont classés, entre autres, par type de fichiers trouvés (ex: png, jpg, gif ... ) et par vulnérabilités plus ou moins critiques. Comme toujours l'utilisation de cet outil présente peu d'intérêt sans une expertise suffisante permettant de comprendre les résultats retournés.

Cet outil est reconnaissable dans les journaux, dans sa configuration par défaut, à son User-Agent Mozilla/5.0 SF/1.26b (1.26 étant la version) et à ses très nombreuses requêtes. Un test mené sur un serveur dédié de taille modéré (3 CMS, 1 forum, 1 phpmyadmin, le tout sans données ) avec le dictionnaire de mots-clefs minimal.wl a engendré plusieurs gigaoctets de journaux d'accès et d'erreurs. Bien que déclaré comme sans risque, son utilisation sur un serveur en production est à éviter compte tenu des possibilités de déni de service.

3.1 Attention

Le CERTA profite de cet article pour rappeler que la détention et l'utilisation de ce type d'outils est encadré par la loi du 5 janvier 1988 relative aux atteintes aux systèmes de traitement automatisé de données (STAD) modifiée par la loi du 21 juin 2004 pour la confiance dans l'économie numérique. Les articles 323-1 à 323-3 du code pénal précisent les peines encourues pour l'accès et le maintien frauduleux dans un STAD, pour l'entrave à son fonctionnement et la modification ou la suppression de données. Donc, l'utilisation de cet outil de façon non maitrisée et sans motif légitime est à proscrire, au risque de se retrouver confronter à des problèmes avec la justice.

3.2 Documentation

• Projet skipfish :

  http://code.google.com/p/skipfish/
  

• Les articles de loi se trouvent dans le code pénal, livre 3 Des crimes et des délits contre les biens, titre 2 Des autres atteintes aux biens, chapitre 3 Des atteintes aux systèmes de traitement automatisé de données :

  http://www.legifrance.gouv.fr/affichCode.do?cidTexte=LEGITEXT0000060070719
  

4 Durcissement de la configuration des systèmes Windows (7/8) : activation des stratégies de restrictions logicielles

Il est possible, à partir de Windows XP, de restreindre l'exécution des programmes selon divers critères, grâce aux stratégies de restrictions logicielles (Software Restriction Policies). Une telle politique peut être mise en œuvre dans le but de :

• limiter le risque d'importation involontaire de virus, en particulier par clé USB ou lors d'un téléchargement depuis un site Web ;
• garder une certaine maîtrise des postes de travail en n'autorisant que les programmes professionnels et qualifiés par l'équipe informatique ;
• réduire le risque de compromission d'un poste à l'insu de l'utilisateur, par exemple suite à l'exploitation d'une vulnérabilité logicielle dans le navigateur Internet.

Les stratégies de restrictions logicielles permettent d'identifier les programmes exécutables suivant plusieurs critères : leur emplacement sur le système de fichiers, la signature numérique du programme ou une empreinte cryptographique. La politique de restriction peut correspondre à une liste blanche de critères autorisés ou à une liste noire de critères interdits. Il est de plus possible d'exempter les administrateurs locaux de ces restrictions, qui pourront ainsi installer et exécuter d'autres logiciels. Enfin, la liste des extensions identifiant les fichiers exécutables concernés est paramétrable.

D'une manière pragmatique, le critère d'emplacement est le plus simple à mettre en œuvre. Il nécessite tout de même de déterminer au préalable les répertoires de confiance contenant des exécutables légitimes du poste : par défaut, la liste contient c:\windows, c:\windows\system32 et c:\program files. Les programmes contenus dans un répertoire autorisé pourront alors être exécutés, ainsi que les programmes présents dans les éventuels sous-répertoires. Il est ensuite nécessaire de déterminer les répertoires dans lesquels les utilisateurs ont les droits d'écriture, par exemple des répertoires temporaires sous c:\windows, afin d'ajouter une règle d'interdiction pour chacun de ces répertoires. Les règles les plus spécifiques étant prédominantes, les exécutables d'un sous-répertoire interdit situé dans un répertoire autorisé ne pourront pas être lancés. Pour déterminer les droits d'accès sur un répertoire et ses sous-répertoires, l'outil Microsoft AccessEnum¹ peut être utilisé.

Les stratégies de restrictions logicielles sont configurables à travers la politique locale de sécurité de la machine et éditables via le composant enfichable secpol.msc (Paramètres de sécurité, Stratégies de restriction logicielle). Elles sont ainsi déployables à large échelle via GPO et plusieurs profils peuvent être définis pour les différents types d'utilisateurs. Si aucune stratégie n'est définie, il faut en créer une grâce au menu « Créer de nouvelles stratégies ». Pour configurer une politique en mode liste blanche de répertoires de confiance, il faut :

• dans la catégorie « Règles supplémentaires », spécifier des règles de chemin d'accès de type « non restreint » (exécution autorisée) pour chaque répertoire contenant des applications ;
• dans la catégorie « Règles supplémentaires », spécifier des règles de chemin d'accès de type « rejeté » (exécution interdite) pour les éventuels sous-répertoires en écriture pour les utilisateurs ;
• modifier les propriétés de « Types de fichiers désignés » pour retirer l'extension « LNK » afin que les raccourcis sur le bureau soient toujours fonctionnels ;
• choisir « Tous les fichiers logiciels », pour que les restrictions s'appliquent également aux fichiers DLL (contenant du code exécutable), et « Tous les utilisateurs exceptés les administrateurs locaux » dans les propriétés de « Contrôle obligatoire » ;
• dans la catégorie « Niveaux de sécurité », définir par défaut le niveau « Rejeté ».

De cette manière, il ne sera plus possible, pour un utilisateur, d'exécuter des programmes se trouvant par exemple sur une clé USB ou dans son profil (bureau, répertoire de documents personnels, répertoire temporaire, etc.). Bien que les stratégies de restriction logicielle réduisent l'exécution de programmes non désirés, ce mécanisme ne protège pas contre l'exécution de code arbitraire via l'exploitation d'une vulnérabilité dans un logiciel. Cependant, les éventuels programmes téléchargés par ce biais ne pourront pas être exécutés au prochain démarrage. Enfin, certains environnements d'exécution de scripts peuvent encore être utilisés (macro VBS, script .Net, etc.).

5 Bonnes pratiques d'administration sous Windows : L'ouverture de session

Cet article est le premier d'une série qui va nous permettre de rappeler quelques bonnes pratiques d'administration sous Windows. En effet une grande partie de la sécurité d'un système d'information repose sur son administration. Aujourd'hui nous allons nous pencher sur l'ouverture de session (ou login interactif) et ses travers...

5.1 L'ouverture de session ou pourquoi s'en passer

Avec la généralisation des techniques type Terminal Server / Remote Desktop, le réflexe veut souvent que l'on ouvre une session à distance sur une machine pour l'administrer.

Cette méthode est certes très pratique mais aussi excessivement dangereuse...

En effet lors d'une ouverture de session de multiples mécanismes sont mis en œuvre, par exemple de nombreux programmes vont être lancés automatiquement via :

• les clés Run dans la base de registre :

   HKEY\_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  

• les programmes du menu « Démarrer » :

   C:\Documents and Settings\USERXXX\Menu D�marrer\Programmes\D�marrage
  

• les extensions du « Shell » ;
• les taches planifiées ;
• etc...

Or, ces entrées sont évidemment très utilisées par les logiciels malveillants pour s'exécuter automatiquement, et ce, avec les droits de l'utilisateur connecté.

Outre ces entrées, certains logiciels malveillants qui s'exécutent typiquement dans un service, peuvent récupérer le jeton de sécurité de l'utilisateur connecté à la session interactive (ou à une session Terminal Server). Ce jeton peut alors servir à se faire passer pour l'utilisateur connecté, et permettre ainsi d'exécuter du code avec tous les droits de cet utilisateur.

On imagine alors facilement les dégâts que cela peut provoquer si un utilisateur de type « Administrateur du domaine » ouvre une session interactive sur une machine infectée...

L'exemple type est le ver Conficker : de très nombreux parcs de machines ont été infectés parce qu'un administrateur du domaine ouvrait une session sur une machine infectée, donnant ainsi les droits administrateur du domaine au code malveillant, qui en profitait pour se répliquer sur toutes les machines du domaine via les partages administratifs (C$, IPC$), sans même avoir besoin d'utiliser la moindre faille...

5.2 L'ouverture de session : les alternatives

Heureusement, il y a d'autres moyens d'administrer une machine à distance sans avoir besoin d'ouvrir une session interactive en tant qu'administrateur.

5.2.1 Les MMC, regedit, etc...

Windows possède de nombreux outils d'administration accessible via les MMC (Microsoft Management Console).

L'une des plus utiles est la MMC « Gestion de l'ordinateur» (lancer compmgmt.msc). Celle-ci permet, entre autres, de gérer :

• les journaux d'événements de la machine ;
• les dossiers partagés ;
• les utilisateurs et groupes locaux ;
• les périphériques ;
• les disques ;
• les services.

Et comme pour beaucoup de MMC, ceci est valable pour la machine locale mais aussi pour une machine distante (click droit sur « Gestion de l'ordinateur (local) » et « Se connecter à un autre ordinateur ...»).

Vous pouvez aussi accéder aux fichiers distants via les partages administratifs :

\\NomDeLaMachine\c$

L'outil Regedit permet, quant à lui, d'éditer la base de registre de machines distantes (menu « Fichier », « Connexion au registre réseau... »).

5.2.2 RunAs ou « Exécuter en tant que »

Les outils précédemment cités permettent déjà de couvrir un large besoin en termes d'administration d'une machine. Il peut cependant rester des cas (rares) où l'ouverture d'une session interactive est obligatoire. Dans ce cas il faudra s'attacher à ouvrir une session en tant qu'utilisateur sans pouvoir puis démarrer une fenêtre de commandes via l'utilitaire RunAs.

L'ouverture d'une session interactive avec un compte administrateur local est aussi possible, mais dans ce cas il faut vérifier que le couple « Administrateur local » / « Mot de Passe » utilisé est unique sur chaque machine.

Nous reviendrons d'ailleurs en détail sur ce point la semaine prochaine.