CWE-350 Reliance on Reverse DNS for Security Decisions

CWE-350, Reliance on Reverse DNS Resolution for a Security-Critical Action, describes a product that performs reverse DNS resolution on an IP address to get a hostname, makes a security decision from it, and does not ensure the address is truly associated with that hostname.

It affects access control lists by hostname, "trusted host" configuration, logging by name, and any code that thinks "this connection came from something.corp.example, so it is internal."

How it happens

Reverse DNS asks the question backwards. Instead of "what address does this name have," it asks "what name does this address have." The answer comes from whoever runs the reverse zone for that address.

MITRE explains the problem. DNS names are easy to spoof or misreport, and it may be hard for the product to tell whether a trusted DNS server has been compromised. As a result, DNS names are not a valid authentication mechanism. If an attacker controls the DNS server for an IP address, they can make it return any hostname they like.

MITRE names two ways attackers get there: compromising a DNS server and changing its records, sometimes called cache poisoning, or having legitimate control over a DNS server associated with their own IP address. The second needs no hacking at all. An attacker who owns an address block controls its reverse records.

The observed examples are older, but the pattern repeats. CVE-2001-1488 describes a product that does not do a double reverse lookup to prevent DNS spoofing. CVE-2001-1500 describes one that does not verify reverse resolved hostnames. CVE-2000-1221 describes an authentication bypass using spoofed reverse resolved hostnames.

What an attacker gains

MITRE lists access control impact: gaining privileges or assuming identity and bypassing protection mechanisms. Malicious users can fake authentication information by providing false DNS information. The record also notes that an attacker may cause the wrong hostname to be recorded in logs, hiding their activity.

How to find it

MITRE notes that automated static analysis can find some instances of this weakness by analyzing source code. A simple search also helps.

• Search for reverse lookup calls: gethostbyaddr, getnameinfo, PTR lookups and similar.
• Follow the result. If it feeds an allow or deny decision, a rate limit or a trust flag, it is a finding.
• Check configuration of services that accept host names in allow lists, and whether they confirm those names forward.
• Look at logging. Do you record the IP, or only the looked up name?

How to fix it

MITRE gives two pieces of guidance. In design, use other means of identity verification that cannot simply be spoofed, such as a username and password or a certificate. In implementation, perform proper forward and reverse DNS lookups to detect DNS spoofing.

The vulnerable pattern in Python:

import socket

host = socket.gethostbyaddr(client_ip)[0]
if host.endswith(".corp.example"):
    allow()          # attacker with their own reverse zone can pass this

The forward confirmed version checks that the name resolves back to the same address:

import socket

def verified_host(ip):
    host = socket.gethostbyaddr(ip)[0]
    forward = {info[4][0] for info in socket.getaddrinfo(host, None)}
    return host if ip in forward else None

host = verified_host(client_ip)
if host and host.endswith(".corp.example"):
    allow()

Be clear about what this does. It defeats the simple case where an attacker sets an arbitrary reverse record, because the forward record for that name will not point back at their address. It still depends on DNS being honest, so for anything that matters, do not stop here. Use real authentication, such as client certificates or credentials, and treat the hostname only as a label for logs.

Also log the IP address itself next to any looked up name, so a false name cannot hide the true source.

Quick check

Sources

• MITRE CWE-350: https://cwe.mitre.org/data/definitions/350.html