En el sector de la ciberseguridad no hay tiempo para aburrirse y nunca ha habido un mejor momento para aceptar esta idea como una ventaja y un catalizador de la actividad empresarial.
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.
Las aplicaciones de software que se ejecutan en Microsoft Windows entornos pueden inyectar código en un proceso que no es propio. Aunque este comportamiento es similar al de malware, también es un mecanismo integrado para Microsoft Windows. Este mecanismo permite a los desarrolladores de software proporcionar una experiencia informática más rica para el usuario.
Hemos encontrado numerosas aplicaciones de software con razones legítimas para cargar dll en nuestros procesos. Aunque intentamos bloquear estos intentos de carga de DLL, las limitaciones técnicas permiten que estas inyecciones se realicen a veces correctamente. A continuación, se necesita una respuesta alternativa para permitir que ENS continúe funcionando con normalidad. Esta situación conduce a la utilidad MfeSysPrep.exe . El MfeSysPrep.exe está disponible a través de soporte técnico y se puede utilizar como una herramienta de descubrimiento de inyectores de dll. Esta utilidad se recomienda para todos los entornos que experimenten síntomas causados por la presencia de archivos dll de terceros en nuestros procesos. También incluye las dll de terceros descritas en las siguientes declaraciones de problemas .
Segundo plano:
Nuestro software considera las dll de terceros que han inyectado en nuestros procesos que no son de confianza. En otras palabras:
No hemos escrito su código.
No sabemos lo que hace su código o lo que puede hacer.
No sabemos si nunca se ha puesto en riesgo y se utiliza de forma maliciosa.
Lo que sabemos es que cualquier trabajo realizado en las funciones DLL de ese tercero parece proceder del proceso inyectado. Por lo tanto, si hay actividad maliciosa, parece que nuestro software lleva a cabo operaciones maliciosas. Permitir la inserción de DLL de terceros en nuestros procesos no es aceptable. Hemos tomado medidas mediante nuestra tecnología de protección de acceso (AP), también conocida como control de acceso arbitrario, para proteger frente a las inyecciones de DLL de terceros. También hemos implementado una estructura de validación y protección de confianza (VTP). Este marco de trabajo protege frente a los escenarios en los que podría haberse producido una inyección.
Cómo usamos VTP:
El servicio VTP, MFEVTPS.exe , es un servicio crítico que realiza inspecciones de archivos dll y procesos en ejecución, incluidos nuestros procesos, que interactúan con nuestro código, para verificar que esos objetos son de confianza. El servicio depende del Microsoft servicio criptográfico ( CryptSvc ), las API relacionadas con la confianza y el estado del almacén de certificados y de los archivos de catálogo. Si esas dependencias se encuentran en mal estado, es posible que nuestro servicio no funcione correctamente.
Se realiza una comprobación de validación cuando nuestro código necesita asegurarse de que el proceso o el objeto activo son de confianza, o ambos.
Cuando se inicializan nuestros procesos, se utiliza el servicio VTP para validar que estamos cargando código de confianza. AP or AACUsamos para garantizar que solo cargamos las dll de confianza.
Tal y como se ha indicado anteriormente, solo el código y el código Microsoft son de confianza de forma implícita.
AppFabric
The MFEVTPS.exe almacena en caché los resultados de una comprobación de validación para mejorar el rendimiento de futuras comprobaciones de validación.
La caché siempre se examina en primer lugar al realizar una comprobación de validación.
Si una comprobación de validación devuelve "no de confianza," que el objeto se almacena en caché como no de confianza. Si un objeto se almacena en caché como no fiable de forma incorrecta, solo se puede corregir el restablecimiento de la caché.
La caché solo se restablece al arrancar en modo seguro, pero no en modo seguro con funciones de red o ejecutando el comando VTPInfo.exe /ResetVTPCache . También se puede restablecer la caché a través del archivo DAT cuando sea necesario. Al seguir inmediatamente después del restablecimiento de la caché, un usuario puede experimentar un breve periodo de rendimiento lento.
Errores de confianza
Un error de confianza ve una comprobación de validación que provoca que "" no de confianza cuando el resultado esperado es "de confianza." Ejemplos:
Un tercero inyecta nuestro proceso. No confiamos en la tercera parte, por lo que el proceso falla una comprobación de validación.
Un archivo firmado del catálogo de Microsoft tiene información de firma no válida. Por lo tanto, no se puede verificar y nuestro proceso no lo carga.
Un archivo dll válido se almacena en caché como "no fiable" de forma incorrecta y los intentos subsiguientes de cargarlo se deniegan.
Todos estos ejemplos pueden provocar que el proceso afectado falle, como no cargar adecuadamente o no realizar sus tareas previstas adecuadamente. Estos errores se producen debido a que nuestro propio mecanismo de seguridad (AAC) deniega el acceso a código que no es de confianza.
Uso de AP o AAC:
AAC ha sustituido a AP. Esta tecnología opera de la kernel Windows. Puede bloquear el acceso a los objetos, tales como la red, el archivo, el registro y los objetos de proceso. La función cuenta con un conjunto de reglas para determinar lo que se debe bloquear y lo que se debe permitir. Las reglas describen "" incorrecta o "comportamientos no" seguros que deben bloquearse o denegarse. Muchas de las reglas están bajo su control, expuestas en la interfaz de usuario o en las directivas de ePolicy Orchestrator (ePO). Algunas reglas que no se exponen aún están en vigor. Consideramos que estas reglas son críticas para el estado de funcionamiento del producto. Las reglas que exponemos para usted pueden ser:
Esta opción puede estar activada o desactivada.
Se establece en solo informar.
Se ha modificado para agregar otros procesos con los que proteger o proteger, o para excluir, de modo que ya no se impide que un proceso determinado infrinja la regla.
Puede crear sus propias reglas de bloqueo de comportamiento, de forma que esta función una de las herramientas más potentes a su disposición para proteger su entorno.
Para resumir cómo funciona AAC, ve una operación que se está intentando llevar a cabo, pasos en y pregunta lo siguiente:
¿Cuál es el nombre del proceso?
¿Qué objeto está accediendo al proceso?
¿Qué es el proceso que está intentando hacer con ese objeto?
¿Se permite esta operación, sí o no?
"Ningún" significa que lo bloqueamos. Si "" de informe está activado, lo registramos y enviamos un evento al servidor de ePO. "Sí" significa que se permite la acción.
Nuestras reglas privadas incluyen más criterios, como los siguientes:
¿Quién escribió este código? La obtención de esta información implica la observación de la firma digital.
¿Confiamos en el certificado digital de ese proveedor? De forma predeterminada, solo confiamos en nuestro y Microsoft.
Los criterios agregados proporcionan más seguridad. Por el contrario, como se ha explicado anteriormente, si una comprobación de validación falla o produce un resultado "no fiable", es posible que nuestras propias protecciones bloqueen los procesos para que no puedan acceder a los objetos. Como se indica en la instrucción en segundo plano anterior, se espera este resultado.
Problema
1
Se impide que un proceso de terceros acceda a nuestros archivos o procesos protegidos. El proceso de terceros recibe el código de error 5, que significa ACCESS_DENIED. Este comportamiento es el esperado y no implica un problema con el software.
Un proceso de terceros que cargue nuestras dll tiene bloqueado el acceso a otros procesos, archivos o carpetas. Por ejemplo, Microsoft Outlook, que carga los archivos dll de enlace de modo usuario de prevención de exploits de ENS, se bloquea al intentar acceder a otros procesos.
Problema
2
Un proceso de no puede iniciarse correctamente. Por ejemplo, no puede iniciar la consola de ENS a pesar de los registros de instalación que indican que han sido correctos.
Un proceso de está ejecutándose, pero solo funciona parcialmente. Por ejemplo, ENS se carga correctamente, pero indica que otros servicios no se están ejecutando correctamente; sin embargo, el servicio aplicable se está ejecutando.
Se produce un error en la instalación de un producto y se intenta revertir, lo que también podría fallar y dejar restos de un intento de instalación fallido.
Se impide que un proceso acceda a otros archivos o carpetas que pertenecen a un producto diferente. Por ejemplo, McScript_InUse.exe, que pertenece a la McAfee Agent, se bloquea el acceso a las carpetas de ens.
Motivo
En un nivel alto, la causa es la siguiente.
Los procesos cargan dll, que contienen código que se ejecuta. Todo este trabajo lo realiza el proceso mediante el uso de subprocesos. Un archivo DLL de terceros es aquel que no está construido a través de un proveedor, que en este caso es US o Microsoft. Cuando nuestro proceso carga una DLL de terceros, dicho proceso se "inyectado" por la dll de terceros, lo que implica que ahora contiene funciones de terceros y puede ejecutar el código de terceros. El resultado es que el proceso ahora puede llevar a cabo operaciones que no se pretenden. Tampoco hay conocimiento de lo que podrían ser esas acciones porque no es nuestro código. No obstante, el código de terceros está activo y reside en nuestro proceso.
Nota: Muchos proveedores de aplicaciones de terceros escriben software legítimo que aplica la inyección de DLL como medio para facilitar la función de sus productos. Existen muchos ejemplos, pero estos nombres son de algunos proveedores cuyas aplicaciones suelen encontrarse en el espacio de la empresa: Citrix, Avecto, lúmenes, más allá de la confianza y NVIDIA.
Solución
1
ENS tiene un proceso con nombre MFECanary.exe que se ejecuta como un proceso secundario a MFEEsp.exe y captura los detalles del certificado digital para cualquier dll que intente inyectarse en él. La información se envía a ePO a través de un evento de agente, que se procesa en el servidor de ePO. A continuación, se rellena a la Directiva Ajustes generales de ENS.
Cuando ve que los certificados se rellenan en la Directiva Ajustes generales de ENS, es una indicación de que el software de terceros que no es de confianza existe en el entorno. Este software está intentando cargar de forma activa dll en nuestros procesos. Si se realizan correctamente, su presencia dentro de nuestros procesos conduce a las declaraciones de problemas descritas anteriormente.
En la Directiva Ajustes generales de ENS, una casilla de verificación permite al administrador controlar si los sistemas cliente confían o no en el certificado de terceros. La misma directiva permite agregar manualmente certificados para que sean de confianza mediante el certificado exportado ( .cer ) de la dll de inserción.
En los sistemas con VSE, no existe ningún método automatizado para confiar en una DLL de inserción. No obstante, a partir de la publicación del parche 9 de VSE 8.8 , la Directiva protección de acceso para VSE contiene una ficha exclusiones globales para la protección automática. En esta ficha, puede excluir procesos que se vean afectados por una inyección de DLL de terceros. Para tener más control sobre las aplicaciones que insertan en nuestros procesos, los clientes se han instado a migrar a ENS.
Solución
2
Asistencia soporte técnico:
Soporte técnico también pueden ayudar a identificar el tercero y, posteriormente, confiar en un certificado digital de terceros de dll de terceros con firma inyectando en nuestros procesos. Esta compatibilidad requiere que se abra una solicitud de servicio. Para agilizar el procesamiento, en este artículo se proporcionan los pasos para conseguir estas tareas.
Contenido Haga clic para expandir la sección que desee ver:
Hay una utilidad disponible en Soporte técnico nombre MfeSysPrep.exe . Puede ejecutar MfeSysPrep.exe de forma independiente en cualquier sistema de destino para el descubrimiento del inyector de dll, se distribuye a través de herramientas de terceros o se implementa mediante ePO. La herramienta escribe un archivo de registro de forma local y envía eventos de ePO a los archivos dll no fiables identificados que pueden afectar a las funciones de ENS.
Por cada inyector identificado y su correspondiente certificado digital, si consideramos que un certificado específico es de confianza, la herramienta actualiza automáticamente ENS para confiar en el certificado. Si la herramienta no descubre ningún dll pendiente que no sea de confianza, no es necesario realizar ninguna otra acción. Consulte la sección "información relacionada" de este artículo para conocer las implicaciones de confiar en un certificado de terceros.
Por cada dll firmada y no de confianza identificada, la información del certificado se captura en el registro y se proporciona a ePO en un evento. El ID de evento es 1092 o 1095. Por cada dll no de confianza y sin firmar identificada, se registra un hash SHA-1 y Sha-2 para esa dll en el registro y se proporciona a ePO en un evento. De nuevo, el ID de evento es 1092 o 1095.
El ID de evento 1092 indica que se encuentra un inyector y no podemos confiar en él.
El ID de evento 1095 indica que se encuentra un inyector y se puede confiar automáticamente.
Es posible que esta identificación sea la más difícil de realizar en todo el proceso. El motivo es que el método para recopilar esta información depende de si está experimentando síntomas que afectan al comportamiento del producto. Consulte las secciones siguientes sobre la recopilación de datos cuando no hay "síntomas adversos" y "síntomas adversos."
Sin síntomas adversos:
Utilice Explorer de procesos, disponible en Microsoft.
Ejecute la herramienta como administrador.
Seleccione el proceso que contiene el archivo DLL de terceros.
Utilice la vista de DLL, o pulse CTRL + D, e identifique el archivo DLL de terceros y anote su ubicación en el disco. Si hay varias ubicaciones, Anote todas.
Utilice Windows Explorer para localizar esa dll en el disco y acceder a sus propiedades.
Consulte obtención del .cer archivo a continuación.
Síntomas adversos:
Cuando se producen los síntomas adversos durante una sesión de Windows, hay dos puntos de datos que se pueden recopilar. Idealmente, estos puntos de datos deben recopilarse en paralelo; es decir, ejecute ambas herramientas al mismo tiempo y Capture el problema una vez.
Recopilar datos del monitor de procesos:
Utilice Process Monitor, disponible en Microsoft.
Ejecute la herramienta como administrador.
Inicie el proceso que se comporta de forma inesperada.
Una vez que haya reproducido el comportamiento anómalo, guarde la Procmon captura.
IMPORTANTE:Guarde todos los eventos y utilice el formato nativo de PML.
Proporcione esta información a Soporte técnico para ayudarle a identificar la DLL de terceros que se va a cargar a través del proceso.
Inicie el proceso que se comporta de forma inesperada.
Una vez que haya reproducido el comportamiento anómalo, vuelva a ejecutarlo AMTrace y, ahora, proporcione la opción para detenerse.
Proporcione el registro creado para Soporte técnico. El archivo de registro ayuda a identificar la DLL que no es de confianza.
Cuando los síntomas adversos solo se producen en Windows arranque/inicio, hay dos puntos de datos que se pueden recopilar, que se puede recopilar en serie o en paralelo:
Recopilar datos del monitor de procesos:
Utilice Process Monitor, disponible en Microsoft.
Ejecute la herramienta como administrador.
En el menú de opciones, haga clic en Seleccionar registro de arranque.
Restablezca la caché de VTP *.
Reinicie el sistema.
Inicie sesión y ejecute el monitor de procesos de nuevo.
Guarde la captura del registro de Procmon arranque.
IMPORTANTE:Guarde todos los eventos y utilice el formato nativo de PML.
Proporcione esta información a Soporte técnico para ayudarle a identificar la DLL de terceros que se va a cargar a través del proceso.
Una vez que haya reproducido el comportamiento anómalo, vuelva a ejecutarlo AMTrace y, ahora, proporcione la opción para detenerse.
Proporcione el registro creado para Soporte técnico. El archivo de registro ayuda a identificar la DLL que no es de confianza.
* Para restablecer la caché de VTP:
Desde un símbolo del sistema de administrador, desplácese hasta \Program Files\Common Files\McAfee\SystemCore .
Ejecute la VTPInfo.exe utilidad con el parámetro /resetvtpcache :
VTPInfo.exe /ResetVTPCache
Obtenga el .cer archivo:
Este procedimiento solo es necesario si se realiza la opción 2 para identificar las DLL que no son de confianza de terceros. No es necesario obtener el archivo si utiliza la .cer opción 1.
Para acceder a las propiedades del archivo EXE o DLL, haga clic con el botón derecho del ratón y seleccione propiedades.
Haga clic en la pestaña certificados digitales .
NOTA:Si falta esta ficha, el archivo no está firmado digitalmente y no existe la opción de confiar en el código de este proveedor. Debe ponerse en contacto con el proveedor y solicitar que proporcione un código firmado.
Seleccione un certificado de la lista de firmas en la que desea confiar.
Haga clic en detalles.
Haga clic en Ver certificado.
Haga clic en la pestaña detalles .
Haga clic en copiar al archivo.
En el Asistente de exportación de certificados, haga clic en siguiente.
Vuelva a hacer clic en siguiente para aceptar la creación de un .cer archivo.
Especifique un nombre de archivo y una ubicación. Por ejemplo, C:\Temp\My3rdParty.cer.
Haga clic en siguiente y en Finalizar.
Si utiliza la opción 1 anterior y no se encuentran más dll que no sean de confianza, no es necesario realizar ninguna otra acción.
En el caso de los archivos dll no de confianza y firmados , esperamos que el certificado digital para esa dll aparezca en la Directiva ajustes generales de ens. En este caso, consulte la Solución 1. Utilice la Directiva opciones de Ajustes generales de ENS para confiar manualmente en el certificado si cualquiera de las siguientes condiciones es la espera:
El certificado no ha aparecido en esa Directiva.
Desea mover el proceso en una forma más predecible una vez que haya obtenido el ( .cer) archivo.
IMPORTANTE:Antes de hacerlo, consulte la sección "información relacionada" de este artículo para conocer las implicaciones de confiar en un certificado de terceros.
En el caso de dll no de confianza y sin firmar , esperamos que el proveedor de ese software le proporcione código firmado digitalmente, ya que es un estándar del sector para identificar Software liberado. En los casos en los que los proveedores no cumplan o no, Soporte técnico puede ayudarle. Debe proporcionar cualquier dll sin firmar que MfeSysPrep.exe haya identificado como inyectores y el MfeSysPrep registro que muestra la inyección. Con esta información, consideramos la posibilidad de agregar la DLL sin firmar de la MfeSysPrep utilidad para ayudarle a solucionar problemas tales como fallos en las instalaciones de ENS debido a la presencia de la aplicación de terceros. No incluye aplicaciones como software antivirus que sirvan la misma función que ENS.
Importante: Para poder agregar confianza a un archivo DLL de terceros, debe enviar el archivo DLL a McAfee Labs como muestra para confirmar que no es malicioso. Para obtener instrucciones, consulte KB85567-envío de posibles falsos positivos del producto o a través de GTI a Labs. Incluya la siguiente información cuando envíe estas muestras de DLL:
Fabricante de software
Proceso o ejecutable principal
¿Esta aplicación es interna o está disponible de forma pública?
Breve descripción de la función y el propósito del software, incluido el archivo DLL enviado
Información relacionada
Implicaciones de seguridad de confiar en un certificado digital de terceros:
Existen implicaciones de seguridad que se aceptan mediante la confianza de un certificado de terceros:
Usted acepta que cualquier código firmado por el certificado de terceros será de confianza para interactuar con nuestros procesos, archivos, registro y todos los demás objetos protegidos.
Puede aceptar que la actividad de archivo generada por los procesos firmados con el certificado de terceros no se pueda analizar.
Usted entiende que cualquier producto o versión de código del mismo proveedor, si utiliza el mismo certificado digital, hereda automáticamente los mismos subsidios.
Usted entiende que cualquier producto o versión de código del mismo proveedor, con un certificado digital distinto, también debe ser de confianza para obtener los mismos resultados.
Si es un usuario registrado, escriba su ID de usuario y contraseña y, a continuación, haga clic en iniciar sesión.
Si no es un usuario registrado, haga clic en registrar y rellene los campos para que la contraseña y las instrucciones se envíen por correo electrónico.
Descargo de responsabilidad
El contenido de este artículo se creó en inglés. En caso de darse cualquier diferencia entre el contenido en inglés y su traducción, el primero siempre será el más preciso. La traducción de algunas partes de este contenido la ha proporcionado Microsoft mediante el uso de traducción automática.