Philips hacked, plaintext passwords revealed as R00tbeer gang strikes again

Sadly, r00tbeer has done it again, this time attacking Dutch technology giant Philips and digging out data from a range of Philips-branded sites.

A few small SQL databases have been leaked in full, divulging a few thousand records.

These include, amongst other things, names, telephone numbers, addresses, passwords and password hashes.

That’s right: passwords. One of the databases, fortunately containing fewer than 400 records, has passwords stored in plain text.

It’s hard to know just how much an attacker might be able to do with these passwords, but are are three massive problems here:

1. The passwords shouldn’t have been accessible in the first place.

2. The passwords shouldn’t have been stored in plain text.

3. The passwords were almost without exception poorly chosen.

The first two of these are the fault of Philips. There’s no such thing as an insignificant or unimportant password.

If a password is genuinely unimportant enough that you consider it acceptable to store it insecurely and not to protect it properly, then it is a poor security choice to have the password at all.

The best that can happen to pointless passwords is nothing. The worst is that you lose them and expose information that was by definition supposed to be secret.

The third of these problems is, of course, the fault of the users, compounded by Philips for letting the passwords out, and by r00tbeersec for their criminal and thoughless behaviour in stealing and dumping them.

Some examples of the poor passwords chosen are as follows:

1234
12345
123456
123457 -- nice try, but no cigar!
00000000
philips -- five appearances
ph1lips -- nice try, but no cigar!
password -- no list complete without it
qwerty -- ditto
seguro -- Spanish for "secure", it isn't
sonsname170908

I altered the last entry, since it had an obvious personal connection to the user – almost certainly his young lad’s name and birthday [*] – but it nevertheless reminds us why the first two points above are important.

Don’t store plaintext passwords, and don’t lose your password database either. By leaking passwords, you may give away personal information beyond the scope of the user and the data you’re protecting.

Philips also appeared to have blundered in one of the other password databases stolen, using what looked at first glance just like raw MD5 hashes of the user’s passwords. There was no random per-hash content (better known as salt).

Without password salts, if two users choose the same password, you can tell at a glance because they get the same hashed password. Crack one, crack all.

And since any password gets exactly the same hash every time it’s used, you can use a precomputed dictionary to attack the database. Checking the hashes doesn’t even require calculation – just a table lookup.

I attempted to crack the passwords in the offending database and found at once that they are, indeed, just plain MD5 hashes of the users’ passwords. No salt, and just one iteration of MD5 on the password before saving it.

(You should hash and rehash each password many times – thousands, at least. This forces a cracker to do the same, slowing down cracking by a factor as big as the number of iterations you used.)

To give you an idea of how easy it can be to crack simple passwords hashed in this simple way, consider that using a single CPU on a 3-year-old laptop, I recovered 139 out of 375 unique password hashes in just two minutes. As I’m typing this, yet more passwords are falling to my low-tech, low-power cracking efforts.

Any cybercrook worth his salt will probably have anywhere from 100 to 1,000,000 times the processing power at his disposal.

As with the plaintext passwords listed above, the hashed list is revealing many woeful choices, including: 123456, 12345678, 999999, philips (once again, chosen by numerous users), facebook and a couple of intriguingly rude ones.

The r00tbeersec cybercriminal co-operative also took the trouble to release a stolen list of nearly 200,000 email addresses at the same time as dumping the SQL files. This isn’t quite as intrusive or disruptive as exposing a structured database of user details, but it may very well mean an uptick in spam for the email users on the list.

What next?

For all my explicit criticism here of Philips, and my implicit criticism of those who chose such easily-guessed passwords, let’s not forget the criminals here.

Do you know r00tbeer and his cohorts? If so, why not do us all a favour? Turn them in to the cops.

Dobbing in your buddies might not be quite the done thing amongst the hacker counterculture, but by the standards of that counterculture – which seems to thrive on the discomfiture and casual cyberexploitation of others – it would be terribly amusing, wouldn’t you say?


[*] This is a database mainly of Italian customers. Italian date format is DD/MM/YYYY, or DDMMYY for short. Even if these passwords had been hashed, remember that password cracking tools make short work of dates. The password sonsname170908may look fairly complex, but sonsname is in my dictionary of Italian children’s names, and the password cracker doesn’t have to try every combination from 000000 to 999999 to cover all likely birthdates – only the ones from recent years which fit the format.