Tweet

The recent attacks on New York Times, Twitter and others while DNS-related, were not the result of a weakness in the DNS at all. They resulted from weaknesses in domain registrar infrastructure. The DNS components related to this event performed exactly as they were designed and instructed to do.

While it is true that the malicious instructions were unauthorized, they followed proper channels. Evidence points to The Syria Electronic Army, but investigation is still ongoing.

The breakdown came when the credentials of a Melbourne IT (a domain registrar) re-seller were compromised. (Please tell me passwords weren’t stored in un-salted MD5 hashes, please?). From there the attacker changed the name-server configuration for the victim domains to their own malicious infrastructure. The DNS took it from there. When the caches started expiring, the new “bogus” data began replacing the good data in DNS replies.

So what could the victims have done differently to prevent or reduce the impact of this attack? Let’s look at the basics:

• DNSSEC. DNSSEC could have been helpful IF the stolen credentials were not sufficient to allow the attacker to change the DNSSEC configuration of the subject domain. Otherwise the attacker could have replaced or removed the DNSSEC configuration and carried on with the attack.
• Domain-locking. Again this would have prevented the change IF the stolen credentials were not capable of disabling the lock feature. The fact that twitter.com was un-touched while some utility domains at Twitter were, indicates that this might be the case. Also it should be noted that depending on the registrar the domain-locking service may come at an additional fee.
• Domain monitoring. Always a good practice for high-profile domain-names. Configuration elements like name-servers tend to change slowly so any changes can be used to trigger an alert. There are a number of commercial monitoring services to choose from or you could consider using a small shell-script. Note I have no information one way or the other as to whether any of the involved companies had monitoring like this in place. It could not have prevented this scenario, but would have shortened the time to repair.
• Carefully selecting vendors based on their security posture. This one is HARD to implement right now. Vendors with a weak posture will not advertise that fact. Vendors with a strong posture will likely practice good operational security and be reluctant to share the details of their infrastructure, lest attackers get a roadmap of these defenses.

One thing we can all learn from these attacks is that dedicated attackers have no problems searching our contacts, connections, vendors and clients for the weakest link in order to gain entry.