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:18 +00:00
parent 3fdc9a3a98
commit b15740f09b
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

@ -2,18 +2,18 @@
# Squashing Grundinformationen
NFS wird normalerweise (insbesondere unter Linux) dem angegebenen `uid` und `gid` des Clients, der sich verbindet, vertrauen, um auf die Dateien zuzugreifen (wenn Kerberos nicht verwendet wird). Es gibt jedoch einige Konfigurationen, die auf dem Server eingestellt werden können, um **dieses Verhalten zu ändern**:
NFS wird normalerweise (insbesondere unter Linux) dem angegebenen `uid` und `gid` des Clients, der sich verbindet, vertrauen, um auf die Dateien zuzugreifen (wenn Kerberos nicht verwendet wird). Es gibt jedoch einige Konfigurationen, die auf dem Server gesetzt werden können, um **dieses Verhalten zu ändern**:
- **`all_squash`**: Es squash alle Zugriffe, indem jeder Benutzer und jede Gruppe auf **`nobody`** (65534 unsigned / -2 signed) abgebildet wird. Daher ist jeder `nobody` und es werden keine Benutzer verwendet.
- **`root_squash`/`no_all_squash`**: Dies ist standardmäßig unter Linux und **squasht nur den Zugriff mit uid 0 (root)**. Daher werden alle `UID` und `GID` vertraut, aber `0` wird auf `nobody` gesquasht (so ist keine Root-Imitation möglich).
- **``no_root_squash`**: Diese Konfiguration, wenn aktiviert, squasht nicht einmal den Root-Benutzer. Das bedeutet, dass Sie, wenn Sie ein Verzeichnis mit dieser Konfiguration einhängen, darauf als Root zugreifen können.
In der **/etc/exports**-Datei, wenn Sie ein Verzeichnis finden, das als **no_root_squash** konfiguriert ist, können Sie **darauf zugreifen** als **Client** und **innerhalb** dieses Verzeichnisses **schreiben**, als ob Sie der lokale **Root** der Maschine wären.
In der **/etc/exports**-Datei, wenn Sie ein Verzeichnis finden, das als **no_root_squash** konfiguriert ist, können Sie **darauf zugreifen** **als Client** und **in dieses Verzeichnis schreiben**, **als ob** Sie der lokale **Root** der Maschine wären.
Für weitere Informationen über **NFS** überprüfen Sie:
Für weitere Informationen über **NFS** siehe:
{{#ref}}
/network-services-pentesting/nfs-service-pentesting.md
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Privilegieneskalation
@ -21,7 +21,7 @@ Für weitere Informationen über **NFS** überprüfen Sie:
## Remote Exploit
Option 1 unter Verwendung von bash:
- **Dieses Verzeichnis** auf einer Client-Maschine **einbinden** und **als Root** die **/bin/bash**-Binärdatei in den eingebundenen Ordner kopieren und ihr **SUID**-Rechte geben, und **von der Opfer**-Maschine diese bash-Binärdatei ausführen.
- **Dieses Verzeichnis** auf einer Client-Maschine einhängen und **als Root** die **/bin/bash**-Binärdatei in den eingehängten Ordner kopieren und ihr **SUID**-Rechte geben, und **von der Opfer**-Maschine diese bash-Binärdatei ausführen.
- Beachten Sie, dass, um Root innerhalb des NFS-Teils zu sein, **`no_root_squash`** auf dem Server konfiguriert sein muss.
- Wenn es jedoch nicht aktiviert ist, könnten Sie zu einem anderen Benutzer eskalieren, indem Sie die Binärdatei in den NFS-Teil kopieren und ihr die SUID-Berechtigung als den Benutzer geben, zu dem Sie eskalieren möchten.
```bash
@ -55,14 +55,14 @@ cd <SHAREDD_FOLDER>
## Lokaler Exploit
> [!NOTE]
> Beachten Sie, dass Sie, wenn Sie einen **Tunnel von Ihrem Rechner zum Opferrechner erstellen können, die Remote-Version weiterhin verwenden können, um diese Privilegieneskalation durch Tunneln der erforderlichen Ports auszunutzen**.\
> Der folgende Trick gilt, falls die Datei `/etc/exports` **eine IP angibt**. In diesem Fall **werden Sie auf keinen Fall** die **remote exploit** verwenden können und müssen **diesen Trick ausnutzen**.\
> Beachten Sie, dass Sie, wenn Sie einen **Tunnel von Ihrem Rechner zum Opferrechner erstellen können, weiterhin die Remote-Version verwenden können, um diese Privilegieneskalation durch Tunneln der erforderlichen Ports auszunutzen**.\
> Der folgende Trick gilt, falls die Datei `/etc/exports` **eine IP angibt**. In diesem Fall **werden Sie auf keinen Fall** die **Remote-Exploit** verwenden können und müssen **diesen Trick ausnutzen**.\
> Eine weitere erforderliche Bedingung, damit der Exploit funktioniert, ist, dass **der Export in `/etc/export`** **das `insecure`-Flag verwenden muss**.\
> --_Ich bin mir nicht sicher, ob dieser Trick funktioniert, wenn `/etc/export` eine IP-Adresse angibt_--
## Grundinformationen
Das Szenario beinhaltet das Ausnutzen eines gemounteten NFS-Teils auf einem lokalen Rechner, wobei eine Schwachstelle in der NFSv3-Spezifikation ausgenutzt wird, die es dem Client ermöglicht, seine uid/gid anzugeben, was potenziell unbefugten Zugriff ermöglicht. Der Exploit beinhaltet die Verwendung von [libnfs](https://github.com/sahlberg/libnfs), einer Bibliothek, die das Fälschen von NFS RPC-Aufrufen ermöglicht.
Das Szenario beinhaltet das Ausnutzen eines gemounteten NFS-Teils auf einem lokalen Rechner, wobei eine Schwachstelle in der NFSv3-Spezifikation ausgenutzt wird, die es dem Client ermöglicht, seine uid/gid anzugeben, was potenziell unbefugten Zugriff ermöglicht. Der Exploit beinhaltet die Verwendung von [libnfs](https://github.com/sahlberg/libnfs), einer Bibliothek, die das Fälschen von NFS-RPC-Aufrufen ermöglicht.
### Kompilieren der Bibliothek

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

@ -2,7 +2,7 @@
{{#include ../banners/hacktricks-training.md}}
## **Grundlegende Informationen**
## **Grundinformationen**
**NFS** ist ein System, das für **Client/Server** konzipiert ist und es Benutzern ermöglicht, nahtlos auf Dateien über ein Netzwerk zuzugreifen, als ob sich diese Dateien in einem lokalen Verzeichnis befinden würden.
@ -14,9 +14,9 @@
Ein bemerkenswerter Aspekt dieses Protokolls ist das übliche Fehlen von integrierten **Authentifizierungs**- oder **Autorisierungsmechanismen**. Stattdessen basiert die Autorisierung auf **Dateisysteminformationen**, wobei der Server dafür verantwortlich ist, die **vom Client bereitgestellten Benutzerinformationen** in das erforderliche **Autorisierungsformat** des Dateisystems genau zu übersetzen, hauptsächlich gemäß der **UNIX-Syntax**.
Die Authentifizierung stützt sich häufig auf **UNIX `UID`/`GID`-Identifikatoren und Gruppenmitgliedschaften**. Ein Problem ergibt sich jedoch aufgrund der möglichen Diskrepanz in den **`UID`/`GID`-Zuordnungen** zwischen Clients und Servern, was keinen Raum für zusätzliche Überprüfungen durch den Server lässt. Darüber hinaus werden diese Details vom Client gesendet und vom Server vertraut, sodass ein böswilliger Client möglicherweise **einen anderen Benutzer imitieren kann, indem er privilegierte `uid` und `gid`s sendet.**
Die Authentifizierung stützt sich häufig auf **UNIX `UID`/`GID`-Identifikatoren und Gruppenmitgliedschaften**. Ein Problem ergibt sich jedoch aufgrund der potenziellen Diskrepanz in den **`UID`/`GID`-Zuordnungen** zwischen Clients und Servern, was keinen Raum für zusätzliche Überprüfungen durch den Server lässt. Darüber hinaus werden diese Details vom Client gesendet und vom Server vertraut, sodass ein böswilliger Client möglicherweise **einen anderen Benutzer imitieren kann, indem er privilegierte `uid` und `gid`s sendet.**
**Beachten Sie jedoch, dass es standardmäßig nicht möglich ist, den `UID` 0 (root) mit NFS zu imitieren. Weitere Informationen dazu finden Sie im Abschnitt über Squashing.**
**Beachten Sie jedoch, dass es standardmäßig nicht möglich ist, die `UID` 0 (root) mit NFS zu imitieren. Mehr dazu im Abschnitt über Squashing.**
#### Hosts
@ -25,30 +25,30 @@ Für eine bessere (oder einige) Autorisierung können Sie die **Hosts** angeben,
/PATH/TO/EXPORT      CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ...
/media/disk/share   192.168.2.123(rw,sec=krb5p:krb5i)
```
As you can see, es ermöglicht die Konfiguration einer spezifischen **IP** oder **Hostname**, um auf den Share zuzugreifen. Nur diese Adresse kann auf den Share zugreifen.
As you can see, es ermöglicht die Konfiguration einer spezifischen **IP** oder **Hostname**, um auf den Share zuzugreifen. Nur diese Adresse wird in der Lage sein, auf den Share zuzugreifen.
### Versionen
- **NFSv2**: Diese Version ist bekannt für ihre breite Kompatibilität mit verschiedenen Systemen und markiert ihre Bedeutung mit anfänglichen Operationen, die überwiegend über UDP durchgeführt werden. Als die **älteste** in der Reihe legte sie den Grundstein für zukünftige Entwicklungen.
- **NFSv3**: Eingeführt mit einer Reihe von Verbesserungen, erweiterte NFSv3 seinen Vorgänger, indem es variable Dateigrößen unterstützte und verbesserte Fehlerberichterstattungsmechanismen bot. Trotz seiner Fortschritte hatte es Einschränkungen in der vollständigen Rückwärtskompatibilität mit NFSv2-Clients.
- **NFSv3**: Eingeführt mit einer Reihe von Verbesserungen, erweiterte NFSv3 seinen Vorgänger, indem es variable Dateigrößen unterstützte und verbesserte Fehlerberichterstattungsmechanismen bot. Trotz seiner Fortschritte hatte es Einschränkungen in der vollständigen Abwärtskompatibilität mit NFSv2-Clients.
- **NFSv4**: Eine wegweisende Version in der NFS-Serie, brachte NFSv4 eine Reihe von Funktionen mit sich, die darauf abzielen, die Dateifreigabe über Netzwerke zu modernisieren. Zu den bemerkenswerten Verbesserungen gehören die Integration von Kerberos für **hohe Sicherheit**, die Fähigkeit, Firewalls zu durchqueren und über das Internet ohne die Notwendigkeit von Portmappern zu arbeiten, Unterstützung für Access Control Lists (ACLs) und die Einführung von zustandsbasierten Operationen. Die Leistungsverbesserungen und die Einführung eines zustandsbehafteten Protokolls heben NFSv4 als einen entscheidenden Fortschritt in der Technologie der Netzwerkdateifreigabe hervor.
- **NFSv4**: Eine wegweisende Version in der NFS-Serie, brachte NFSv4 eine Reihe von Funktionen mit sich, die darauf abzielen, die Dateifreigabe über Netzwerke zu modernisieren. Zu den bemerkenswerten Verbesserungen gehören die Integration von Kerberos für **hohe Sicherheit**, die Fähigkeit, Firewalls zu durchqueren und über das Internet zu arbeiten, ohne dass Portmapper erforderlich sind, Unterstützung für Access Control Lists (ACLs) und die Einführung von zustandsbasierten Operationen. Die Leistungsverbesserungen und die Einführung eines zustandsbehafteten Protokolls heben NFSv4 als einen entscheidenden Fortschritt in der Technologie der Netzwerkdateifreigabe hervor.
- Beachten Sie, dass es sehr seltsam ist, einen Linux-Host zu finden, der NFS mit Kerberos-Authentifizierung unterstützt.
Jede Version von NFS wurde mit der Absicht entwickelt, die sich entwickelnden Bedürfnisse von Netzwerkumgebungen zu adressieren und dabei Sicherheit, Kompatibilität und Leistung schrittweise zu verbessern.
Jede Version von NFS wurde mit dem Ziel entwickelt, den sich entwickelnden Bedürfnissen von Netzwerkumgebungen gerecht zu werden und dabei Sicherheit, Kompatibilität und Leistung schrittweise zu verbessern.
### Squashing
Wie bereits erwähnt, wird NFS normalerweise dem `uid` und `gid` des Clients vertrauen, um auf die Dateien zuzugreifen (wenn Kerberos nicht verwendet wird). Es gibt jedoch einige Konfigurationen, die auf dem Server eingestellt werden können, um **dieses Verhalten zu ändern**:
Wie bereits erwähnt, wird NFS normalerweise dem `uid` und `gid` des Clients vertrauen, um auf die Dateien zuzugreifen (wenn Kerberos nicht verwendet wird). Es gibt jedoch einige Konfigurationen, die auf dem Server festgelegt werden können, um **dieses Verhalten zu ändern**:
- **all_squash**: Es squasht alle Zugriffe, indem jeder Benutzer und jede Gruppe auf **`nobody`** (65534 unsigned / -2 signed) abgebildet wird. Daher ist jeder `nobody` und es werden keine Benutzer verwendet.
- **all_squash**: Es squash alle Zugriffe und mappt jeden Benutzer und jede Gruppe auf **`nobody`** (65534 unsigned / -2 signed). Daher ist jeder `nobody` und es werden keine Benutzer verwendet.
- **root_squash/no_all_squash**: Dies ist standardmäßig auf Linux und **squasht nur Zugriffe mit uid 0 (root)**. Daher werden alle `UID` und `GID` vertraut, aber `0` wird auf `nobody` gesquasht (so ist keine Root-Impersonation möglich).
- **no_root_squash**: Diese Konfiguration, wenn aktiviert, squasht nicht einmal den Root-Benutzer. Das bedeutet, dass Sie, wenn Sie ein Verzeichnis mit dieser Konfiguration einhängen, darauf als Root zugreifen können.
### Subtree-Check
Nur auf Linux verfügbar. man(5) exports sagt: "Wenn ein Unterverzeichnis eines Dateisystems exportiert wird, das gesamte Dateisystem jedoch nicht, muss der Server bei jedem NFS-Antrag nicht nur überprüfen, dass die zugegriffene Datei im entsprechenden Dateisystem ist (was einfach ist), sondern auch, dass sie im exportierten Baum ist (was schwieriger ist). Diese Überprüfung wird als Subtree-Check bezeichnet."
Nur verfügbar auf Linux. man(5) exports sagt: "Wenn ein Unterverzeichnis eines Dateisystems exportiert wird, das gesamte Dateisystem jedoch nicht, muss der Server bei jedem NFS-Antrag nicht nur überprüfen, dass die zugegriffene Datei im entsprechenden Dateisystem ist (was einfach ist), sondern auch, dass sie im exportierten Baum ist (was schwieriger ist). Diese Überprüfung wird als Subtree-Check bezeichnet."
In Linux ist die **`subtree_check`-Funktion standardmäßig deaktiviert**.
@ -57,7 +57,7 @@ In Linux ist die **`subtree_check`-Funktion standardmäßig deaktiviert**.
### Showmount
Dies kann verwendet werden, um **Informationen von einem NFSv3-Server zu erhalten**, wie die Liste der **Exports**, wer **berechtigt ist, auf** diese Exports zuzugreifen, und welche Clients verbunden sind (was ungenau sein kann, wenn ein Client sich trennt, ohne dem Server Bescheid zu geben).
In **NFSv4 greifen Clients direkt auf die /export** zu und versuchen, von dort auf Exports zuzugreifen, wobei sie fehlschlagen, wenn es ungültig oder aus irgendeinem Grund nicht autorisiert ist.
In **NFSv4 greifen Clients direkt auf die /export zu** und versuchen, von dort auf Exports zuzugreifen, wobei sie fehlschlagen, wenn es ungültig oder aus irgendeinem Grund nicht autorisiert ist.
Wenn Tools wie `showmount` oder Metasploit-Module keine Informationen von einem NFS-Port anzeigen, handelt es sich möglicherweise um einen NFSv4-Server, der Version 3 nicht unterstützt.
```bash
@ -79,7 +79,7 @@ Dieses Tool von [https://github.com/hvs-consulting/nfs-security-tooling](https:/
## Mounting
Um zu wissen, **welcher Ordner** dem Server **verfügbar** ist, um ihn zu mounten, können Sie ihn fragen mit:
Um zu wissen, **welcher Ordner** dem Server **verfügbar** ist, um ihn zu mounten, kannst du ihn fragen mit:
```bash
showmount -e <IP>
```
@ -108,7 +108,7 @@ Natürlich ist das einzige Problem hier, dass es standardmäßig nicht möglich
Überprüfen Sie die Seite:
{{#ref}}
/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
../linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
{{#endref}}
### Entkommen von den Exports
@ -119,7 +119,7 @@ Daher, wenn ein Export einen Ordner exportiert, der ein **Unterordner** des **ge
Zum Beispiel, wenn ein NFS-Server `/srv/` exportiert und `/var/` im selben Dateisystem ist, ist es möglich, Protokolle von `/var/log/` zu lesen oder eine Webshell in `/var/www/` zu speichern.
Darüber hinaus beachten Sie, dass standardmäßig nur der root (0) Benutzer vor der Impersonierung geschützt ist (überprüfen Sie den Squash-Abschnitt). Wenn jedoch eine Datei **im Besitz von root ist, die Gruppe jedoch nicht 0 ist, ist es möglich, darauf zuzugreifen**. Zum Beispiel ist die Datei `/etc/shadow` im Besitz von root, aber die Gruppe ist `shadow` (gid 42 auf Debian). Daher ist es standardmäßig möglich, sie zu lesen!
Darüber hinaus beachten Sie, dass standardmäßig nur der root (0) Benutzer davor geschützt ist, impersoniert zu werden (überprüfen Sie den Squash-Abschnitt). Wenn jedoch eine Datei **von root besessen wird, aber die Gruppe nicht 0 ist, ist es möglich, darauf zuzugreifen**. Zum Beispiel ist die Datei `/etc/shadow` von root besessen, aber die Gruppe ist `shadow` (gid 42 auf Debian). Daher ist es standardmäßig möglich, sie zu lesen!
Das Tool **`nfs_analyze`** von [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) wurde entwickelt, um diesen Angriff gegen die Dateisysteme ext4, xfs, btrfs in der Version 3 zu unterstützen (es sollte auch in v4 möglich sein).