Suite à notre récent article sur les pilotes du noyau de Sophos Intercept X, dans lequel nous expliquions comment ils étaient testés et ce qu’ils faisaient exactement, nous apportons davantage de transparence sur le fonctionnement interne d’Intercept X, cette fois-ci en examinant les mises à jour de contenu qui sont soit des modifications de configuration entraînant des changements au niveau des chemins d’exécution du code, soit du code à proprement parler.
Intercept X utilise une combinaison de recherches (lookups) dans le Cloud en temps réel et de mises à jour de contenu sur l’appareil. Étant donné que le paysage des menaces évolue et change constamment, il est essentiel que les mises à jour de contenu sur les appareils soient fournies fréquemment (certaines données sur les appareils changent moins fréquemment, mais peuvent nécessiter des mises à jour dans des délais courts). Néanmoins, cette méthode comporte des risques : en effet, si les mises à jour de contenu sont corrompues ou invalides, alors une telle situation pourrait entraîner des perturbations.
Sophos utilise un mécanisme classique pour diffuser les mises à jour de contenu sur l’appareil, qui sont chargées dans des processus au niveau de l’espace utilisateur Sophos à faible privilège (plutôt que d’être chargées ou interprétées par les pilotes du noyau Sophos) à partir du CDN (Content Distribution Network) de Sophos. Les mises à jour de contenu constituent l’un des trois composants principaux d’Intercept X, avec les logiciels du CDN, la politique et la configuration de Sophos Central.
Dans cet article, nous explorerons les différents types de mise à jour de contenu que nous utilisons, comment nous les vérifions et les validons, et nous détaillerons aussi l’architecture de l’écosystème qui permet d’éviter les problèmes causés par un contenu corrompu ou défectueux (comme nous l’avons noté dans notre article précédent, Intercept X [et tous ses composants] fait également partie d’un programme externe bug bounty depuis le 14 décembre 2017).
Il convient de noter que les détails contenus dans cet article sont corrects au moment de l’écriture de ces lignes (août 2024), mais pourraient changer à mesure que nous continuons à mettre à jour et à développer des solutions.
Déploiement des mises à jour de contenu étape par étape
Sophos propose de nouvelles mises à jour de contenu aux clients via des “groupes de version”. Chaque entité (tenant) Sophos Central est affecté à un groupe de version.
Le premier groupe de version est destiné aux tests d’ingénierie internes ; nous ne lui affectons aucun client en termes de production. Cette approche permet à nos équipes d’ingénierie de tester de nouvelles mises à jour de contenu au niveau de l’infrastructure de production, sans aucune étape manuelle. Si les tests échouent, nous abandonnons la version sans passer à d’autres groupes de version.
Si la qualification au matière d’ingénierie réussit, alors nous diffusons manuellement la version au niveau du groupe de version “Sophos internal” (“dogfooding“). Cette approche inclut les appareils de production des employés de Sophos, ainsi que les comptes personnels des employés. Encore une fois, si des problèmes sont détectés ou signalés, nous abandonnons la version et ne poursuivons pas plus loin.
Si tout va bien, nous diffusons ensuite manuellement la version auprès des groupes de version publique. À partir de ce moment-là, les systèmes de version Sophos publient automatiquement la nouvelle mise à jour de contenu au niveau de tous les groupes de version sur une période de plusieurs heures ou jours par défaut (voir Figure 1 ci-dessous).
Figure 1 : Phases de diffusion, avec des vérifications à chaque phase
Téléchargement des données : Sophos AutoUpdate
Sophos AutoUpdate, qui fait partie d’Intercept X, vérifie les nouvelles mises à jour de contenu toutes les heures, bien qu’en pratique les mises à jour soient moins fréquentes (voir tableau ci-dessous).
Sophos AutoUpdate télécharge chaque mise à jour de contenu à partir du CDN et vérifie si de nouveaux packages de mise à jour de contenu sont disponibles pour le groupe de version approprié.
Les mises à jour de contenu sont horodatées et signées à l’aide de la fonction de hachage SHA-384 et d’une chaîne de certificat Sophos privée. Sophos AutoUpdate vérifie les mises à jour téléchargées. S’il détecte des mises à jour corrompues ou non fiables, il les supprime et avertit Sophos ainsi que l’administrateur de Sophos Central. De plus, pour vous protéger contre les caches CDN obsolètes ou les attaques par relecture (replay) malveillantes, Sophos AutoUpdate rejette toute mise à jour, pourtant valide, si l’horodatage de la signature est plus ancien que la mise à jour déjà téléchargée.
Si un nouveau package de mise à jour de contenu est disponible, Sophos AutoUpdate le télécharge et l’installe à l’aide du programme d’installation du package approprié. Différentes mises à jour sont gérées par différents composants d’Intercept X.
Aperçu des mises à jour de contenu
Les mises à jour de contenu suivantes font partie de la dernière version d’Intercept X (2042.2).
Tableau 1 : Un aperçu des mises à jour de contenu qui font partie de la dernière version d’Intercept X (2024.2).
Figure 2 : Un diagramme illustrant les processus Sophos (indiqués en bleu marine) qui chargent des mises à jour de contenu spécifiques (indiquées en violet).
DatasetA
DatasetA est chargé par SophosFileScanner.exe, un processus à faible privilège, sans accès au système de fichiers (à part son dossier de log et un répertoire temporaire utilisé pour analyser les objets volumineux). Il charge l’interface SAVI (Sophos Anti-Virus Interface).
SophosFileScanner.exe analyse le contenu suite aux demandes d’analyse provenant d’autres processus Sophos. Bien qu’il s’appelle “SophosFileScanner.exe“, le nom est quelque peu historique : en effet, il s’agit du principal scanner de contenu d’Intercept X, analysant les fichiers, la mémoire des processus, le trafic réseau, etc.
LocalRepData
LocalRepData contient deux listes de réputation :
- Réputation par la fonction de hachage SHA-256.
- Réputation par signataire.
Lorsqu’un exécutable Windows lance son exécution, Intercept X le recherche dans LocalRepData par son hachage SHA-256 et sa signature (en supposant que ce dernier soit valablement signé). Si la réputation est fournie par LocalRepData, Intercept X “identifie (tag)” le processus avec la réputation appropriée (les règles Sophos traitent différemment les fichiers et les processus de haute réputation, par exemple, en les exemptant de nettoyage).
SSPService.exe utilise LocalRepData pour attribuer une réputation lors du lancement des processus.
SophosFileScanner.exe charge également LocalRepData, afin de pouvoir attribuer une réputation aux flux exécutables intégrés qu’il découvre dans le contenu et qui ne concernent pas les fichiers exécutés.
Comportements
Les règles de comportement sont chargées par SSPService.exe. Les fichiers de règle contiennent du code Lua signé et chiffré. SSPService.exe vérifie, déchiffre et charge les règles dans un interpréteur LuaJIT sandboxé avec un accès uniquement aux API internes de Sophos.
Lua est un langage de script rapide et intégré. Sophos utilise Lua pour les règles de comportement car il offre un moyen flexible de fournir de nouvelles détections de comportement sans avoir besoin d’une nouvelle version logicielle, tout en préservant la sécurité. Les règles sont chargées dans l’espace utilisateur et ne peuvent donc pas provoquer une panne critique du système si elles se comportent de manière malveillante. De plus, Sophos construit son moteur de règles sans les bibliothèques de base Lua : le seul accès au système se fait via l’API interne de Sophos, qui est renforcée contre toute utilisation abusive accidentelle des règles de comportement. Sophos collecte des données télémétriques approfondies sur les temps d’exécution (runtime) des règles, et ajuste/réduit en permanence la surcharge d’exécution.
Les règles sont de véritables moteurs : Intercept X fournit divers événements et des gestionnaires d’enregistrement de règle pour ces événements. Les règles peuvent également configurer divers paramètres d’agrégation pour certains événements à volume élevé, permettant aux capteurs de fusionner ou d’ignorer certains événements.
Indicateurs
Les indicateurs sont le moyen par lequel Sophos active progressivement de nouvelles fonctionnalités dans Intercept X. Ces derniers sont fournis de deux manières différentes :
- Les Alertes Complémentaires (Flags Supplement) contiennent un ensemble de base composé d’indicateurs correspondant aux fonctionnalités disponibles dans le logiciel.
- Le Service des Alertes (Flags Service) est un microservice de Sophos Central qui permet aux ingénieurs en charge des versions de Sophos de configurer des indicateurs au niveau de plusieurs entités (tenants).
Les alertes complémentaires (Flags Supplement) pour une version logicielle donnée contient un ensemble d’indicateurs de fonctionnalité et indique comment cette dernière doit être activée :
| Valeur de l’alerte complémentaire (Flag Supplement Value) | Valeur du service d’alerte (Flag Service Value) | La fonctionnalité est… |
| Désactivée | Ignorée | Désactivée |
| Disponible | Désactivée | Désactivée |
| Disponible | Activée | Activée |
Ce mécanisme offre à Sophos plusieurs possibilités pour activer et désactiver des fonctionnalités :
- Sophos peut introduire de nouvelles fonctionnalités avec l’alerte (flag) “Disponible” (mais non activées dans le Service des Alertes [Flags Service]).
- Sophos peut progressivement activer de nouvelles fonctionnalités à l’aide du Service des Alertes (Flags Service) pour activer les indicateurs entre les entités (tenants).
- Sophos peut désactiver une fonctionnalité problématique en modifiant l’indicateur dans le Service des Alertes (Flags Service).
- Sophos peut désactiver une fonctionnalité problématique dans une version logicielle spécifique en modifiant les alertes complémentaires (Flags Supplement) de la version.
CRT
Le CRT (Competitor Removal Tool) contient un ensemble de règles permettant de supprimer les logiciels incompatibles connus lors de l’installation. Il est automatiquement téléchargé par le programme d’installation et supprimé après l’installation.
Normalement, le CRT n’est pas utilisé par Intercept X ; cependant, si un client installe un composant de type “non-protection” tel que Sophos Device Encryption, et choisit ultérieurement de déployer Intercept X, l’agent existant télécharge et installe le CRT et l’exécute avant l’installation. Une fois Intercept X installé, le CRT est automatiquement supprimé.
Outil ESH (Endpoint Self Help)
Les règles ESH (Endpoint Self Help) sont un ensemble d’expressions régulières pour certains fichiers de log. Si les ingénieurs Sophos ont identifié une cause fondamentale commune ou une mauvaise configuration, ils peuvent publier une nouvelle règle et créer un lien vers l’article KBA (Knowledge Base Article) décrivant le problème et/ou la/les solution(s) suggérée(s).
ScheduledQueryPack
La mise à jour planifiée du contenu du pack de requêtes contient une liste des requêtes planifiées et leur fréquence d’exécution. Les règles sont chargées par SophosOsquery.exe ; la sortie est fournie par McsClient.exe pour une ingestion par le Data Lake de Sophos Central.
SophosOsquery.exe dispose d’un système de surveillance intégré qui empêche les requêtes de type “runaway” de consommer trop de CPU ou de mémoire. Sophos collecte des données télémétriques sur les performances des requêtes planifiées et optimise/ajuste régulièrement les requêtes planifiées pour éviter de déclencher le watchdog.
RemapperRules
Les règles en matière de remapping sont chargées par McsAgent.exe et utilisées pour “remapper” les paramètres de politique dans Sophos Central au niveau de la configuration Endpoint, stockés dans le registre Windows sous HKLM\SOFTWARE\Sophos\Management\Policy.
La politique est fournie par Central sous la forme d’un ensemble de documents XML. Les règles sont également un ensemble de documents XML qui décrivent la structure des données stockées dans le registre et fournissent des requêtes XPath et certaines fonctions de conversion pour extraire le contenu des politiques XML et générer des données de registre.
Si un fichier de règle est corrompu ou si son traitement échoue pour une autre raison, aucune des valeurs de registre définies par ce fichier n’est mise à jour et tous les paramètres précédents resteront intacts. Le traitement d’autres fichiers de règle valides ne sera pas non plus affecté.
EPIPS_data
La mise à jour de contenu EPIPS_data contient les signatures de l’IPS (Intrusion Prevention System) chargées par SophosIPS.exe. SophosIPS.exe contient un produit IPS développé par Sophos ; les signatures sont de type IPS, publiées par les SophosLabs.
SophosIPS.exe s’exécute comme un processus à faible privilège. Lorsque l’IPS est activé, le pilote sntp.sys envoie des paquets à SophosIPS.exe pour le filtrage ; SophosIPS.exe répond alors au pilote avec des commandes pour accepter ou rejeter les paquets.
Interagir avec les flux réseau ‘paquet-par-paquet’ au plus profond de la pile réseau (network stack) implique une extrême prudence. Les appels WFP (Windows Filtering Platform) au niveau L2 sont très sensibles aux pilotes sous-jacents, souvent provenant de tiers, qui interagissent avec les couches d’accès physique et média. En raison du risque élevé pour la stabilité du système, la fonctionnalité IPS se surveille elle-même pour détecter les BSOD ou les perturbations du réseau susceptibles d’être causées par des interactions de pilotes tiers. En cas de détection, la fonctionnalité IPS se désactive automatiquement et met l’état de sécurité du système endpoint sur rouge pour alerter sur l’incompatibilité.
NTP_OVERRIDES
L’un des problèmes potentiels lors de la création d’un pilote de noyau (kernel) WFP (Windows Filtering Platform) est que, bien que la plateforme soit conçue pour que plusieurs pilotes interagissent simultanément avec la pile de filtrage (filtering stack), Sophos a identifié certains packages logiciels tiers qui ne sont pas compatibles avec la fonctionnalité IPS, et qui nécessite alors de pouvoir intercepter et manipuler les paquets L2.
La mise à jour de contenu NTP_OVERRIDES contient une liste de pilotes incompatibles connus. Si l’IPS est activé au niveau de la politique mais déployé sur un appareil avec un pilote incompatible, SophosNtpService.exe désactive l’IPS, remplaçant ainsi la politique en question.
Cette capacité est fournie sous forme de mise à jour de contenu, ainsi, à mesure que de nouveaux pilotes incompatibles sont découverts, Sophos pourra réagir de manière dynamique pour protéger les autres clients ayant la même configuration. De plus, si Sophos ou des tiers mettent à jour les pilotes pour traiter cette incompatibilité, Sophos pourra supprimer le pilote à partir d’une certaine version.
RepairKit
Lors de chaque mise à jour, effectuée toutes les heures, Sophos AutoUpdate exécutera un programme d’auto-réparation (su-repair.exe) pour détecter et corriger tout problème connu et réparable. Le RepairKit a été initialement conçu pour détecter et réparer l’altération de fichier causée par des interruptions suspectes qui pourraient corrompre l’installation de Sophos. Au fil du temps, l’équipe engineering de Sophos a utilisé cette fonctionnalité pour corriger de nombreux problèmes qui, historiquement, auraient nécessité une implication en termes de support Sophos auprès du client, ou qui seraient potentiellement passés inaperçus jusqu’à ce qu’une future mise à jour logicielle ne signale le problème en question.
Les règles RepairKit sont écrites en langage Lua et chargées par su-repair.exe. Les règles sont chiffrées et signées. Si su-repair.exe ne parvient pas à charger les règles RepairKit, il charge un ensemble de règles de “dernier recours (last resort)” intégré qui se concentre uniquement sur la réparation de Sophos AutoUpdate lui-même.
Les règles RepairKit ont un large accès à la machine et s’exécutent en tant que SYSTEM, car elles doivent pouvoir corriger les clés et les fichiers privilégiés.
TELEMSUP
Cette mise à jour de contenu télémétrique contient un document JSON décrivant à quelle fréquence et où soumettre la télémétrie :
{
"additionalHeaders": "x-amz-acl:bucket-owner-full-control",
"port": 0,
"resourceRoot": "prod",
"server": "t1.sophosupd.com",
"verb": "PUT",
"interval": 86400
}
La mise à jour de contenu télémétrique n’a pas changé depuis son introduction en 2016.
APPFEED et USERAPPFEED
Les mises à jour de contenu APPFEED contiennent des extraits Lua signés et chiffrés pour détecter les applications installées et générer dynamiquement des exclusions pour celles-ci.
Si une application est détectée et que APPFEED contient des règles d’exclusion concernant celle-ci, les règles génèrent dynamiquement des exclusions spécifiques à la machine en fonction de l’application installée. Ces exclusions sont signalées à Sophos Central pour un envoi d’informations à l’administrateur de Sophos Central.
Les règles ont un accès en lecture seule au registre et au système de fichier et fonctionnent généralement en recherchant des applications connues dans les clés de registre des programmes ‘Add/Remove’. Certaines applications, comme Microsoft SQL Server, nécessitent l’exécution d’un script PowerShell pour détecter les composants optionnels du système d’exploitation (OS).
APPFEED et USERAPPFEED sont chargées par une instance de SEDService.exe.
ProductRulesFeed
Les règles du produit sont chargées par SSPService.exe. Elles sont au même format que les règles de comportement, avec les mêmes accès et privilèges. Elles sont chargées dans le même interpréteur LuaJIT et fournissent les fonctionnalités de base requises par les règles de comportement.
Modèles ML
La mise à jour de contenu des modèles ML contient plusieurs modèles d’apprentissage automatique (ML) chargés par SophosFileScanner.exe. Contrairement à la plupart des mises à jour de contenu, les modèles ML contiennent des DLL Windows qui renferment la logique essentielle du modèle ML, ainsi que les “pondérations”, à savoir le résultat de l’entraînement et du paramétrage des modèles dans le Cloud des SophosLabs.
Les modèles ML sont chargés par SophosFileScanner.exe et sont exécutés dans le même environnement à faible privilège. SophosFileScanner.exe prend en charge le chargement de deux versions de chaque modèle : ‘telemetry’ and ‘live.’ Sophos utilise cette fonctionnalité pour fournir des modèles ML, potentiellement éligibles, en mode télémétrie. Lorsque SophosFileScanner.exe dispose d’un modèle ML en mode télémétrie, il sélectionne un échantillon de données pour l’analyse télémétrique et l’exécute via le modèle en question (en plus des activités normales). La sortie du modèle de télémétrie, ainsi que les données collectées par les modèles classiques, fournissent à Sophos la télémétrie à des fins d’analyse et de formation.
Sophos fournit des modèles ML sous forme de mises à jour de contenu afin qu’un nouveau modèle ML puisse bénéficier de plusieurs itérations en matière de télémétrie, de recyclage et de réglage plus précis avant d’être utilisé au niveau d’un modèle représentatif du monde réel.
Étant donné que la mise à jour du modèle ML contient du code exécutable, Sophos la publie plus progressivement, via plusieurs étapes différentes :
- Cette dernière passe plus de temps dans les groupes de version préliminaire (à savoir les tests techniques et ceux de Sophos Internal).
- Elle est publiée sur plusieurs semaines et non sur quelques heures.
Hmpa_data
La mise à jour de contenu Hmpa_data contient une liste globale d’empreintes digitales (thumbprints) autorisées pour HitmanPro.Alert. Chaque détection HitmanPro.Alert crée une empreinte digitale (thumbprint) unique pour une mitigation pertinente et des informations spécifiques à la détection. Par exemple, une empreinte digitale pour une mitigation StackPivot peut inclure le processus et quelques derniers ‘stack frames’.
Hmpa_data contient une liste condensée d’empreintes digitales autorisées globalement. Le service HitmanPro.Alert, hmpalertsvc.exe, utilise cette base de données pour supprimer rapidement et silencieusement les détections, réduire les faux positifs et éviter les problèmes de performances ou de stabilité.
- Le pilote HitmanPro.Alert, hmpalert.sys, génère des empreintes digitales et les envoie au service pour toute mitigation basée sur le pilote : CryptoGuard, CiGuard, PrivGuard, etc.
- La DLL hook HitmanPro.Alert, hmpalert.dll, qui est injectée dans les processus utilisateur, génère des empreintes digitales pour chaque détection et les envoie au service pour reporting.
Conclusion
Afin de suivre le rythme des menaces en constante évolution et de se protéger contre les menaces émergentes, il est extrêmement important de mettre régulièrement à jour les produits de sécurité avec de nouvelles données. Cependant, les mises à jour de contenu corrompues ou défectueuses peuvent provoquer des perturbations. Il est donc également essentiel que des mécanismes soient en place pour garantir qu’elles sont valides, signées et vérifiées.
Dans cet article, nous avons fourni un aperçu général des mises à jour de contenu que nous utilisons dans Intercept X, en explorant ce qu’elles sont réellement, à quelle fréquence elles sont diffusées, comment elles sont validées et vérifiées, les processus spécifiques à faible privilège et les méthodes spécifiques que nous utilisons pour les déployer en mode étape-par-étape et contrôlée.
Comme nous l’avons mentionné dans notre précédent article sur les pilotes du noyau Intercept X, équilibrer protection et sécurité est risqué, mais nous nous engageons à gérer ce risque de la manière la plus transparente possible.
Billet inspiré de Content updates and product architecture: Sophos Endpoint, sur le Blog Sophos.