Top 10 vulnerabilidades encontradas em pentests internos

Nos últimos anos, a cibersegurança tornou-se cada vez mais importante para as empresas devido ao surgimento de uma variedade de ameaças, incluindo violações de dados sensíveis, comprometimento de sistemas de informação (SI) internos e danos à reputação. Como resultado, os nossos clientes procuram aumentar a sua postura de segurança. Uma forma de alcançar isso é realizar testes de penetração internos.

Este serviço consiste na simulação de um ciberataque, realizado por especialistas em segurança, dentro da rede da empresa para encontrar vulnerabilidades no sistema e elevar privilégios na infraestrutura, da mesma forma que um verdadeiro ciberatacante faria (mas sem causar danos reais). O objetivo é encontrar vulnerabilidades e fornecer recomendações para corrigi-las antes que um atacante real tenha oportunidade para explorá-las.

A nossa equipa de pentesting realizou muitas auditorias de segurança internas, para vários clientes, ao longo dos anos. Eis as 10 principais vulnerabilidades que encontramos, como conseguimos explorá-las e recomendações para resolvê-las.

1) Protocolos legacy de nomenclatura

O Windows utiliza múltiplos protocolos de nomenclatura para identificar computadores ou serviços na rede, de forma a facilitar o acesso dos utilizadores. O mais amplamente utilizado é o DNS (Domain Name System): cada computador que se junta ao domínio ou ao serviço é adicionado ao servidor DNS, de modo que sempre que um utilizador solicita um recurso específico, o serviço DNS responde com o IP correspondente.

Infelizmente, se um utilizador comete um erro ao consultar um recurso, o servidor DNS não pode responder (por exemplo: ao assumir que existe um serviço CIFS (Common Internet File System) como o SMB (Server Message Block) em “ws-share.domain.tld”, enquanto o utilizador está a pedir “w-share.domain.tld”, o servidor DNS não responderá porque “w-share” não está na sua base de dados). Neste caso, o Windows ainda tentará responder usando protocolos de fallback como mDNS (Multicast DNS), NBNS (NetBIOS Name Service) ou LLMNR (Link-Local Multicast Name Resolution).

Todos estes são protocolos de transmissão, o que significa que um pedido é enviado para todos na tentativa de encontrar o IP de “w-share.domain.tld”. O problema é que se alguém na rede responder a esta consulta com o seu próprio endereço IP, o cliente que pede “ws-share.domain.tld” pode ser redirecionado para iniciar um processo de autenticação, enviando diretamente ao atacante uma resposta NTLMv2, que inclui o hash da sua palavra-passe. Neste cenário, o atacante pode recolher os hashes das palavras-passe de vários utilizadores e tentar quebrá-los offline.

Para prevenir esta ameaça, é recomendado evitar o uso de protocolos legacy antigos, desativando-os e permitindo apenas o uso de DNS. Isto pode ser feito através de Objetos de Política de Grupo (GPO – Group Policy Object).

2) Retransmissão NTLM

Outra técnica amplamente utilizada é a retransmissão NTLM (NT LAN Manager). Este ataque baseia-se na falta de verificação de assinatura durante a autenticação NTLM, quando um utilizador tenta aceder a um serviço (principalmente ao LDAP – Lightweight Directory Access Protocol – ou ao SMB).

As autenticações NTLM funcionam em 3 etapas:

1. O cliente faz um pedido de autenticação para um recurso a um servidor.
2. O servidor envia um desafio ao cliente.
3. O cliente envia uma resposta ao servidor (que consiste no desafio encriptado usando a palavra-passe do cliente).

Atacantes numa posição de Man-in-the-Middle (MitM) podem intercetar o pedido de autenticação entre um utilizador e um serviço A, encaminhando esse pedido para um serviço B. Então, ao receberem o desafio do serviço A, encaminham-no para o cliente e aguardam a sua resposta, que enviarão ao serviço B. Desta forma, podem autenticar-se como o cliente no serviço B, sem qualquer conhecimento da sua palavra-passe.

Este ataque já não funciona se os serviços solicitarem a assinatura do cliente. É de notar que permitir a assinatura e exigir a assinatura são coisas diferentes: no primeiro caso, a assinatura é possível e não obrigatória, enquanto no segundo será solicitada sempre.

3) Configuração incorreta do LAPS

Como é muito difícil gerir computadores em ambientes de larga escala, a Microsoft adicionou uma solução para automatizar a gestão da conta de administrador local, chamada LAPS (Local Administrator Password Solution). Esta solução adiciona duas novas propriedades aos objetos de computador: "ms-Mcs-AdmPwd" e "ms-Mcs-AdmPwdExpirationTime" (uma palavra-passe em texto simples e a sua data de expiração).

Por padrão, apenas contas com privilégios elevados podem ler as propriedades "ms-Mcs-AdmPwd", mas como alguns grupos frequentemente têm mais privilégios do que deveriam, não é raro encontrar utilizadores autorizados a ler estas propriedades, mesmo que não o devam fazer, o que lhes concede direitos de administrador local.

Outra configuração incorreta que a nossa equipa encontra é a de quando os utilizadores têm direitos em excesso sobre um computador A. Neste cenário, se o utilizador tiver o direito de adicionar um novo computador ao domínio, pode adicionar um computador B (no qual tem privilégios de administrador) e sincronizar a sua palavra-passe de administrador local com o computador A (sobrepondo-a à sua própria palavra-passe). Depois, como já é administrador local na máquina, só precisa de ler a propriedade "ms-Mcs-AdmPwd" para obter a palavra-passe.

Usar o LAPS é uma forma muito eficiente de proteger os computadores, mas pode ser difícil restringir os utilizadores de terem acesso de leitura ou direitos excessivos sobre a palavra-passe.

4) Permissões de partilha

Durante testes de penetração internos, uma vez que um auditor de segurança tem uma conta, este pode verificar se existem partilhas abertas na rede e verificar se alguma delas está configurada com restrições fracas, como acesso anónimo, acesso de leitura total, ou acesso de escrita.

O acesso anónimo a uma partilha significa que qualquer pessoa, mesmo sem uma conta, pode aceder a esta partilha. Dar acesso de escrita a demasiados princípios também pode resultar em utilizadores a modificar dados (por exemplo, binários) para introduzir portas de entrada traseiras. Por outro lado, dar acesso de leitura a todos pode acabar em exposição de informação crítica.

É difícil gerir as permissões corretamente devido ao número de utilizadores e grupos, ou mesmo devido ao número de partilhas disponíveis, mas ter uma política de partilha forte e restrita reduz a superfície de ataque.

5) Abuso de política de grupo

O Objeto de Política de Grupo (GPO) é uma funcionalidade que ajuda os administradores a gerir e a controlar o ambiente de trabalho dos utilizadores e respetivas contas dentro de uma organização. Um atacante que tenha uma conta no domínio pode aceder às partilhas SYSVOL (volume do sistema) de qualquer controlador de domínio para extrair esses GPO. Se os administradores usarem GPO para enviar e executar scripts nos computadores, estes podem conter informações críticas, como credenciais.

Outro risco é quando um utilizador tem demasiados direitos (como CreateChild, WriteProperty, ou GenericWrite) sobre um GPO. Neste cenário, um utilizador pode alterá-lo para assumir o controlo dos computadores aos quais o GPO se aplica.

Para resolver esta vulnerabilidade, é essencial não escrever palavras-passe em texto simples nos GPO e verificar cuidadosamente quem tem privilégios de escrita sobre os GPO.

6) Configuração incorreta do template ADCS

O ADCS (Active Directory Certificate Service) é um serviço utilizado para emitir e gerir certificados para utilizadores, computadores ou serviços. Permite configurar templates que serão então usados para gerar certificados. No entanto, como estes templates são muito moldáveis, também contêm opções perigosas. Por exemplo, alguns templates podem ser usados para autenticar utilizadores no domínio, por isso se o template permitir que um utilizador solicite um certificado em nome de outra conta (opção "ENROLLE_SUPPLIES_SUBJECT"), um atacante pode igualmente solicitar um certificado e adicionar no campo SAN (Subject Alternative Name) o nome de um administrador de domínio. O ADCS irá, portanto, emitir um certificado válido para o atacante, que o mesmo pode utilizar para se autenticar como um administrador de domínio.

Outra vulnerabilidade que a nossa equipa encontra durante os testes de penetração são templates que podem ser substituídos por qualquer utilizador autenticado. Neste caso, somos capazes de alterar as opções do template para autorizar a autenticação do cliente, e podemos modificar o sujeito do certificado para gerar um certificado em nome de um administrador de domínio, comprometendo assim todo o SI.

As empresas devem verificar os direitos do seu modelo ADCS para restringir o acesso à sua modificação, e devem certificar-se de que os utilizadores não são capazes de fornecer o sujeito do certificado.

7) Uso de SPN para contas de utilizador (kerberoasting)

Uma vulnerabilidade não tão recente, mas ainda bem presente, é o uso de SPN (Service Principal Name) para contas não técnicas - o chamado ataque kerberoasting. SPN é um identificador de uma instância de serviço (por exemplo, MSSQL01_svc/sql.domain.tld:1433 representa a conta MSSQL01_svc em sql.domain.tld). Se uma conta tiver a propriedade "servicePrincipalName", qualquer utilizador pode solicitar um TGS (Ticket-Granting Service) para o seu serviço. Este TGS inclui uma encriptação da palavra-passe da conta, pelo que um atacante pode pedir um TGS e tentar quebrar a palavra-passe offline. Isto não é tão perigoso para contas de serviço, porque as palavras-passe são geralmente aleatórias e longas o suficiente, portanto mais difíceis de quebrar, mas torna-se problemático para contas de utilizador, porque na maioria das vezes, mesmo com uma boa política de palavras-passe, é mais fácil quebrá-las com um bom dicionário e conjuntos de regras eficientes.

Portanto, é recomendável não definir a propriedade SPN para contas de utilizador e garantir a aplicação de uma boa política de palavras-passe para limitar a possibilidade de os atacantes as desvendarem.

8) Sistemas e software desatualizados

Uma ameaça que frequentemente enfrentamos em testes de penetração internos é a descoberta de sistemas ou software desatualizados, que são vulneráveis a Vulnerabilidades e Exposições Comuns (CVE – Common Vulnerabilities and Exposures). É difícil ter uma boa política de atualização, especialmente em grandes empresas, mas isto pode tornar-se uma entrada fácil para atacantes, já que novas vulnerabilidades são descobertas e exploradas todos os dias, e muitas PoC (Prova de Conceito) estão frequentemente disponíveis.

As organizações devem estabelecer uma boa política de atualização para limitar a possibilidade de ciberatacantes explorarem essas vulnerabilidades.

9) Configuração incorreta do SCCM

Recentemente, durante uma auditoria interna, a nossa equipa encontrou uma forma de comprometer todo o domínio de um cliente ao abusar da configuração incorreta do serviço SCCM (System Center Configuration Manager). Este produto ajuda os administradores a instalar, gerir e configurar computadores num domínio. Infelizmente, a conta usada para executar tarefas de configuração era uma conta de domínio com demasiados direitos (direitos de administrador de domínio).

O facto é que um administrador local de um computador gerido pelo SCCM pode decifrar a palavra-passe NAA (Network Access Account) do SCCM, porque esta é apenas protegida pela API de Proteção de Dados do Windows. Portanto, chegar a administrador local de um posto de trabalho é algo frequentemente alcançado pelos nossos especialistas.

A Microsoft recomenda não usar contas de domínio para realizar a configuração de computadores ou, pelo menos, restringir as permissões.

10) Política de palavras-passe fraca

Por fim, a vulnerabilidade mais comum que enfrentamos durante as nossas auditorias é a existência de palavras-passe de utilizador fracas. À medida que o poder de computação aumenta, torna-se mais fácil para os atacantes quebrar palavras-passe mais complexas, e ainda mais fácil quando a política de palavras-passe em causa é fraca. Por exemplo, este artigo mostra como uma palavra-passe de 8 caracteres com maiúsculas, minúsculas e caracteres especiais leva 5 dias a ser recuperada e envolve um custo de 3000 dólares.

A Agência de Segurança Francesa (ANSSI) recomenda um comprimento de palavra-passe entre 9 e 11 caracteres para proteger dados de baixa sensibilidade, 12 a 14 para conteúdo de sensibilidade média, e 15 ou mais para um nível de sensibilidade alto a muito alto. Também recomenda o uso de maiúsculas, minúsculas, dígitos e caracteres especiais. As contas altamente sensíveis também devem recorrer a Autenticação Multi-Fator (MFA).