Many secure online services rely on a username and password to authenticate users and provide access. Domain registrars are no different. During the recent Comcast DNS hijack, someone gained control over the domain registration of Comcast.net. This breach allowed the hijacker to change Comcast’s DNS servers. It is unclear how they gained control but the hijackers were able to act as if they were the authorized person to make changes on behalf of Comcast.net. How they authenticated themselves is unclear right now, but it was as if they had the username and password to Comcast’s registrar account. As a registrar of domains, this security risk should be of particular note to all of our users.
According to DomainTools, their administrative contact changed on 05-28-08 to the hijacker. At the time of writing, Comcast is using a DynDNS Secret Registration-like service from Network Solutions. During the time of the attack, the hijackers changed the authoritative DNS servers for comcast.net. As the NS records from the com registry expired (the TTL for those records is two days), caching nameservers would receive the new nameservers, operated by the hijackers. They chose to point www.comcast.net to a static “I hacked you page,” but it could have just as easily been a Comcast login page where they harvested email address user names and password or billing information. It brings the concept of a phishing attack to a new, frightening scale.
Critical to preventing this type of attack is security of at least two-factor authentication. Before you, the unknown user, can be authorized to do something with your online account, you need to be authenticated. When you go to a bank and ask to withdraw money, they need two pieces of information for authentication. There is a name (what account number) and a password (ATM PIN, drivers license). The assumption is that the name is public (which is why credit card numbers and social security numbers have no security – it’s just a name) and the password is secret.
That’s why with all Dyn accounts, we limit our access control to an email address. If you forget a password (the other part of the two-factor authentication), you need to have access to your email address. We rely on your authorized access to your email address to ensure good security to your email address. Relying on authentication tokens like mother’s maiden name or credit card billing information is like building a house of cards. These pieces of semi-public information are not private and require only a little effort to collect. A real password (or even better, a changing password through a security token) is critical to limit authorization to an online service.
In the bank example, how many times can the same person ask the teller before the teller calls the police? Brute force attacks in real life hardly work but are a potentially huge problem online. So how is it solved? Stopping brute force attacks has a number of imperfect techniques. On the user side, there is password rotation and locking accounts out after a tries. On the server side, you can limiting the speed of guessing but little else.
How do you secure an email addresses then? That’s a topic for another time.