Linkedin DNS Hijack - Update

Published: 2013-06-20
Last Updated: 2013-06-22 02:00:37 UTC
by Johannes Ullrich (Version: 2)
8 comment(s)

Update

It looks like this issue stemmed from a DDoS mitigation [1] gone awry or human error depending upon what source you refer to... [2] 

Orginal

LinkedIn had its DNS "hijacked". There are no details right now, but often this is the result of an attacker compromissing the account used to manage DNS servers.But so far, no details are available so this could be just a simple misconfiguration.

The issue has been resolved, but If LinkedIn is "down" for you, or if it points to a different site, then you should flush your DNS cache.

It does not appear that Linkedin uses DNSSEC (which may not have helped if the registrar account was compromissed). Your best bet to make sure you connect to the correct site is SSL. But of course, "owning" the domain may allow the attacker to create a new certificate rather quickly.

As indicated in a comment below (and some twitter messages), other sites are affected as well. Please add a comment if you find any. The fact that multiple site's NS records are affected implies that this may not be a simple compromissed registrar account.

Current, appearantly accurate, DNS replies for LinkedIn:

 

dig +short A linkedin.com
216.52.242.86

dig +short NS linkedin.com
ns4.p43.dynect.net.
ns4.linkedin.com.
ns3.p43.dynect.net.
ns1.p43.dynect.net.
ns2.p43.dynect.net.
ns1.linkedin.com.
ns3.linkedin.com.
ns5.linkedin.com.
ns6.linkedin.com.
ns2.linkedin.com.
All the NS records point to the same IP address right now: 156.154.69.23.
 
According to http://blog.escanav.com/2013/06/20/dns-hijack/, the bad IP address is 204.11.56.17.
 
For partial passive DNS cache results, see http://www.bfk.de/bfk_dnslogger.html?query=204.11.56.17#result
 
[1] https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/
[2] http://www.confluence-networks.com/
 
 
------
Johannes B. Ullrich, Ph.D.

SANS Technology Institute
Twitter

Keywords: dns linkedin
8 comment(s)

Comments

Also affecting other sites... most critical issue is the NS records, which typically have a long TTL. It is very likely that several businesses will start reporting more issues as the work day begins.
the IP is different for each ns$.linkedin.com

# dig ns{1..6}.linkedin.com A +short
156.154.64.23
156.154.65.23
156.154.66.23
156.154.67.23
156.154.68.23
156.154.69.23
I get the same output as bill
Domain Reg' Moniker sent out emails for a mandatory system wide password reset last night. Vague email but reads like they are worried about user account database comprise. Related? More widespread than Moniker?
Just talked to NS via our account with them. They are aware they have an issue but will not give out any details. Our accounts wer affected but their databases didn't show any record of us changing our DNS server entries. Nothing else was changed in our records including the password which doesn't make sense if the account was breached
Confluence Networks (who apparently all the domains were routed to) is indicating that the issue was PBCAK, not Security Related: http://www.confluence-networks.com/

"Note that it has already been verified that this issue was caused due to a human error and there was NO security related issue caused by the same. More details will be provided shortly."
I that Yelp and Craigslist are possibly affected as well: http://www.gossamer-threads.com/lists/nanog/users/163803

Before we would be willing to accept this as a mistake, and not a "breach coverup"; I think we need to understand what kind of mistake... I don't see any way this can be explained away as a simple "fat fingering"; something is horribly designed if this can happen, outside of an incorrect list of nameserver addresses sent to the domain registrar..

What's the chance, that registrants of multiple domains made the same error?
I think this almost has to be an ISP DNS man-in-the-middle-attack-box error....


Human error downtime /is/ a kind of security issue; comparable to accidentally running a security exploit against the wrong server, or performing a Man-in-the-Middle or response rewriting against the wrong server. Loss of availability or misdirection due to mistake.

There was a posting on Cisco's security blog: http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions/

Indeed, apparently the domain registrar NSol (not the registrant/not an operator of Linkedin's DNS servers)
made an unkinkable major goof -- submitted an unauthorized nameserver update to the shared registry, for a minimum of several thousands of domains registered through NSol.


Diary Archives