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, em vez de contornar essas barreiras, um atacante pode simplesmente quebrá-las ou removê-las por completo. É por isso que os produtos de AEP precisam implementar salvaguardas contra a adulteração do próprio produto.
Este ano, o NSS Labs introduziu uma categoria de proteção contra adulteração em sua metodologia de teste AEP v3.0 [1]. O objetivo é avaliar a eficácia das medidas de segurança que impedem a adulteração de recursos-chave do produto, como a prevenção de ameaças. Durante esse teste de proteção contra violação, a equipe descobriu vulnerabilidades de injeção de código. Como resultado, a NSS reteve por completo os resultados anti-adulteração da publicação do Teste 2019 do Grupo AEP, de 5 de março, para dar tempo aos fornecedores de corrigirem os problemas.
As técnicas comuns de proteção contra adulterações empregadas pelos produtos da AEP incluem:
Como o NSS Labs testou a proteção contra adulteração
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. Os produtos de AEP chamam esse tipo de proteção de várias maneiras, incluindo “self-protection”, “self-defense”, “tamper 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.
Metodologia do teste NSS Labs
Para o teste de grupo AEP v3.0, o NSS Labs implantou vinte e um produtos AEP em máquinas virtuais. A equipe usou Windows 10 RS1 de 64 bits e Windows 7 SP1 de 32 bits, ambos sem patches. A equipe configurou as políticas de cada produto para refletir a política de proteção “padrão empresarial” ou “padrão”. Os testes de proteção contra violação partiram da suposição de que um invasor já obteve privilégios de administrador na máquina vítima. Trata-se de uma suposição razoável, já que usuários locais totalmente privilegiados são comuns em organizações, e um invasor com execução de código de baixo privilégio pode escalar privilégios até virar administrador. [3]
Critérios de avaliação da funcionalidade anti-adulteração
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.
O NSS considerou desativada a funcionalidade de prevenção contra ameaças de um produto AEP sempre que conseguiu executar com êxito uma carga maliciosa que o produto normalmente bloqueava antes da adulteração.
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 uma injeção de código bem-sucedida, o NSS avaliou se o processo injetado conseguia acessar ou modificar recursos do produto AEP normalmente protegidos por medidas de autoproteção. Isso incluía, por exemplo, alterar o conteúdo do diretório de instalação, encerrar processos do produto ou modificar o registro. O NSS também verificou se a funcionalidade de prevenção de ameaças pode ser desativada no processo.
Resultados dos testes de adulteração
Nosso teste de proteção contra adulteração produziu os seguintes resultados:
Alguns produtos de AEP que não impediram os métodos de adulteração 1, 2 ou 3 teriam impedido esses ataques se as medidas de autoproteção e as senhas anti-violação estivessem 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 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 da metade dos produtos AEP lançou algum dos seus serviços como serviço protegido anti-malware. Entre os poucos que o fizeram, a maioria foi concebida de um jeito que tornava desnecessário violar esses serviços protegidos para desativar a prevenção de ameaças.
No Windows 10, o NSS considerou vulneráveis a alguma forma de injeção de código quase todos os produtos AEP (18 de 21). Em cada caso, isso desativou a funcionalidade de prevenção de ameaças do produto.
A NSS também testou no Windows 7 os três fornecedores que resistiram às técnicas de injeção de código no Windows 10. Nesse sistema mais antigo, porém, as técnicas de adulteração funcionaram. 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.
Seguindo a prática de divulgação responsável, a NSS notificou os fornecedores com instruções detalhadas para reproduzir as vulnerabilidades de injeção de código encontradas. Cada fornecedor recebeu pelo menos 90 dias para corrigir os problemas antes da divulgação pública. A Figura 1 resume todas as respostas e resultados de fornecedores:
Divulgação responsável e resposta dos 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 reconheceu as vulnerabilidades de injeção de código e forneceu correções aos clientes em tempo hábil; em alguns casos, os pesquisadores atribuíram CVEs às falhas. 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.
Atualizações dos fornecedores após o teste
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, que estava desativado por padrão, e passou a ativá-lo.
Outro fornecedor fez melhorias gerais no recurso de autoproteção de seu produto.
Um terceiro fornecedor implementou serviços protegidos contra malware.
Conclusão
Os produtos de AEP devem proteger contra ameaças antigas e novas ameaças avançadas. As tecnologias atuais de proteção contra adulteração dos produtos AEP bastam para bloquear os métodos básicos de violação usados por malwares comuns. Isso vale, porém, apenas quando todos os recursos de autoproteção estão ativados. O mesmo não vale para métodos de violação mais avançados, que atacantes podem empregar em ataques direcionados sofisticados. 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.
Referências
[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
