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:10 +00:00
parent f4bdaeb3bd
commit 0f1b4ba79d
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -6,14 +6,14 @@ NFS di solito (soprattutto in linux) si fida del `uid` e `gid` indicati dal clie
- **`all_squash`**: Squasha tutti gli accessi mappando ogni utente e gruppo a **`nobody`** (65534 unsigned / -2 signed). Pertanto, tutti sono `nobody` e non vengono utilizzati utenti.
- **`root_squash`/`no_all_squash`**: Questo è il valore predefinito su Linux e **squasha solo l'accesso con uid 0 (root)**. Pertanto, qualsiasi `UID` e `GID` sono fidati, ma `0` è squashed a `nobody` (quindi non è possibile impersonare root).
- **``no_root_squash`**: Questa configurazione, se abilitata, non squasha nemmeno l'utente root. Ciò significa che se monti una directory con questa configurazione, puoi accedervi come root.
- **``no_root_squash`**: Questa configurazione, se abilitata, non squasha nemmeno l'utente root. Questo significa che se monti una directory con questa configurazione, puoi accedervi come root.
Nel file **/etc/exports**, se trovi qualche directory configurata come **no_root_squash**, allora puoi **accedervi** da **client** e **scrivere all'interno** di quella directory **come** se fossi il **root** locale della macchina.
Per ulteriori informazioni su **NFS** controlla:
{{#ref}}
/network-services-pentesting/nfs-service-pentesting.md
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Escalation dei Privilegi
@ -21,9 +21,9 @@ Per ulteriori informazioni su **NFS** controlla:
## Exploit Remoto
Opzione 1 usando bash:
- **Montare quella directory** in una macchina client e **come root copiare** all'interno della cartella montata il **/bin/bash** binario e dargli diritti **SUID**, ed **eseguire dalla macchina vittima** quel binario bash.
- **Montare quella directory** in una macchina client e **come root copiare** all'interno della cartella montata il **/bin/bash** binario e dargli i diritti **SUID**, ed **eseguire dalla macchina vittima** quel binario bash.
- Nota che per essere root all'interno della condivisione NFS, **`no_root_squash`** deve essere configurato nel server.
- Tuttavia, se non abilitato, potresti elevare i privilegi a un altro utente copiando il binario nella condivisione NFS e dandogli il permesso SUID come l'utente a cui vuoi elevare i privilegi.
- Tuttavia, se non è abilitato, potresti escalare a un altro utente copiando il binario nella condivisione NFS e dandogli il permesso SUID come l'utente a cui vuoi escalare.
```bash
#Attacker, as root user
mkdir /tmp/pe
@ -62,7 +62,7 @@ cd <SHAREDD_FOLDER>
## Basic Information
Lo scenario prevede di sfruttare una condivisione NFS montata su una macchina locale, sfruttando un difetto nella specifica NFSv3 che consente al client di specificare il proprio uid/gid, potenzialmente abilitando l'accesso non autorizzato. Lo sfruttamento comporta l'uso di [libnfs](https://github.com/sahlberg/libnfs), una libreria che consente la falsificazione delle chiamate RPC NFS.
Lo scenario prevede di sfruttare una condivisione NFS montata su una macchina locale, sfruttando un difetto nella specifica NFSv3 che consente al client di specificare il proprio uid/gid, potenzialmente abilitando l'accesso non autorizzato. Lo sfruttamento coinvolge l'uso di [libnfs](https://github.com/sahlberg/libnfs), una libreria che consente la falsificazione delle chiamate RPC NFS.
### Compiling the Library
@ -95,7 +95,7 @@ LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs:/
/mnt/share/a.out
#root
```
## Bonus: NFShell per Accesso ai File Stealthy
## Bonus: NFShell per Accesso ai File Stealth
Una volta ottenuto l'accesso root, per interagire con la condivisione NFS senza cambiare la proprietà (per evitare di lasciare tracce), viene utilizzato uno script Python (nfsh.py). Questo script regola l'uid per corrispondere a quello del file a cui si accede, consentendo l'interazione con i file sulla condivisione senza problemi di autorizzazione:
```python

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

@ -14,7 +14,7 @@
Un aspetto notevole di questo protocollo è la sua abituale mancanza di meccanismi di **autenticazione** o **autorizzazione** integrati. Invece, l'autorizzazione si basa su **informazioni del file system**, con il server incaricato di tradurre accuratamente le **informazioni utente fornite dal client** nel **formato di autorizzazione** richiesto dal file system, seguendo principalmente la **sintassi UNIX**.
L'autenticazione si basa comunemente su **identificatori `UID`/`GID` UNIX e appartenenze ai gruppi**. Tuttavia, sorge una sfida a causa della potenziale discrepanza nelle **mappature `UID`/`GID`** tra client e server, lasciando poco spazio per ulteriori verifiche da parte del server. Inoltre, questi dettagli vengono inviati dal client e sono fidati dal server, quindi un client malintenzionato potrebbe potenzialmente **fingere di essere un altro utente inviando `uid` e `gid` più privilegiati**.
L'autenticazione si basa comunemente su **identificatori `UID`/`GID` UNIX e appartenenze ai gruppi**. Tuttavia, sorge una sfida a causa del potenziale disallineamento nelle **mappature `UID`/`GID`** tra client e server, lasciando poco spazio per ulteriori verifiche da parte del server. Inoltre, questi dettagli vengono inviati dal client e sono fidati dal server, quindi un client malintenzionato potrebbe potenzialmente **impersonare un altro utente inviando `uid` e `gid` più privilegiati**.
**Tuttavia, nota che per impostazione predefinita non è possibile impersonare il `UID` 0 (root) utilizzando NFS. Maggiori informazioni su questo nella sezione di squashing.**
@ -43,21 +43,21 @@ Ogni versione di NFS è stata sviluppata con l'intento di affrontare le esigenze
Come accennato in precedenza, NFS di solito si fida del `uid` e `gid` del client per accedere ai file (se non viene utilizzato kerberos). Tuttavia, ci sono alcune configurazioni che possono essere impostate nel server per **cambiare questo comportamento**:
- **all_squash**: Riduce tutti gli accessi mappando ogni utente e gruppo a **`nobody`** (65534 unsigned / -2 signed). Pertanto, tutti sono `nobody` e non vengono utilizzati utenti.
- **root_squash/no_all_squash**: Questo è predefinito su Linux e **riduce solo l'accesso con uid 0 (root)**. Pertanto, qualsiasi `UID` e `GID` sono fidati, ma `0` è ridotto a `nobody` (quindi non è possibile impersonare root).
- **root_squash/no_all_squash**: Questo è predefinito su Linux e **riduce solo l'accesso con uid 0 (root)**. Pertanto, qualsiasi `UID` e `GID` è fidato ma `0` è ridotto a `nobody` (quindi non è possibile impersonare root).
- **no_root_squash**: Questa configurazione, se abilitata, non riduce nemmeno l'utente root. Ciò significa che se monti una directory con questa configurazione puoi accedervi come root.
### Controllo del sottoalbero
Disponibile solo su Linux. man(5) exports dice: "Se una sottodirectory di un filesystem è esportata, ma l'intero filesystem non lo è, allora ogni volta che arriva una richiesta NFS, il server deve controllare non solo che il file accessibile sia nel filesystem appropriato (che è facile) ma anche che sia nell'albero esportato (che è più difficile). Questo controllo è chiamato controllo del sottoalbero."
In Linux la **funzione `subtree_check` è disabilitata** per impostazione predefinita.
In Linux la **funzionalità `subtree_check` è disabilitata** per impostazione predefinita.
## Enumerazione
### Showmount
Questo può essere utilizzato per **ottenere informazioni da un server NFSv3**, come l'elenco delle **esportazioni**, chi è **autorizzato ad accedere** a queste esportazioni e quali client sono connessi (che potrebbe essere impreciso se un client si disconnette senza avvisare il server).
Nei **client NFSv4 accedono direttamente all' / export** e provano ad accedere alle esportazioni da lì, fallendo se è non valido o non autorizzato per qualsiasi motivo.
Nei **client NFSv4 accedono direttamente all' / export** e cercano di accedere alle esportazioni da lì, fallendo se è non valido o non autorizzato per qualsiasi motivo.
Se strumenti come `showmount` o moduli Metasploit non mostrano informazioni da una porta NFS, è potenzialmente un server NFSv4 che non supporta la versione 3.
```bash
@ -108,14 +108,14 @@ Certo, l'unico problema qui è che per impostazione predefinita non è possibile
Controlla la pagina:
{{#ref}}
/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}
### Uscire dagli export
In questo [ottimo articolo](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) è possibile vedere che è possibile **uscire dagli export per accedere ad altre cartelle nel FS**.
Pertanto, se un export sta esportando una cartella che è una **sottocartella** dell'**intero filesystem**, è possibile accedere a file al di fuori dell'export se **`subtree_check`** è disabilitato. Ed è **disabilitato per impostazione predefinita in Linux**.
Pertanto, se un export sta esportando una cartella che è una **sottocartella** del **filesystem completo**, è possibile accedere a file al di fuori dell'export se **`subtree_check`** è disabilitato. Ed è **disabilitato per impostazione predefinita in Linux**.
Ad esempio, se un server NFS sta esportando `/srv/` e `/var/` si trova nello stesso filesystem, è possibile leggere i log da `/var/log/` o memorizzare una webshell in `/var/www/`.