According to a series of news accounts today, it looks like twitter was either hacked or not hacked, depending on who you listen to. The bottom line seems to be that Twitter’s DNS servers were hijacked. How this was done has not been revealed. Twitter seems to be dodging the brunt of the blame because their provider runs their DNS servers. (Confirmed by a quick nslookup below). While this may be true, that only reflects how twitter should react internally. The risk to twitter’s users is still the same. If the hackers had wanted to do damage instead of showing off by putting up a “look at me I’m so cool” type of page, then they would have forwarded users to a phishing page that intercepted authentication credentials. (While this has fairly trivial implications for twitter, imagine if they did this for a bank).

C:\>nslookup

> set type=ns
> twitter.com
Server:  UnKnown
Address:  x.x.x.x

(root)
primary name server = trafficdns1.ddc.com
responsible mail addr = hostmaster.jettissystems.com
serial  = 2009072301
refresh = 43200 (12 hours)
retry   = 3600 (1 hour)
expire  = 1209600 (14 days)
default TTL = 3600 (1 hour)

Update: more details on the DNS records can be found at SANS’ incident handler diary.

A few weeks ago Bruce Schneier wrote an article entitled “memo to the next president“. In it he has several pieces of advice, including asking the president to use the government’s immense buying power to increase the security of products. The government’s buying power has been used before to influence products, whether deliberately or accidentally, and Schneier wants to see the government weild this power for the greater good. This is logical – after all the government exists to provide for the greater good where no other actor is able to do it.

On the same theme, OMB recently announced that it was requiring all government agencies to start deploying DNSSEC, and then gave them a deadline of January 2009. (See the wikipedia page on DNSSEC if you don’t know what it is). While it will almost assuredly be completed behind schedule (it is government after all), it is great news. Simply put, DNS is inherently flawed. As was pointed out by commenters in a previous post, assuming that the first response is the correct one is just a bad idea. DNSSEC fixes all of that by enforcing digital signatures. Most commercial enterprises right now are simply applying the newest patch and leaving it at that. As everyone knows though, continuing to try and patch over breaches in the dike will only work so long – eventually you have to build a whole new dike (In this case DNS). Hopefully with such a large entity getting behind DNSSEC, we’ll see a large movement to it, and we can avoid the next DNS cache poisoning attack before it ever comes, because we all know it will.

It was of course inevitable that once Dan Geer found a vulnerability in DNS, someone else would find it too, even if Dan asked people not to publicize it. It was also inevitable that someone would quickly write a metasploit plugin for it. What amazes me is the fact that despite all the fuss over this, everyone who was security conscious should have had this problem fixed years ago. Yes, I know it was only “discovered” recently, but what people are failing to highlight is that to exploit this against a DNS server, you have to allow recursive queries from third parties. I’ve been telling my clients for years to turn that off (the ones that had it on that is). This falls under the old security rule of “if you don’t need it, turn it off”, which is perhaps the single most important, and yet often ignored, security rule there is.

Since cache poisoning became a worry it has been well known that leaving recursive queries on was allowing an attacker an avenue to force your DNS server to make specific and known queries. This is a necessary step in almost any poisoning attack. In 2007, a study found that about half the DNS servers on the net still allowed recursive queries. Even after repeated warnings and previous DNS vulnerabilities, you would think that most people would have disabled recursive queries, but it doesn’t look like that’s the case. (Furthermore, the response has universally been to patch, rather than to turn off recursive queries). The solution to this and almost all other cache poisoning attacks is very simple:

If you don’t use it, TURN IT OFF!