Às custas da VPN: análise de técnicas pós-exploração de VPN
Resumo executivo
Nesta publicação do blog, os pesquisadores da Akamai destacam a ameaça ignorada de pós-exploração de VPN, ou seja, abordamos técnicas que podem ser usadas por agentes de ameaça para aumentar ainda mais sua invasão após comprometer um servidor de VPN.
Nossas descobertas incluem diversas vulnerabilidades que afetaram as VPNs Ivanti Connect Secure e FortiGate.
Além das vulnerabilidades, detalhamos um conjunto de técnicas sem correções que podem afetar os produtos Ivanti Connect Secure e FortiGate e possivelmente outros servidores de VPN.
Nossa pesquisa mostra que, em muitos casos, um servidor de VPN comprometido pode permitir que os invasores consigam o controle facilmente sobre outros ativos críticos na rede.
Este post de blog tem como objetivo aumentar a conscientização sobre esses riscos e apresenta as melhores práticas que devem ser seguidas pelos defensores para minimizar os riscos das técnicas de pós-exploração de VPN.
Introdução
Todos já ouviram esta história: Uma vulnerabilidade crítica é descoberta em um servidor de VPN. Ela é explorada em sistemas reais. Os administradores se apressam em aplicar patches. O pânico se espalha pelas mídias sociais.
No ano passado, era muito difícil para a segurança de VPN, parecia que um mês após outro uma vulnerabilidade crítica fosse descoberta ou corrigida após a exploração em sistemas reais por agentes de ameaça. Embora tenha sido observado um aumento significativo nesse tipo de atividade em 2023, isso não é novo. Os invasores procuram explorar servidores de VPN há muito tempo, pois eles são acessíveis pela Internet, expõem uma superfície de ataque rica e muitas vezes não têm segurança e monitoramento.
Historicamente, os servidores de VPN têm sido invadidos para alcançar um único objetivo principalmente: o acesso inicial. Com isso, os invasores comprometem o servidor de VPN voltado para a Internet e o utilizam para conquistar espaço na rede interna e realizar as invasões.
Embora essa abordagem seja muito eficaz, nós nos perguntamos: O controle sobre um servidor de VPN deve ser visto apenas como um gateway para a rede?
Queríamos ver o que mais poderia ser possível.
A publicação no blog a seguir explora técnicas de pós-exploração de VPN que podem ser usadas por um invasor que tenha comprometido um servidor de VPN por outros meios (vulnerabilidades, credenciais furtadas etc.) para atingir outras metas.
Às custas da VPN
A principal abordagem que os agentes de ameaça usam para executar técnicas de pós-exploração é o direcionamento do SO do dispositivo. Depois de obter a execução remota de código (RCE), um invasor pode instalar um software malicioso personalizado no sistema operacional do dispositivo. A partir desse ponto, os agentes de ameaça podem controlar todos os aspectos da VPN, por exemplo, eles podem interligar funções para vazar informações confidenciais, tentar escapar da detecção por meio da manipulação de logs ou modificar a configuração do sistema para manter a persistência no dispositivo.
Essa abordagem tem muitas vantagens, mas tem com uma das principais desvantagens: é muito cara. Como os dispositivos geralmente são executados em um sistema operacional personalizado e reforçado, o esforço necessário para desenvolver e manter um software malicioso personalizado para um dispositivo VPN pode ser significativo. Por isso, as técnicas de pós-exploração de VPN são usadas normalmente apenas por agentes de ameaça sofisticados de estados-nação de nível superior.
Análise de uma abordagem diferente
Decidimos analisar uma abordagem diferente, uma maneira "mais fácil" de pós-exploração de VPN. Em vez de depender de um software malicioso personalizado executado no sistema operacional, decidimos usar uma funcionalidade existente do dispositivo. Nós nos perguntamos: O que um invasor pode fazer usando apenas a interface de gerenciamento da VPN?
Esta abordagem, que apelidamos de "vida fora da VPN", tem pelo menos duas vantagens.
Esse tipo de acesso pode ser mais fácil de obter do que o RCE completo. O acesso à interface de gerenciamento pode ser obtido por meio de uma vulnerabilidade de desvio de autenticação, credenciais fracas ou phishing.
Essa abordagem pode ser mais econômica, pois evitamos a necessidade de desenvolver uma carga maliciosa personalizada.
Como base de teste, optamos por dois dos principais servidores de VPN do mercado: Ivanti Connect Secure e FortiGate. Descobrimos 2 CVEs e um conjunto de técnicas sem correção que podem ser usadas por invasores que controlam o servidor de VPN para assumir outros ativos críticos na rede, o que pode transformar um comprometimento de VPN em um comprometimento total da rede.
Embora os nossos resultados se concentrem na FortiGate e na Ivanti, acreditamos que variações das técnicas encontradas sejam provavelmente relevantes para outros servidores de VPN e dispositivos de edge.
A invasão de servidores de autenticação remota
Alguns dos ativos de maior interesse tratados por um servidor de VPN são credenciais externas. Embora os servidores de VPN suportem o uso de usuários locais para autenticação, um servidor de autenticação externo é usado em muitos casos.
Em vez de manter um conjunto separado de credenciais por usuário, os administradores podem optar por usar um provedor de identidade existente para autenticar seus usuários. O usuário envia suas credenciais "normais" ao servidor de VPN, que são validadas por meio do servidor de autenticação remota (Figura 1).
Fig. 1: Uso de um servidor de autenticação remota para autenticar usuários
Vários tipos de servidores de autenticação podem ser usados para essa finalidade: as 2 principais opções são LDAP e RADIUS.
Identificamos algumas técnicas que podem permitir que os invasores capitalizem esse comportamento para comprometer essas credenciais externas, o que potencialmente fornece aos invasores acesso a recursos adicionais na rede.
Interceptação de credenciais LDAP
Uma opção de servidor de autenticação muito popular para VPNs é o LDAP, frequentemente integrado a um controlador de domínio do Active Directory (AD). Com essa configuração, os usuários podem acessar a VPN por meio de suas credenciais de domínio, o que torna essa opção muito conveniente.
Ao configurar um servidor de autenticação LDAP, são fornecidas credenciais de uma conta de serviço AD para permitir que a VPN consulte as informações do usuário. Um exemplo dessa configuração no FortiGate pode ser visto na Figura 2.
Fig. 2: Configuração do servidor de autenticação LDAP na GUI do FortiGate
Quando um usuário tenta se autenticar no FortiGate ou no Ivanti usando credenciais LDAP, a VPN o verifica entrando em contato com o servidor LDAP. A implementação exata varia um pouco entre os dois, então vamos examinar ambos.
Autenticação LDAP do FortiGate
Para validar as credenciais, o FortiGate tenta usá-las para se autenticar no servidor remoto. Este processo é realizado por meio de autenticação simples, isto é, o FortiGate envia a senha para o servidor em texto não criptografado (Figura 3).
Fig. 3: O vínculo simples de LDAP expõe a senha do usuário de texto não criptografado
Dois conjuntos de credenciais são transmitidos durante esse processo: as credenciais da conta de serviço LDAP configurada no FortiGate e as credenciais fornecidas pelo usuário de autenticação. Ambos são enviados em texto não criptografado.
Embora a configuração padrão seja LDAP, o FortiGate também suporta LDAPS e TLS, o que deve impedir a comunicação de texto não criptografado.
Autenticação LDAP do Ivanti
A implementação do Ivanti para a autenticação LDAP é ligeiramente diferente e suporta dois tipos de servidores de autenticação LDAP: LDAP normal e Active Directory (Figura 4).
Fig. 4: Opções de servidor de autenticação Ivanti, incluindo servidores LDAP e Active Directory
Servidor de autenticação LDAP
Com um servidor de autenticação LDAP, o processo é bastante semelhante ao processo do FortiGate, ou seja, quando o LDAP simples é usado, uma ligação simples é realizada e a conta de serviço do AD e as credenciais de usuário autenticadas são transmitidas em texto não criptografado (Figura 5).
Fig. 5: Credenciais LDAP de transmissão Ivanti em texto não criptografado
No entanto, ao configurar um servidor de autenticação LDAP, a configuração padrão é TLS. LDAPS também é suportado. Portanto, é menos provável que as instâncias do Ivanti usem LDAP simples.
Servidor de autenticação AD
O segundo tipo de servidor de autenticação LDAP que pode ser configurado é um servidor AD. Ao usar essa opção, a autenticação é realizada usando o Kerberos, o que significa que nenhuma senha é transmitida (Figura 6).
Fig. 6: Autenticação LDAP segura usando Kerberos
Captura de credenciais LDAP de texto não criptografado
Para FortiGate e Ivanti, quando o LDAP simples é usado para autenticar um usuário, qualquer credencial enviada à VPN pode ser comprometida. Esse comprometimento pode ser executado por um invasor que esteja entre a VPN e o servidor LDAP ou por um invasor que controle o servidor de VPN.
Como é possível capturar as credenciais sem instalar um software malicioso no dispositivo? Felizmente para nós, FortiGate e Ivanti incluem um recurso de captura de pacotes integrado. Ao usá-lo para capturar pacotes LDAP, um invasor pode interceptar todas as credenciais que passam pela VPN (Figura 7).
Fig. 7: Uso do recurso de captura de pacotes do FortiGate ou Ivanti para capturar comunicações LDAP
Nos casos em que um protocolo seguro é usado, nenhuma credencial de texto não criptografado é enviada do servidor. Apesar disso, um invasor que tenha controle sobre a VPN ainda pode capturá-las facilmente. Se controlarmos a VPN, não há nada que nos impeça de modificar a configuração e de rebaixar a configuração para LDAP simples.
Para servidores LDAP normais, podemos simplesmente alterar a configuração para LDAP simples. Para fazer o downgrade do servidor AD da Ivanti, podemos usar os detalhes de conexão AD para configurar um novo servidor LDAP normal em vez do existente. Em ambos os casos, essa alteração deve ser transparente para os usuários e fará com que a VPN envie as senhas em texto não criptografado.
Em resumo, é o seguinte: Se a autenticação LDAP for utilizada, independentemente da configuração, um invasor que comprometer a VPN poderá facilmente obter credenciais e se infiltrar no domínio.
Registro de um servidor de autenticação não autorizado
Como mencionamos, ao autenticar um usuário remoto, a VPN entrará em contato com o servidor de autenticação apropriado para validar as credenciais fornecidas. Identificamos um método que explora esse fluxo de autenticação para comprometer qualquer credencial fornecida por um usuário à VPN.
Essa técnica funciona registrando um servidor de autenticação não autorizado que será usado pela VPN ao autenticar usuários. Para ajudar você a entender como isso pode ser implementado, descreveremos primeiro alguns detalhes do processo de autenticação em ambas as VPNs.
Grupos de usuários FortiGate
Os usuários do FortiGate podem receber diferentes permissões e ter políticas distintas aplicadas a eles. Em vez de gerenciar cada usuário individualmente, os usuários podem ser incluídos em grupos de usuários; ou seja, conjuntos de usuários que podem ter políticas e permissões aplicadas a eles.
Ao configurar esse grupo, podemos incluir usuários de grupos remotos, ou seja, grupos que estão presentes em um servidor de autenticação remota. Por exemplo, podemos incluir usuários de um grupo específico do AD (Figura 8).
Fig. 8: Configuração do grupo de usuários FortiGate
Observamos um comportamento interessante que ocorre ao usar grupos remotos. Digamos que configuremos um grupo de usuários que inclua duas entidades: um usuário local FortiGate e um grupo remoto presente em um servidor LDAP.
Com relação à autenticação, esperamos o seguinte comportamento:
Quando o membro local do grupo se autentica no FortiGate, suas credenciais serão verificadas usando o banco de dados de usuários local do FortiGate.
Quando um membro do grupo remoto se autentica no FortiGate, suas credenciais serão verificadas usando o servidor LDAP do grupo remoto.
No entanto, ao que parece, isso não é exatamente o que acontece. Depois de adicionarmos um grupo remoto a um grupo de usuários, sempre que qualquer membro do grupo de usuários autentica, o FortiGate tentará validar suas credenciais usando o banco de dados de usuários local e o servidor de autenticação remota. Além disso, se adicionarmos mais de um servidor remoto a um grupo de usuários, o FortiGate tentará autenticar usuários usando todos os servidores de autenticação configurados.
Essencialmente, o FortiGate não corresponde a um usuário específico com seu método de autenticação apropriado, ele simplesmente tenta todos eles. Se houver sucesso, o usuário será autenticado.
Reinos de autenticação Ivanti
A Ivanti implementa um recurso semelhante aos grupos de usuários chamados reinos de autenticação. Ao contrário dos grupos de usuários do FortiGate, cada reino de autenticação do Ivanti é limitado a um único servidor de autenticação. Para gerenciar usuários de servidores diferentes, devem ser usados reinos separados.
Apesar dessa restrição (e convenientemente para nós), a Ivanti nos permite configurar um "servidor de autenticação adicional" (Figura 9). Esta opção destina-se a ativar determinadas configurações de SSO.
Fig. 9: Configuração de um servidor de autenticação adicional para um reino de usuário Ivanti
Quando um servidor de autenticação adicional é configurado, o Ivanti tentará validar as credenciais usando ambos os servidores. A autenticação será bem-sucedida somente se ambos os servidores a aprovarem.
Criação de um servidor de autenticação não autorizado para vazar credenciais
Um invasor pode explorar esses comportamentos para vazar as credenciais de qualquer usuário que se autentica para FortiGate ou Ivanti, usando qualquer tipo de servidor de autenticação remota. Ao adicionar um servidor de autenticação não autorizado a um grupo de usuários ou reino, podemos fazer com que o servidor de VPN vaze credenciais para um servidor controlado por invasor (Figura 10).
Fig. 10: Adição de um servidor de autenticação não autorizado para comprometer as credenciais de cliente
Essas credenciais podem ser de clientes que se conectem à VPN ou de administradores que se conectem à interface de gerenciamento. Qualquer autenticação gerenciada usando um grupo de usuários ou reino pode ser sequestrada por meio desse método.
Para implementar isso no FortiGate, criamos um grupo remoto que usa nosso servidor não autorizado e, em seguida, o adicionamos ao nosso grupo de usuários de destino. Com o Ivanti, simplesmente adicionamos nosso servidor não autorizado como um servidor de autenticação adicional para nosso reino de destino.
Agora, sempre que um membro do grupo de usuários/reino de destino autenticar, a VPN tentará validar suas credenciais usando nosso servidor (Figura 11).
Fig. 11: Adição de um servidor de autenticação RADIUS não autorizado a um grupo de usuários
Para capturar as credenciais, usaremos um servidor de autenticação RADIUS. Nesse cenário, a autenticação RADIUS é conveniente por dois motivos:
As credenciais são enviadas para o servidor durante a solicitação inicial sem primeiro verificar se o usuário existe no servidor.
As credenciais são enviadas para o servidor criptografado com uma chave determinada pelo invasor, permitindo que ele recupere as credenciais de texto não criptografado (Figura 12).
Fig. 12: Uma senha criptografada em uma mensagem de autenticação RADIUS
O seguinte script (baseado no RFC 2865) pode descriptografar senhas do RADIUS:
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
Uma nota final: Como dissemos, quando a Ivanti usa um servidor de autenticação adicional, ambos os servidores precisam aprovar o usuário para que a autenticação seja bem-sucedida. Se o nosso servidor não aprovar as credenciais fornecidas, os usuários não poderão se autenticar no Ivanti. Para evitar isso, precisamos garantir que nosso servidor RADIUS aprove todas as credenciais fornecidas, que podem ser facilmente configuradas.
Extração de segredos do arquivo de configuração
O que pode ser mais importante para a descoberta envolve arquivos de configuração de VPN.
Entre as várias configurações interessantes que podemos localizar nos arquivos de configuração, uma se destaca: segredos. As VPNs armazenam muitos segredos em sua configuração: senhas de usuário local, chaves SSH, certificados e, o mais interessante, credenciais de contas de serviço de terceiros.
Esses arquivos confidenciais podem ser obtidos por um invasor de duas maneiras principais:
Depois de obter controle sobre uma VPN, um invasor pode exportar a configuração do dispositivo por meio da interface de gerenciamento.
Um invasor pode localizar um arquivo de configuração exportado anteriormente, que foi salvo em um local público, como uma pasta compartilhada.
Para protegê-los, os segredos são armazenados no arquivo de configuração em uma forma criptografada. A Figura 13 mostra um exemplo de um segredo criptografado em um arquivo de configuração FortiGate.
Fig. 13: Uma senha criptografada dentro de um arquivo de configuração FortiGate
Agora, vamos descriptografar alguns segredos!
Descriptografia de segredos de um arquivo de configuração FortiGate
Pode-se pensar que os segredos são criptografados e, portanto, não podem ser recuperados, mas isso não pode ser o caso. Pense em senhas de integração, por exemplo, como a senha de texto não criptografado é necessária para a conexão com terceiros, ela precisa ser armazenada usando criptografia reversível.
Isso foi comprovado em uma postagem de blog por Bart Dopheide, que analisou o processo de criptografia de senha do FortiGate. A FortiGate usa AES para criptografar todos os segredos na configuração. Qual chave é usada para executar essa criptografia? Dopheide descobriu que uma única chave codificada é usada em todos os dispositivos FortiGate. Não foi possível alterar esta chave. A postagem original do blog não a compartilha, mas uma pesquisa rápida do Google o levará direto para ela.
A Fortinet atribuiu o código CVE 2019-6693 a esse problema e implementou uma correção ao permitir que os usuários alterem a chave codificada para uma personalizada.
Mesmo depois dessa correção, o problema ainda é muito relevante hoje. A chave não foi alterada, então por padrão, as soluções FortiGate ainda usam a mesma chave. Isso significa que, se um invasor conseguir obter um arquivo de configuração de uma solução FortiGate com a configuração padrão, ele poderá descriptografar todos os segredos armazenados no dispositivo. Esse código implementa o processo de descriptografia.
Está bem, mas e se o administrador da FortiGate tiver seguido a prática recomendada e usado uma chave personalizada em vez da padrão? Descobrimos que, se controlarmos a VPN, ainda poderemos obter facilmente os segredos.
A criptografia-de-dados-privada é usada para controlar a chave de criptografia personalizada. O que é surpreendente é que os administradores podem simplesmente desativar esse recurso. Isso não requer conhecimento da chave configurada no momento e reverterá a criptografia de todos os segredos de volta para a chave codificada original.
Revertendo a criptografia
Para reverter a criptografia, podemos usar os seguintes comandos de interface de linha de comando FortiGate:
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
Neste ponto, podemos baixar o arquivo de configuração e descriptografar os segredos usando a chave padrão conhecida (exatamente como foi mostrado anteriormente).
Muitos segredos interessantes podem ser comprometidos usando esse método. O FortiGate oferece suporte a integrações com vários aplicativos por meio do recurso "conector externo". Esses conectores têm vários objetivos, mas a maioria deles compartilha um aspecto importante: eles exigem credenciais para o aplicativo (Figura 14).
Fig. 14: Opções de conector externo FortiGate
Isto é, o FortiGate pode conter credenciais para serviços críticos, como provedores de nuvem, SAP, Kubernetes, ESXi e muito mais.
Em alguns casos, as credenciais exigem altos privilégios para o respectivo aplicativo. Por exemplo, a integração "Poll Active Directory Server" requer as credenciais de uma conta com acesso administrativo a um controlador de domínio, potencialmente transformando uma violação FortiGate em um comprometimento de domínio completo imediatamente.
Descriptografia de segredos de um arquivo de configuração Ivanti
A situação é muito semelhante com a Ivanti. Na verdade, isso pode ser pior.
O Ivanti também armazena segredos usando criptografia reversível. Se extrairmos o código do dispositivo e o analisarmos, encontraremos rapidamente o valor secreto que é usado como chave de criptografia, que é (novamente) uma string estática (Figura 15).
Fig. 15: Chave de criptografia estática Ivanti
Omitimos a chave completa, no entanto, ao inspecionar o início dela, podemos supor que ela provavelmente não mudou pelo menos desde 2015, que foi o ano em que a Juniper deixou se ser proprietária do Connect Secure.
O Ivanti parece ter feito o maior esforço para proteger os segredos armazenados, implementando um algoritmo de criptografia mais complexo do que o FortiGate. Apesar disso, esse processo ainda é obviamente reversível. Isso quer dizer que segredos de todas as instâncias do Ivanti são criptografados usando uma chave estática que não pode ser alterada. Os invasores podem usar esse conhecimento para descriptografar qualquer arquivo de configuração Ivanti.
Ao permitir que o Ivanti descriptografe senhas para nós,
nossa abordagem inicial era fazer engenharia reversa do processo de criptografia para criar um descriptografador. Isso é certamente possível, mas depois de algumas horas de análise de código descompactado, decidimos adotar uma abordagem diferente como prova de conceito. Nós deixamos o Ivanti fazer o levantamento pesado para nós.
A ideia principal é usar uma instância dedicada do Ivanti, de propriedade de um invasor, "alimentá-lo" com a senha criptografada e fazer com que ela a descriptografe (Figura 16).
Fig. 16: O processo de descriptografia de uma senha do Ivanti em um ambiente de laboratório do invasor
Essa descriptografia pode ser feita por meio das seguintes etapas:
Obtenha uma senha criptografada de um arquivo de configuração Ivanti
Em um ambiente de laboratório, configure uma instância Ivanti e um servidor LDAP (por exemplo, um servidor Windows executando o Active Directory)
Na instância Ivanti do laboratório, configure nosso servidor LDAP como um servidor de autenticação que usa autenticação simples
Exporte a configuração Ivanti do laboratório para um arquivo
Substitua a senha LDAP criptografada, existente no arquivo de configuração, pela senha criptografada que estamos tentando descriptografar
Importe o arquivo de configuração modificado de volta para a instância do Ivanti
Agora, quando acionarmos uma tentativa de autenticação para o servidor LDAP, o Ivanti irá descriptografar a senha da configuração e enviar por texto não criptografado para o servidor LDAP. Ao capturar os pacotes, podemos obter a senha descriptografada (Figura 17).
Fig. 17: Descriptografia pelo Ivanti de nossa senha fornecida e vazamento do resultado pelo LDAP
Usamos a autenticação do servidor LDAP como uma "interface" com o processo de descriptografia, mas é importante observar que não estamos limitados a senhas LDAP. Nossos testes mostraram que essa técnica funcionará para todos os segredos armazenados no arquivo de configuração, incluindo (mas não se limitando a) senhas do AD, chaves pré-compartilhadas do RADIUS e chaves de API.
Senhas do servidor MDM de texto não criptografado
A Ivanti suporta alguns servidores de gerenciamento de dispositivos móveis (MDM) populares como métodos de autenticação (Figura 18).
Fig. 18: Configuração do servidor Ivanti MDM
Como outros servidores de autenticação, essa integração requer credenciais para o servidor MDM. Se inspecionarmos a configuração do servidor MDM, encontraremos dois campos interessantes: "criptografado por senha" e "texto sem senha". E, apesar do que os nomes podem sugerir, ambos os campos são armazenados em texto não criptografado (Figura 19). ♂️
Fig. 19: Configuração Ivanti MDM contendo senhas de texto não criptografado
Técnicas de pós-exploração de VPN na natureza
É provável que algumas das técnicas que destacamos neste post já estejam sendo usadas em sistemas reais. Em um relatório inovador, que envolveu uma série de campanhas de exploração contra dispositivos Ivanti, os pesquisadores da Mandiant compartilharam que os invasores conseguiram comprometer a conta de serviço LDAP configurada no dispositivo Ivanti (Figura 20).
Fig. 20: Relatório do Mandiant mencionando uma conta LDAP comprometida
Embora o relatório Mandiant não detalhe como os invasores conseguiram fazer isso, acreditamos que é bastante provável que os invasores tenham conseguido obter as credenciais usando um dos métodos que destacamos neste blog; ou seja, extraindo-os do arquivo de configuração ou interceptando o tráfego da rede.
A implementação desses tipos de técnicas é simples, e acreditamos que os invasores de todos os níveis de sofisticação poderão usá-los.
Recomendações ao usar um servidor de VPN
Recomendamos quatro princípios que devem ser seguidos ao usar um servidor de VPN para minimizar os riscos das técnicas que acabamos de destacar:
Acesso à rede Zero Trust
Limitação das permissões da conta de serviço
Uso de identidades dedicadas para autenticação VPN
Monitoramento de alterações de configuração
1. Acesso à rede Zero Trust
Um dos principais problemas com VPNs tradicionais é sua abordagem de "tudo ou nada" na concessão de acesso à rede, isto é, os usuários estão "dentro" (e têm acesso completo à rede) ou "fora" (e não podem acessar nada).
Ambas as opções são problemáticas. Por um lado, devemos fornecer aos usuários acesso remoto a aplicativos internos. Por outro lado, não queremos que um intruso tenha acesso total à rede caso comprometa um servidor de VPN.
O acesso à rede Zero Trust (ZTNA) oferece uma solução. Ao definir políticas de acesso à rede por entidade, podemos permitir que os usuários executem operações remotas aprovadas, o que reduz o impacto de uma possível violação.
Akamai Enterprise Application Access é uma solução ZTNA que oferece acesso preciso, com base em identidade e contexto, a aplicativos particulares. Ela usa políticas baseadas em identidade e dados em tempo real, como localização do usuário, horário e segurança do dispositivo, para garantir que os usuários tenham acesso apenas aos aplicativos de que precisam e elimina o acesso no nível da rede. Funciona perfeitamente com a MFA da Akamai para fornecer uma autenticação forte do usuário.
2. Limitação das permissões da conta de serviço
Conforme foi demonstrado neste post, é fácil recuperar as senhas de texto não criptografado das contas de serviço armazenadas em servidores de VPN. Não há maneira real de evitar isso, pois as VPNs exigem o uso de senhas de texto não criptografado em alguns casos.
Para reduzir o impactos de um possível comprometimento de VPN, recomendamos o uso de contas de serviço com um conjunto limitado de permissões, de preferência somente leitura. Os defensores devem tentar entender como um invasor pode aproveitar as credenciais armazenadas na VPN e garantir que um comprometimento de VPN não comprometa outros ativos críticos.
Algumas integrações exigem uma conta de serviço com permissões fortes para que sejam operadas. Se possível, eles devem ser evitados.
3. Uso de identidades dedicadas para autenticação VPN
Agora sabemos que é fácil para um invasor, que tenha controle sobre a VPN, comprometer as credenciais de autenticação de usuários de VPN. Embora possa ser tentador usar serviços de autenticação existentes, como o AD, para autenticar usuários na VPN, recomendamos que você evite fazer isso. Os invasores que tenham controle sobre a VPN poderão obter credenciais e usá-las para se transformar em ativos internos, transformando a VPN em um único ponto de falha.
Em vez disso, recomendamos que você use uma maneira separada e dedicada de autenticar usuários na VPN. Por exemplo, execute a autenticação baseada em certificado usando certificados emitidos especificamente para essa finalidade.
4. Monitoramento de alterações de configuração
As técnicas que destacamos refletirão na configuração do dispositivo de uma forma ou de outra. Como a configuração do dispositivo de rede não tende a mudar com frequência, essas alterações podem oferecer uma oportunidade de detecção significativa.
Para identificar alterações de configuração, recomendamos extrair periodicamente a configuração do dispositivo e compará-la com uma "imagem dourada". A maioria dos dispositivos também inclui recursos de registro interno para eventos de sistema e segurança. Recomendamos que você colete e analise todos os registros disponíveis e use-os para identificar alterações suspeitas na configuração do dispositivo.
Todos esses quatro princípios se resumem a isso: Não confie cegamente na VPN.
Resumo
Os invasores estão de olho na VPN. Isso é um fato. Os defensores devem presumir que é apenas uma questão de tempo antes que um agente de ameaça obtenha acesso à VPN, e eles devem agir antecipadamente. Os defensores devem se certificar de que uma VPN comprometida não cause o total comprometimento de toda a rede.
Cronograma de divulgação
Ivanti
26.03.2024 – Relatório inicial ao fornecedor
05.04.2024 – Ivanti reconhece o relatório e confirma que está trabalhando em uma correção
03.06.2024 – Aviso inicial à Ivanti que planejamos publicar a pesquisa em 7 de agosto
27.06.2024 – O Ivanti afirma que está trabalhando em uma correção, mas não pode confirmar que os problemas serão corrigidos antes da data de publicação
08.07.2024 – O Ivanti atribui CVE-2024-37374 e CVE-2024-37375 ao problema de chave codificada e às senhas de texto não criptografado do MDM, mas ainda não lançou um patch
15.07.2024 – Aviso adicional ao Ivanti sobre a programação de lançamento planejada
07.08.2024 – Pesquisa publicada
Fortinet
22.03.2024 – Relatório inicial ao fornecedor
17.04.2024 – Resposta inicial do Fortinet, concluindo que nenhum dos problemas descritos requer uma correção
21.04.2024 – Aviso inicial para o Fortinet de que planejamos publicar a pesquisa em 7 de agosto
30.04.2024 – Fortinet nos informa que pretende corrigir o desvio de chave de criptografia personalizada que descrevemos
15.07.2024 – Aviso adicional ao Fortinet sobre a programação de liberação planejada
23.07.2024 – Fortinet afirma que provavelmente não conseguirá liberar o patch antes da data de publicação
02.08.2024 – Fortinet nos informou que, após consideração adicional, eles decidiram não corrigir o desvio de chave de criptografia personalizada, pois "não ultrapassa um limite de segurança"
07.08.2024 – Pesquisa publicada