Subject: Security considerations for DNS rebinding

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Feb 2010 05:48:35 -0800

Hello HTTP WG,

A discussion of DNS Spoofing and DNS Rebinding came up on the W3C Web Apps Working Group. Someone pointed out the RFC2616 Security Considerations subsection on DNS Spoofing. This led me to notice that RFC2616 and the latest HTTPbis internet drafts not only lack a mention of DNS rebinding in their security considerations, but actually have requirements that increase the risk of DNS spoofing.

DNS spoofing is addressed here: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#dns.spoofing>

DNS rebinding is a different type of attack than DNS spoofing. DNS spoofing typically involves binding the hostname of the victim to the IP of the attacker. This is done by fully controlling DNS on the local network or via DNS cache poisoning. Users attempting to visit the victim site then secretly end up loading content from a different host, possibly leading them to reveal confidential information.

DNS rebinding is almost the reverse - the attacker's domain name is bound to the victim's IP. This is used for an attack like so:

1) User loads a page from the attacker's domain.
2) Attacker serves his own DNS record with a very short TTL.
3) Attacker changes his DNS record to point to victim IP.
4) Script in the attackers page loads fresh resources on a short timeout - they are now coming from the victim's IP, but because they are labeled with the attacker's domain name, they are accessible due to the same-origin policy.

This won't allow access to resources protected by cookies, but it *does* allow attackers to read arbitrary resources from firewall-protected internets, where being inside the firewall is the only access restriction.

The DNS Spoofing security considerations subsection has a requirement that actually increases the risk of DNS rebinding attacks. It says that "If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS". Clients that follow this advice will be at greater risk than if they give cached DNS lookup results a floor on time-to-live, or keep a DNS resolution result "pinned" so long as any resource from that domain is active. Those are the simplest client-side mitigation strategies for DNS rebinding attacks. If DNS lookups are cached in the browser for a minimum of, say, an hour, there is much less risk of a DNS rebinding attack, because the attacker must get the user to keep a page open for at least an hour to be able to perform the rebinding attack.

DNS rebinding can also be defended against with complete effectiveness if servers always check the Host header. A server attacked via DNS rebinding will get an unexpected value in the Host header - the attackers hostname instead of any of its own. 

HTTPbis should address this threat in the security considerations section, and should strongly consider making it a MUST-level requirement for servers to check that the Host header is a host they serve. Currently it actually says: "An origin server that does not allow resources to differ by the requested host may ignore the Host header field value when determining the resource identified by an HTTP/1.1 request" <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#the.resource.identified.by.a.request>. A server that takes advantage of that allowance may be at greater security risk.

If HTTP had a requirement to check the Host header and all servers followed it, then the risk of DNS rebinding attacks would be eliminated for conforming servers. Meanwhile clients can only implement mitigation strategies that are only partially effective or inordinately complex or both. And client-side protections can risk breaking completely valid DNS round-robin load balancing setups.

Regards,
Maciej

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Feb 2010 14:54:58 +0100

Maciej Stachowiak wrote:
> ...

Recorded as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/202>.

(Thanks, Maciej)

---

From: Tim <[email-masked]>
Date: Tue, 9 Feb 2010 06:23:15 -0800

Hi Maciej,

> The DNS Spoofing security considerations subsection has a
> requirement that actually increases the risk of DNS rebinding attacks.
> It says that "If HTTP clients cache the results of host name lookups
> in order to achieve a performance improvement, they must observe the
> TTL information reported by DNS". Clients that follow this advice will
> be at greater risk than if they give cached DNS lookup results a floor
> on time-to-live, or keep a DNS resolution result "pinned" so long as
> any resource from that domain is active. Those are the simplest
> client-side mitigation strategies for DNS rebinding attacks. If DNS
> lookups are cached in the browser for a minimum of, say, an hour,
> there is much less risk of a DNS rebinding attack, because the
> attacker must get the user to keep a page open for at least an hour to
> be able to perform the rebinding attack.

While I'm not an expert on DNS rebinding, I'm afraid I don't agree
that DNS pinning helps prevent rebinding attacks.

To bypass DNS pinning, it has been shown that the attacker can close
their own server's HTTP port (return a RST to all future packets).  At
this point, browsers current go out and get the new IP address from
the DNS and initiate a new connection.  When you think about it, what
else can a user agent do?  It has no way of knowing if the DNS record
legitimately expired, so the only alternative is to simply prevent
users from accessing the web site for an hour (or whatever time limit
you propose).

The negative side of your proposal is, of course, the fact that plenty
of legitimate sites utilize small TTLs where the IPs actually change.
Some possible examples: dynamic DNS based sites, high availability
hosting sites designed to mitigate denial of service attacks, and just
legitimate sites in transition between different server IP addresses.

> DNS rebinding can also be defended against with complete
> effectiveness if servers always check the Host header. A server
> attacked via DNS rebinding will get an unexpected value in the Host
> header - the attackers hostname instead of any of its own.

I think it certainly would be worth discussing DNS rebinding in any
revisions, even if I don't agree with your first suggestion.  Host
header checking is something to look into.

Regards,
tim

---

From: Adam Barth <[email-masked]>
Date: Tue, 9 Feb 2010 10:08:38 -0800

> that DNS pinning helps prevent rebinding attacks.

DNS pinning is not a great solution to DNS rebinding, and I would
hesitate to recommend it to user agent implementors.  For details,
please see:

http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-boneh.pdf

On the other hand, Host header checking is effective, and it seems
valuable for HTTPbis to recommend it to server implementors.

Adam

---

From: Justin Erenkrantz <[email-masked]>
Date: Tue, 9 Feb 2010 10:21:17 -0800

> If HTTP had a requirement to check the Host header and all servers followed it, then the risk of DNS rebinding attacks would be eliminated for conforming servers. Meanwhile clients can only impleme…

I can see this as a SHOULD, but not as a MUST as I'm not a fan of
httpbis making such fundamental changes.  Enforcing this as a MUST
would certainly break most httpd configs that rely upon virtual
hosting in odd ways - so I'm not even sure httpd would make this the
default, but rather opt-in at best.  -- justin

---

From: Amit Klein <[email-masked]>
Date: Tue, 9 Feb 2010 20:23:14 +0200

Note that Host header verification is only effective if it can be
guaranteed that the client side cannot forge it - see
http://www.securityfocus.com/archive/1/445490/30/0/threaded

Thanks,
-Amit

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Feb 2010 10:40:27 -0800

> http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-boneh.pdf

I don't necessarily think HTTPbis should recommend it. However, I don't think HTTPbis should make it a MUST-level requirement not to do any DNS pinning, nor claim that following that requirement is necessary for security.

> valuable for HTTPbis to recommend it to server implementors.

I think that is the important recommendation to add.

Regards,
Maciej

---

From: Blake Frantz <[email-masked]>
Date: Tue, 9 Feb 2010 12:50:20 -0600

> valuable for HTTPbis to recommend it to server implementors.
 
I agree.

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Feb 2010 10:51:20 -0800

> http://www.securityfocus.com/archive/1/445490/30/0/threaded

I see some specific IE vulnerabilities cited here which allow the Host header to be forged via request splitting over a proxy: <http://www.securityfocus.com/archive/1/411585> It also cites some old Mozilla bugs that enabled header injection. And also some Flash vulnerabilities

Do these vulnerabilities or any similar ones still exist in current versions of browsers or in Flash?

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Tue, 9 Feb 2010 11:14:40 -0800

> Do these vulnerabilities or any similar ones still exist in current versions of browsers or in Flash?

Not that I'm aware of.  Put another way, all the user agents that have
those vulnerabilities also have known arbitrary code execution
vulnerabilities, so it's not really worth worrying about.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Feb 2010 07:38:07 +1100

... which is a duplicate of <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/100>. :)

--
Mark Nottingham     http://www.mnot.net/

---

From: Amit Klein <[email-masked]>
Date: Wed, 10 Feb 2010 09:56:09 +0200

> vulnerabilities, so it's not really worth worrying about.

I don't want to split hairs here, but the fact that browsers had
remote command execution bugs (which were probably fixed) doesn't mean
that the less critical issue of Host header forging was addressed.

Anyway, was http://www.securityfocus.com/archive/1/466906 ever addressed in IE?

---

From: Adam Barth <[email-masked]>
Date: Wed, 10 Feb 2010 00:03:34 -0800

> that the less critical issue of Host header forging was addressed.

Indeed.  What I meant is that all the versions of user agents that I
know of that are vulnerable to Host header spoofing are also
vulnerable to arbitrary code execution, which trumps host header
checking.  :)

> Anyway, was http://www.securityfocus.com/archive/1/466906 ever addressed in IE?

I believe so.

The integrity of the Host header appears to be a security property
user agent vendors are willing to ensure by providing security updates
when they notice violations.  In this business, that's the best we can
hope for.

Adam