The LinkedIn hack that wasn’t

Bryan Berg, the co-founder of microblogging site App.net (a Twitter variant with no ads and a sassy 80% more content permitted per post), pronounced earlier today that LinkedIn had been hacked.

According to Bryan, “LinkedIn just got DNS hijacked,” with the result that anyone trying to access LinkedIn ended up at a server belonging to confluence-networks.com.

Other reports suggested that US financial services giant Fidelity suffered almost exactly the same fate at the same time.

DNS, or the Domain Name System, is the globally-distributed database that turns human-friendly server and domain names such as www.example.com into computer-friendly IP numbers such as 192.0.43.10.

Clearly, if you can hack any of my network’s DNS servers (I am supposed to have two or more, for redundancy’s sake), and change my name-to-number mappings, you can probably take over any or all of my servers.

You don’t need to hack my web server, for example, if you can simply redirect visitors to a fake site in the first place.

For obvious reasons, stealing my traffic by hacking my DNS servers, and reconfiguring them so that they give out a false map of the internet, is known metaphorically as a DNS hijack.

The redirect

By its own admission, 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."

Interesting.

Why would crooks who had managed to own both LinkedIn’s and Fidelity’s DNS servers want to redirect traffic to an ISP’s holding page?

Surely a hack on this scale could be worth thousands, perhaps even millions, of ill-gotten dollars?

Could this have been the work of a crook so incompetent he didn’t even realise what he’d achieved?

Was it an incomplete hack that managed one level of DNS redirection but couldn’t get any further, leaving the crooks “stuck” inside a part of the network where there weren’t any customer servers to be found?

The explanation

According to Confluence Networks, the last suggestion above is the closest, though there was technically no DNS hack:

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.

Confluence links onwards to a report from domain name registration biggie Network Solutions, which offers the observation that:

In the process of resolving a Distributed Denial of Service (DDoS) incident on Wednesday night, the websites of a small number of Network Solutions customers were inadvertently affected for up to several hours. We are proactively working with these customers and have resolved most issues, none of which involved malicious activity. No confidential data was compromised...

LinkedIn and Fidelity, among millions of other organisations large and small, use Network Solutions to look after their domain names.

So it seems reasonable to assume that this completes the explanation.

DDoS mitigation

When a DDoS happens, it means that someone is co-ordinating a deliberate and sustained spike in traffic against your network, with the aim of drowning your genuine traffic in a sea of network sewage.

To counteract a DDoS, your service provider typically needs to start teasing apart your traffic from everyone else’s, if only to reduce the collateral damage on other customers. (If your site is going to collapse anyway, there’s no point in letting it bring down other sites at the same time.)

There are several ways to send traffic on a detour, including altering network routing tables, and performing DNS redirection.

And, with the best will in the world, if you need to make those sorts of change in double-quick time while an attack is under way, errors are more likely to happen.

We don’t know exact details yet, and they will probably never matter to most people anyway, but it’s a good guess that something like that happened here.

The conclusion

The bad redirection caused an outage, but doesn’t seem to have caused any more damage, since the target of the faulty redirect was apparently just a service provider’s holding page.

We can almost certainly all stand down from puce alert: there was no hijack, just an unexpected and temporary diversion to a nearby airfield.