Date: 14 Nov 1999 05:24:53 -0000
Message-ID: <19991114052453.12962.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: bugtraq@securityfocus.com
Subject: Re: BIND bugs of the month (spoofing secure Web sites?)
References: <19991113011424.6999.qmail@cr.yp.to> <Pine.LNX.4.10.9911132116410.18106-100000@localhost>

Let's say an attacker wants to intercept your ``secure'' transactions
with hugebank.com. Here's what happens:

   (1) The attacker obtains two IP addresses, say 1.2.3.4 and 9.8.7.6.
       He also obtains a domain name, say secure-banking.dom.

   (2) The attacker sets up a DNS record for hugebank.secure-banking.dom
       pointing to 1.2.3.4. He sets up an SSL HTTP server on 1.2.3.4
       that looks just like hugebank.com.

   (3) The attacker sets up an HTTP server on 9.8.7.6 to respond to
       hugebank.com with a redirection to hugebank.secure-banking.dom.

   (4) You connect to hugebank.com. The attacker forges a DNS response
       to convince your browser to connect to 9.8.7.6. Your browser is
       automatically redirected to hugebank.secure-banking.dom.

   (5) You see the familiar home page for HugeBank. Your browser informs
       you that your connection to hugebank.secure-banking.dom is
       cryptographically protected and immune to eavesdropping.

   (6) Because you're a paranoid freak, you manually check the server
       certificate. You see a signed document from VeriSign telling you
       that hugebank.secure-banking.dom is ``HugeBank Secure Banking.''

   (7) You have now been lulled into a false sense of security. You type
       in your account number and password. Ten thousand other people do
       the same thing. The attacker steals all your money.

The main difficulty for the attacker is to guess the time and ID of your
DNS request---but he won't bother if your name server is vulnerable to
buffer overflows! He'll simply break in and forge cache entries.

> Even if the attackers monitored all your network communications, they
> still would not have your web server's private key and its passphrase.

The attacker doesn't need that information. The client used an insecure
procedure to obtain the server's key, and ended up with the attacker's
key instead.

---Dan