Machine name: Explosion
Address: https://app.hackthebox.com/starting-point
Introdução
Em um ambiente corporativo, os funcionários frequentemente precisam de ajuda de seus colegas, especialmente ao utilizar ferramentas técnicas em seus sistemas Windows. Essas ferramentas podem variar desde interceptadores de pacotes de rede, que monitoram a comunicação entre hosts, até editores de scripts para automatizar tarefas rotineiras, além de ferramentas de acesso remoto que permitem a conexão com outros sistemas (Linux ou Windows) para oferecer suporte a colegas ou clientes.
Neste caso, vamos explorar os riscos associados a configurações inadequadas dessas ferramentas de acesso remoto. Vale ressaltar que o software de acesso remoto não é, por si só, malicioso ou perigoso; é uma maneira legítima dos funcionários acessarem outros sistemas para realizar ações ou fornecer suporte. O protocolo principal utilizado por essas ferramentas é o RDP (Remote Desktop Protocol), que opera nas portas 3389 TCP e 3389 UDP.
A principal diferença entre as ferramentas de acesso remoto está na interface utilizada para a comunicação. Algumas oferecem uma Interface de Linha de Comando (CLI), enquanto outras utilizam uma Interface Gráfica (GUI). Ambas as interfaces dependem do RDP para transmitir informações entre o cliente e o host, mas o método de apresentação varia conforme a ferramenta utilizada.
CLI – Remote Access Tools
As ferramentas de Acesso Remoto baseadas em Interface de Linha de Comando (CLI) existem há muito tempo. Um exemplo rudimentar disso é o Telnet. Em sua configuração mais básica, o Telnet é considerado inseguro por não possuir a capacidade de criptografar os dados transmitidos de forma segura. Isso significa que um atacante com acesso a um ponto de acesso à rede (TAP – Traffic Access Point) poderia facilmente interceptar os pacotes enviados por uma conexão Telnet e ler seu conteúdo, seja credenciais de login, arquivos sensíveis ou qualquer outro dado. O Telnet, que por padrão utiliza a porta 23 TCP, foi em grande parte substituído por uma ferramenta mais segura, o SSH (Secure Shell), que utiliza a porta 22 TCP por padrão.
O SSH, que significa Protocolo de Shell Seguro. Ele adiciona camadas necessárias de autenticação e criptografia ao modelo de comunicação, tornando-o uma abordagem muito mais viável para realizar acessos remotos e transferências de arquivos de maneira segura. Ele é utilizado tanto para entrega de patches, transferências de arquivos, transferências de logs, quanto para gerenciamento remoto nos ambientes atuais.
O SSH utiliza a criptografia de chave pública para verificar a identidade do host remoto, e seu modelo de comunicação é baseado na arquitetura Cliente-Servidor. O host local usa a chave pública do servidor para verificar sua identidade antes de estabelecer a conexão criptografada do túnel. Uma vez que o túnel é estabelecido, métodos de criptografia simétrica e algoritmos de hash são usados para garantir a confidencialidade e a integridade dos dados transmitidos através do túnel.
No entanto, tanto o Telnet quanto o SSH oferecem ao usuário final apenas acesso à parte terminal remota do host que está sendo acessado. Isso significa que não há projeção de tela com essas ferramentas. Para poder visualizar a tela remota do host, é possível recorrer a ferramentas baseadas em CLI, como o xfreerdp.
Essas ferramentas são chamadas de Ferramentas de Área de Trabalho Remota, apesar de fazerem parte da família de Ferramentas de Acesso Remoto. A razão para isso é que toda a área de trabalho pode ser controlada remotamente pelo usuário que inicia a conexão, como se estivesse fisicamente na sala com o host remoto, usando seu teclado, mouse e display para interagir com ele, incluindo a capacidade de visualizar conteúdo gráfico, controlar o ponteiro do mouse e a entrada do teclado, interagir facilmente com o navegador da web e muito mais.
Neste cenário, usaremos o xfreerdp para nos conectar ao alvo e obter uma projeção de área de trabalho remota em nossa tela. Analisaremos os detalhes dessa ferramenta mais adiante no texto.
GUI – Remote Access Tools
Ferramentas de Acesso Remoto Baseadas em Interface Gráfica de Usuário (GUI) são mais recentes na família do que as baseadas em CLI. Embora essas ferramentas sejam antigas, a tecnologia continuou a evoluir, tornando a interação do usuário com o software e o host remoto mais fácil e intuitiva para o usuário comum. Esse tipo de ferramenta permite apenas conexões de Área de Trabalho Remota, não havendo necessidade de uma ferramenta baseada em GUI que ofereça apenas conexão de terminal, como acontece com o Telnet e o SSH.
Duas das ferramentas de Área de Trabalho Remota mais comuns são o TeamViewer e o Conexão de Área de Trabalho Remota do Windows, anteriormente conhecida como Terminal Services Client.
A captura de tela abaixo mostra a interface do TeamViewer. Ela possui um ID de host intitulado “Your ID” (Seu ID) e uma senha gerada aleatoriamente logo abaixo dele. Para que um host remoto se conecte à sua máquina, ele precisará de ambos os códigos. Como a senha é exigida por padrão para qualquer tipo de conexão remota e é gerada aleatoriamente, uma versão atualizada do TeamViewer pode ser mais segura do que outros softwares mais simples. O TeamViewer não vem pré-instalado em nenhum sistema operacional, sendo necessário fazer o download e a instalação manualmente a partir de um repositório ou do site oficial do TeamViewer.
Softwares mais simples que rodam nativamente podem, às vezes, ser mal configurados, pois a experiência do usuário, especialmente para usuários inexperientes, nem sempre é um fator chave ao desenvolver ferramentas técnicas integradas com alguns sistemas operacionais. Um exemplo disso é a Conexão de Área de Trabalho Remota do Windows. O Microsoft Remote Desktop Connection roda nativamente no Windows, o que significa que ele vem pré-instalado em todos os sistemas operacionais Windows como um serviço, sem que o usuário final precise realizar qualquer ação além de ativar o serviço e configurar seus parâmetros. É aqui que alguns erros de configuração acontecem, o que nos leva a casos como o mostrado abaixo.
Enumeração
Começamos, como sempre, com uma varredura nmap, resultando em portas abertas que estão executando o RDP. Realizamos a varredura com a opção de detecção de versão ativada para determinar as versões exatas de todos os serviços em execução nas portas abertas do alvo, permitindo assim avaliar o sistema operacional real da máquina e identificar quaisquer vulnerabilidades potenciais devido a softwares desatualizados.
Sempre é uma boa ideia pesquisar as portas encontradas para entender melhor o contexto. O SpeedGuide é um bom recurso para quem está começando com os conceitos básicos de redes e quer entender mais rapidamente as portas comuns. Abaixo estão alguns exemplos:
Port 135 TCP : https://www.speedguide.net/port.php?port=135
Port 139 TCP : https://www.speedguide.net/port.php?port=139
Port 445 TCP : https://www.speedguide.net/port.php?port=445
Port 3389 TCP : https://www.speedguide.net/port.php?port=3389
Port 5357 TCP : https://www.speedguide.net/port.php?port=5357
Olhando a entrada do SpeedGuide para a porta 3389 TCP, consideramos ela interessante. Essa porta é tipicamente usada para conexões de Área de Trabalho Remota do Windows e Assistência Remota (via RDP – Remote Desktop Protocol). Podemos verificar rapidamente se há alguma má configuração no controle de acesso tentando nos conectar a essa porta disponível, sem credenciais válidas, o que confirmará se o serviço permite conexões de convidados ou anônimas.
Foothold
Como mencionado anteriormente, usaremos o xfreerdp para conectar a partir da nossa máquina virtual Parrot Security. Você pode verificar se o xfreerdp está instalado digitando o comando no terminal. Se o menu de ajuda do script for exibido no terminal, significa que está pronto para ser utilizado. Na captura de tela a seguir, omitimos uma grande parte da saída por questões de espaço. O menu de ajuda desse script é extenso, e você pode encontrar muitas informações sobre a funcionalidade de cada opção se ler com atenção.
Se você precisar instalar o xfreerdp, pode seguir com o seguinte comando:
sudo apt install freerdp2-x11 -y
Em seguida, podemos tentar iniciar uma sessão RDP com o alvo, sem fornecer nenhuma informação adicional para as opções, além do endereço IP do alvo. Isso fará com que o script utilize o seu próprio nome de usuário como o nome de usuário de login para a sessão RDP, testando assim as capacidades de login de convidado.
Exemplo de comando para iniciar a sessão:
xfreerdp /v:{target_IP}
Onde {target_IP} deve ser substituído pelo endereço IP do alvo.
Como podemos ver na saída abaixo, nosso próprio nome de usuário não é aceito pelo mecanismo de login da sessão RDP. Podemos tentar uma série de outras contas padrões, como user, admin, Administrator, e assim por diante. Na prática, esse seria um processo demorado. No entanto, para fins de exploração do RDP, vamos tentar fazer login com o usuário Administrator, conforme mostrado nos comandos abaixo. Também vamos especificar no script que gostaríamos de ignorar todos os requisitos de certificado de segurança, para que nosso script não solicite nenhum. O alvo, neste caso, já não exige nenhum. Vamos dar uma olhada nos parâmetros que precisaremos usar com o xfreerdp para nos conectar com sucesso ao nosso alvo neste cenário:
/cert:ignore: Informa ao script que todos os certificados de segurança devem ser ignorados.
/u:Administrator: Especifica que o nome de usuário para login será “Administrator”.
/v:{target_IP}: Especifica o IP de destino do host ao qual queremos nos conectar.
O resultado é diferente desta vez, e durante a inicialização da sessão RDP, somos solicitados a fornecer uma Senha. No nosso caso, a conta Administrator não foi configurada com uma senha de login, visando facilitar o acesso para o usuário final. Isso é um erro grave de configuração, que permite que o atacante, no caso nós, acessemos a máquina sem grandes dificuldades. Quando solicitados a inserir a senha, como mostrado na saída acima, podemos simplesmente pressionar Enter para continuar o processo sem fornecer uma senha.
Após isso, uma grande quantidade de informações será exibida no terminal antes de uma janela de área de trabalho remota ser carregada. A flag que estamos procurando está localizada na área de trabalho.
Para encontrar a flag, basta abrir o arquivo com o mesmo nome na área de trabalho.
Question 01: What does the 3-letter acronym RDP stand for?
Remote Desktop Protocol
Question 02: What is a 3-letter acronym that refers to interaction with the host through a command line interface?
cli
Question 03: What about graphical user interface interactions?
gui
Question 04: What is the name of an old remote access tool that came without encryption by default and listens on TCP port 23?
telnet
Question 05: What is the name of the service running on port 3389 TCP?
ms-wbt-server
Question 06 : What is the switch used to specify the target host’s IP address when using xfreerdp?
/v:
Question 07: What username successfully returns a desktop projection to us with a blank password?
Vamos iniciar investigando o serviço com o comando:
xfreerdp /v:10.129.55.62
A partir da saída mostrada acima, fica claro que nosso próprio nome de usuário não é permitido para login na sessão RDP. Podemos tentar várias outras contas padrão, como user, admin, administrator e opções semelhantes. Na prática, isso levaria um tempo considerável. No entanto, para continuar explorando a configuração do RDP, vamos tentar fazer login com a conta Administrator, conforme demonstrado nos comandos abaixo.
xfreerdp /v:10.129.55.62 /cert:ignore /u:Administrator
- /cert:ignore : Specifies to the scrips that all security certificate usage should be ignored.
- /u:Administrator : Specifies the login username to be “Administrator”.
- /v:{target_IP} : Specifies the target IP of the host we would like to connect to.
Coloque uma senha em branco e pressione Enter:
Abra o arquivo
951fa96d7830c451b536be5a6be008a0