|
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
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute |
Johannes 4478 Posts ISC Handler Jun 20th 2013 |
| Thread locked Subscribe |
Jun 20th 2013 8 years ago |
|
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.
|
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
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 |
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
I get the same output as bill
|
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
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?
|
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
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
|
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
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." |
Anonymous |
| Quote |
Jun 20th 2013 8 years ago |
|
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. |
Mysid 146 Posts |
| Quote |
Jun 20th 2013 8 years ago |
|
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. |
Mysid 146 Posts |
| Quote |
Jun 22nd 2013 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!
https://www.sans.edu
