Skip to content

F-5.7: Case-Insensitive Filesystem (Windows NFS / NTFS Fingerprint)

Classification

  • Severity: Low (Information Disclosure / Fingerprinting)
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: NFSv3 (via PATHCONF), NFSv4 (via GETATTR fattr4)
  • RFC Reference: RFC 1813 S3.3.20 (PATHCONF case_insensitive), RFC 7530 S12 (case-insensitive security)
  • Prerequisite: Valid file handle for the export root

Summary

When PATHCONF returns case_insensitive=true, the underlying filesystem performs case-insensitive name lookups. This is a strong indicator of a Windows NFS server (NTFS) or a NetApp volume in NTFS mode. Beyond fingerprinting, case-insensitive lookups enable filename collision attacks: an attacker can create Makefile to shadow an existing makefile, or create .SSH/authorized_keys to bypass access controls that check for .ssh/authorized_keys.

Technical detail

PATHCONF fields

RFC 1813 S3.3.20 defines two relevant fields:

  • case_insensitive (bool): Server treats File.txt and file.txt as the same name
  • case_preserving (bool): Server preserves the original case of created filenames
Filesystem case_insensitive case_preserving Platform
ext4 / XFS / btrfs false true Linux
NTFS true true Windows Server
NetApp NTFS vol true true NetApp ONTAP
HFS+ (default) true true macOS
ZFS (casesensitivity=insensitive) true true Solaris / FreeBSD

Security implications

RFC 7530 S12 warns about case-insensitive semantics:

"If the server's filesystem is case-insensitive, it is possible for a client to look up a name and get back a different name than it asked for."

Filename collision attacks

1. Target has /export/config/settings.conf
2. Attacker creates /export/config/Settings.conf
   -> On case-insensitive FS: overwrites the original
   -> On case-sensitive FS: creates a separate file
3. Applications loading "settings.conf" now read the attacker's version

Access control bypass

1. SSH checks ~/.ssh/authorized_keys (lowercase)
2. Attacker creates ~/.SSH/authorized_keys on a case-insensitive NFS export
3. On case-sensitive clients: file is ignored (different directory)
4. If the NFS export is case-insensitive: both paths resolve to the same file

Fingerprinting value

case_insensitive=true reliably identifies: - Windows NFS Server (Server for NFS role on Windows Server) - NetApp ONTAP in NTFS security style - macOS NFS exports (HFS+ default)

This narrows the attack surface and guides further enumeration (e.g., Windows-specific handle signing per F-2.3).

Impact

  • Reliable OS/filesystem fingerprinting without active probing
  • Filename collision attacks can replace legitimate files
  • Access control assumptions based on case sensitivity may be violated
  • Indicates a mixed-OS environment (often has weaker security posture)

Detection (nfswolf)

The analyzer calls PATHCONF on each export root handle and checks the case_insensitive field. If true, the finding fires at Low severity with the fingerprinting implications noted. The check also records case_preserving for completeness.

Remediation

  1. Awareness only -- the filesystem type cannot be changed without reformatting the volume

  2. Application hardening -- do not rely on filename case for security decisions on NFS exports

  3. Use NFSv4 ACLs instead of POSIX mode bits for access control on case-insensitive exports

  4. Segment Windows NFS exports from Unix clients when possible to avoid cross-platform case confusion