Skip to content

F-3.7: AUTH_DH Advertised (Cryptographically Broken)

Classification

  • Severity: Medium
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: Any NFS version advertising AUTH_DH (flavor 3)
  • RFC Reference: RFC 5531 S14 (AUTH_DH declared obsolete), RFC 2695
  • Prerequisite: Server advertises auth_flavor 3 via MOUNT or NFSv4 SECINFO

Summary

AUTH_DH (Diffie-Hellman authentication, auth_flavor 3) uses a 192-bit DH key exchange and 56-bit DES encryption. Both are trivially breakable with modern hardware: 192-bit DH can be factored in seconds, and 56-bit DES was publicly brute-forced in 1998 (EFF's "Deep Crack"). RFC 5531 explicitly marks AUTH_DH as "considered obsolete and insecure" and directs implementors to RFC 2695. A server advertising this flavor signals a legacy configuration that an attacker can exploit to bypass any illusion of cryptographic protection.

Technical detail

AUTH_DH key exchange

AUTH_DH (originally called AUTH_DES or "Secure RPC") was designed for the SunOS/NIS ecosystem. The protocol:

  1. Client and server share a 192-bit DH public key (distributed via NIS publickey map)
  2. Client generates a random conversation key (56-bit DES)
  3. Client encrypts the conversation key under the DH shared secret
  4. Subsequent RPC calls are authenticated with DES-CBC MACs using the conversation key

Why it is broken

Component Key Size Status
Diffie-Hellman 192 bits Factorable in seconds on commodity hardware
DES encryption 56 bits Brute-forced in 22 hours in 1998 (EFF Deep Crack)
DES-CBC MAC 56 bits Same key, same weakness

NIST withdrew DES as a standard in 2005. A 192-bit DH discrete log is well within reach of academic computing clusters, let alone state-level adversaries.

Where AUTH_DH appears

  • MOUNT reply: The auth_flavors list in a successful MNT response may include flavor 3
  • NFSv4 SECINFO: Per-object security negotiation can advertise AUTH_DH
  • Legacy Solaris/NIS environments: AUTH_DH was the default "secure" option before Kerberos adoption

Exploitation

An attacker who observes an AUTH_DH handshake on the wire can:

  1. Factor the 192-bit DH modulus to recover the shared secret
  2. Decrypt the 56-bit conversation key
  3. Forge authenticated RPC calls as any principal in the NIS publickey map
  4. The entire attack is passive (no MITM required) and offline

Impact

  • Cryptographic authentication is effectively absent despite being advertised
  • False sense of security may prevent migration to real authentication (krb5)
  • Passive attackers can forge credentials for any NIS principal
  • Indicates a legacy environment likely to have other configuration weaknesses

Detection (nfswolf)

The analyzer checks for AUTH_DH in two places:

  1. MOUNT auth_flavors: After a successful MNT call, the reply includes a list of accepted auth flavors. If flavor 3 (AUTH_DH) is present, the finding fires.
  2. NFSv4 SECINFO: For NFSv4 exports, a SECINFO call on the export root returns per-object security flavors. Flavor 3 in this list triggers the same finding.

The check is purely passive -- no AUTH_DH handshake is attempted.

Remediation

  1. Remove AUTH_DH from server configuration: 

    # /etc/exports (Linux)
/srv/share  client(rw,sec=krb5p)

  2. Migrate to RPCSEC_GSS (Kerberos):

  3. sec=krb5 for authentication only
  4. sec=krb5i for integrity protection

  5. sec=krb5p for full privacy (encryption)

  6. Decommission NIS publickey maps -- AUTH_DH depends on NIS for key distribution, which is itself unauthenticated

  7. Audit for Solaris/legacy hosts that may still default to AUTH_DH