I'm done with LinkedIn.<p>I've been on the fence about it for a year now. I get more recruiter spam than value.<p>I'm also a bit too old for the schadenfreude that accompanies news of my overpaid friends getting canned. I'm running my own race these days and I've never been happier since I stopped comparing my lot in life to the few lucky SOBs I know that survived the cull of sub-prime.<p>I think a better strategy is (1) your own domain and/or (2) a site on github with actual code to validate* your talents.<p>*I hate those "Joe Schmo supported you skill in [insert banal technical skill here]" messages. I once put down C++ because I had been working with it for a couple years. Then, I thought better (I would not take a C++ programming job. Period. Hate that language.) and took it off. Next thing I know, I've got coworkers supporting my C++ acumen and LinkedIn trying to push it back on my profile. Ugh. I call that invasive feature creep.<p>On top of that, they seem to leave the backdoor open a bit too much for a company with $20b market cap.
The DNS was not exactly hijacked, there were issues inside of LinkedIn's top level DNS provider whom were delegating www.linkedin.com authorization to unauthorized nameservers, namely NS[SOMETHING].ztomy.com. The ztomy DNS replaces its delegated domains to point to a domain parking page if there is no record exiting. These changes were then propagated to other nameservers and thus to the end user. End result, dns doesn't point where you think it does.
Can anyone think of a good reason LinkedIn didn't mark their cookies as HTTPS-only?<p><a href="http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly" rel="nofollow">http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly</a>
Random anecdote:<p>One of the DNS issues I tried to fix with NIS+ was the 'maintaining a list of trusted servers' problem by distributing the management of the authoritative servers. Trust was built bottom up, and authority came top down.<p>The way it worked was that clients used a 'coldstart' file which was the (small number) of servers you trusted to provide your namespace lookups. You to their public key and you put it into your coldstart file. Similarly, a server put the key(s) of the servers it trusted above it in the name space in its coldstart file. And at company 'root' level was a set of servers run by a trusted authority.<p>Locating the authoritative name server for x.y.z from p.q.z (same as DNS root is rightmost) client in x.y.z asks its server for a trusted y.z server, gets it, and asks that server for a trusted z. server, then asks that server for a q.z. server and finally for a p.q.z. server. Once this has happened once you know trusted servers can can jump to the nearest one to start resolving a new path in the namespace.<p>It was slower on initial lookup and then just as fast as DNS on later ones.<p>It had the downside that compromised (or borked) high level servers could send you on a different path to different root if the server above them was incorrect.<p>It is one of the more fun problems in the whole name/directory service space.
<a href="http://confluence-networks.com/" rel="nofollow">http://confluence-networks.com/</a>:<p>Important Notice [20th June, 2013]<p>Confluence Networks is a Colocation & Network service provider having tie-ups with data centers across various geographical regions. We don't host any services ourselves. Starting few hours ago, we received reports about some sites (including linkedin.com) pointing to IPs allotted to our ranges. We are in touch with the affected parties & our customer to identify the root cause of this event.<p>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.
This isn't over yet - press dot linkedin.com (dont go there) is still pointing to the rogue server at 204.11.56.17<p>I'm trying to find other subdomains that might be still pointing there.<p>edit: i'm enumerating all the linkedin.com hosts using a dict. 80% of A records are returning the rogue IP 204.11<p>edit: 96 records still pointing at the rogue server, here is a dump I just uploaded:<p><a href="http://pastebin.com/uc2JXPfB" rel="nofollow">http://pastebin.com/uc2JXPfB</a>
Was api.linkedin.com compromised/hijacked? If so, that means they'll need to reset a lot of OAuth token/secrets which will be very painful indeed (worse than just a site-wide session reset).
I think confluence-networks.com may be apart of Network Solutions (which is whom LinkedIn is registered with).<p>I had a domain (nitren.com), that I let expire after 3yrs and confluence-networks.com back ordered it, I remember looking it up a while back, but if I remember right, all the ip and domains were registered or associated with netsol.
I'm going to blatantly advertise my own project "RubyDNS" - it can be a lot of fun, and it is especially relevant because it allows you to perform these kinds of attacks in a controlled environment. <a href="http://www.codeotaku.com/projects/rubydns/index.en" rel="nofollow">http://www.codeotaku.com/projects/rubydns/index.en</a>
My traceroute is going thru prolexic.com so there might be something else at play here. "Prolexic is the world’s largest and most trusted distributed denial of service (DDoS) mitigation service provider"
DNS hacks on big public companies seems like a big security oversite form the linkedin team. wow.<p>Perhaps my HTTPS anywhere extension could have helped folks.
<a href="https://linkedin.com" rel="nofollow">https://linkedin.com</a> 301s to <a href="http://linkedin.com" rel="nofollow">http://linkedin.com</a> for me. Should I be suspicious or do browsers validate the certificate even during re-directs?
LinkedIn has posted a statement pointing over to "the company that manages our domain" - <a href="http://linkd.in/12XMvpu" rel="nofollow">http://linkd.in/12XMvpu</a>
HTTPS everywhere; that's all I have to say. Something like this is very malicious and very hard to detect -- unless you ALWAYS use SSL. I noticed right away that the DNS was incorrect.
I just realised; If you opened a website with a linked in share button, your cookie might be compromised as well; you didn't even have to go the the site while under the DNS Hijack...
Can someone examine the cookies that they set and tell if there is any sensitive information (passwords?) that are hashed in there? Should we consider this a password breach?