1. 1. Introdução
As empresas que não possuíam sistemas de acesso remoto implantaram-nos com urgência há alguns meses. Nem todos os administradores estavam preparados para tal “calor”, o que resultou em lapsos de segurança: configuração incorreta de serviços ou mesmo instalação de versões desatualizadas de software com vulnerabilidades previamente descobertas. Para alguns, essas omissões já foram um bumerangue, outros tiveram mais sorte, mas todos deveriam definitivamente tirar conclusões. A fidelidade ao trabalho remoto aumentou exponencialmente e cada vez mais empresas estão aceitando o trabalho remoto como um formato aceitável de forma contínua.
Portanto, existem muitas opções para fornecer acesso remoto: diversas VPNs, RDS e VNC, TeamViewer e outros. Os administradores têm muito por onde escolher, com base nas especificidades da construção de uma rede corporativa e dos dispositivos nela contidos. As soluções VPN continuam sendo as mais populares, no entanto, muitas pequenas empresas escolhem RDS (Remote Desktop Services), pois são mais simples e rápidas de implantar.
Neste artigo falaremos mais sobre segurança RDS. Faremos uma breve visão geral das vulnerabilidades conhecidas e também consideraremos vários cenários para lançar um ataque a uma infraestrutura de rede baseada no Active Directory. Esperamos que nosso artigo ajude alguém a resolver bugs e melhorar a segurança.
2. Vulnerabilidades recentes de RDS/RDP
Qualquer software contém erros e vulnerabilidades que podem ser exploradas por invasores, e o RDS não é exceção. A Microsoft tem relatado frequentemente novas vulnerabilidades ultimamente, então decidimos dar-lhes uma breve visão geral:
Esta vulnerabilidade coloca em risco os usuários que se conectam a um servidor comprometido. Um invasor pode obter o controle do dispositivo de um usuário ou obter uma posição segura no sistema para ter acesso remoto permanente.
- / /
Este grupo de vulnerabilidades permite que um invasor não autenticado execute remotamente código arbitrário em um servidor executando RDS usando uma solicitação especialmente criada. Eles também podem ser usados para criar worms – malware que infecta de forma independente dispositivos vizinhos na rede. Assim, essas vulnerabilidades podem colocar em risco toda a rede da empresa, e somente atualizações oportunas podem salvá-las.
O software de acesso remoto tem recebido cada vez mais atenção tanto de pesquisadores quanto de invasores, portanto, em breve poderemos ouvir falar de mais vulnerabilidades semelhantes.
A boa notícia é que nem todas as vulnerabilidades têm explorações públicas disponíveis. A má notícia é que não será difícil para um invasor com experiência escrever uma exploração para uma vulnerabilidade com base na descrição ou usando técnicas como Patch Diffing (nossos colegas escreveram sobre isso em ). Portanto, recomendamos que você atualize regularmente o software e monitore o aparecimento de novas mensagens sobre vulnerabilidades descobertas.
3. Ataques
Passamos para a segunda parte do artigo, onde mostraremos como começam os ataques à infraestrutura de rede baseada no Active Directory.
Os métodos descritos são aplicáveis ao seguinte modelo de invasor: um invasor que possui uma conta de usuário e acesso ao Gateway de Área de Trabalho Remota - um servidor de terminal (geralmente acessível, por exemplo, de uma rede externa). Ao utilizar estes métodos, o atacante poderá continuar o ataque à infraestrutura e consolidar a sua presença na rede.
A configuração da rede em cada caso específico pode ser diferente, mas as técnicas descritas são bastante universais.
Exemplos de saída de um ambiente restrito e aumento de privilégios
Ao acessar o Remote Desktop Gateway, um invasor provavelmente encontrará algum tipo de ambiente restrito. Quando você se conecta a um servidor de terminal, um aplicativo é iniciado nele: uma janela para conexão via protocolo Remote Desktop para recursos internos, Explorer, pacotes de escritório ou qualquer outro software.
O objetivo do invasor será obter acesso para executar comandos, ou seja, iniciar o cmd ou o powershell. Várias técnicas clássicas de escape da sandbox do Windows podem ajudar com isso. Vamos considerá-los mais detalhadamente.
opção 1. O invasor tem acesso à janela de conexão da Área de Trabalho Remota no Gateway de Área de Trabalho Remota:
O menu “Mostrar opções” é aberto. Aparecem opções para manipular arquivos de configuração de conexão:
A partir desta janela você pode acessar facilmente o Explorer clicando em qualquer um dos botões “Abrir” ou “Salvar”:
O Explorador é aberto. Sua “barra de endereços” permite lançar arquivos executáveis permitidos, bem como listar o sistema de arquivos. Isto pode ser útil para um invasor nos casos em que as unidades do sistema estão ocultas e não podem ser acessadas diretamente:
→
Um cenário semelhante pode ser reproduzido, por exemplo, ao usar o Excel do pacote Microsoft Office como software remoto.
→
Além disso, não se esqueça das macros utilizadas neste pacote de escritório. Os nossos colegas analisaram o problema da macrosegurança neste .
opção 2. Usando as mesmas entradas da versão anterior, o invasor inicia várias conexões com a área de trabalho remota na mesma conta. Ao reconectar, o primeiro será fechado e uma janela com notificação de erro aparecerá na tela. O botão de ajuda nesta janela chamará o Internet Explorer no servidor, após o qual o invasor poderá acessar o Explorer.
→
opção 3. Se as restrições ao lançamento de arquivos executáveis estiverem configuradas, um invasor poderá encontrar uma situação em que as políticas de grupo proíbam o administrador de executar o cmd.exe.
Existe uma maneira de contornar isso executando um arquivo bat na área de trabalho remota com conteúdo como cmd.exe /K <command>. Um erro ao iniciar o cmd e um exemplo bem-sucedido de execução de um arquivo bat são mostrados na figura abaixo.
opção 4. Proibir o lançamento de aplicativos que utilizam listas negras baseadas no nome de arquivos executáveis não é uma panaceia; elas podem ser contornadas.
Considere o seguinte cenário: desabilitamos o acesso à linha de comando, impedimos o lançamento do Internet Explorer e do PowerShell usando políticas de grupo. O invasor tenta pedir ajuda - sem resposta. Tentando iniciar o PowerShell através do menu de contexto de uma janela modal, chamada com a tecla Shift pressionada - uma mensagem indicando que o lançamento é proibido pelo administrador. Tenta iniciar o PowerShell através da barra de endereço - novamente sem resposta. Como contornar a restrição?
Basta copiar powershell.exe da pasta C:WindowsSystem32WindowsPowerShellv1.0 para a pasta do usuário, alterar o nome para algo diferente de powershell.exe e a opção de inicialização aparecerá.
Por padrão, ao conectar-se a uma área de trabalho remota, é fornecido acesso aos discos locais do cliente, de onde um invasor pode copiar powershell.exe e executá-lo após renomeá-lo.
→
Fornecemos apenas algumas maneiras de contornar as restrições; há muitos outros cenários que você pode imaginar, mas todos eles são unidos acessando o Windows Explorer. Existem muitos aplicativos que usam ferramentas padrão de manipulação de arquivos do Windows e, quando colocados em um ambiente limitado, técnicas semelhantes podem ser usadas.
4. Recomendações e conclusão
Como podemos ver, mesmo em um ambiente limitado há espaço para o desenvolvimento de ataques. No entanto, você pode dificultar a vida do invasor. Fornecemos recomendações gerais que serão úteis tanto nas opções que consideramos como em outros casos.
- Limite os lançamentos de programas a listas negras/brancas usando políticas de grupo.
Na maioria dos casos, entretanto, ainda é possível executar o código. Recomendamos que você se familiarize com o projeto , para ter uma ideia das formas não documentadas de manipulação de arquivos e execução de código no sistema.
Recomendamos combinar os dois tipos de restrições: por exemplo, você pode permitir o lançamento de arquivos executáveis assinados pela Microsoft, mas restringir o lançamento de cmd.exe. - Desative as guias de configurações do Internet Explorer (pode ser feito localmente no registro).
- Desative a ajuda interna do Windows via regedit.
- Desative a capacidade de montar discos locais para conexões remotas se tal limitação não for crítica para os usuários.
- Limite o acesso às unidades locais da máquina remota, deixando o acesso apenas às pastas do usuário.
Esperamos que você tenha achado no mínimo interessante e, no máximo, este artigo ajudará a tornar o trabalho remoto da sua empresa mais seguro.
Fonte: habr.com