Intro to After the Hack

In the MSP world, October is cybersecurity awareness month.

In honor of this occasion, we are running a new mini-series, After the Hack. For the next two weeks, we’re going to break down a handful of infamous hacks that have taken place and made headlines over the past couple of years. For each hack, we’ll discuss what happened, how it happened, and what lessons were learned.

81% of all breaches happen to small and medium-sized businesses. No one is immune to hackers, and SMBs cannot afford ANY mistakes.

Therefore, our goal for this series is to provide small and medium-sized businesses with some food for thought about cybersecurity. Hopefully, by the end of this series, you’ll consider reevaluating your business’s security.

So, what happened to LinkedIn in 2012?

On June 5, 2012, LinkedIn reported that it had been hacked. Nearly 6.5 million hashed user passwords were purportedly stolen by a Russian cybercriminal, and the users affected by the hack were not able to access their accounts for a period of time.

What does it mean that the passwords were hashed? Well, it doesn’t mean they were used as hashtags on Twitter…

If a company has leveled security, and its users’ passwords are compromised by hackers, it doesn’t lose those passwords in a human-readable form. Rather, hashed passwords don’t look like passwords at all. They look like an encrypted jumble.

The practice of hashing passwords is used to prevent passwords from being misused in the event that they’re stolen.

But that doesn’t mean it’s impossible to crack those cryptographic hashes…

The LinkedIn hacker uploaded 6.5 million hashed passwords to a Russian hacking forum requesting help in cracking the hashes.

Interestingly, no easy passwords (like 123456789 or password) appeared to be part of the hashed upload. There were also no duplicates. These two outlying facts suggested that the attacker had already cracked the easy, weak password hashes and had edited down the list of passwords to omit them.

By the morning of June 6, the Russian hacker’s list of passwords were cracked and posted, in plain-text, for the world to see.

LinkedIn’s solution for the users?

Email them with security instructions to reset their passwords. Many argued that this response seemed to lack the urgency demanded by the incident. Instead of implementing required password-resets to affected users, LinkedIn opted for an “Alert-and-Forget” approach.

And sure enough, in May 2016, security researchers discovered an additional 110.5 email addresses and hashed passwords that were leaked from the same 2012 breach. LinkedIn stepped in to help confirm that these newly found user credentials were in fact from LinkedIn and that they were not gathered from the result of a new breach.

So that leaves us with one of two conclusions concerning LinkedIn’s response to the 2012 data breach. Either LinkedIn didn’t notice the fact that 117 million user accounts had been compromised as opposed to 6.5 million, or they did notice and decided to withhold that information from the public. Neither conclusion represents the ideal.

Finally, as a last response to the breach in question, LinkedIn invalidated the passwords of all users that had not changed their passwords since 2012. Better late than never.

How did LinkedIn get hacked?

It’s hard to say what exactly happened because LinkedIn has only released a small amount of information. But we can speculate, and one thing we know for certain is that LinkedIn did not salt its password hashes.

In cryptography, a salt is random data that is used as an additional input to a one-way function that “hashes” data and passwords.  So, salt is like a doorknob.

Why salt?

Usually, if two users have the same password, they’ll also have the same password hashes. Salt can prevent bruteforce attacks that target this weakness by randomizing each hash. This means no two hashes are exactly the same, even if two plain-text passwords happen to be the same… Think of it like sprinkling a little bit of randomness on each user password.  If two users have the same password, it would look something like this:

And an attacker won’t know in advance what the salt will be – they won’t be able to pre-compute a lookup table or rainbow table.Simply by salting the hashes, rainbow tables (a table used to help crack passwords) become almost useless.

If each user’s password is hashed with a different salt, the reverse lookup table attack won’t work either. It’s a massive headache for the hacker.

LinkedIn’s failure to salt passwords suggested a more widespread lack of effective security practices. Hashing and salting is just one layer of protection, one you would expect to see in an enterprise environment comprising troves of customer data. A company like LinkedIn needs as many cybersecurity layers as possible.

The legal aftermath.

The LinkedIn breach triggered a $5 million class-action lawsuit, which US District Judge Edward dismissed in 2013.

Judge Edward proclaimed, “Unfortunately for the plaintiffs, they failed to provide evidence of injury coming out of the breach that was ‘concrete and particularized,’ as well as ‘actual and imminent.”

Nevertheless, LinkedIn did eventually pay $1.25 million to settle different and consolidated lawsuits filed by customers who paid for a LinkedIn premium subscription.

What about the hacker?

The feds got him. In October 2016, Yevgeniy Nikulin, a Russian hacker, was arrested in the Czech Republic. Nikulin is facing charges connected to LinkedIn, Dropbox, and Formspring data breaches.

LinkedIn said in a statement, via Reuters, that they have been “actively involved with the FBI’s case to pursue those responsible” for the attack.

Nikulin was extradited from the Czech Republic to the US in March 2018.

He pleaded not guilty to the charges against him.

The jury trial is scheduled to begin on January 28, 2019.

Takeaways for SMB owners.

As I mentioned in the beginning, small-to-mid-sized businesses are even MORE vulnerable to these sorts of cyber-attacks.

Why?

Because they don’t have enterprise-level cybersecurity set in place. In this day and age, you need more than antivirus and firewalls.

Using the LinkedIn data breach as a case study, here are our five big takeaways for SMB owners:

No business is 100% breach-proof.

Data breaches should always be treated as a “when not if” proposition. If cybercriminals want to get into your network, sooner or later, they’re going to do it

With that statement in mind, companies should consider investing in a security incident management solution. With security event monitoring, you’ll know RIGHT AWAY when there are initial signs of a breach. As a result, you’ll be able to minimize the damage.

All encryption is not created equal.

As mentioned, LinkedIn’s user passwords were encrypted, but the company was still using a relatively weak hashing algorithm. They did not salt their password hashes.

Wherever a business relies on passwords being encrypted, they should ensure that the passwords are salted and hashed using a strong algorithm. You don’t need the perks of enterprise-level security to ensure passwords are stored safely.

Implement layered network security solutions.

After the 2012 breach, LinkedIn enabled two-factor authentication using SMS text messages. We advise our clients to use two-factor authentication wherever possible as it increases protection significantly in the event of a data breach.

Make policies around passwords.

We have been saying this for years, but yes, you really should NOT reuse passwords. Creating unique passwords for every online service means that if one is compromised, none of the others are affected.

Additionally, everyone in your company should follow strong password creation guidelines. Emphasis on making sure all your passwords are unique!

Keep your database protected.

While salting hash passwords will help deter hackers, a determined one might not stop at the sign of salted hashes. That’s where layered security comes in. Don’t let hashes be your last (or only) defense.

Companies, regardless of size, should make sure their database is properly secured. That means proper security configurations, timely patching, and database activity monitoring. In the case of cybersecurity, less is NOT more.