hacktricks/src/network-services-pentesting/nfs-service-pentesting.md

# 2049 - Pentesting NFS Service

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

## **Podstawowe informacje**

**NFS** to system zaprojektowany dla **klient/serwer**, który umożliwia użytkownikom bezproblemowy dostęp do plików w sieci, tak jakby te pliki znajdowały się w lokalnym katalogu.

**Domyślny port**: 2049/TCP/UDP (z wyjątkiem wersji 4, potrzebuje tylko TCP lub UDP).
```
2049/tcp open  nfs     2-3 (RPC #100003
```
### Autoryzacja

Zauważalnym aspektem tego protokołu jest zwykle brak wbudowanych mechanizmów **autoryzacji** lub **uwierzytelniania**. Zamiast tego, autoryzacja opiera się na **informacjach o systemie plików**, a serwer ma za zadanie dokładne przetłumaczenie **informacji o użytkowniku dostarczonych przez klienta** na wymagany przez system plików **format autoryzacji**, głównie zgodnie z **składnią UNIX**.

Uwierzytelnianie zazwyczaj opiera się na **identyfikatorach `UID`/`GID` UNIX oraz członkostwie w grupach**. Jednak pojawia się problem z powodu potencjalnego niedopasowania w **mapowaniach `UID`/`GID`** między klientami a serwerami, co nie pozostawia miejsca na dodatkową weryfikację przez serwer. Co więcej, te szczegóły są wysyłane przez klienta i ufane przez serwer, więc złośliwy klient mógłby potencjalnie **podszyć się pod innego użytkownika, wysyłając bardziej uprzywilejowane `uid` i `gid`.

**Należy jednak zauważyć, że domyślnie nie jest możliwe podszywanie się pod `UID` 0 (root) przy użyciu NFS. Więcej na ten temat w sekcji o squashing.**

#### Hosty

Aby uzyskać lepszą (lub jakąkolwiek) autoryzację, możesz określić **hosty**, które mogą uzyskać dostęp do udostępnionego zasobu NFS. Można to zrobić w pliku Linux `/etc/exports`. Na przykład:
```
/PATH/TO/EXPORT      CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ...
/media/disk/share   192.168.2.123(rw,sec=krb5p:krb5i)
```
As you can see, it allows to configure a specific **IP** or **hostname** to access the share. Only that address will be able to access the share.

### Wersje

- **NFSv2**: Ta wersja jest rozpoznawana za swoją szeroką kompatybilność z różnymi systemami, co podkreśla jej znaczenie w początkowych operacjach głównie przez UDP. Będąc **najstarszą** w serii, położyła fundamenty pod przyszłe rozwój.

- **NFSv3**: Wprowadzona z szeregiem ulepszeń, NFSv3 rozszerzyła możliwości swojego poprzednika, wspierając zmienne rozmiary plików i oferując ulepszone mechanizmy raportowania błędów. Pomimo swoich postępów, napotkała ograniczenia w pełnej kompatybilności wstecznej z klientami NFSv2.

- **NFSv4**: Kamieni milowy w serii NFS, NFSv4 wprowadził zestaw funkcji zaprojektowanych w celu modernizacji udostępniania plików w sieciach. Znaczące ulepszenia obejmują integrację Kerberos dla **wysokiego bezpieczeństwa**, zdolność do przechodzenia przez zapory i działania przez Internet bez potrzeby używania portmapperów, wsparcie dla list kontroli dostępu (ACL) oraz wprowadzenie operacji opartych na stanie. Ulepszenia wydajności i przyjęcie protokołu stanowego wyróżniają NFSv4 jako kluczowy postęp w technologiach udostępniania plików w sieci.
- Zauważ, że bardzo dziwne jest znalezienie hosta Linux NFS wspierającego uwierzytelnianie kerberos.

Każda wersja NFS została opracowana z zamiarem zaspokojenia ewoluujących potrzeb środowisk sieciowych, stopniowo poprawiając bezpieczeństwo, kompatybilność i wydajność.

### Squashing

Jak wspomniano wcześniej, NFS zazwyczaj ufa `uid` i `gid` klienta do uzyskania dostępu do plików (jeśli nie używa się kerberos). Istnieją jednak pewne konfiguracje, które można ustawić na serwerze, aby **zmienić to zachowanie**:

- **all_squash**: Zmienia wszystkie dostęp do mapowania każdego użytkownika i grupy na **`nobody`** (65534 unsigned / -2 signed). Dlatego wszyscy są `nobody` i żaden użytkownik nie jest używany.
- **root_squash/no_all_squash**: To jest domyślne w systemie Linux i **tylko zmienia dostęp z uid 0 (root)**. Dlatego każdy `UID` i `GID` są ufane, ale `0` jest zmieniane na `nobody` (więc nie ma możliwości podszywania się pod roota).
- **no_root_squash**: Ta konfiguracja, jeśli jest włączona, nie zmienia nawet użytkownika root. Oznacza to, że jeśli zamontujesz katalog z tą konfiguracją, możesz uzyskać do niego dostęp jako root.

### Sprawdzenie poddrzewa

Dostępne tylko w systemie Linux. man(5) exports mówi: "Jeśli podkatalog systemu plików jest eksportowany, ale cały system plików nie, to za każdym razem, gdy przychodzi żądanie NFS, serwer musi sprawdzić nie tylko, że dostępny plik znajduje się w odpowiednim systemie plików (co jest łatwe), ale także, że znajduje się w eksportowanym drzewie (co jest trudniejsze). Ta kontrola nazywa się sprawdzeniem poddrzewa."

W systemie Linux funkcja **`subtree_check` jest domyślnie wyłączona**.

## Enumeracja

### Showmount

Można to wykorzystać do **uzyskania informacji z serwera NFSv3**, takich jak lista **eksportów**, kto ma **prawo dostępu** do tych eksportów oraz którzy klienci są połączeni (co może być niedokładne, jeśli klient rozłączy się bez informowania serwera).
W **klientach NFSv4 po prostu bezpośrednio uzyskują dostęp do / export** i próbują uzyskać dostęp do eksportów stamtąd, nie udaje się, jeśli jest to nieprawidłowe lub nieautoryzowane z jakiegokolwiek powodu.

Jeśli narzędzia takie jak `showmount` lub moduły Metasploit nie pokazują informacji z portu NFS, to potencjalnie jest to serwer NFSv4, który nie wspiera wersji 3.
```bash
showmount -e <IP>
```
### Przydatne skrypty nmap
```bash
nfs-ls #List NFS exports and check permissions
nfs-showmount #Like showmount -e
nfs-statfs #Disk statistics and info from NFS share
```
### Przydatne moduły metasploit
```bash
scanner/nfs/nfsmount #Scan NFS mounts and list permissions
```
### nfs_analyze

To narzędzie z [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) może być używane do uzyskania wielu danych z serwera NFS, takich jak **montaże**, obsługiwane wersje NFS, podłączone adresy IP, a nawet czy możliwe jest **ucieczka z eksportów** do innych folderów w FS lub **czy `no_root_squash` jest włączone**.


## Mounting

Aby dowiedzieć się, **który folder** jest **dostępny** na serwerze do zamontowania, możesz zapytać go używając:
```bash
showmount -e <IP>
```
Następnie zamontuj to używając:
```bash
mount -t nfs [-o vers=2] <ip>:<remote_folder> <local_folder> -o nolock
```
Powinieneś określić, aby **używać wersji 2**, ponieważ nie ma **żadnej** **autoryzacji** ani **uwierzytelniania**.

**Przykład:**
```bash
mkdir /mnt/new_back
mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
```
## Ataki

### Zaufanie UID i GID

Oczywiście, jedynym problemem tutaj jest to, że domyślnie nie można podszyć się pod roota (`UID` 0). Jednak możliwe jest podszywanie się pod innego użytkownika lub, jeśli `no_root_squash` jest włączone, można również podszyć się pod roota.

- Jeśli zamontujesz folder, który zawiera **pliki lub foldery dostępne tylko dla niektórego użytkownika** (przez **UID**). Możesz **utworzyć** **lokalnie** użytkownika z tym **UID** i używając tego **użytkownika** będziesz mógł **uzyskać dostęp** do pliku/folderu.
- Narzędzie **`fuse_nfs`** z [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) zawsze będzie wysyłać potrzebne UID i GID do uzyskania dostępu do plików.

### Eskalacja uprawnień SUID

Sprawdź stronę:

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

### Ucieczka z eksportów

W tym [świetnym artykule](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) można zobaczyć, że możliwe jest **uciekanie z eksportów, aby uzyskać dostęp do innych folderów w systemie plików**.

Dlatego, jeśli eksportuje folder, który jest **podfolderem** **całego systemu plików**, możliwe jest uzyskanie dostępu do plików poza eksportem, jeśli **`subtree_check`** jest wyłączone. A jest **wyłączone domyślnie w Linuksie**.

Na przykład, jeśli serwer NFS eksportuje `/srv/` a `/var/` znajduje się w tym samym systemie plików, możliwe jest odczytanie logów z `/var/log/` lub umieszczenie webshella w `/var/www/`.

Ponadto, zauważ, że domyślnie tylko użytkownik root (0) jest chroniony przed podszywaniem się (sprawdź sekcję Squash). Jednak jeśli plik jest **własnością roota, ale grupa nie jest 0, możliwe jest uzyskanie do niego dostępu**. Na przykład plik `/etc/shadow` jest własnością roota, ale grupa to `shadow` (gid 42 w Debianie). Dlatego można go odczytać domyślnie!

Narzędzie **`nfs_analyze`** z [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) zostało stworzone, aby wspierać ten atak przeciwko systemom plików ext4, xfs, btrfs w wersji 3 (powinno być również możliwe w v4).

### NSFShell

Aby łatwo wylistować, zamontować i zmienić UID i GID, aby uzyskać dostęp do plików, możesz użyć [nfsshell](https://github.com/NetDirect/nfsshell).

[Ładny samouczek NFSShell.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)

## Pliki konfiguracyjne
```
/etc/exports
/etc/lib/nfs/etab
```
## Niebezpieczne ustawienia

- **Uprawnienia do odczytu i zapisu (`rw`):** To ustawienie pozwala na zarówno odczyt, jak i zapis w systemie plików. Ważne jest, aby rozważyć konsekwencje przyznawania tak szerokiego dostępu.

- **Użycie niebezpiecznych portów (`insecure`):** Po włączeniu, to pozwala systemowi na korzystanie z portów powyżej 1024. Bezpieczeństwo portów powyżej tego zakresu może być mniej rygorystyczne, co zwiększa ryzyko.

- **Widoczność zagnieżdżonych systemów plików (`nohide`):** Ta konfiguracja sprawia, że katalogi są widoczne, nawet jeśli inny system plików jest zamontowany poniżej eksportowanego katalogu. Każdy katalog wymaga własnego wpisu eksportu dla prawidłowego zarządzania.

- **Własność plików root (`no_root_squash`):** Przy tym ustawieniu pliki tworzone przez użytkownika root zachowują swój oryginalny UID/GID równy 0, ignorując zasadę najmniejszych uprawnień i potencjalnie przyznając nadmierne uprawnienia.

- **Brak zbijania wszystkich użytkowników (`no_all_squash`):** Ta opcja zapewnia, że tożsamości użytkowników są zachowywane w całym systemie, co może prowadzić do problemów z uprawnieniami i kontrolą dostępu, jeśli nie jest odpowiednio obsługiwane.

## Eskalacja uprawnień przy użyciu błędnych konfiguracji NFS

[NFS no_root_squash i no_all_squash eskalacja uprawnień](../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md)

## Automatyczne polecenia 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}}