LinkedIn suffers DNS hijack • Hacker News Board

Re: LinkedIn suffers DNS hijack

#61

Post by dvanduzer » Thu, Jun 20, 2013, 5:29 AM UTC

ChuckMcM wrote: post #30

Random anecdote: 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. 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 i…

DNS SEC doesn't seem any closer to solving this problem, unfortunately.

Do you know of any designs that require a quorum at each level prior to trust? BitCoin seems to be having success with this model, but I'm wondering if anyone's built something like that with the primary intent of creating a directory service.

Re: LinkedIn suffers DNS hijack

#62

Post by ChuckMcM » Thu, Jun 20, 2013, 5:39 AM UTC

dvanduzer wrote: post #61

ChuckMcM wrote: post #30

Random anecdote: 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. 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 i…

DNS SEC doesn't seem any closer to solving this problem, unfortunately. Do you know of any designs that require a quorum at each level prior to trust? BitCoin seems to be having success with this model, but I'm wondering if anyone's built something like that with the primary intent of creating a directory service.

I don't think they have, much of the work on directory services died when people gave up. DNS was "too hard" to change and Microsoft wasn't going to let anything make into a standard that killed off the need for Active Directory. The LDAP guys, being formerly X.500 guys, went off solving a different problem and ended up somewhat stuck between AD and DNS. Sad really.

That said, your idea about poaching the Bitcoin quorum ideas is a good one. Essentially a data structure, equivalent to the block chain, where it only gets authenticated if enough people ack that its the most valid version of reality. Probably a publishable paper in exploring that question.

Re: LinkedIn suffers DNS hijack

#63

Post by wavefunction » Thu, Jun 20, 2013, 5:41 AM UTC

nikcub wrote: post #60

meatmanek wrote: post #54

Earlier quoted context omitted.

What nameserver are you using?

against their primary NS ns1.linkedin.com short TTL's on a lot of these domains I just ran it again this time using Google name servers and still a lot of subdomains are pointing to the 214 server. confirmed it running against their NS, which means it hasn't been changed yet.

I've got my nameservice hardset through openDNS and it's resolving to 198.55.195.121, which is allocated to NASDAQ OMX according to ARIN...

The 214.-.-.- is some British Virgin Islands allocation?

Re: LinkedIn suffers DNS hijack

#64

Post by gergles » Thu, Jun 20, 2013, 5:43 AM UTC

dsl wrote: post #43

memmove wrote: post #40

Earlier quoted context omitted.

dsl, no offense, but you seem to have a problem with any company that doesn't hire/provide employment to your average local community college CS grad and instead hires globally based purely on merit. Linkedin interviews are on par with facebook/google et al.

Really, now the sock puppets are coming out? I hire people purely on technical merit, I don't even bother reviewing educational credentials. I am opposed to abusing the H1-B system rather than opening offices overseas to bring in skilled labor and raise local standards of living.

LinkedIn does have overseas offices.

http://www.buzzom.com/2011/11/linkedin-opens-a-technology-ce...

Re: LinkedIn suffers DNS hijack

#65

Post by gergles » Thu, Jun 20, 2013, 5:46 AM UTC

rsamvit wrote: post #44

Sigh. At least they didn't leak plaintext passwords again

When did they ever leak plaintext passwords before? If you're referring to the event a year ago, that was unsalted MD5 hashes (obviously not great, but let's not hyperbolize.)

Re: LinkedIn suffers DNS hijack

#66

Post by shuw » Thu, Jun 20, 2013, 5:51 AM UTC

https://linkedin.com 301s to http://linkedin.com for me. Should I be suspicious or do browsers validate the certificate even during re-directs?

Re: LinkedIn suffers DNS hijack

#67

Post by dvanduzer » Thu, Jun 20, 2013, 5:52 AM UTC

ChuckMcM wrote: post #62

dvanduzer wrote: post #61

Earlier quoted context omitted.

DNS SEC doesn't seem any closer to solving this problem, unfortunately. Do you know of any designs that require a quorum at each level prior to trust? BitCoin seems to be having success with this model, but I'm wondering if anyone's built something like that with the primary intent of creating a directory service.

I don't think they have, much of the work on directory services died when people gave up. DNS was "too hard" to change and Microsoft wasn't going to let anything make into a standard that killed off the need for Active Directory. The LDAP guys, being formerly X.500 guys, went off solving a different problem and ended up somewhat stuck between AD and DNS. Sad really. That said, your idea about poaching the Bitcoin quo…

I love the fact that AD, and this newer posixy clone FreeIPA essentially operate as independent but interdependent directory services: LDAP, Kerberos, and DNS, and they still need X.500 in the form of SSL CA trusts to finish gluing it all together.

You may see an email from me in the next few weeks asking for feedback on such a paper.

Re: LinkedIn suffers DNS hijack

#68

Post by yannk » Thu, Jun 20, 2013, 5:53 AM UTC

inopinatus wrote: post #22

kcen wrote: post #12

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 doe…

Au contraire; having the delegation going somewhere unwanted is practically the definition of a DNS hijack. The question is - how did that happen? A malicious third party? a blundering sysadmin? or a bug in some provisioning code? It does sound like LinkedIn's NOC are playing the blame game already. Well, I guess they've gotta get all those spamming recruiters & sales reps back online. EDIT: heh, maybe it was The New…

ahaha, the job posting is a good find. We'll know if you are right if tomorrow a different add asking for "Total badass, Expert guru knowledge of Bind 9"

Re: LinkedIn suffers DNS hijack

#69

Post by dclowd9901 » Thu, Jun 20, 2013, 5:56 AM UTC

rsamvit wrote: post #44

Sigh. At least they didn't leak plaintext passwords again

The leaked passwords were hashed and unassociated with emails.

Re: LinkedIn suffers DNS hijack

#70

Post by nikcub » Thu, Jun 20, 2013, 6:06 AM UTC

wavefunction wrote: post #63

nikcub wrote: post #60

Earlier quoted context omitted.

against their primary NS ns1.linkedin.com short TTL's on a lot of these domains I just ran it again this time using Google name servers and still a lot of subdomains are pointing to the 214 server. confirmed it running against their NS, which means it hasn't been changed yet.

I've got my nameservice hardset through openDNS and it's resolving to 198.55.195.121, which is allocated to NASDAQ OMX according to ARIN... The 214.-.-.- is some British Virgin Islands allocation?

I just got a message on twitter that 214.11 might be a DDoS mitigation service.. have emailed linkedin to find out what is what.