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.”

Fonte: https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/Gaia-Overview.htm

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:

1. abra o SmartConsole e selecione a opção manage & Settings;
2. selecione Blades;
3. 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:

1. 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;
2. 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:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuide/Content/Topics-SECMG/Compliance-Check.htm

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.