Autor: Edsel Valle
Os produtos avançados de proteção de terminal (AEP) são responsáveis por detectar e prevenir ameaças, bem como fornecer relatórios em nível forense sobre eventos de segurança. Esses produtos criam barreiras que podem ser difíceis de escapar. No entanto, ao invés de encontrar uma maneira de contornar essas barreiras, um atacante pode optar por quebrar ou remover completamente as barreiras, razão pela qual os produtos de AEP devem implementar salvaguardas que impeçam a adulteração do próprio produto.
Este ano, o NSS Labs introduziu uma categoria de proteção contra adulteração em nossa metodologia de teste AEP v3.0 [1] para avaliar a eficácia das medidas de segurança projetadas para impedir adulteração de recursos chave do produto, como prevenção de ameaças. Durante esse teste de proteção contra violação, foram descobertas vulnerabilidades de injeção de código. Como resultado, a NSS reteve completamente os resultados anti-adulteração da publicação do Teste 2019 do Grupo AEP em 5 de março, a fim de dar aos fornecedores tempo para remediar.
As técnicas comuns de proteção contra adulterações empregadas pelos produtos da AEP incluem:
Restringir o acesso não autorizado ou a modificação de recursos do produto, como arquivos, diretórios, chaves do Registro, processos e serviços. Esse tipo de proteção é referido pelos produtos de AEP de várias maneiras, incluindo “self-protection”, “self-defense”, “amper protection” ou “anti-tamper protection”.
Empregar controles de acesso, como senha, código de autorização único ou outras credenciais para administração local de produtos
Sempre que possível, iniciar serviços de produtos como serviços protegidos contra malware no Microsoft Windows 8.1 e posterior, para proteger processos contra injeção de código, encerramento de processos e outros ataques por processos administrativos.
Vinte e um produtos AEP foram implantados em máquinas virtuais Windows 10 RS1 de 64 bits e Windows 7 SP1 de 32 bits sem patches para o teste de grupo AEP v3.0. As políticas do produto foram configuradas para refletir a política de proteção “padrão empresarial” ou “padrão” para cada produto AEP. Os testes de proteção contra violação foram executados sob a suposição de que um invasor obteve privilégios de administrador em uma máquina vítima, o que é uma suposição razoável, já que usuários locais totalmente privilegiados são comuns em organizações e que um invasor com execução de código com poucos privilégios pode usar uma exploração de escalonamento de privilégios locais para adquirir privilégios de administrador. [3]
Para cada produto, o NSS primeiro determinou se a funcionalidade de prevenção de ameaças poderia ser desativada usando os seguintes métodos de violação (identificados pelo número do método de adulteração):
Desative a proteção através da funcionalidade de gerenciamento de política local do produto, às vezes disponível na UI do terminal, sem usar credenciais.
- Encerre os processos do produto por meio da função TerminateProcess da API do Windows ou pare os serviços do produto por meio das funções de serviço da API do Windows.
- Desinstale o produto através de “Programas e Recursos” no Painel de Controle do Windows ou usando um desinstalador incluído com o produto sem usar credenciais.
A funcionalidade de prevenção contra ameaças de um produto AEP foi considerada desativada se o NSS pudesse executar com êxito uma carga maliciosa que o produto bloqueava antes de adulterar.
O NSS realizou mais testes para determinar se o código poderia ser injetado em um ou mais processos do produto usando métodos como criação remota de threads e carregamento inseguro de bibliotecas. [1] Após injeção de código bem-sucedida, o NSS avaliou se o processo injetado poderia acessar ou modificar recursos do produto AEP que normalmente são inacessíveis devido a medidas de autoproteção (por exemplo, modificar o conteúdo do diretório de instalação, encerrar processos do produto e / ou fazer modificações no registro). O NSS também verificou se a funcionalidade de prevenção de ameaças pode ser desativada no processo.
Nosso teste de proteção contra adulteração produziu os seguintes resultados:
Alguns dos produtos de AEP que não impediram os métodos de adulteração 1, 2 ou 3 os impediriam, se as medidas de autoproteção e/ou as senhas anti-violação tivessem sido ativadas por padrão. Certifique-se de confirmar que sua política está configurada para fornecer o nível de proteção esperado.
A NSS descobriu algumas medidas anti-adulteração que foram implementadas apenas parcialmente. Por exemplo, um produto exigiu uma senha durante a desinstalação usando “Programas e Recursos” no Painel de Controle do Windows, mas não durante a desinstalação usando um desinstalador incluído.
Menos de metade dos produtos AEP lançaram um dos seus serviços como um serviço protegido anti-malware, e dos poucos que o fizeram, a maioria foi concebida de uma forma que tornava desnecessária a violação dos serviços protegidos designados, a fim de desativar a prevenção de ameaças.
No Windows 10, quase todos (18 de 21) produtos AEP foram considerados vulneráveis a alguma forma de injeção de código, em cada caso levando à desativação de sua funcionalidade de prevenção de ameaças.
Os três fornecedores que não eram vulneráveis às técnicas de adulteração de injeção de código no Windows 10 também foram testados no Windows 7, onde as técnicas foram bem-sucedidas. Nesses casos, os fornecedores responderam que isso se deve a uma deficiência no sistema operacional, e não a um problema com o próprio produto.
No interesse da divulgação responsável das vulnerabilidades de injeção de código descobertas, os fornecedores foram notificados com instruções detalhadas sobre como reproduzir os problemas descobertos e receberam pelo menos 90 dias para remediar antes da divulgação pública. A Figura 1 resume todas as respostas e resultados de fornecedores:
* Embora a criação remota de threads não seja uma vulnerabilidade, é um recurso do Windows que deve ser protegido.
** Fornecedores com produtos que eram apenas vulneráveis a injeção de código no Windows 7 forneceram feedback de que, nesses casos, há uma deficiência no sistema operacional, e não um problema com o próprio produto.
A maioria dos fornecedores de AEP no teste reconheceram as vulnerabilidades de injeção de código e forneceram correções aos clientes em tempo hábil e, em alguns casos, os CVEs foram atribuídos. Algumas exceções a serem observadas:
Dois fornecedores (F-Secure e Symantec) rejeitaram os problemas relatados, alegando que são necessários privilégios de administrador. Dessa forma, esses fornecedores não consideram os problemas como vulnerabilidades. A Symantec também informou que removeu algum código legado que permitia a manifestação do problema.
Dois fornecedores (ESET e G DATA) não responderam apesar de várias tentativas de estabelecer comunicação com vários pontos de contato. Nos dois casos, o NSS recebeu apenas respostas automatizadas.
A NSS está ciente das seguintes alterações específicas feitas pelos fornecedores de AEP para seus produtos em resposta aos resultados do teste de proteção contra adulteração:
Um fornecedor alterou o recurso de autoproteção de arquivos do produto de desativado por padrão para ativado.
Um fornecedor fez melhorias gerais no recurso de autoproteção de seu produto.
Um fornecedor implementou serviços protegidos contra malware.
Os produtos de AEP devem proteger contra ameaças antigas e novas ameaças avançadas. As tecnologias atuais usadas para proteção contra adulteração por produtos AEP são suficientes para proteger contra métodos básicos de violação usados por malwares comuns, presumindo que todos os recursos de autoproteção estejam ativados. O mesmo não pode ser dito quando se lida com métodos de violação mais avançados que possam ser usados em ataques direcionados avançados. Todos os fornecedores de AEP devem procurar melhorar sua proteção contra adulteração, uma vez que as empresas a consideram uma característica essencial de um produto de terminal.
O NSS Labs publicou os resultados do Teste do Grupo AEP v3.0 em março de 2019. Os resultados dos testes estão disponíveis para os assinantes da nossa Biblioteca de Pesquisas. Para perguntas ou comentários relacionados a este relatório, envie-nos um e-mail para info@nsslabs.com.
[1] O termo “carregamento inseguro de biblioteca” é usado aqui como um todo para pré-carregamento de DLL, sequestro de ordem de pesquisa de DLL, carregamento lateral de DLL ou similar.
[1] https://research.nsslabs.com/library/methodologies/aep-test-methodology-v3.0/
[2] https://docs.microsoft.com/pt-br/windows/win32/services/protecting-anti-malware-services-
[3] No Teste do Grupo AEP v3.0 (https://www.nsslabs.com/advanced-endpoint-protection-aep-security-value-map), 17 dos 21 produtos não forneceram proteção para pelo menos um exploração de escalonamento de privilégios locais disponível publicamente.
Traduzido do original em: https://www.nsslabs.com/blog-posts/2019/7/24/your-advanced-endpoint-protection-aep-product-protects-your-computer-but-can-it-protect-itself
