
A pandemia do vírus COVID-19 mudou radicalmente o modelo de trabalho do pessoal de muitas organizações de forma voluntária-compulsória, “recompensando” a maioria com o status de “remoto”, e alguns, até mesmo “trabalhador remoto”.
Se antes da “megepidemia” os funcionários realizavam suas tarefas no escritório usando a infraestrutura corporativa controlada pelo departamento de TI da empresa, então, durante o auto-isolamento, a parte “do leão” do trabalho de escritório começou a ser realizada em dispositivos domésticos usando o Remote Desktop Protocol (RDP). Popular, como o próprio SO da MS, mas, como sugere a lista de vulnerabilidades, não é o protocolo mais seguro. Falaremos sobre como proteger seu RDP de ataques externos.
Infelizmente, para considerar as características de cada uma das vulnerabilidades para as quais gostaria de chamar sua atenção, um artigo definitivamente não é suficiente para mim, então neste vou me limitar aos detalhes do ciclo de vida de um dos últimos.
RDP vice-versa
Em 2018, no processo de pesquisa da segurança do protocolo de área de trabalho remota, os especialistas da Check Point Research descobriram várias vulnerabilidades em três clientes populares projetados para trabalhar com ele:
- Cliente RDP da Microsoft / Mstsc.exe
- rdesktop
- FreeRDP
No total, foram descobertas 25 vulnerabilidades, incluindo as críticas, incluindo aquelas que permitem a um invasor mudar a direção usual da comunicação e atacar um computador cliente, ou seja, realizar um ataque usando uma conexão RDP reversa (ataque RDP reverso).
No cliente RDP da Microsoft, essa vulnerabilidade se escondia na área de transferência compartilhada entre o cliente e o servidor. O que, ao usar o buffer durante a conexão, permitia que o servidor com o exploit "incluísse" seus próprios arquivos no processo de troca iniciado pelo usuário. E a funcionalidade do ataque path traversal é determinar o “destino final” para o arquivo em qualquer lugar no computador cliente. Por exemplo, sem notificações desnecessárias, envie um arquivo executável (miner, programa de criptografia) para a pasta de inicialização do computador do usuário para iniciá-lo na próxima reinicialização do sistema.
Demonstração da vulnerabilidade da Check Point Research
O fato foi relatado à Microsoft (MSRC) em 16 de outubro de 2018. Em resposta a que, em 17 de dezembro de 2018, o destinatário respondeu:
"Obrigado pela sua submissão. Determinamos que sua descoberta é válida, mas não atende aos nossos padrões de manutenção. Para obter mais informações, consulte os Critérios de serviço de segurança da Microsoft para Windows (https://aka.ms/windowscriteria). "
“Obrigado por enviar sua inscrição. Determinamos que sua descoberta é válida, mas não atende ao nosso nível de serviço. Para obter mais informações, consulte Critérios de manutenção da Microsoft para Windows (https://aka.ms/windowscriteria).
Como resultado, esta vulnerabilidade não recebeu seu ID e patch para sua correção. uma fonte
HyperRDP
Após a publicação de informações sobre esta vulnerabilidade, os funcionários da Check Point Research começaram a receber muitos comentários e perguntas, um dos quais despertou genuíno interesse e os levou a voltar a pesquisar mais e olhar a vulnerabilidade de um "ângulo diferente", a saber: pode a vulnerabilidade do cliente Microsoft RDP ser usado no Microsoft Hyper-V?
Como resultado de um estudo mais aprofundado, descobriu-se que no coração da GUI para gerenciamento de VM - gerenciador Hyper-V, a tecnologia RDP é usada nos bastidores, em sessões estendidas das quais, assim como nas propriedades da área de trabalho remota, é possível habilitar uma área de transferência compartilhada. E, como consequência, a mesma vulnerabilidade está presente!
Demonstração de uma vulnerabilidade no Hyper-V da Check Point Research
Os funcionários da Check Point Research falaram sobre isso em seu blog, bem como na conferência Black Hat USA 2019 .
Apresentação de vulnerabilidade na Black Hat USA 2019
E, claro, o MSRC relatou . Desta vez, a Microsoft abriu um tíquete e em outubro de 2019 lançou um patch para corrigir esta vulnerabilidade, que recebeu ID: CVE-2019-0887 . uma fonte
Caminhos inescrutáveis
Depois de analisar a eficácia do patch, quando os especialistas da Check Point Research estavam prestes a atribuir à vulnerabilidade o status "fechado", um usuário do Mac OS RDP Client os contatou com informações sobre o comportamento do cliente após instalar o patch do MS.
No processo de prototipagem do modelo de conexão RDP usando este cliente, ficou claro que o patch em si contém brechas de segurança que permitem contornar a proteção e recriar o exploit original. Isso foi relatado ao MSRC .
Em fevereiro de 2020, a Microsoft se reuniu e lançou um patch para corrigir esta vulnerabilidade CVE-2020-0655., que, de acordo com especialistas da Check Point Research, não resolveu totalmente o problema de ataques path traversal, em particular, para a API do Windows. A Microsoft anunciou sobre este "conjunto" ainda não comentou sobre esta situação. uma fonte
E daí…
Como o leitor astuto pode perceber, um servidor RDP comprometido é necessário para realizar com êxito esse tipo de ataque. E você pode "obtê-lo" de três maneiras:
- Crie o seu próprio e passe-o como legítimo
- Acesse o existente e comprometa-o
- Híbrido
Uma opção relativamente segura e ideal em termos de custos e velocidade de provisionamento nas realidades de hoje seria "assumir" uma nuvem ou servidor VPS / VDS alugado de um provedor de serviços. E há três razões principais para isso:
- Cada servidor virtual alugado executando o Windows já é um servidor RDP por padrão
- Cada servidor virtual alugado rodando Windows, via de regra, já possui uma conta RDP com direitos de administrador e um único login para todos os usuários.
- Regra geral, o acesso RDP ao servidor virtual é efectuado através da porta TCP disponível no endereço IP público: 3389.
Na verdade, essa porta "saliente" é provavelmente o "pano vermelho" para um invasor cibernético que deseja assumir o controle de algum servidor virtual, pegando uma senha para ele usando um método de força bruta automatizado simples. Ou como também é chamado de ataque de força bruta.
Para referência: Um exemplo de um aumento no número de ataques da família Bruteforce.Generic.RDP, fevereiro - abril de 2020 da Kaspersky Lab.

uma fonte
… Mais longe
Para não se tornar uma vítima das situações acima, você pode, é claro, alterar as configurações da conta e as portas RDP padrão, bloquear tentativas de conexão não autorizada usando o firewall do Windows ou programas de terceiros como IPBAN , usar criptografia e certificados e muito, muito mais. Mas, para mim, a maneira mais fácil e rápida de proteger uma conexão RDP a um servidor recém-criado é permitir o acesso RDP a ele apenas de hosts de uma rede confiável.
No RUVDS, isso requer três etapas simples:
- Combine um servidor virtual com computadores que precisam acessá-lo via RDP com uma rede privada virtual. Estou usando - ZeroTier
- :
.
:
—
— . — ZeroTier.
— RDP- . . - RDP- IP- .
Sobre isso quero me despedir e aconselho você a monitorar o "funcionamento" da conexão RDP do seu servidor virtual. Pois, desde CVE-2020-0655, mais três vulnerabilidades com funcionalidade de ataque RDP reverso apareceram .
