maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/linux-hardening/privilege-escalation/nfs-no_root_squash

Browse Source
This commit is contained in:
Translator 2025-02-05 09:39:48 +00:00
parent f470e7bc87
commit 8965d50bd7
2 changed files with 22 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
View File

@ -1,19 +1,19 @@
{{#include ../../banners/hacktricks-training.md}}
# Podstawowe informacje o Squashing
# Podstawowe informacje o Squashingu
NFS zazwyczaj (szczególnie w systemie Linux) ufa wskazanym `uid` i `gid` przez klienta łączącego się w celu uzyskania dostępu do plików (jeśli nie używa się Kerberosa). Istnieją jednak pewne konfiguracje, które można ustawić na serwerze, aby **zmienić to zachowanie**:
- **`all_squash`**: Zmienia wszystkie dostęp do plików, mapując każdego użytkownika i grupę na **`nobody`** (65534 unsigned / -2 signed). W związku z tym, każdy jest `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)**. W związku z tym, 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.
- **`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.
W pliku **/etc/exports**, jeśli znajdziesz jakiś katalog skonfigurowany jako **no_root_squash**, wtedy możesz **uzyskać dostęp** do niego **jako klient** i **zapisywać wewnątrz** tego katalogu **jakbyś był lokalnym** **rootem** maszyny.
Aby uzyskać więcej informacji o **NFS**, sprawdź:
{{#ref}}
/network-services-pentesting/nfs-service-pentesting.md
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Eskalacja uprawnień
@ -21,9 +21,9 @@ Aby uzyskać więcej informacji o **NFS**, sprawdź:
## Zdalny exploit
Opcja 1 używając bash:
- **Zamontowanie tego katalogu** na maszynie klienckiej i **jako root skopiowanie** do zamontowanego folderu binarnego **/bin/bash** i nadanie mu praw **SUID**, a następnie **wykonanie z maszyny ofiary** tego binarnego pliku bash.
- **Zamontowanie tego katalogu** na maszynie klienckiej i **jako root skopiowanie** do zamontowanego folderu binarki **/bin/bash** oraz nadanie jej praw **SUID**, a następnie **wykonanie z maszyny ofiary** tej binarki bash.
- Zauważ, że aby być rootem we współdzielonym zasobie NFS, **`no_root_squash`** musi być skonfigurowane na serwerze.
- Jednak jeśli nie jest włączone, możesz eskalować do innego użytkownika, kopiując binarny plik do zasobu NFS i nadając mu uprawnienia SUID jako użytkownik, do którego chcesz się eskalować.
- Jednak, jeśli nie jest włączone, możesz eskalować do innego użytkownika, kopiując binarkę do zasobu NFS i nadając jej uprawnienia SUID jako użytkownik, do którego chcesz się eskalować.
```bash
#Attacker, as root user
mkdir /tmp/pe
@ -37,8 +37,8 @@ cd <SHAREDD_FOLDER>
./bash -p #ROOT shell
```
Opcja 2 z użyciem skompilowanego kodu C:
- **Zamontowanie tego katalogu** na maszynie klienckiej i **jako root skopiowanie** do zamontowanego folderu naszego skompilowanego ładunku, który wykorzysta uprawnienia SUID, nadanie mu **praw SUID** i **wykonanie z maszyny ofiary** tego binarnego pliku (możesz znaleźć tutaj kilka [ładunków C SUID](payloads-to-execute.md#c)).
- Te same ograniczenia co wcześniej
- **Zamontowanie tego katalogu** na maszynie klienckiej, a następnie **jako root skopiowanie** do zamontowanego folderu naszego skompilowanego ładunku, który wykorzysta uprawnienia SUID, nadanie mu **praw SUID** i **wykonanie z maszyny ofiary** tego binarnego pliku (możesz znaleźć tutaj kilka [ładunków C SUID](payloads-to-execute.md#c)).
- Te same ograniczenia co wcześniej.
```bash
#Attacker, as root user
gcc payload.c -o payload
@ -97,7 +97,7 @@ LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs:/
```
## Bonus: NFShell do dyskretnego dostępu do plików
Gdy uzyskano dostęp do roota, aby interagować z udostępnionym NFS bez zmiany właściciela (aby uniknąć pozostawiania śladów), używany jest skrypt Pythona (nfsh.py). Skrypt ten dostosowuje uid, aby pasował do uid pliku, do którego się uzyskuje dostęp, co pozwala na interakcję z plikami na udostępnieniu bez problemów z uprawnieniami:
Gdy uzyskano dostęp do roota, aby interagować z udostępnionym zasobem NFS bez zmiany właściciela (aby uniknąć pozostawiania śladów), używany jest skrypt Pythona (nfsh.py). Skrypt ten dostosowuje uid, aby odpowiadał uid pliku, do którego uzyskuje się dostęp, co pozwala na interakcję z plikami na udostępnionym zasobie bez problemów z uprawnieniami:
```python
#!/usr/bin/env python
# script from https://www.errno.fr/nfs_privesc.html

28
src/network-services-pentesting/nfs-service-pentesting.md
View File

@ -16,11 +16,11 @@ Zauważalnym aspektem tego protokołu jest zwykle brak wbudowanych mechanizmów
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 squashing.**
**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 udziału NFS. Można to zrobić w pliku Linux `/etc/exports`. Na przykład:
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)
@ -33,7 +33,7 @@ As you can see, it allows to configure a specific **IP** or **hostname** to acce
- **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ła 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. Jej ulepszenia wydajności i przyjęcie protokołu stanowego wyróżniają NFSv4 jako kluczowy postęp w technologiach udostępniania plików w sieci.
- **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ść.
@ -46,9 +46,9 @@ Jak wspomniano wcześniej, NFS zazwyczaj ufa `uid` i `gid` klienta do uzyskania
- **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.
### Subtree check
### 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ę kontrolą 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**.
@ -56,7 +56,7 @@ W systemie Linux funkcja **`subtree_check` jest domyślnie wyłączona**.
### 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óre klienci są połączeni (co może być niedokładne, jeśli klient rozłączy się bez informowania serwera).
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.
@ -75,7 +75,7 @@ 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 **mounts**, 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**.
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
@ -99,9 +99,9 @@ mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
### Zaufanie UID i GID
Oczywiście, jedynym problemem tutaj jest to, że domyślnie nie można udawać roota (`UID` 0). Jednak możliwe jest udawanie innego użytkownika lub, jeśli `no_root_squash` jest włączone, można również udawać roota.
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** (według **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.
- 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
@ -109,7 +109,7 @@ Oczywiście, jedynym problemem tutaj jest to, że domyślnie nie można udawać
Sprawdź stronę:
{{#ref}}
/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}
### Ucieczka z eksportów
@ -118,15 +118,15 @@ W tym [świetnym artykule](https://www.hvs-consulting.de/en/nfs-security-identif
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 przechowywanie webshella w `/var/www/`.
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/`.
Co więcej, zauważ, że domyślnie tylko użytkownik root (0) jest chroniony przed udawaniem (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!
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 oraz GID, aby uzyskać dostęp do plików, możesz użyć [nfsshell](https://github.com/NetDirect/nfsshell).
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/)
@ -145,7 +145,7 @@ Aby łatwo wylistować, zamontować i zmienić UID oraz GID, aby uzyskać dostę
- **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 prawidłowo obsługiwane.
- **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