Trusting Self-reported DNS Name
Weakness ID: 292 (Weakness Variant)Status: Incomplete
+ Description

Description Summary

The use of self-reported DNS names as authentication is flawed and can easily be spoofed by malicious users.
+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Authentication

Malicious users can fake authentication information by providing false DNS information.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

The following code uses a DNS lookup to determine whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(Bad Code)
Example Language: C 
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
trusted = true;
} else {
trusted = false;
}

Example 2

(Bad Code)
Example Languages: C and C++ 
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));
while (1) {

memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
h=gethostbyname(inet_ntoa(cliAddr.sin_addr));
if (h->h_name==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}
Example Language: Java 
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp);
String in = new String(p.getData(),0, rp.getLength());
InetAddress IPAddress = rp.getAddress();
int port = rp.getPort();
if ((rp.getHostName()==...) & (in==...)) {

out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port);
outSock.send(sp);
}
}
+ Observed Examples
ReferenceDescription
CVE-2009-1048VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
+ Potential Mitigations

Phase: Architecture and Design

Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

+ Other Notes

As DNS names can be easily spoofed or misreported, they do not constitute a valid authentication mechanism. Alternate methods should be used if the significant authentication is necessary. In addition, DNS name resolution as authentication would -- even if it was a valid means of authentication -- imply a trust relationship with the DNS servers used, as well as all of the servers they refer to.

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base290Authentication Bypass by Spoofing
Development Concepts (primary)699
Research Concepts (primary)1000
PeerOfCompound Element: CompositeCompound Element: Composite291Trusting Self-reported IP Address
Research Concepts1000
PeerOfWeakness VariantWeakness Variant293Using Referer Field for Authentication
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPTrusting self-reported DNS name
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
89Pharming
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-10-29CWE Content TeamMITREInternal
updated Observed Examples
Back to top