# 2049 - Pentesting NFS Service

{{#include ../banners/hacktricks-training.md}}

## **Informações Básicas**

**NFS** é um sistema projetado para **cliente/servidor** que permite aos usuários acessar arquivos de forma contínua através de uma rede como se esses arquivos estivessem localizados em um diretório local.

**Porta padrão**: 2049/TCP/UDP (exceto a versão 4, que precisa apenas de TCP ou UDP).
```
2049/tcp open  nfs     2-3 (RPC #100003
```
### Autenticação

Um aspecto notável deste protocolo é sua habitual falta de **mecanismos de autenticação** ou **autorização** embutidos. Em vez disso, a autorização depende das **informações do sistema de arquivos**, com o servidor encarregado de traduzir com precisão as **informações do usuário fornecidas pelo cliente** no formato de **autorização** exigido pelo sistema de arquivos, seguindo principalmente a **sintaxe UNIX**.

A autenticação comumente depende de **identificadores `UID`/`GID` do UNIX e associações a grupos**. No entanto, um desafio surge devido ao potencial descompasso nas **mapeações `UID`/`GID`** entre clientes e servidores, não deixando espaço para verificação adicional pelo servidor. Além disso, esses detalhes são enviados pelo cliente e confiados pelo servidor, de modo que um cliente mal-intencionado poderia potencialmente **se passar por outro usuário enviando `uid` e `gid` mais privilegiados**.

**No entanto, observe que, por padrão, não é possível se passar pelo `UID` 0 (root) usando NFS. Mais sobre isso na seção de squashing.**

#### Hosts

Para uma melhor (ou alguma) autorização, você pode especificar os **hosts** que podem acessar o compartilhamento NFS. Isso pode ser feito no arquivo `/etc/exports` do Linux. Por exemplo:
```
/PATH/TO/EXPORT      CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ...
/media/disk/share   192.168.2.123(rw,sec=krb5p:krb5i)
```
Como você pode ver, ele permite configurar um **IP** ou **hostname** específico para acessar o compartilhamento. Somente esse endereço poderá acessar o compartilhamento.

### Versões

- **NFSv2**: Esta versão é reconhecida por sua ampla compatibilidade com vários sistemas, marcando sua importância com operações iniciais predominantemente sobre UDP. Sendo a **mais antiga** da série, ela lançou as bases para desenvolvimentos futuros.

- **NFSv3**: Introduzido com uma série de melhorias, o NFSv3 expandiu seu predecessor ao suportar tamanhos de arquivo variáveis e oferecer mecanismos de relatórios de erro aprimorados. Apesar de seus avanços, enfrentou limitações na compatibilidade total com clientes NFSv2.

- **NFSv4**: Uma versão marcante na série NFS, o NFSv4 trouxe um conjunto de recursos projetados para modernizar o compartilhamento de arquivos em redes. Melhorias notáveis incluem a integração do Kerberos para **alta segurança**, a capacidade de atravessar firewalls e operar pela Internet sem a necessidade de portmappers, suporte para Listas de Controle de Acesso (ACLs) e a introdução de operações baseadas em estado. Suas melhorias de desempenho e a adoção de um protocolo com estado distinguem o NFSv4 como um avanço crucial nas tecnologias de compartilhamento de arquivos em rede.
- Note que é muito estranho encontrar um host Linux NFS suportando autenticação kerberos.

Cada versão do NFS foi desenvolvida com a intenção de atender às necessidades em evolução dos ambientes de rede, aprimorando progressivamente a segurança, compatibilidade e desempenho.

### Squashing

Como mencionado anteriormente, o NFS geralmente confiará no `uid` e `gid` do cliente para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:

- **all_squash**: Ele reduz todos os acessos mapeando cada usuário e grupo para **`nobody`** (65534 unsigned / -2 signed). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **root_squash/no_all_squash**: Este é o padrão no Linux e **apenas reduz o acesso com uid 0 (root)**. Portanto, qualquer `UID` e `GID` são confiáveis, mas `0` é reduzido a `nobody` (então nenhuma impersonação de root é possível).
- **no_root_squash**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, poderá acessá-lo como root.

### Subtree check

Disponível apenas no Linux. man(5) exports diz: "Se um subdiretório de um sistema de arquivos for exportado, mas o sistema de arquivos inteiro não, então sempre que um pedido NFS chegar, o servidor deve verificar não apenas se o arquivo acessado está no sistema de arquivos apropriado (o que é fácil), mas também se está na árvore exportada (o que é mais difícil). Esta verificação é chamada de verificação de subárvore."

No Linux, o **recurso `subtree_check` está desativado** por padrão.

## Enumeração

### Showmount

Isso pode ser usado para **obter informações de um servidor NFSv3**, como a lista de **exports**, quem está **autorizado a acessar** esses exports e quais clientes estão conectados (o que pode ser impreciso se um cliente desconectar sem avisar o servidor).
Nos **clientes NFSv4, eles acessam diretamente o / export** e tentam acessar exports a partir daí, falhando se for inválido ou não autorizado por qualquer motivo.

Se ferramentas como `showmount` ou módulos do Metasploit não mostrarem informações de uma porta NFS, é potencialmente um servidor NFSv4 que não suporta a versão 3.
```bash
showmount -e <IP>
```
### Scripts nmap úteis
```bash
nfs-ls #List NFS exports and check permissions
nfs-showmount #Like showmount -e
nfs-statfs #Disk statistics and info from NFS share
```
### Módulos úteis do metasploit
```bash
scanner/nfs/nfsmount #Scan NFS mounts and list permissions
```
### nfs_analyze

Esta ferramenta de [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) pode ser usada para obter muitos dados de um servidor NFS, como **montagens**, versões NFS suportadas, IPs conectados e até mesmo se é possível **escapar das exportações** para outras pastas no FS ou **se `no_root_squash` está habilitado**.

## Mounting

Para saber **qual pasta** o servidor tem **disponível** para montar, você pode perguntar usando:
```bash
showmount -e <IP>
```
Então monte-o usando:
```bash
mount -t nfs [-o vers=2] <ip>:<remote_folder> <local_folder> -o nolock
```
Você deve especificar para **usar a versão 2** porque ela não tem **nenhuma** **autenticação** ou **autorização**.

**Exemplo:**
```bash
mkdir /mnt/new_back
mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
```
## Ataques

### Confiando no UID e GID

Claro, o único problema aqui é que, por padrão, não é possível se passar por root (`UID` 0). No entanto, é possível se passar por qualquer outro usuário ou, se `no_root_squash` estiver habilitado, você também pode se passar por root.

- Se você montar uma pasta que contém **arquivos ou pastas acessíveis apenas por algum usuário** (por **UID**). Você pode **criar** **localmente** um usuário com esse **UID** e, usando esse **usuário**, você poderá **acessar** o arquivo/pasta.
- A ferramenta **`fuse_nfs`** de [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) basicamente sempre enviará o UID e GID necessários para acessar os arquivos.

### Escalação de Privilégios SUID

Verifique a página:

{{#ref}}
../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}

### Escapando das exportações

Neste [ótimo artigo](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) é possível ver que é possível **escapar das exportações para acessar outras pastas no FS**.

Portanto, se uma exportação estiver exportando uma pasta que é uma **subpasta** do **sistema de arquivos inteiro**, é possível acessar arquivos fora da exportação se **`subtree_check`** estiver desativado. E está **desativado por padrão no Linux**.

Por exemplo, se um servidor NFS estiver exportando `/srv/` e `/var/` estiver no mesmo sistema de arquivos, é possível ler logs de `/var/log/` ou armazenar um webshell em `/var/www/`.

Além disso, note que, por padrão, apenas o usuário root (0) está protegido contra ser impersonado (verifique a seção Squash). No entanto, se um arquivo for **possuído por root, mas o grupo não for 0, é possível acessá-lo**. Por exemplo, o arquivo `/etc/shadow` é possuído por root, mas o grupo é `shadow` (gid 42 no Debian). Portanto, é possível lê-lo por padrão!

A ferramenta **`nfs_analyze`** de [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) foi criada para suportar esse ataque contra os sistemas de arquivos ext4, xfs, btrfs na versão 3 (também deve ser possível na v4).

### NSFShell

Para listar, montar e mudar facilmente o UID e GID para ter acesso a arquivos, você pode usar [nfsshell](https://github.com/NetDirect/nfsshell).

[Ótimo tutorial sobre NFSShell.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)

## Arquivos de configuração
```
/etc/exports
/etc/lib/nfs/etab
```
## Configurações Perigosas

- **Permissões de Leitura e Escrita (`rw`):** Esta configuração permite tanto a leitura quanto a escrita no sistema de arquivos. É essencial considerar as implicações de conceder acesso tão amplo.

- **Uso de Portas Inseguras (`insecure`):** Quando ativado, isso permite que o sistema utilize portas acima de 1024. A segurança das portas acima desse intervalo pode ser menos rigorosa, aumentando o risco.

- **Visibilidade de Sistemas de Arquivos Aninhados (`nohide`):** Esta configuração torna diretórios visíveis mesmo que outro sistema de arquivos esteja montado abaixo de um diretório exportado. Cada diretório requer sua própria entrada de exportação para gerenciamento adequado.

- **Propriedade de Arquivos do Root (`no_root_squash`):** Com esta configuração, arquivos criados pelo usuário root mantêm seu UID/GID original de 0, desconsiderando o princípio do menor privilégio e potencialmente concedendo permissões excessivas.

- **Não Squashing de Todos os Usuários (`no_all_squash`):** Esta opção garante que as identidades dos usuários sejam preservadas em todo o sistema, o que pode levar a problemas de permissão e controle de acesso se não for tratado corretamente.

## Escalada de Privilégios usando Configurações Incorretas do NFS

[NFS no_root_squash e no_all_squash escalada de privilégios](../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md)

## Comandos Automáticos HackTricks
```
Protocol_Name: NFS    #Protocol Abbreviation if there is one.
Port_Number:  2049     #Comma separated if there is more than one.
Protocol_Description: Network File System         #Protocol Abbreviation Spelled out

Entry_1:
Name: Notes
Description: Notes for NFS
Note: |
NFS is a system designed for client/server that enables users to seamlessly access files over a network as though these files were located within a local directory.

#apt install nfs-common
showmount 10.10.10.180      ~or~showmount -e 10.10.10.180
should show you available shares (example /home)

mount -t nfs -o ver=2 10.10.10.180:/home /mnt/
cd /mnt
nano into /etc/passwd and change the uid (probably 1000 or 1001) to match the owner of the files if you are not able to get in

https://book.hacktricks.wiki/en/network-services-pentesting/nfs-service-pentesting.html

Entry_2:
Name: Nmap
Description: Nmap with NFS Scripts
Command: nmap --script=nfs-ls.nse,nfs-showmount.nse,nfs-statfs.nse -p 2049 {IP}
```
{{#include ../banners/hacktricks-training.md}}