LinkedIn gets hacked, and you might have, too

Bryan Berg on ADN identified that LinkedIn got DNS-hijacked for about an hour or so yesterday before it was noticed and corrected. This is already a bad thing, because by hijacking the linkedin.com domain name it could be redirected to any site, including ones that might host malware or drive-by downloads. These are low risk to us PowerPC holdouts, but it gets worse: some of you who use LinkedIn regularly should also realize that your long-lived LinkedIn login session credentials may have been transmitted without encryption to the malicious site that temporarily took over the domain name. If you use LinkedIn and saw the malicious redirect (a link farm or some such called Confluence Networks), they got leaked. Even if Confluence didn't themselves collect them, a snooper in the middle may have. This might be a good time to change your password, even if you didn't (or didn't think you did) access LinkedIn during the vulnerable timeframe.

There is an extension called HTTP Strict Transport Security (HSTS) that is supposed to minimize the potential attack window for these kinds of situations -- the browser has a built-in whitelist of sites, which can be added to as the browser receives certain headers from the server, saying they can only be accessed with encryption over SSL. Naturally LinkedIn did not implement this, and that unacceptable oversight is all on them. But if they had, because the Confluence redirect was not encrypted, the browser, seeing that SSL was not available on the malicious server, would have stopped immediately and not transmitted the login credentials or visited the page. Even if Confluence had implemented SSL, they would not have been able to generate a trusted certificate matching the domain name, assuming the certificate authority wasn't incompetent, and self-signed certificates that have not already been approved by the client fail HSTS.

This is another potential issue with older browser security on Power Macs. Chrome, Opera and Firefox support HSTS, but HSTS wasn't added to Firefox until 4.0 (meaning not until TenFourFox) and the default whitelist wasn't implemented until 17, and not to Opera until version 12. Safari has never supported it, nor iCab, nor Camino, nor Roccat, nor OmniWeb. Yes, not all sites support it that should, but it's easy to add, and it's a security measure that could have prevented this leak. If LinkedIn had implemented this correctly, TenFourFox users would not have been vulnerable, and TenFourFox users are not vulnerable to similar attacks on sites that are HSTS-protected.

17.0.7 is building remotely as we speak on my G5 and I will be back at my desk tomorrow fully rested from my lovely vacation. There was a late breaking issue with 22's updater support, so unstable branch may get delayed until Sunday or Monday, but 17.0.7 should be up by tomorrow PM with the usual security and stability updates and a definitive fix for issue 225. It will finalize on Monday PM as usual. After that begins the death march to 24 and BaselineCompiler or bust.