daemon-sec-cheatsheet

The cheatsheet vault for operators: AD, enumeration, exploitation, priv-esc, web, DFIR
git clone https://git.daemon-sec.xyz/daemon-sec-cheatsheet.git
Log | Files | Refs | README | LICENSE

nfs-service-pentesting.md (12024B)


      1 ---
      2 title: "2049 - Pentesting NFS Service"
      3 section: "Network Services"
      4 sectionSlug: "network-services-pentesting"
      5 sourcePath: "src/network-services-pentesting/nfs-service-pentesting.md"
      6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/nfs-service-pentesting.md"
      7 sha: "188de82beb54e70956b2952367a0af91d26758b8"
      8 isIndex: false
      9 modified: true
     10 license: "CC-BY-NC-4.0"
     11 ---
     12 
     13 # 2049 - Pentesting NFS Service
     14 
     15 ## **Basic Information**
     16 
     17 **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.
     18 
     19 **Default port**: 2049/TCP/UDP (except version 4, it just needs TCP or UDP).
     20 
     21 ```text
     22 2049/tcp open  nfs     2-3 (RPC #100003
     23 ```
     24 
     25 ### Authentication
     26 
     27 A notable aspect of this protocol is its usual lack of built-in **authentication** or **authorization mechanisms**. Instead, authorization relies on **file system information**, with the server tasked with accurately translating **client-provided user information** into the file system's required **authorization format**, primarily following **UNIX syntax**.
     28 
     29 Authentication commonly relies on **UNIX `UID`/`GID` identifiers and group memberships**. However, a challenge arises due to the potential mismatch in **`UID`/`GID` mappings** between clients and servers, leaving no room for additional verification by the server. Moreover, these details are sent by the client and trusted by the server, so a rogue client could potentially **impersonate another user sending more privileged `uid` and `gid`s.<sup>[[1]](#references)</sup>
     30 
     31 **However, note that by default it's not possible to impersonate the `UID` 0 (root) using NFS. More on this ins the squashing section.**
     32 
     33 #### Hosts
     34 
     35 For better (or some) authorization, you can specify the **hosts** that can access the NFS share. This can be done in the Linux `/etc/exports` file. For example:
     36 
     37 ```text
     38 /PATH/TO/EXPORT      CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ...
     39 /media/disk/share   192.168.2.123(rw,sec=krb5p:krb5i) 
     40 ```
     41 
     42 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.
     43 
     44 ### Versions
     45 
     46 - **NFSv2**: This version is recognized for its broad compatibility with various systems, marking its significance with initial operations predominantly over UDP. Being the **oldest** in the series, it laid the groundwork for future developments.
     47 
     48 - **NFSv3**: Introduced with an array of enhancements, NFSv3 expanded on its predecessor by supporting variable file sizes and offering improved error reporting mechanisms. Despite its advancements, it faced limitations in full backward compatibility with NFSv2 clients.
     49 
     50 - **NFSv4**: A landmark version in the NFS series, NFSv4 brought forth a suite of features designed to modernize file sharing across networks. Notable improvements include the integration of Kerberos for **high security**, the capability to traverse firewalls and operate over the Internet without the need for portmappers, support for Access Control Lists (ACLs), and the introduction of state-based operations. Its performance enhancements and the adoption of a stateful protocol distinguish NFSv4 as a pivotal advancement in network file sharing technologies.
     51   - Note that it's very weird to find a Linux host NFS supporting kerberos authentication.
     52 
     53 Each version of NFS has been developed with the intent to address the evolving needs of network environments, progressively enhancing security, compatibility, and performance.
     54 
     55 ### Squashing
     56 
     57 As mentioned previously, NFS will usually trust the client's `uid` and `gid` to access the files (if kerberos is not used). However, there are some configurations that can be set in the server to **change this behavior**:<sup>[[1]](#references)</sup>
     58 
     59 - **all_squash**: It squashes all accesses mapping every user and group to **`nobody`** (65534 unsigned / -2 signed). Therefore, everyone is `nobody` and no users are used.
     60 - **root_squash/no_all_squash**: This is default on Linux and **only squashes access with uid 0 (root)**. Therefore, any `UID` and `GID` are trusted but `0` is squashed to `nobody` (so no root imperonation is possible).
     61 - **no_root_squash**: This configuration if enabled doesn't even squash the root user. This means that if you mount a directory with this configuration you can access it as root.
     62 
     63 ### Subtree check
     64 
     65 Only available on Linux. man(5) exports says: "If a subdirectory of a filesystem is exported, but the whole filesystem isn’t then whenever an NFS request arrives, the server must check not only that the accessed file is in the appropriate filesystem (which is easy) but also that it is in the exported tree (which is harder). This check is called the subtree check."
     66 
     67 In Linux the **`subtree_check` feature is disabled** by default.
     68 
     69 ## Enumeration
     70 
     71 ### Showmount
     72 
     73 This can be used to **get information from an NFSv3 server**, like the list of **exports**, who is **allowed to access** these exports, and which clients are connected (which may be inaccurate if a client disconnects without telling the server). 
     74 In **NFSv4 clients just directly access the / export** and try to access exports from there, failing if it's invalid or unathorized for any reason.
     75 
     76 If tools like `showmount` or Metasploit modules don't show information from a NFS port, it's potentially a NFSv4 server that doesn't support version 3. 
     77 
     78 ```bash
     79 showmount -e <IP>
     80 ```
     81 
     82 ### Useful nmap scripts
     83 
     84 ```bash
     85 nfs-ls #List NFS exports and check permissions
     86 nfs-showmount #Like showmount -e
     87 nfs-statfs #Disk statistics and info from NFS share
     88 ```
     89 
     90 ### Useful metasploit modules
     91 
     92 ```bash
     93 scanner/nfs/nfsmount #Scan NFS mounts and list permissions
     94 ```
     95 
     96 ### nfs_analyze
     97 
     98 This tool from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) can be used to obtain a lot of data from an NFS server like **mounts**, supported NFS versions, conencted IPs, and even if it's possible to **escape from the exports** to other folder sin the FS or **if `no_root_squash` is enabled**.<sup>[[1]](#references)</sup>
     99 
    100 
    101 ## Mounting
    102 
    103 To know **which folder** has the server **available** to mount you an ask it using:
    104 
    105 ```bash
    106 showmount -e <IP>
    107 ```
    108 
    109 Then mount it using:
    110 
    111 ```bash
    112 mount -t nfs [-o vers=2] <ip>:<remote_folder> <local_folder> -o nolock
    113 ```
    114 
    115 You should specify to **use version 2** because it doesn't have **any** **authentication** or **authorization**.
    116 
    117 **Example:**
    118 
    119 ```bash
    120 mkdir /mnt/new_back
    121 mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
    122 ```
    123 
    124 ## Attacks
    125 
    126 ### Trusting UID and GID
    127 
    128 Ofc, the only problem here is that by default it's not possible to impersonate root (`UID` 0). However, it's possible to impersonate any other user or if `no_root_squash` is enabled you can also impersonate root.
    129 
    130 - If you mount a folder which contains **files or folders only accesible by some user** (by **UID**). You can **create** **locally** a user with that **UID** and using that **user** you will be able to **access** the file/folder.
    131 - The tool **`fuse_nfs`** from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) will basically send always the needed UID and GID to access the files.<sup>[[1]](#references)</sup>
    132 
    133 ### SUID Privilege Escalation
    134 
    135 Check the page:
    136 
    137 
    138 [Nfs No Root Squash Misconfiguration Pe](/hacktricks/linux-hardening/interesting-files-permissions/nfs-no-root-squash-misconfiguration-pe)
    139 
    140 ### Escaping from the exports
    141 
    142 In this [great article](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) it's possible to see that it's possible to **escape from the exports to access other folders in the FS**.<sup>[[1]](#references)</sup>
    143 
    144 Therefore, if an export is exporting a folder that is a **subfolder** of the **whole filesystem** it's possible to access files outside the export if **`subtree_check`** disabled. And it's **disabled by default in Linux**.
    145 
    146 For example, if an NFS server is exporting `/srv/` and `/var/` is in the same filesystem, it's possible to read logs from `/var/log/` or store a webshell in `/var/www/`.
    147 
    148 Moreover, note that by default only the root (0) user is protected from being impersonated (check the Squash section). However, if a file is **owned by root but the group is not 0, it's possible to access it**. For example, the file `/etc/shadow` is owned by root but the group is `shadow` (gid 42 on Debian). Therefore, it's possible to read it by default!<sup>[[1]](#references)</sup>
    149 
    150 The tool **`nfs_analyze`** from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) is built to support this attack against the file systems ext4, xfs, btrfs in the version 3 (it should also be posisble in v4).<sup>[[1]](#references)</sup>
    151 
    152 ### NSFShell
    153 
    154 To easily list, mount and change UID and GID to have access to files you can use [nfsshell](https://github.com/NetDirect/nfsshell).
    155 
    156 [Nice NFSShell tutorial.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)<sup>[[2]](#references)</sup>
    157 
    158 ## Config files
    159 
    160 ```text
    161 /etc/exports
    162 /etc/lib/nfs/etab
    163 ```
    164 
    165 ## Dangerous settings
    166 
    167 - **Read and Write Permissions (`rw`):** This setting allows both reading from and writing to the file system. It's essential to consider the implications of granting such broad access.
    168 
    169 - **Use of Insecure Ports (`insecure`):** When enabled, this allows the system to utilize ports above 1024. The security of ports above this range can be less stringent, increasing risk.
    170 
    171 - **Visibility of Nested File Systems (`nohide`):** This configuration makes directories visible even if another file system is mounted below an exported directory. Each directory requires its own export entry for proper management.
    172 
    173 - **Root Files Ownership (`no_root_squash`):** With this setting, files created by the root user maintain their original UID/GID of 0, disregarding the principle of least privilege and potentially granting excessive permissions.
    174 
    175 - **Non-Squashing of All Users (`no_all_squash`):** This option ensures that user identities are preserved across the system, which could lead to permission and access control issues if not correctly handled.
    176 
    177 ## Privilege Escalation using NFS misconfigurations
    178 
    179 [NFS no_root_squash and no_all_squash privilege escalation](/hacktricks/linux-hardening/interesting-files-permissions/nfs-no-root-squash-misconfiguration-pe)
    180 
    181 ## HackTricks Automatic Commands
    182 
    183 ```text
    184 Protocol_Name: NFS    #Protocol Abbreviation if there is one.
    185 Port_Number:  2049     #Comma separated if there is more than one.
    186 Protocol_Description: Network File System         #Protocol Abbreviation Spelled out
    187 
    188 Entry_1:
    189   Name: Notes
    190   Description: Notes for NFS
    191   Note: |
    192     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.
    193 
    194     #apt install nfs-common
    195     showmount 10.10.10.180      ~or~showmount -e 10.10.10.180
    196     should show you available shares (example /home)
    197 
    198     mount -t nfs -o ver=2 10.10.10.180:/home /mnt/
    199     cd /mnt
    200     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
    201 
    202     https://book.hacktricks.wiki/en/network-services-pentesting/nfs-service-pentesting.html
    203 
    204 Entry_2:
    205   Name: Nmap
    206   Description: Nmap with NFS Scripts
    207   Command: nmap --script=nfs-ls.nse,nfs-showmount.nse,nfs-statfs.nse -p 2049 {IP}
    208 ```
    209 
    210 ## References
    211 
    212 - [1] [NFS security: identifying and exploiting misconfigurations](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/)
    213 - [2] [Using nfsshell to compromise older environments](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/)