S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 20 juin 2014
N° CERTFR-2014-ACT-025
Affaire suivie par: CERT-FR
le 20 juin 2014

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTFR-2014-ACT-025

Gestion du document

Référence CERTFR-2014-ACT-025
Titre Bulletin d’actualité CERTFR-2014-ACT-025
Date de la première version 20 juin 2014
Date de la dernière version 20 juin 2014
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 – Journalisation des flux réseau (seconde partie)

Conservation des journaux

Le premier article de cette série, publié dans le bulletin d’actualité du 13 Juin 2014, a présenté les informations issues des flux réseaux qu’il est nécessaire d’avoir journalisées afin de traiter un incident. Ce deuxième article décrit les bonnes pratiques facilitant l’analyse des journaux lors du traitement d’un incident ainsi que leur exploitation au quotidien.

Accessibilité

Lors de ses interventions, le CERT-FR constate régulièrement la difficulté que peut présenter l’accès aux journaux réseau : dispersion des journaux, emplacements de stockage inconnus, outils spécifiques d’extraction, etc. Dans certains cas, il est même nécessaire de mettre en place une architecture spécifique exigeant plusieurs semaines de mise en œuvre. Il en résulte une réelle difficulté pour l’analyste ou l’administrateur d’accéder rapidement aux informations nécessaire au traitement d’un incident.

Durée de conservation

Certains attaquants peuvent maintenir leur accès au système cible pendant plusieurs mois : le CERT-FR constate malheureusement qu’un grand nombre d’attaques est détecté très tardivement. Il est donc recommandé d’archiver les journaux sur la plus grande durée possible tout en respectant les contraintes juridiques éventuelles (rétention de données personnelles, législation spécifique, etc.). L’archivage est généralement réalisé sur des supports amovibles de grande capacité conservés hors-ligne. La centralisation des journaux évoquée précédemment facilite cette opération.

Assurer le suivi

Des équipements peuvent être mis à jour, reconfigurés, remplacés, changés, etc. Il en résulte une hétérogénéité dans les formats de journaux générés et parfois une disparité dans leurs emplacements de stockage. Il est donc nécessaire de conserver un historique du format et de l’emplacement de stockage des journaux. Par exemple, il est indispensable de :
  • connaitre la norme d’horodatage de chaque événement afin d’assurer une cohérence dans la chronologie d’un incident ;
  • distinguer les champs de taille de requêtes entrantes et sortantes lors de la recherche d’exfiltration de données ;
  • s’assurer que les systèmes de journalisation fonctionnent correctement afin de ne pas perdre d’information. Cette vérification peut se faire, par exemple, via l’utilisation d’une solution de supervision.

Exploitation des journaux au quotidien

Au-delà du traitement d’incident, la journalisation est également un premier pas vers la mise en Å“uvre de solutions telles que les SIEM (Security Information and Event Management) qui corrèlent des événements issus de différentes sources afin de lever des alertes de sécurité. A termes, ces données peuvent être exploitées au quotidien par l’équipe d’un SOC (Security Operation Center) ou par un administrateur afin de détecter les incidents de sécurité le plus tôt possible.

L’ANSSI a publié une note technique de recommandation de sécurité pour la mise en œuvre d’un système de journalisation. Ce document décrit les prérequis ainsi que des recommandations d’architecture et de conception nécessaires à la mise en œuvre d’un tel système.

Documentation

2 – Mécanismes de protection de type « sandbox » sous Windows

Comme présentés dans un article précédent, les mécanismes de protection dits de « sandbox » permettent d’améliorer la sécurité de certains produits en diminuant les droits associés aux processus responsables de l’interprétation de code provenant de sources inconnues. La restriction des droits d’un processus repose sur plusieurs mécanismes mis à disposition des développeurs par le système d’exploitation. Pour les systèmes Windows, il est possible de citer les mécanismes suivants :
  • l’utilisation d’un jeton d’accès utilisateur limité ;
  • l’utilisation d’objets de type « Jobs » ;
  • l’utilisation d’une station et d’un bureau spécifique ;
  • l’utilisation des niveaux d’intégrité (à partir de Windows Vista) ;
  • l’utilisation de l’API SetProcessMitigationPolicy.
Cet article présente tout particulièrement les deux premiers mécanismes énoncés précédemment. Les trois derniers seront détaillés dans un article ultérieur.

Utilisation d’un jeton d’accès utilisateur limité

Sous Windows, le jeton d’accès représente le contexte de sécurité associé à un utilisateur. Il contient notamment un ensemble d’identifiants de sécurité (SID : Security IDentifier) associés à l’utilisateur (SID de l’utilisateur, des groupes auxquels il appartient, etc.) ainsi que les privilèges qui lui sont accordés. Le jeton est créé par le système lorsque l’utilisateur s’authentifie sur ce dernier. Ce jeton est associé à chaque processus exécuté par l’utilisateur et c’est grâce à lui qu’un processus pourra avoir accès aux ressources de l’utilisateur.

La fonction CreateRestrictedToken permet au développeur de créer un jeton d’accès limité (cette fonction ne peut que restreindre les droits). Ce jeton est construit principalement à partir des SIDs présents dans le jeton de l’utilisateur et dont les propriétés ont été modifiées :

  • en ajoutant un SID dans la liste des SidsToDisable (il ne peut y avoir dans cette liste un SID que l’utilisateur ne possède pas) : le jeton va conserver le SID passé en paramètre mais il ne sera évalué que dans le cas de règles refusant l’accès au SID. Ce SID ne sera donc plus évalué pour permettre à l’utilisateur l’accès a un objet, cependant il le sera pour lui refuser l’accès (ACE de type « Deny ») ;
  • en ajoutant un SID dans la liste des SidsToRestrict : lorsque des SID sont présents dans cette liste, une double vérification est faite, d’abord avec la liste des SIDs du jeton puis avec la liste des SIDs restreints. Pour que la vérification réussisse, il faut que les deux passes soient un succès. Ainsi il est possible de réduire les droits d’un jeton en n’incluant pas certains de ses SID dans la liste des SID restreints ;
  • enfin, en supprimant certains privilèges de l’utilisateur.

Utilisation d’objets de type « Jobs »

Les objets de type « Jobs » de Windows permettent de regrouper plusieurs processus et de les gérer comme un seul élément : ainsi, toute modification faite à un Job affecte l’ensemble des processus qui lui sont associés. Par exemple, la fonction TerminateJobObject permet de terminer tous les processus liés à un Job donné.

En plus de cette fonctionnalité de gestion, les Jobs permettent aussi de définir des limitations sur ces processus. Grâce à un appel à la fonction SetInformationJobObject, il est possible de contraindre certains comportements des processus.

Dix grandes catégories de limitations existent. Parmi ces dernières, il est intéressant de noter :

  • JOBOBJECT_BASIC_LIMIT_INFORMATION : permet de définir des limites « basiques » pour les processus du Job telles que la mémoire utilisée, le temps de calcul disponible, la priorité, le nombre maximum de processus, etc ;
  • JOBOBJECT_BASIC_UI_RESTRICTIONS : permet de définir des limites concernant l’interface utilisateur pour les processus du Job telles que la possibilité de créer ou de changer de bureau, la possibilité de changer la résolution de l’écran, la possibilité de lire et/ou écrire dans le presse-papier, la possibilité d’utiliser les atoms globaux (tables de chaînes de caractères partagées entre différentes applications) , etc.
Dans ces deux catégories, certaines limites peuvent particulièrement intéresser les développeurs de sandbox par exemple :
  • JOB_OBJECT_LIMIT_ACTIVE_PROCESS : afin de limiter le nombre de processus actifs au sein du Job ;
  • JOB_OBJECT_UILIMIT_HANDLES : afin d’empêcher les processus du Job d’accéder à des handles ouverts par des processus n’appartenant pas au Job ;
  • JOB_OBJECT_UILIMIT_DESKTOP : afin d’empêcher les processus du Job de créer ou de changer de Bureau ;
  • JOB_OBJECT_UILIMIT_READCLIPBOARD / JOB_OBJECT_UILIMIT_WRITECLIPBOARD : afin d’empêcher les processus du Job de lire ou d’écrire dans le presse-papier ;
  • JOB_OBJECT_UILIMIT_GLOBALATOMS : afin d’empêcher les processus du Job d’utiliser la table d’atom globale ;
  • JOB_OBJECT_UILIMIT_SYSTEMPARAMETERS : afin d’empêcher les processus du Job de changer des paramètres systèmes.

Par exemple, les limites de type JOB_OBJECT_LIMIT_BREAKAWAY_OK et
JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK permettent à un processus faisant partie d’un Job de créer un processus enfant ne dépendant pas de ce même Job. Il est donc nécessaire de s’assurer, lors de la création de Jobs pour un mécanisme de sandbox, que de telles limites ne sont pas définies pour le Job créé.

Documentation

Enfin, il est à noter que certaines fonctionnalités des Jobs permettent à un processus de contourner les restrictions mises en place.

Rappel des avis émis

Dans la période du 09 au 15 juin 2014, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 20 juin 2014
    version initiale.