fortify scan: Often Misused: Authentication

Abstract:

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. ... For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

Explanation:

Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.

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.

 struct hostent *hp;

 struct in_addr myaddr;

 char* tHost = "trustme.trusty.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;

 }

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may 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.

Recommendations:

You can increase confidence in a domain name lookup if you check to make sure that the host's forward and backward DNS entries match. Attackers will not be able to spoof both the forward and the reverse DNS entries without controlling the nameservers for the target domain. However, this is not a foolproof approach: attackers may be able to convince the domain registrar to turn over the domain to a malicious nameserver. Basing authentication on DNS entries is simply a risky practice.

While no authentication mechanism is foolproof, there are better alternatives than host-based authentication. Password systems offer decent security, but are susceptible to bad password choices, insecure password transmission, and bad password management. A cryptographic scheme like SSL is worth considering, but such schemes are often so complex that they bring with them the risk of significant implementation errors, and key material can always be stolen. In many situations, multi-factor authentication including a physical token offers the most security available at a reasonable price.

Tips:

1. Check how the DNS information is being used. In addition to considering whether or not the program's authentication mechanisms can be defeated, consider how DNS spoofing can be used in a social engineering attack. For example, if attackers can make it appear that a posting came from an internal machine, can they gain credibility?