Embora uma parte fundamental da resiliência cibernética seja a adaptação às mudanças tecnológicas, é igualmente crítico abordar as superfícies de ataque que permaneceram constantes. Isso ocorre porque a maioria das empresas manteve uma quantidade significativa de infraestrutura legada, além de cargas de trabalho em nuvem e aplicativos SaaS mais recentes. Às vezes, isso se deve ao custo operacional da migração, bem como a preocupações sobre a possibilidade de quebrar processos críticos ao fazê-lo. Em outros casos, isso ocorre simplesmente porque a equipe de TI nem sequer tem conhecimento da existência dos componentes legados. Mas seja qual for o motivo, a infraestrutura legada é um alvo adequado para os agentes de ameaças, pois é sempre menos segura do que as suas alternativas modernas. 

Nesta postagem exploramos um exemplo proeminente de infraestrutura legada: o protocolo de autenticação NTLMv1. Esta versão inicial do NTLM incluía falhas críticas de segurança, permitindo que os invasores executassem uma variedade de ataques baseados em identidade. E embora já tenha mais de 30 anos, ainda pode ser encontrado em ambientes de produção, expondo-os a riscos de comprometimento que são extremamente difíceis de detectar.

Mostraremos então como Silverfort permite que as empresas superem os riscos do NTLMv1 com descoberta, monitoramento e controle em cada autenticação e tentativa de acesso que ainda utiliza esse protocolo arcaico. 

Autenticação NTLM: uma breve história

De acordo com o Wikipedia, "Em um Windows rede, o New Technology LAN Manager (NTLM) é um conjunto de Microsoft protocolos de segurança destinados a fornecer autenticação, integridade e confidencialidade aos usuários. NTLM é o sucessor do protocolo de autenticação da Microsoft Gerenciador de LAN. O conjunto de protocolos NTLM é implementado em um Provedor de suporte de segurança, que combina o Gerenciador de LAN protocolos de autenticação NTLMv1, NTLMv2 e NTLM2 em um único pacote.” (NTLM2 combina NTLMv1 e NTLMv2.) 

NTLMv1 foi lançado em 1993 e é um protocolo de autenticação de resposta a desafio, o que significa que o processo de autenticação é realizado em três etapas: 

1. A máquina cliente estabelece uma conexão de rede com o servidor de destino.
2. O servidor envia um desafio para a máquina cliente.
3. A máquina cliente responde ao desafio e o servidor permite ou nega o acesso com base na resposta.

Em 1998, o NTLMv2 foi lançado no Windows NT 4.0 SP 4 e tem sido a versão atual do protocolo desde então.

Problemas gerais de segurança NTLM

Todas as versões da autenticação NTLM enfrentam os seguintes problemas de segurança:

1. Falta de salga torna o hash equivalente à senha, o que significa que se você conseguir obter o valor do hash do servidor, poderá autenticar sem saber a senha real. Isso significa que um invasor que consegue recuperar um hash – e há várias maneiras de despejá-lo da memória da máquina – pode então acessar facilmente um servidor de destino e se passar pelo usuário real.
2. Embora o servidor realmente valide a identidade do cliente, não há validação correspondente da identidade do servidor, o que abre a possibilidade de um ataque Man-In-The-Middle (MITM).
3. O NTLMv1 não possui um desafio de cliente – no caso de um ataque ao NTLMv1, o invasor pode forçar o cliente a calcular a resposta NTLMv1 com um desafio de servidor conhecido. Então, o invasor pode adivinhar com eficiência a senha do usuário, verificando a resposta NTLMv1 em relação a um mesa arco-íris.
4. Falta de MFA o suporte priva o protocolo de qualquer proteção no caso de uma senha ou hash comprometida. 

Essas preocupações levaram a Microsoft a substituir o NTLM pelo mais seguro Kerberos protocolo de autenticação como padrão em ambientes AD, embora mantendo o NTLM como backup. Mas mesmo dentro do NTLM, o NTLMv1 é significativamente menos seguro que seu sucessor, o NTLMv2.

O que torna o NTLMv1 um risco à segurança

O nível de segurança do protocolo depende do desafio – quanto mais difícil de comprometer, mais segura será a autenticação. 

No caso do NTLMv1, a diferença está nos desafios específicos:

1. O NTLMv1 produz um desafio com um número de comprimento fixo de 16 bits, enquanto o NTLMv2 produz desafios de comprimento variável.
2. O NTLMv1 usa um algoritmo de criptografia DES fraco que é rápido para descriptografar, tornando-o vulnerável à força bruta, enquanto o NTLMv2 usa o HMAC-MD5 mais lento que pode resistir melhor a esses ataques, já que a descriptografia não pode ocorrer em tempo real. 

Qualquer sistema que utilize autenticação NTLMv1 está, portanto, exposto a comprometimento, uma vez que os invasores podem facilmente criar uma maneira de aceitar o desafio e, assim, obter acesso ao sistema. 

Com isso em mente, é fácil entender por que as equipes de TI e segurança desejam abandonar o NTLMv1. Em teoria, parece fácil – basta encontrar todos os sistemas que usam NTLMv1 e mudar para um protocolo mais seguro. Na prática, porém, é muito mais desafiador.

Obstáculos na detecção e remoção de NTLMv1

Em um mundo ideal, haveria algum filtro que, ao ser clicado, revelaria todas as autenticações NTLMv1 que ocorrem em um ambiente. Infelizmente, a realidade não é tão simples.

O caminho mais direto é habilitar a auditoria de sucesso de logon no controlador de domínio. De acordo com a documentação da Microsoft, cada endpoint deve então gerar um evento com as informações necessárias (Evento de auditoria de sucesso 4624, que contém informações sobre a versão do NTLM. Os logs de eventos recebidos contêm um campo 'Nome do pacote (somente NTLM)' que indica o NTLM versão). No entanto, a coleta desses logs não pode ser feita centralmente no controlador de domínio e deve ser recuperada de cada máquina individual. Além disso, em muitos casos o evento não possui os dados da versão NTLM ou nem mesmo foi criado. 

Além disso, na maioria dos casos, o NTLMv1 é encontrado em um aplicativo legado onde a autenticação NTLMv1 é executada no servidor do aplicativo. Como tal, não há garantia de que o programador que codificou a aplicação tenha implementado um mecanismo de auditoria sólido. Se a aplicação utilizar um servidor Windows, ela poderá ser parcialmente auditada localmente, por exemplo, se utilizar bibliotecas internas do Windows, como autenticação IIS (aplicação de servidor Web). No entanto, se o aplicativo for totalmente escrito por terceiros, nenhum log será auditado. Nesse caso, não há como descobrir se o NTLMv1 está em uso sem etapas intrusivas (como descriptografar os pacotes ou analisar o código real do aplicativo).

Embora as autenticações NTLMv1 possam ser detectadas parcialmente usando a inspeção em nível de rede, tal inspeção não é possível, pois na maioria dos casos esse tráfego é criptografado.

Portanto, o desafio reside não apenas na insegurança inerente ao próprio NTLMv1, mas também na dificuldade de determinar se ele está sendo usado em um determinado ambiente. 

SilverfortProteção do para a superfície de ataque NTLMv1

A Silverfort Proteção de identidade unificada A plataforma oferece às organizações a capacidade única não apenas de descobrir todas as autenticações NTLMv1 em um ambiente, mas também de bloqueá-las ativamente. 

Silverfort O mecanismo de análise detecta autenticações NTLMv1 e as sinaliza como um indicador de risco. Este indicador de risco pode ser utilizado tanto como filtro para descobrir máquinas que realizam tais autenticações, quanto como gatilho de política de acesso. Vamos ver como fica dentro do Silverfort console:

Discovery

Na tela Logs de autenticação, marque a caixa Autenticação NTLMv1. Depois de marcadas, todas as autenticações correspondentes serão exibidas, fornecendo conhecimento prático sobre quais máquinas estão usando NTLMv1 para ajudar a decidir se devem ser desativadas.

NTLMv1 habilitado em SilverfortTela de logs de autenticação

pós-colheita 

De maneira semelhante, Silverfort permite o uso de um indicador de risco NTLMv1 como gatilho para ativar uma política de acesso. A ação seria então:

• Denegar: escolha esta opção se não quiser permitir o NTLMv1 no ambiente como medida de precaução adicional.
  

Silverfort política para negar acesso via NTLMv1

• MFA: escolha esta opção se, por algum motivo, você não puder eliminar o uso do NTLMv1 (por exemplo, se houver um aplicativo antigo que possa quebrar e colocar em risco processos críticos de negócios). Neste caso, mesmo que o fluxo de autenticação esteja comprometido, o verdadeiro utilizador deve verificar a sua identidade através de MFA para obter acesso, desarmando efetivamente a capacidade dos atacantes de aproveitarem as fraquezas do protocolo para acesso malicioso.
  

Silverfort política para exigir intensificação de MFA ao autenticar via NTLMv1

O caminho para uma segurança abrangente

No ambiente híbrido atual, existem muitos tipos de sistemas lado a lado, portanto, segurança abrangente significa monitorar e proteger todos eles. NTLMv1 é apenas um exemplo dos problemas com sistemas legados; também é importante compreender que quando a fraqueza da segurança reside na infra-estrutura legada, um compromisso aqui pode permitir que os atacantes obtenham acesso também a outras partes do ambiente. A maneira correta de pensar nisso não é tanto proteger os sistemas legados, mas sim evitar que os sistemas legados se tornem a porta de entrada para o seu ambiente. 

Silverforté unificado Proteção de identidade é a primeira plataforma desenvolvida especificamente para proteger contra ameaças de identidade em toda a empresa híbrida – seja o recurso direcionado um aplicativo SaaS, uma carga de trabalho em nuvem ou um servidor local. Silverfort estende a MFA e a segurança de identidade moderna a todos os recursos principais que não podiam ser protegidos antes – incluindo NTLMv1.

NTLMv1 é um superfície de ataque você quer abordar? Agende uma reunião com um de nossos especialistas SUA PARTICIPAÇÃO FAZ A DIFERENÇA.