Contrôle d'intégrité : alerter chaque fois que quelque chose de critique est modifié, créé ou supprimé (programme, paramètre, commande, composant, etc.)

cr  01.01.2012      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Dans quel but se doter d'un outil de contrôle d'intégrité ?

Un contrôle d'intégrité s'exerce avec un contrôleur d'intégrité chargé d'alerter l'utilisateur chaque fois que quelque chose est modifié, créé ou supprimé sur un appareil alors que ce quelque chose est « critique » (un programme, un paramètre de comportement de l'appareil, une commande, un composant du système, etc.) afin de :

• Détecter une intrusion.

• Détecter une faille de sécurité.

• Tracer une installation d'un logiciel ou une session de travail.

• Contrôleurs d'intégrité
  Les contrôleurs d'intégrité sont passifs et vérifient l'intégrité des objets (fichiers).

• IDS - HIDS
  Les IDS (Intrusion Detection System) et HIDS (Host Intrusion Detection Systems)détectent et signalent des comportements suspects et ne contrôlent pas l'intégrité des objets (fichiers).

• IPS - HIPS
  Les IPS (Intrusion prevention system) et HIPS (Host Intrusion prevention system) contrôlent des comportements (de composants ou du réseau), pas l'intégrité des objets (fichiers). Ils sont actifs et réagissent en temps réel pour bloquer un comportement suspect.

Les propriétés de tous les fichiers « sensibles » - on ne surveille pas les fichiers de données utilisateur (documents de traitement de texte, images, sons, etc.) par des outils de contrôle d'intégrité.

Ces propriétés portent sur :

• Le contenu (condensat (ou checksum ou hashcode) de type MD5 ou SHA-1, SHA-256, etc. ...) comme peuvent en produire SummerProperties ou HashTab, etc.

• Le contenant (l'enveloppe). Des informations comme la taille du fichier ou sa date de dernière modification et sa date de dernier accès sont peu significatives mais des paramètres modifiés portant sur les droits (d'exécuter, d'ouvrir, de modifier, de créer, de supprimer etc.) et les propriétaires des fichiers peuvent être significatifs.

Alors que le système est réputé dans un état sain (immédiatement après son installation et application des derniers correctifs à partir d'un support local (cd-rom) sans aller sur l'Internet (synthèse de tous les bulletins de sécurité et service packs Microsoft, avec ISO à télécharger depuis une autre machine, et à graver), vous faites un calcul de chiffres clé pour tous les fichiers système et tous les objets critiques. Vous notez tout cela ainsi que toutes les propriétés dans une base de données (une feuille d'un tableur). C'est un cliché du système à un instant donné.

Par la suite, chaque fois qu'un objet est sollicité (ouverture d'un programme exécutable, d'un composant du système etc.) vous refaites la même chose et comparez les résultats obtenus à ceux notés dans la base de données de référence.

Dans la pratique, ceci est fait automatiquement et en temps réel avec un « contrôleur d'intégrité ».

• S'il y a concordance parfaite, aucune alerte n'est émise et le travail se poursuit normalement.

• S'il y a une divergence, et en fonction du degré de surveillance souhaité (paranoïa totale, moyenne, faible...) il y a production d'un message d'alerte signalant à l'utilisateur qu'un composant est modifié. Le système d'alerte empêche alors le composant de s'ouvrir (de s'exécuter) et attend que l'utilisateur donne son avis.

Un ordinateur simplement bien protégé comporte déjà un pare-feu, un antivirus / anti-malwares (voir nos recommandations de kits de sécurité), ses navigateurs durcis et protégés et les mécanismes publicitaires bloqués(sauf pour les sites de confiance que l'on souhaite soutenir financièrement). Il s'avère, dans la pratique, que cette configuration minimale de sécurité est déjà rare. Un ordinateur qui comporterait, en sus, un contrôleur d'intégrité, est un ordinateur blindé avec un utilisateur qui a tout prévu ! Seulement voilà :

• Installation du contrôleur d'intégrité

  Le contrôleur d'intégrité est installé sur une machine réputée saine. Il calcule alors les condensats (chiffres clé) de tous les objets à surveiller et collecte toutes les propriétés sensibles. Avec cela il construit sa base de signatures initiale et en fait la clé de voûte de son utilisation - c'est son système de référence.

  Toutefois, rien ne permet de dire, avec une certitude absolue, que la machine est réellement saine (n'est pas compromise). Ce n'est qu'une supposition. (On ne parle pas des failles de sécurité, qui sont un problème de nature différente).

  La seule base de signatures fiable devrait être constuite exclusivement à partir des empreintes (condensats - hashcodes) donnés par les éditeurs eux-même, et aucun autre. Un contrôleur d'intégrité qui construit sa propre base de signatures de l'existant, sur une machine, prend le risque de signer un composant réputé sain alors qu'il est compromis et que cette compromission n'a pas été découverte. Lorsque, plus tard, une mise à jour ou un antivirus tentera de restaurer ce composant à un contenu sain, le contrôleur d'intégrité émettra une alerte et demandera, s'il est réglé pour cela, son avis à l'utilisateur, qui aura bien du mal à choisir. Il faudrait que le contrôleur d'intégrité dispose, en amont, des condensats officiels et non pas, uniquement, de ceux qu'il a calculé à un moment où l'utilisateur croit sa machine saine. Or les éditeurs ne donnent pas ces listes de condensats sûrs. Le contrôleur d'intégrité permet donc de mettre en lumière les modifications apportées à un système, par rapport à son propre système de références, qu'il s'est construit à son installation, mais pas d'en assurer la non compromission.

• Utilisation du contrôleur d'intégrité

  1. L'utilisateur face à une alerte

     L'utilisateur est bloqué par une alerte et il ne sait pas pourquoi un composant est modifié or les composants sont très souvent modifiés, même en dehors des périodes de mises à jour (le second mardi de chaque mois pour les produits Microsoft, par exemple). Que faire ? Refuser la modification et rester bloqué ou l'accepter sans savoir pourquoi ou perdre un temps fou à chercher sur l'Internet ou au téléphone de quoi il retourne (information que l'on ne trouvera jamais car elle n'existe pas) ?

     C'est là qu'apparaît, avec les meilleures intentions du monde, le virus PEBCAK. L'observation du comportement des utilisateurs montre que la modification est généralement acceptée sans aucune vérification, au petit bonheur la chance, les mains jointes, en prière, en espérant que l'on ne fait pas une bêtise et que la modification est "normale".

     On ne gère pas un système de traitement de l'information les yeux fermés et en vivant dans l'espoir que "ça marche" ! Il y a un soucis là, avec l'usage de tous les contrôleurs d'intégrité ! Le traitement d'une alerte de type " Il y a une modification du contenant ou du contenu de tel composant - qu'est-ce que dois faire ? " est tout simplement transféré à l'utilisateur. Je met au défi l'utilisateur, même très avancé, de savoir pourquoi et par qui un composant est modifié !

  2. Les composants exceptionnels

     Il y a, dans les contrôleurs d'intégrité, des listes d'exceptions : ne pas contrôler tel et tel composants ! Par exemple, les contrôleurs d'intégrité ne peuvent pas et ne doivent pas contrôler l'intégrité du processus actif (monté en mémoire) du tableur Excel, de Microsoft. Qui est capable de dire pourquoi on ne peut contrôler l'injection de code dans Excel ?! (Nota : le comportement normal d'Excel (mais curieux, voire suspect, en matière de programmation informatique) fait qu'il modifie son code une fois monté en mémoire !). A partir du moment où des composants sont exclus "institutionnellement" des contrôles d'intégrité, c'est la porte ouverte à des choses comme la NSA Trapdoor et les révélations feuilletonnées de Snowden (Prism et Cie).

     Combien de logiciels sont équipés de système d'autodéfense ? Pour un OutPost Pro qui se protège avec son mécanisme "Légitime Défense", combien se laissent faire. Pourquoi l'explorateur de Windows tente de modifier OutPost Pro une fois celui-ci lancé ?

     Et pourquoi les contrôleurs d'intégrité ne s'intéressent pas aux injections en mémoire.

  3. Le retour en arrière - Le RollBack

     Il s'agit du droit de repentir. Je me suis trompé : j'ai accepté une modification après une alerte et je n'aurais pas dû - je veux restaurer ma machine à son état précédent en ce qui concerne telle alerte (dont restaurer la version précédente du composant modifié ou supprimé etc.).

     Un contrôleur d'intégrité bien écrit fera un point de restauration avant d'autoriser l'application d'une modification, et permetra d'y revenir.

L'échec très médiatisé de Viguard, un contrôleur d'intégrité, est en grande partie dû au virus PELCEC (outre l'incompréhension par la société Tegam (diffuseur de Viguard) du fonctionnement de leur outil, leur communication tapageuse (Viguard est présenté, de manière réductrice, comme un antivirus sans mises à jour et sans base de signatures) et leur procès intenté à un chercheur, Guillermito, ayant trouvé des failles dans Viguard).

Ce genre de décision ne relève, normalement, que d'un administrateur système. Comment s'en sortir lorsque l'on est un simple particulier utilisant son ordinateur sans en avoir le mode d'emploi mais tout en souhaitant échapper à la face obscure de l'Internet. Il n'y a pas de solution simple et "presse bouton". Pour s'assurer qu'un composant Microsoft (et de quelques autres marques) est fiable (il a un bon chiffre clé signé par l'éditeur) on peut consulter le serveur de signatures des éditeurs avec RunScanner mais ce n'est déjà pas un produit simple.

La solution réside donc dans un paramétrage fin du contrôleur d'intégrité pour qu'il ne produise pas trop d'alertes, c'est-à-dire en baissant son niveau de vigilance et en excluant un certain nombre d'objets de la surveillance ce qui nécessite un travail de paramétrage initial pointilleux (entendez, par là, un travail long et fastidieux).

Il s'agit des mises à jour comme "Microsoft Update". Ces modifications doivent être faites avec la plus grande précaution, si possible en ayant téléchargé et gravé les correctifs depuis les sites des éditeurs eux-mêmes (sans jamais passer par un site de téléchargement tiers) puis en appliquant ces correctifs HORS LIGNE. Microsoft Update, par exemple, oblige à se connecter au site de Microsoft avec Internet Explorer (ce qui est une première faille de sécurité) et avec la technologie ActiveX activée (ce qui est une seconde faille de sécurité).

Ensuite, les alertes risquent de ne pas être émissent immédiatement mais diluées dans le temps (le fonctionnement en temps réel des contrôleurs d'intégrité fait que l'objet est contrôlé au moment où il est sollicité - s'il est modifié maintenant mais sollicité dans plusieurs mois, l'utilisateur sera, au bas mot, perplexe. Il faut donc, après une mise à jour touchant plusieurs composants, pouvoir faire un recalcul des contrôles d'intégrité sur la totalité des objets, analyser le journal (le rapport) produit par le contrôleur d'intégrité et mettre à jour la base de données en une seule fois.

Les contrôleurs d'intégrité qui analysent les journaux des systèmes (les traces dans les logs) peuvent être aveuglés par un attaquant qui efface ou camoufle ses traces.

Un attaquant peut tenter de modifier la base de signatures du contrôleur d'intégrité. Le contrôleur d'intégrité doit être assez fort pour protéger ses objets.

Un attaquant peut tenter de modifier l'exécutable même du contrôleur d'intégrité qui doit être assez fort pour s'auto-protéger.

Liste des contrôleurs d'intégrité

Avant de se lancer dans l'installation, même gratuite, d'un véritable contrôleur d'intégrité, il existe dans les pare-feu majeurs un contrôleur d'intégrité.

Recommandé :

• le contrôleur d'intégrité en temps réel du pare-feu OutPost Pro

• la surveillance d'installation, désinstallation et le "surfback" / "RollBack" avec Total Uninstall

• le contrôle de signatures numériques avec RunScanner

Remarque :

Les "grands" contrôleurs d'intégrité, comme Tripwire, sont souvent sous Linux mais pas sous Windows, analysent les journaux et fonctionnent en batch (en temps différé), produisent des alertes à postériori (c'est trop tard !) mais pas en temps réel et omettent également le contrôle d'injection dans un processus déjà monté en mémoire. Ils n'accèdent pas aux serveurs de signatures des éditeurs ce qui serait la base même, l'essence, le fondamental de leur travail ! Un hooker (partie des rootkit) qui se serait installé aveugle totalement les contrôleurs d'intégrité.

Contrôleurs d'intégrité :

Le principe même des contrôles d'intégrité par des logiciels, qui ont été mis à toutes les sauces, côté client, est abandonné : il est impossible à un utilisateur, même très avancé, de faire des arbitrages entre les flots d'alertes qui le noie et auxquelles, de toutes manières, il n'a aucune réponse éclairée et n'en trouvera jamais, sauf à chercher plusieurs jours par alerte, sachant qu'il peut en recevoir plusieurs par jour (ou à abaisser le niveau d'alerte du contrôleur). Même le TeaTimer de l'ancienne branche de SpyBot Search and Destroy, délibérément orienté grand public, alertait des modifications apportées au registre Windows et laissait l'utilisateur en plan, face à un choix cornellien : accepter ou refuser la modification, sans rien savoir de ses tenants et aboutissants.

DiamondCS RegistryProt : Abandonné
System Safety Monitor : Abandonné depuis 2008