Téléchargez le rapport Magic Quadrant de Gartner, qui évalue 18 fournisseurs selon des critères tels que la vision complète et la capacité de mise en œuvre.
Selon Gartner, « le XDR est une technologie émergente capable de renforcer l'efficacité de la prévention, de la détection et de la neutralisation des menaces ».
As of May 14, 2024, Knowledge Base (KB) articles will only be published and updated in our new Trellix Thrive Knowledge space.
Log in to the Thrive Portal using your OKTA credentials and start searching the new space. Legacy KB IDs are indexed and you will be able to find them easily just by typing the legacy KB ID.
Les injecteurs de fichiers DLL tiers, les détourages de code et l’accrochage
Articles techniques ID:
KB88085
Date de la dernière modification : 2023-02-27 21:36:56 Etc/GMT
Environnement
Endpoint Security (ENS) Prévention contre les menaces 10.x
VirusScan Enterprise (VSE) 8.x
McAfee Agent (MA) 5.x
Synthèse
Les applications logicielles qui s’exécutent dans des environnements Microsoft Windows peuvent injecter du code dans un processus qui n’est pas le seul. Bien que ce comportement soit similaire à celui de logiciels malveillants (malwares), il s’agit également d’un mécanisme intégré pour Microsoft Windows. Ce mécanisme permet aux développeurs de logiciels de fournir une expérience informatique plus riche pour l’utilisateur.
Nous avons rencontré de nombreuses applications logicielles ayant des raisons légitimes de charger des dll dans nos processus. De même si nous essayons de bloquer ces tentatives de chargement de DLL, les limitations techniques permettent parfois une réussite de ces injections. Une autre réponse est alors nécessaire pour permettre à ENS de continuer à fonctionner normalement. Cette situation conduit à l’utilitaire MfeSysPrep.exe . Le MfeSysPrep.exe est disponible via support technique et peut être utilisé en tant qu’outil de découverte d’injecteur de dll. Cet utilitaire est recommandé pour tout environnement qui rencontre des symptômes dus à la présence de dll tierces dans nos processus. Il inclut également les dll tierces décrites dans les déclarations de problème ci-dessous.
Arrière-plan :
Notre logiciel considère que les fichiers dll tiers qui ont été injectés dans nos processus ne sont pas approuvés. En d’autres termes :
Nous n’avons pas écrit leur code.
Nous ne savons pas ce que leur code fait ou ce qu’il peut faire.
Nous ne savons pas si elle peut être compromise et utilisée à des fins malveillantes.
Nous savons que tous les travaux effectués à partir des fonctions de DLL de ce tiers semblent provenir du processus injecté. Ainsi, en cas d’activité malveillante, il semble que notre logiciel procède à des opérations malveillantes. L’autorisation d’injections de DLL tierces dans nos processus n’est pas acceptable. Nous avons pris des mesures à l’aide de notre technologie de protection de l’accès (AP), également connue sous le nom de contrôle d’accès arbitraire, pour la sécurisation contre les injections de DLL tierces. Nous avons également mis en œuvre une structure de validation et de protection de l’approbation (VTP). Cette structure est sécurisée contre les scénarios où une injection peut se produire.
Utilisation de VTP :
Le service VTP, MFEVTPS.exe , est un service essentiel qui effectue des inspections des dll et des processus en cours d’exécution, y compris nos processus, qui interagissent avec notre code afin de vérifier que ces objets sont approuvés. Le service dépend du service de chiffrement Microsoft ( CryptSvc ), des API liées à la confiance, ainsi que de l’intégrité du magasin de certificats et des fichiers de catalogue. Si ces dépendances sont en mauvais état, notre service risque de ne pas fonctionner correctement.
Une vérification de la validation se produit lorsque notre code doit s’assurer que le processus ou l’objet agissant est approuvé, ou les deux.
Lors de l’initialisation de nos processus, le service VTP est utilisé pour valider le chargement de code approuvé. AP or AACNous utilisons pour nous assurer que nous chargeons uniquement les dll approuvées.
Comme indiqué ci-dessus, seuls notre code et Microsoft Code sont implicitement approuvés.
Partagé
The MFEVTPS.exe met en cache les résultats d’une vérification de la validation afin d’améliorer les performances des futures vérifications de validation.
Le cache est toujours examiné en premier lieu lors de l’exécution d’une vérification de validation.
Si une vérification de validation renvoie "non approuvé," cet objet est mis en cache comme non approuvé. Si un objet est mis en cache de manière incorrecte, seule une cache réinitialisée peut le corriger.
La cache est réinitialisée uniquement lors du démarrage en mode sans incident, mais pas en mode sans-accès avec le réseau, ou en exécutant la commande VTPInfo.exe /ResetVTPCache . Nous pouvons également réinitialiser le cache via le fichier DAT, le cas échéant. Immédiatement après la réinitialisation cache, un utilisateur peut constater un court délai de ralentissement des performances.
Echecs d’approbation
Une défaillance de l’approbation voit une vérification de la validation qui se traduit par "" non approuvé lorsque le résultat attendu est "approuvé." Exemples :
Un tiers injecte notre processus. Nous ne faisons pas confiance à la tierce partie. par conséquent, le processus échoue à une vérification de validation.
Un fichier signé du catalogue Microsoft contient des informations de signature non valides. Elle ne peut donc pas être vérifiée et notre processus ne parvient pas à la charger.
Un fichier dll valide est mis en cache en tant que "non approuvé" de manière incorrecte et les tentatives suivantes de chargement sont refusées.
Tous ces exemples peuvent provoquer l’échec du processus concerné, par exemple s’il ne se charge pas correctement ou n’effectue pas correctement ses tâches attendues. Ces échecs sont dus à notre propre mécanisme de sécurité (AAC) qui refuse l’accès à du code non approuvé.
Utilisation de AP ou AAC :
AAC remplacé AP. Cette technologie fonctionne à partir du noyau Windows. Il peut bloquer l’accès aux objets, tels que les objets réseau, fichier, registre et processus. La fonctionnalité comporte un ensemble de règles permettant de déterminer les éléments à bloquer et les éléments à autoriser. Les règles décrivent "" incorrecte ou "des comportements de" potentiellement dangereux qui doivent être bloqués ou refusés. La plupart des règles sont sous votre contrôle, exposées dans l’interface utilisateur ou dans les stratégies ePolicy Orchestrator (ePO). Certaines règles qui ne sont pas encore exposées sont toujours en vigueur. Nous considérons ces règles comme essentielles à l’état de fonctionnement du produit. Les règles que nous exposez pour vous pouvez être :
Activée ou Désactivée.
Définir sur rapport uniquement.
Modification pour ajouter d’autres processus à protéger ou protéger contre, ou pour les exclure de sorte que nous ne bloquons plus un certain processus de la violation de la règle.
Vous pouvez créer vos propres règles de blocage de comportement, ce qui permet de sécuriser votre environnement en fonction de l’un des outils les plus puissants à votre disposition.
Pour récapituler la manière dont fonctionne AAC, il voit une opération qui a tenté de s’exécuter, la procédure dans, et demande ce qui suit :
Quel est le nom du processus ?
Quel objet est l’accès au processus ?
Quel est le processus qui tente d’effectuer cette opération sur cet objet ?
Cette opération est-elle autorisée, oui ou non ?
"Aucune" signifie que nous la bloquons. Si "rapport" est activé, vous le consignez et l’envoi d’un événement au serveur ePO. "Oui" signifie que l’action est autorisée.
Nos règles privées comportent davantage de critères, tels que les suivants :
Qui a écrit ce code ? Pour obtenir ces informations, vous devez examiner la signature numérique.
Approuvez-vous le certificat numérique de ce fournisseur ? Nous approuvons uniquement la nôtre et Microsoft par défaut.
Les critères ajoutés fournissent davantage de sécurité. A l’inverse, comme expliqué ci-dessus, si une vérification de la validation échoue ou renvoie "un résultat" non approuvé, nos propres protections peuvent empêcher les processus d’accéder à des objets. Comme indiqué dans la déclaration d' arrière-plan ci-dessus, ce résultat est attendu.
Problème
1
Un processus tiers n’est pas autorisé à accéder à nos fichiers ou processus protégés. Le processus tiers reçoit un code d’erreur 5, ce qui signifie ACCESS_DENIED. Ce comportement est normal et n’implique pas un problème avec le logiciel.
L’accès à d’autres processus, fichiers ou dossiers est bloqué par un processus tiers qui charge nos dll. Par exemple, Microsoft Outlook, qui charge les dll de raccordement en mode utilisateur de prévention contre les exploits ENS, est bloquée lors d’une tentative d’accès à d’autres processus.
Problème
2
Un processus ne parvient pas à démarrer correctement. Par exemple, vous ne pouvez pas démarrer la console ENS malgré les journaux d’installation indiquant la réussite.
Un processus est en cours d'exécution, mais n'est opérationnel que partiellement. Par exemple, ENS se charge correctement, mais indique que d’autres services ne s’exécutent pas correctement ; Pourtant, le service applicable est en cours d’exécution.
L’installation d’un produit échoue et tente de revenir en arrière, ce qui peut également échouer, ce qui laisse les restes d’une tentative d’installation en échec.
Un processus n’est pas autorisé à accéder à d’autres fichiers ou dossiers appartenant à un autre produit. Par exemple, McScript_InUse.exe, qui appartient à la McAfee Agent, n’est pas autorisé à accéder aux dossiers ens.
Cause
A un niveau élevé, la cause est la suivante :
Les processus chargent des dll, qui contiennent du code qui est exécuté. Toutes ces tâches sont effectuées par le processus à l’aide de threads. Une DLL tierce est une DLL qui n’est pas construite par un fournisseur, ce qui, dans le cas présent, est US ou Microsoft. Lorsque notre processus charge une dll tierce, ce processus est "injecté" par la dll tierce, ce qui implique qu’il contient désormais des fonctions de tiers et peut exécuter le code du tiers. Le résultat est que le processus peut désormais effectuer des opérations qu’il n’a jamais prévu. Il n’y a pas non plus de connaissance de ces actions, car il ne s’agit pas de notre code. Toutefois, le code tiers est actif et réside au sein de notre processus.
Remarque : De nombreux fournisseurs de application tiers écrivent des logiciels légitimes qui appliquent une injection de DLL afin de faciliter leur fonction de produit. Il existe de nombreux exemples, mais ces noms sont de fournisseurs dont les applications sont fréquemment rencontrées dans l’espace d’entreprise : Citrix, Avecto, Lumension, outre l’approbation et NVIDIA.
Solution
1
ENS comporte un processus nommé MFECanary.exe qui s’exécute en tant que processus MFEEsp.exe enfant et capture les détails du certificat numérique pour toute dll qui tente de s’y injecter. Les informations sont envoyées à ePO via un événement agent, qui est traité sur le serveur ePO. Elle est ensuite renseignée dans la stratégie ENS Partagés.
Si vous constatez que les certificats sont renseignés dans la stratégie ENS Partagés, il s’agit d’une indication que des logiciels tiers non approuvés existent dans l’environnement. Ce logiciel tente activement de charger des dll dans nos processus. En cas de succès, leur présence au sein de nos processus mène aux affirmations de problème décrites ci-dessus.
Dans la stratégie ENS Partagés, une case à cocher permet à l’administrateur de contrôler si les systèmes clients approuvent ou non le certificat tiers. La même stratégie vous permet d’ajouter manuellement des certificats à approuver, à l’aide du certificat exporté ( .cer ) de la dll d’injection.
Pour les systèmes dotés de VSE, il n’existe pas de méthode automatisée permettant d’approuver une DLL d’injection. Mais, à partir de la version de VSE 8.8 patch 9, la stratégie de protection de l’accès pour VSE contient une exclusion globale pour l’onglet protection automatique. Dans cet onglet, vous pouvez exclure les processus concernés par une injection de DLL tierce. Pour disposer d’un plus grand contrôle sur les applications qui injectent dans nos processus, les clients sont invités à migrer vers ENS.
Solution
2
Assistance support technique :
Support technique peut également aider à identifier le tiers et à approuver ultérieurement un certificat numérique tiers de dll tierces signées injectant dans nos processus. Cette prise en charge nécessite l’ouverture d’une demande de service. Pour accélérer le traitement, les étapes nécessaires à la réalisation de ces tâches sont fournies dans cet article.
Contenus Cliquez pour développer la section à afficher :
Un utilitaire est disponible à partir de Support technique nommé MfeSysPrep.exe . Vous pouvez exécuter MfeSysPrep.exe une session autonome sur n’importe quel système cible pour la découverte de l’injecteur de dll, distribuée via des outils tiers ou déployé via ePO. L’outil écrit un fichier journal localement et envoie des événements ePO pour identifier les dll non approuvées qui peuvent avoir un impact sur les fonctions ENS.
Pour chaque injecteur identifié et son certificat numérique correspondant, si nous jugeons que le certificat en question est digne de confiance, l’outil met automatiquement à jour ENS pour approuver le certificat. Si l’outil ne Découvre aucune dll non approuvée en attente, aucune autre action n’est nécessaire. Pour plus d’informations sur l’approbation d’un certificat tiers, reportez-vous à la section "informations connexes" de cet article.
Pour chaque dll non approuvée et signée identifiée, les informations de certificat sont capturées dans le journal et fournies à ePO dans un événement. L’ID d’événement est 1092 ou 1095. Pour chaque dll non approuvée et non signée identifiée, un hachage SHA-1 et SHA-2 est enregistré pour cette dll dans le journal et fourni à ePO dans un événement. De nouveau, l’ID d’événement est 1092 ou 1095.
L’ID d’événement 1092 indique qu’un injecteur est détecté et que nous ne pouvons pas y faire confiance.
L’ID d’événement 1095 indique qu’un injecteur est détecté et que nous pouvons l’approuver automatiquement.
Cette identification est peut-être l’entreprise la plus difficile pour tout le processus. La raison en est que la méthode utilisée pour collecter ces informations dépend du fait que vous rencontriez des symptômes qui affectent le comportement du produit. Reportez-vous aux sections ci-dessous concernant la collecte de données en cas de "aucun symptôme indésirable" et "des symptômes indésirables."
Aucun symptôme indésirable :
Utilisez les Explorer de processus, disponibles à partir de Microsoft.
Exécutez l’outil en tant qu’administrateur.
Sélectionnez le processus qui contient la DLL tierce à l’intérieur de celui-ci.
Utilisez l’affichage des fichiers DLL ou appuyez sur CTRL + D, puis identifiez la DLL tierce, en notant son emplacement sur le disque. S’il existe plusieurs emplacements, notez-les tous.
Utilisez l'Explorateur Windows pour localiser cette dll sur le disque et accéder à ses Propriétés.
Consultez la section obtention du .cer fichier ci-dessous.
Symptômes indésirables :
Lorsque les symptômes défavorables se produisent au cours d’une session Windows, il existe deux points de données à collecter. Ces points de données doivent idéalement être collectés en parallèle ; Cela revient à exécuter les deux outils en même temps et à capturer le problème une fois.
Collecter les données du moniteur de processus :
Utilisez Process Monitor, disponible à partir de Microsoft.
Exécutez l’outil en tant qu’administrateur.
Démarrez le processus qui se comporte de manière inattendue.
Après avoir reproduit le comportement anormal, enregistrez la Procmon capture.
IMPORTANT :Enregistrez tous les événements et utilisez le format PML natif.
Fournissez ces informations à Support technique pour vous aider à identifier la DLL tierce chargée via le processus.
Démarrez le processus qui se comporte de manière inattendue.
Après avoir reproduit le comportement anormal, réexécutez AMTrace maintenant, en fournissant l’option arrêter.
Fournissez le journal créé à Support technique. Le fichier journal aide à identifier la DLL non approuvée.
Lorsque les symptômes défavorables se produisent uniquement à Windows démarrage/démarrage, il existe deux points de données à collecter, qui peuvent être collectés en série ou en parallèle :
Collecter les données du moniteur de processus :
Utilisez Process Monitor, disponible à partir de Microsoft.
Exécutez l’outil en tant qu’administrateur.
Dans le menu options, cliquez sur activer la journalisation de démarrage.
Réinitialisez le VTP cache *.
Redémarrez le système.
Connectez-vous et exécutez à nouveau Process Monitor .
Enregistrez la capture de journalisation de Procmon démarrage.
IMPORTANT :Enregistrez tous les événements et utilisez le format PML natif.
Fournissez ces informations à Support technique pour vous aider à identifier la DLL tierce chargée via le processus.
Après avoir reproduit le comportement anormal, réexécutez AMTrace maintenant, en fournissant l’option arrêter.
Fournissez le journal créé à Support technique. Le fichier journal aide à identifier la DLL non approuvée.
* Pour réinitialiser le cache VTP :
A partir d’une invite de commande administrateur, accédez à \Program Files\Common Files\McAfee\SystemCore .
Exécutez l' VTPInfo.exe utilitaire avec le paramètre /resetvtpcache :
VTPInfo.exe /ResetVTPCache
Obtenir le .cer fichier :
Cette procédure est nécessaire uniquement si vous effectuez l’option 2 pour identifier les dll tierces non approuvées. L’obtention du fichier n’est pas nécessaire si vous utilisez l' .cer option 1.
Pour accéder aux propriétés du fichier EXE ou DLL, cliquez avec le bouton droit de la même façon et sélectionnez Propriétés.
Cliquez sur l’onglet certificats numériques .
REMARQUE : Si cet onglet n’est pas présent, cela indique que le fichier n’est pas signé numériquement et qu’il n’existe aucune option pour que nous approuvions le code de ce fournisseur. Vous devez contacter le fournisseur et demander qu’il fournisse un code signé.
Sélectionnez un certificat dans la liste des signatures à laquelle vous souhaitez faire confiance.
Cliquez sur Détails.
Cliquez sur afficher le certificat.
Cliquez sur l’onglet Détails .
Cliquez sur copier dans un fichier.
Dans l’Assistant exportation de certificat, cliquez sur suivant.
Cliquez à nouveau sur suivant pour accepter la création d’un .cer fichier.
Spécifiez un nom de fichier et un emplacement. Par exemple, C:\Temp\My3rdParty.cer.
Cliquez sur suivant et sur Terminer.
Si vous utilisez l’option 1 ci-dessus et qu’aucune autre DLL non approuvée n’est trouvée, aucune autre action n’est nécessaire.
Pour les dll signées et non approuvées , nous pensons que le certificat numérique de cette dll s’affiche dans la stratégie ens partagés. Dans ce cas, reportez-vous à la solution 1. Utilisez la stratégie ENS Partagés options pour approuver manuellement le certificat si l’une des conditions ci-dessous est vraie :
Le certificat n’a pas été affiché dans cette stratégie.
Vous souhaitez déplacer le processus en suivant une méthode plus prévisible, une fois que vous avez obtenu le fichier ( .cer) .
IMPORTANT :Avant de procéder à cette opération, reportez-vous à la sectioninformations connexes"" de cet article pour les implications de l’approbation d’un certificat tiers.
Pour les dll non approuvées et non signées , nous pensons que le fournisseur de ce logiciel vous fournit un code signé numériquement, car il s’agit d’une norme industrielle pour l’identification des logiciels lancés. Dans les cas où les fournisseurs ne sont pas conformes ou ne sont pas conformes, Support technique peut vous aider. Vous devez fournir toutes les dll non signées qui MfeSysPrep.exe ont été identifiées comme injecteurs et le MfeSysPrep journal qui affiche l’injection. A l’aide de ces informations, nous envisageons d’ajouter la DLL non signée dans l' MfeSysPrep utilitaire, afin de résoudre des problèmes tels que l’échec des installations ens, en raison de la présence du application tiers. Elle n’inclut pas les applications telles que les logiciels antivirus qui remplissent la même fonction que ENS.
Important : Avant de pouvoir ajouter une approbation à une DLL tierce, vous devez envoyer la DLL à McAfee Labs en tant qu’échantillon pour vous assurer qu’elle n’est pas malveillante. Pour obtenir des instructions, voir KB85567-soumettre des faux positifs potentiels du produit ou par le biais de GTI à Labs. Incluez les informations suivantes lorsque vous soumettez de tels exemples de DLL :
Fabricant du logiciel
Fichier exécutable ou processus parent
Cette application est-elle disponible à l’interne ou publiquement ?
Brève description de la fonction et de l’objectif du logiciel, y compris la DLL soumise
Informations connexes
Implications en matière de sécurité de l’approbation d’un certificat numérique tiers :
Les implications en matière de sécurité que vous acceptez en approuvant un certificat tiers sont les suivantes :
Vous acceptez que tout code signé par le certificat tiers sera approuvé pour interagir avec nos processus, fichiers, registre et tous les autres objets protégés.
Vous acceptez que l’activité de fichier générée par les processus signés à l’aide du certificat tiers ne soit pas analysée.
Vous comprenez que les distributions de produits ou de code provenant du même fournisseur, en cas d’utilisation du même certificat numérique, héritent automatiquement des mêmes allocations.
Vous comprenez que les distributions de produits ou de code provenant du même fournisseur, à l’aide d’un certificat numérique différent, doivent également être approuvées pour obtenir les mêmes résultats.
Si vous êtes un utilisateur enregistré, saisissez votre ID d’utilisateur et votre mot de passe, puis cliquez sur connexion.
Si vous n’êtes pas un utilisateur enregistré, cliquez sur Enregistrer et renseignez les champs pour que votre mot de passe et les instructions vous soient envoyés par e-mail.
Clause d'exclusion de responsabilité
Le contenu du présent article a été rédigé en anglais. En cas de divergences entre la version anglaise et sa traduction, la version en anglais prévaut. Certaines parties de ce contenu ont été traduites par le moteur de traduction automatique de Microsoft.
