A indústria da segurança cibernética nunca descansa, e não há melhor momento do que agora para enxergar isso como uma vantagem e um catalisador para o empoderamento dos negócios.
Os aplicativos de software que são executados em Microsoft Windows ambientes podem injetar código em um processo que não é seu. Embora esse comportamento seja semelhante ao do malware, ele também é um mecanismo incorporado para Microsoft Windows. Esse mecanismo permite que os desenvolvedores de software forneçam uma experiência de computação mais rica para o usuário.
Encontramos inúmeros aplicativos de software com motivos legítimos para carregar DLLs em nossos processos. Embora tentemos bloquear essas tentativas de carregamento de DLL, as limitações técnicas permitem que essas injeçãos às vezes sejam bem-sucedidas. Uma resposta alternativa é, então, necessária para permitir que o ENS continue funcionando normalmente. Essa situação leva ao utilitário MfeSysPrep.exe . O está disponível através do MfeSysPrep.exe suporte técnico e pode ser usado como uma ferramenta de descoberta de injetador de dll. Esse utilitário é recomendado para qualquer ambiente que apresente sintomas causados pela presença de DLLs de terceiros em nossos processos. Ele também inclui as DLLs de terceiros descritas nas declarações de problemas abaixo.
Plano de fundo:
Nosso software considera DLLs de terceiros que se injetaram em nossos processos não confiáveis. Em outras palavras:
Não escrevemos o código.
Não sabemos o que seus códigos fazem ou o que ele pode fazer.
Não sabemos se ele pode ser comprometido e usado maliciosamente.
O que sabemos é que qualquer trabalho feito das funções de DLL do terceiro parece originar do processo injetado. Portanto, se houver atividade maliciosa, parece que nosso software executa operações maliciosas. Permitir injeções de DLL de terceiros em nossos processos não é aceitável. Tomamos as medidas de uso da tecnologia de proteção de acesso (PA), também conhecida como controle de acesso arbitrário, para proteção contra injeção de DLL de terceiros. Também implementamos uma estrutura de validação e proteção confiável (VTP). Essa estrutura se protege contra cenários em que pode ter ocorrido uma injeção.
Como usamos o VTP:
O serviço VTP, MFEVTPS.exe ,, é um serviço crítico que realiza inspeções de DLLs e processos em execução, incluindo nossos processos, que interagem com nosso código, para verificar se esses objetos são confiáveis. O serviço depende do serviço de criptografia Microsoft ( CryptSvc ), das APIs relacionadas à confiança e da integridade do armazenamento de certificados e dos arquivos de catálogo. Se essas dependências estiverem em estado inválido, nosso serviço pode não funcionar corretamente.
Uma verificação de validação ocorre quando o nosso código precisa ter certeza de que o processo ou o objeto de ação é confiável, ou ambos.
Quando nossos processos são inicializados, o serviço VTP é usado para validar que estamos carregando código confiável. AP or AACUsamos para certificar-se de que carregamos somente DLLs confiáveis.
Conforme mencionado acima, apenas nosso código e código de Microsoft são implicitamente confiáveis.
PMK
The MFEVTPS.exe armazena em cache os resultados de uma verificação de validação para melhorar o desempenho de futuras verificações de validação.
O cache é sempre examinado primeiro ao executar uma verificação de validação.
Se uma verificação de validação retornar "não confiável," esse objeto será armazenado em cache como não confiável. Se um objeto for armazenado em cache como não confiável incorretamente, somente uma redefinição de cache poderá corrigi-lo.
O cache é redefinido apenas ao se inicializar no modo de segurança, mas não no modo de segurança com rede ou ao executar o comando VTPInfo.exe /ResetVTPCache . Também podemos redefinir o cache por meio do DAT, quando necessário. Imediatamente após a redefinição do cache, um usuário pode enfrentar um breve período de baixo desempenho.
Falhas de confiança
Uma falha na relação de confiança vê uma verificação de validação que resulta em "" não confiável quando o resultado esperado é "confiável."
Exemplos:
Uma terceira parte injeta nosso processo. Não confiamos no terceiro, portanto, o processo falha em uma verificação de validação.
um arquivo assinada pelo catálogo do Microsoft tem informações de assinatura inválidas. Portanto, não pode ser verificado e o processo falha ao carregá-lo.
Um arquivo de dll válido é armazenado em cache como "não confiável" incorretamente, e tentativas subsequentes de carregá-lo são negadas.
Todos esses exemplos podem fazer com que o processo afetado falhe, como não carregar corretamente ou não executar suas obrigações esperadas corretamente. Essas falhas ocorrem por causa do nosso mecanismo de segurança (AAC) negar acesso a código não confiável.
Como utilizamos o AP ou o AAC:
AAC substituiu o AP. Essa tecnologia opera a partir do Windows kernel. Ele pode bloquear o acesso a objetos, como os objetos de rede, arquivo, registro e processo. O recurso tem um conjunto de regras para determinar o que deve ser bloqueado e o que permitir. As regras descrevem "" incorretos ou "comportamentos de" inseguros que precisam ser bloqueados ou negados. Muitas das regras estão sob seu controle, expostas na interface do usuário ou nas políticas do ePolicy Orchestrator (ePO). Algumas regras que ainda não estão expostas ainda estão em vigor. Consideramos essas regras críticas para a saúde operacional do produto. As regras que expõemos para você podem ser:
Ativado ou desativado.
Definir como somente relatar.
Modificadas para adicionar outros processos a serem protegidos ou protegidos contra o ou para exclusão, de modo que não bloqueamos mais um determinado processo para violar a regra.
Você pode criar suas próprias regras de bloqueio de comportamento, fazendo com que esse recurso seja uma das ferramentas mais poderosas à sua disposição, para proteger o seu ambiente.
Para resumir como o AAC funciona, ele vê uma operação que está tentando ser executada, etapas no e pergunta o seguinte:
Qual é o nome do processo?
Qual objeto está acessando o processo?
Qual é o processo que está tentando fazer com esse objeto?
Esta operação é permitida, sim ou não?
"Nenhuma" significa bloqueá-lo. Se "" de relatório estiver ativado, nós o registramos e enviamos um evento para o servidor ePO. "Sim" significa que a ação é permitida.
Nossas regras privadas incluem mais critérios, como os seguintes:
Quem escreveu este código? A obtenção dessas informações envolve a análise da assinatura digital.
Confiamos no certificado digital desse fornecedor? Nós confiamos apenas no nosso e Microsoft por padrão.
Os critérios adicionados proporcionam mais segurança. Inversamente, conforme explicado acima, se uma verificação de validação falhar ou gerar um "" resultado não confiável, nossas próprias proteções poderão bloquear os processos de acesso a objetos. Conforme indicado na declaração de segundo plano acima, esse resultado é esperado.
Problema
1
Um processo de terceiros está impedido de acessar nossos arquivos ou processos protegidos. O processo de terceiros recebe o código de erro 5, o que significa ACCESS_DENIED. Esse comportamento é esperado e não significa um problema com o software.
Um processo de terceiros que carrega nossas DLLs é impedido de acessar outros processos, arquivos ou pastas. Por exemplo, Microsoft Outlook, que carrega as DLLs de interceptação do modo de usuário da prevenção de exploração do ENS, é bloqueada ao tentar acessar outros processos.
Problema
2
Ocorre uma falha ao tentar iniciar um processo da corretamente. Por exemplo, você não pode iniciar o console do ENS apesar de os logs de instalação indicarem êxito.
Há um processo da em execução, mas encontra-se parcialmente em operação. Por exemplo, o ENS é carregado com êxito, mas indica que outros serviços não estão sendo executados corretamente; no entanto, o serviço aplicável está em execução.
Uma instalação de um produto falha e tenta ser revertido, o que também pode falhar, deixando vestígios de tentativas de instalação com falha.
Um processo está impedido de acessar outros arquivos ou pastas pertencentes a um produto diferente. Por exemplo, McScript_InUse.exe, que pertence à McAfee Agent, está impedido de acessar pastas do ens.
Causa
Em um nível alto, a causa é a seguinte.
Os processos carregam DLLs, que contêm o código que é executado. Todo esse trabalho é feito pelo processo que usa threads. Uma DLL de terceiros é aquela que não é criada por meio de um fornecedor, que, nesse caso, é EUA ou Microsoft. Quando o nosso processo carrega uma DLL de terceiros, esse processo é "injetado" pela DLL de terceiros, que indica que agora ela contém funções de terceiros e pode executar o código de terceiros. O resultado é que o processo agora pode executar operações que nunca pretendem fazer. Também não há nenhum conhecimento do que essas ações podem ser, por não ser o nosso código. No entanto, o código de terceiros está ativo e reside em nosso processo.
Nota: Muitos fornecedores de aplicativos de terceiros escrevem softwares legítimos que aplicam injeção de DLL como um meio de facilitar a função do produto. Existem muitos exemplos, mas esses nomes são de alguns fornecedores cujos aplicativos são normalmente encontrados na área corporativa: Citrix, Avecto, lumens, além de confiança e NVIDIA.
Solução
1
O ENS tem um processo chamado MFECanary.exe que é executado como um processo MFEEsp.exe filho e captura detalhes do certificado digital para qualquer DLL que tente injetar-se nele. As informações são enviadas ao ePO por meio de um evento do agente, que é processado no servidor ePO. Ele será então preenchido para a política de Em Comum do ENS.
Quando você vê que os certificados são preenchidos na política de Em Comum do ENS, é uma indicação de que um software de terceiros não confiável existe no ambiente. Este software está tentando carregar DLLs ativamente em nossos processos. Se eles obtiverem êxito, sua presença dentro de nossos processos leva às instruções de problema descritas acima.
Na política de Em Comum do ENS, uma caixa de seleção permite que o administrador controle se os sistemas clientes confiam ou não confiam no certificado de terceiros. A mesma política permite que você adicione certificados manualmente para serem confiáveis, usando o certificado exportado ( .cer ) da DLL de injeção.
Para sistemas com o VSE, não existe nenhum método automatizado para confiar em uma DLL de injeção. Mas, a partir do lançamento do VSE 8.8 patch 9, a política de proteção de acesso para o VSE contém uma exclusão global para a guia autoproteção. Nessa guia, você pode excluir processos que são afetados por meio de uma injeção de DLL de terceiros. Para ter mais controle sobre os aplicativos que injetam em nossos processos, os clientes são encorajados a migrar para o ENS.
Solução
2
Ajuda do suporte técnico:
Suporte técnico também pode ajudar a identificar o terceiro e, posteriormente, confiar em um certificado digital de terceiros de DLLs assinadas de terceiros que injetam em nossos processos. Esse suporte exige que você abra uma solicitação de serviço. Para agilizar o processamento, as etapas para chegar a essas tarefas são fornecidas neste artigo.
Sumário Clique para expandir a seção que você deseja exibir:
Há um utilitário disponível no Suporte técnico nomeado MfeSysPrep.exe . Você pode executar MfeSysPrep.exe independente em qualquer sistema de destino para a descoberta do injetador de dll, distribuído por meio de ferramentas de terceiros ou distribuído por meio do ePO. A ferramenta grava um log arquivo localmente e envia eventos do ePO para DLLs identificadas e não confiáveis que podem afetar as funções do ENS.
Para cada injetador identificado e certificado digital correspondente, se julgarmos que o certificado específico é confiável, a ferramenta atualiza o ENS automaticamente para confiar no certificado. Se a ferramenta não descobrir nenhuma dll não confiável pendente, nenhuma ação adicional será necessária. Consulte a seção "informações relacionadasa" deste artigo para obter as implicações de confiar em um certificado de terceiros.
Para cada dll não confiável e assinada identificada, as informações do certificado são capturadas no registro e fornecidas ao ePO em um evento. A ID do evento é 1092 ou 1095. Para cada DLL não confiável e não assinada identificada, uma hash SHA-1 e SHA-2 é registrada para aquela dll no registro e fornecida ao ePO em um evento. Novamente, a ID do evento é 1092 ou 1095.
A ID de evento 1092 indica que um injetador foi encontrado e não é possível confiar nele.
A ID de evento 1095 indica que um injetador foi encontrado e nós podemos confiar nele automaticamente.
Essa identificação é, provavelmente, a tarefa mais difícil de todo o processo. O motivo é que o método para coletar essas informações depende de você estar tendo sintomas que afetem o comportamento do produto. Consulte as seções a seguir sobre como coletar dados quando há "nenhum sintoma adverso" e "sintomas negativos."
Nenhum sintoma adverso:
Use o Explorer de processo, disponível no Microsoft.
Execute a ferramenta como administrador.
Selecione o processo que tem a DLL de terceiros dentro dela.
Use a exibição de DLL ou pressione CTRL + D e identifique a DLL de terceiros, anotando sua localização no disco. Se houver vários locais, observe todos eles.
Use Windows Explorer para localizar essa dll no disco e acessar suas Propriedades.
Consulte obtenção do arquivo a .cer seguir.
Sintomas adversos:
Quando os sintomas negativos ocorrem durante uma seção de Windows, há dois pontos de dados a serem coletados. Esses pontos de dados devem, idealmente, ser coletados em paralelo; ou seja, execute as duas ferramentas ao mesmo tempo e Capture o problema uma vez.
Coletar dados do monitor do processo:
Use o Monitor de processo, disponível em Microsoft.
Execute a ferramenta como administrador.
Inicie o processo que está se comportando inesperadamente.
Depois que Ele reproduziu o comportamento anormal, salve a Procmon captura.
IMPORTANTE:Salve todos os eventos e use o formato de PML nativo.
Forneça essas informações paro Suporte técnico para ajudar na identificação da DLL de terceiros carregada por meio do processo.
Inicie o processo que está se comportando inesperadamente.
Depois que Ele reproduziu o comportamento anômala, execute AMTrace novamente, agora oferecendo a opção de parar.
Forneça o registro criado paro Suporte técnico. O arquivo de log ajuda a identificar a DLL não confiável.
Quando os sintomas adversos ocorrem apenas em Windows inicialização/inicialização, há dois pontos de dados a serem coletados, que podem ser coletados em série ou em paralelo:
Coletar dados do monitor do processo:
Use o Monitor de processo, disponível em Microsoft.
Execute a ferramenta como administrador.
No menu opções, clique em Ativar registro de inicialização.
Redefina o VTP cache *.
Reinicialize o sistema.
Entre e execute o Monitor de processo novamente.
Salve a captura do registro de Procmon inicialização.
IMPORTANTE:Salve todos os eventos e use o formato de PML nativo.
Forneça essas informações paro Suporte técnico para ajudar na identificação da DLL de terceiros carregada por meio do processo.
Depois que Ele reproduziu o comportamento anômala, execute AMTrace novamente, agora oferecendo a opção de parar.
Forneça o registro criado paro Suporte técnico. O arquivo de log ajuda a identificar a DLL não confiável.
* Para redefinir a cache do VTP:
A partir de um prompt de comando administrador, vá para \Program Files\Common Files\McAfee\SystemCore .
Execute o VTPInfo.exe utilitário com o parâmetro /resetvtpcache :
VTPInfo.exe /ResetVTPCache
Obtenha o .cer arquivo:
Esse procedimento é necessário somente se você executar a opção 2 para identificar as DLLs não confiáveis de terceiros. A obtenção do arquivo não será necessária se você usar a .cer opção 1.
Para acessar as propriedades do arquivo EXE ou DLL, clique com o botão direito do mouse e selecione Propriedades.
Clique na guia certificados digitais .
NOTA:Se essa guia estiver ausente, a arquivo não será assinada digitalmente e não há a opção de confiar no código deste fornecedor. Você deve entrar em contato com o fornecedor e solicitar que eles forneçam um código assinado.
Selecione um certificado na lista de assinaturas na qual você deseja confiar.
Clique em detalhes.
Clique em Exibir certificado.
Clique na guia detalhes .
Clique em copiar para arquivo.
No Assistente para exportação de certificados, clique em Avançar.
Clique em Avançar novamente para aceitar a criação de .cer arquivo.
Especifique um nome de arquivo e um local. Por exemplo, C:\Temp\My3rdParty.cer .
Clique em Avançar e em concluir.
Se você usar a opção 1 acima e nenhuma outra dll não confiável for encontrada, nenhuma ação adicional será necessária.
Para DLLs assinadas e não confiáveis , espera-se que o certificado digital desse dll seja exibido na política de em comum do ens. Nesse caso, consulte a solução 1. Use a política de opções de Em Comum do ENS para confiar no certificado manualmente se um dos seguintes Contentos for verdadeiro:
O certificado não apareceu nessa política.
Você deseja mover o processo da maneira mais previsível, depois de obter o ( .cer) arquivo.
IMPORTANTE:Antes de fazer isso, consulte a seção "informações relacionadasa" deste artigo para as implicações de confiar em um certificado de terceiros.
Para DLLs não confiáveis e não assinadas , esperamos que o fornecedor desse software forneça código assinado digitalmente, pois ele é um padrão industrial para a identificação de software lançado. Nos casos em que os fornecedores não podem ou não estão em conformidade, Suporte técnico podem ajudá-lo. Você precisa fornecer quaisquer DLLs não assinadas que MfeSysPrep.exe sejam identificadas como injetadores e o MfeSysPrep log que mostra a injeção. Usando essas informações, consideramos a adição da DLL não assinada dentro do MfeSysPrep utilitário, para ajudar com problemas como instalações com falha do ens devido à presença do aplicativo de terceiros. Ele não inclui aplicativos como software antivírus que atendam à mesma função que o ENS.
Importante: Para que a relação de confiança possa ser adicionada a uma DLL de terceiros, você deve enviar a DLL para McAfee Labs como uma amostra para confirmar que ela não é maliciosa. Para obter instruções, consulte KB85567-envie um potencial falso positivo do produto ou por meio do GTI para o Labs. Inclua as seguintes informações ao enviar as amostras de DLL a seguir:
Fabricante do software
Executável ou processo pai
Este aplicativo está interno ou publicamente disponível?
Breve descrição da função e do objetivo do software, incluindo a DLL enviada
Informações relacionadas
Implicações de segurança ao confiar em um certificado digital de terceiros:
Há implicações de segurança que você aceita ao confiar em um certificado de terceiros:
Você aceita que qualquer código assinado pelo certificado de terceiros seja confiável para interagir com nossos processos, arquivos, registro e todos os outros objetos protegidos.
Você aceita que arquivo atividade gerada por processos assinados com o certificado de terceiros não possa ser varrida.
Você compreende que qualquer lançamento de produto ou código do mesmo fornecedor, se estiver usando o mesmo certificado digital, herdará automaticamente as mesmas bonificações.
Você compreende que qualquer lançamento de produto ou código do mesmo fornecedor, usando um certificado digital diferente, também precisa ser confiável para alcançar os mesmos resultados.
Se você for um usuário registrado, digite sua ID de usuário e senha e, em seguida, clique em efetuar login.
Se você não for um usuário registrado, clique em registrar e preencha os campos para ter sua senha e suas instruções enviadas por e-mail para você.
Aviso de isenção de responsabilidade
O conteúdo original deste artigo foi redigido em inglês. Se houver diferenças entre o conteúdo em inglês e sua tradução, o conteúdo em inglês será o mais exato. Parte deste conteúdo foi criado por meio de tradução automática da Microsoft.