Attacks/Breaches
8/29/2013
02:54 PM
Connect Directly
RSS
E-Mail
50%
50%

Lessons Learned From N.Y. Times Hack Attack

How could the Times have recovered faster after the Syrian Electronic Army attacked its DNS registry? Here are six considerations to help protect your business from similar harm.

4. Employ DNS Registry Locks

Twitter -- but not the Times -- also subscribed to a registry lock service, which resembles a credit card fraud alert: Whenever someone attempts to do something suspicious, such as change DNS settings, the website owner receives an email alert. Such services cost as little as $50 per year, and are available from VeriSign and NeuStar. While the cost to the Times from the advertising revenue it lost as a result of the disruptions can't be tallied in full until its site is fully restored, the cost is likely to be orders of magnitude more expensive than a registry lock service subscription.

Why don't more registrars offer locking as an always-on service, layered with even better security controls? "The domain name registrars are trying to get better at doing things like this," said Carl Herberger, VP of security solutions for Radware, speaking by phone. "A lot of times there are complications in the way that they can actually accomplish their business. If you change the configuration it may break something."

In addition, using registry locks requires more effort when it comes to renewing domain names. Furthermore, what's to prevent an attacker from hacking into the registry lock provider?

5. Beware Simple Solutions

There is no silver bullet for preventing opportunistic attacks, and every new defense, such as registry locks, might create a potential new weakness, or require more effort. "At the end of the day, this was an integrity-based attack, and what I mean by that is they reconfigured the domain servers so they did different things," said Herberger. "So, to ensure the integrity of those different things, you're [now] going to lock those," referring to registry locking services. But what if someone attacks those services directly, or finds a way to cause long-term outages that leave customers unable to unlock settings?

Herberger added: "Whenever you centralize all of your security around fewer gatekeepers, you have the opportunity of a denial of service. That's the irony of it."

6. Be Prepared To Not Stop Every Attack

If attackers devote enough time and energy to finding a weakness that they can exploit with relatively low cost and little effort, then it will be almost impossible to stop them. "There's not a whole lot The New York Times can do if their third party DNS provider was hacked," said Ken Pickering, director of engineering at penetration testing firm CORE Security, via email. "The system is only really failsafe if DNS providers are unhackable, which obviously isn't the case. And this is the resultant outcome: A story that the NYT was hacked with very little they could do aside from picking a better service provider."

Furthermore, it's important to remember that the SEA -- graduating from its long-running Twitter account takeover activities -- found a new vulnerability to exploit. "They exposed some world-class exposures in some world-class environments," said Herberger. "To take down The New York Times website? Pretty impressive. To expose some security problems in Twitter, even if the rest of the world didn't know they were there? Very impressive."

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
David F. Carr
50%
50%
David F. Carr,
User Rank: Apprentice
8/30/2013 | 1:23:15 PM
re: Lessons Learned From N.Y. Times Hack Attack
Is there something website operators can do to get visibility into all the subcontractor relationships between different organizations involved in the management and maintenance of DNS records? Seems like simplifying the chain of command might be one way to minimize the chance of problems like this.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.