Hacker News Reader

Comment by ryanlol | Hacker News Reader

My theory is that this data leaked via custhelp.com, the filename of the data dump I have (linkedin.cfg) seems to support that.

This would also explain linkedins initial "confusion" regarding the hack.

View on HN

Could you elaborate? Also, when you say '"confusion"', do you mean it was feigned?

Linkedins support site URLs (hosted by custhelp.com) used to look something like this http://linkedin.custhelp.com/cgi-bin/*linkedin.cfg*/php/endu...

I know custhelp used to be particularly insecure right around when this hack happened, as I myself discovered several vulnerabilities back then.

>Also, when you say '"confusion"', do you mean it was feigned?

Partly. From what I recall it took them quite a while to own up to this very easily verifiable hack, which could very well have been because they couldn't figure out why it happened because it didn't actually happen on their systems.

Ah...I assumed that a leak happening via third-party would be an excuse for a company to be legit confused at first and then breathe a sigh of relief because that means they can blame someone else in the press release. Though I guess that's tricky when people start asking about why their data is being given in bulk to a third party in the first place...

Doesn't matter. If your logo is on the product, it's your fault. Full stop.

That's why I put the Google Maps logo on my surveillance van.

Wow, just looking at that URL is cause for concern.

Oh yeah, it was vulnerable to the exact RCE bug you'd guess at first glance.

In fact, the hack coincides perfectly with that php-cgi bug being released. Coincidence?

Reply on news.ycombinator.com