Por: Antonio Junior
Apresentação:
“Gaia é o sistema operacional de próxima geração da Check Point para aplicativos de segurança. Na mitologia grega, Gaia é a mãe de tudo, o que representa partes intimamente integradas para formar um sistema eficiente.”
Diante desse conglomerado, existe um conjunto de regras que iremos abordar nesse artigo que estão associadas às permissões de compliance para autorizar autenticação via VPN.
Como e em que menu é configurada essa regra de compliance?
Existem diversos tipos de regras que podem ser usadas para compliance, como, por exemplo:
- segurança do Windows – hotfixes, patches e service packs do Microsoft Windows;
- proteção anti-spyware – software anti-spyware;
- proteção antivírus – versão do software antivírus e arquivos de assinatura de vírus;
- firewall – software de firewall;
- verificação de spyware – ação realizada para diferentes tipos de spyware;
- personalizado – Regras compliance para a organização, por exemplo: aplicativos, arquivos e chaves de registro.
Vamos nos ater ao tipo de regra personalizada, a qual possibilita que um administrador de sistemas configure um registro do Windows para servir como lista de referências (“de-para”) na validação entre cliente e servidor.
A seguir, apresentamos uma breve explicação, com imagens, de como ocorre essa configuração:
- abra o SmartConsole e selecione a opção manage & Settings;
- selecione Blades;
- selecione Mobile Access > configure in SmartDashboard;
4. abra Endpoint Security on Demand;
5. abra Endpoint Compliance;
6. abra Edit Policies;
7. selecione uma policy já aplicada no ambiente ou crie uma nova;
8. Edite a policy selecionada anteriormente (Edit);
9. adicione uma nova Enforcement Rule (botão add);
10. crie uma New Role;
11. selecione a opção custom check no menu flutuante;
12. crie um nome para a nova regra;
13. marque a opção check for registry key and value;
14. insira o caminho da chave de registro no campo Registry Key;
15. insira o nome do registro no campo Registry Entry e defina qual o nome do domínio (value).
16.Salve todas as alterações.
Explicando em detalhes:
Uma vez que o usuário — em seu computador — solicita a conexão via client VPN (não iremos detalhar como é feita a configuração básica para a conexão como forma de manter a abordagem o mais genérica possível), um script coleta as informações do computador e envia para o roteador de borda com o Gaia. Este, por sua vez, realiza a checagem de lista de referência (“de-para”) e valida se as regras criadas de compliance são minimamente aceitáveis para viabilizar a conexão do usuário.
Contudo, essa validação ocorre através da verificação da string de origem configurada no registro do Windows da máquina do cliente solicitante contra o valor estabelecido pela regra criada (a saber: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain\”). Dessa forma, a confiabilidade torna-se falha, haja vista o fato de que toda a informação oriunda de um cliente não deve ser aceita sem uma checagem assertiva.
Então mãos à obra – explorando um cenário real:
Durante a execução de um projeto externo do tipo black box, ou seja, sem conhecimento prévio sobre a infraestrutura interna/externa da contratante, foi ventilado o cenário da configuração de compliance ao tentar acessar a VPN quando nos deparamos com o seguinte erro de conexão:
Sabendo como funciona a estrutura de configuração do Gaia, foi utilizada a seguinte técnica:
- criar um domínio local, utilizando Windows Server 2019, para exaustivamente testar a cadeia de caracteres (“brute force”) que representa o nome do domínio real do alvo;
- inserir uma máquina Windows 11 neste “falso” domínio (com o intuito de facilitar a conexão).
Como forma de elucidar os passos mencionados no item anterior de maneira mais didática, confeccionamos imagens que tem o papel de ilustrá-los, entretanto, para fins de sanidade documental e economia de tempo, demonstraremos apenas as ações que culminaram no resultado esperado:
- Máquina com Windows 11 sem domínio configurado:
- Máquina Windows Server 2019 com o falso domínio configurado para teste:
- Máquina Windows 11 agora ingressada no domínio local:
E como resultado dos passos tomados anteriormente, a imagem a seguir ilustra uma nova tentativa de conexão contra a VPN do alvo, tendo como diferencial — neste exemplo — a máquina ingressada no domínio criado localmente:
Como observado, a conexão foi realizada sem nenhum tipo de impeditivo por parte das normativas de compliance. A partir desse cenário, durante a execução do projeto, foi possível comprometer a rede interna do alvo, demonstrando as fragilidades congênitas que esse tipo de regra/configuração pode produzir.
Mitigação:
Sob o contexto doutrinário de segurança da informação, a recomendação mitigatória para esse tipo de cenário contemplaria adotar uma estrutura de zero trust network access e descontinuar o acesso tradicional de VPN, tendo em vista diversas fragilidades como as apresentadas neste write-up. Contudo, em muitos casos a implementação desta infraestrutura tende a tornar-se custosa. Desta forma, como uma medida mitigatória suplementar, seria de bom alvitre a adoção de um segundo fator de validação para o compliance, que por sua vez necessitaria ser algo único/específico, como por exemplo:
- software de antivírus utilizado pela organização;
- agent de monitoramento e coleta de informações da máquina;
- arquivo/software de uso exclusivo, o qual poderia ter o seu hash adicionado nas configurações do Gaia;
- validação do nome da máquina (hostname) dentro da estrutura do Active Directory
Referência:
Agradecimentos:
Esse blog post não seria possível sem o amparo técnico de Gustavo Brustolin (https://br.linkedin.com/in/gustavobps), que contribuiu com a criação dos laboratórios da Checkpoint para validar o cenário aqui exposto.
Ademais estendo os agradecimentos especiais para Joaquim Brasil, que incentivou essa pesquisa/publicação, bem como é responsável por auxiliar e direcionar minha jornada no hacking. E para Marcelo Pessoa, que acreditou e acredita no potencial de cada um do time de consultoria.