The Hello Kitty Data Breach – a Deeper Look

Earlier this month we chose the Hello Kitty breach as the ‘winner’ of 2017’s first Breach of the Month. Why did we choose this particular data leak from the other January contenders? We’d like to outline the 2 major reasons we selected this particular breach: the nature of the data stolen, and some of the technical details around the breach.

Our first reason for selecting the breach was the type of data stolen — among the 3.3M records stolen in the Hello Kitty breach, around 186K of them included account details of children. Identity theft is enough of a problem for adults to deal with, let alone children. In the case of children’s information being compromised, the ugly face of identity theft will not manifest itself until they reach adulthood, and when it finally does, they will be clueless as to why it happened. Unlike passwords, some information — like SSNs — cannot be changed to mitigate the problem.

The second reason the Hello Kitty breach was selected for January’s Breach of the Month has a lot to do with how the breach happened, and some technical details surrounding it. This will be the main focus of this blog post.

Proper Configuration is Key

The records associated with this breach were compromised for more than a year before being found by the now-defunct LeakedSource, a data breach notification website. But the primary reason for this breach was a MongoDB misconfiguration, as uncovered by security researcher Chris Vickery. This misconfiguration led to public exposure of the data. At the time this happened (Dec 2015) Sanrio (Hello Kitty’s parent company), investigated the matter in detail and claimed that no one had accessed the database in its misconfigured state. The “misconfiguration” (no-configuration would be a better way to put it) behind the breach was that the MongoDB required no authentication for access.

This is not the only instance of unauthenticated MongoDB databases leading to an organizational apocalypse. A recent Cisco Continuum blog post describes ransomware attacks where hackers copy all the contents of unauthenticated MongoDB databases to their server, then delete the original database, asking for bitcoin in return for the stolen data. Now, MongoDB happens to be a really good, robust, and most importantly, free database. It ships with loads of security features out of the box. Then, what’s the catch here? These features need to be enabled.

Even then, just enabling MongoDB’s security features is not enough. They must be configured correctly. If authentication is enabled, that is certainly better than no authentication, but it’s still not very useful if the both the username and password are “admin”. MongoDB has other useful security features too, such as Role-Based Access control and the ability to audit system activities. All of these features and ways to configure them are described in a security checklist on the MongoDB website. A blog post on the MongoDB website also describes ways to check whether a MongoDB instance has been attacked.

Please… Don’t Hold the Salt

In addition to misconfiguration, there was another oversight that made the Sanrio breach even worse. The passwords found in the records were found to be hashed using the SHA-1 algorithm but were not salted. What’s a salt? This is not the salt we add to our food, although it isn’t any less useful. Let’s try to explain password salts with an example:

The password (qwerty) is stored within the database, hashed using the SHA-1 algorithm but without a salt. The way hashes work is that for a particular string of characters, they are always the same, unless a salt is used (more on that in a moment).

An attacker creates a list of commonly used passwords and words found in an English dictionary. Each word on this list is hashed using the same SHA-1 algorithm and checked for matches against a hashed password entry in the database.

You might think this sort of cross-matching would take a while, but with the computing power available today, a password like qwerty would be cracked using a common password list in a few seconds. Depending on how large a dictionary file is, any password from the dictionary will be cracked in anywhere from a few seconds to a few minutes, irrespective of whether it contains a mixture of upper case and lower case characters.

Salt is a sequence of random looking characters that is added to the password. Before being hashed, this random string is appended to the password. This considerably increases the work of a password cracker, since now dictionary or common password guessing attacks will not work. In case of qwerty, an attacker has to brute-force the entire character space of, as an example, [(qwerty) + (fmf4i54@!#$#$%)] — in this case the string of characters in the 2nd parenthesis is the salt. This is a very rudimentary example of salting; in real life there are very good cryptographic libraries available that do this even better, thus making the job of the attacker extremely difficult.

Another advantage of salting (if implemented correctly) is that since the salt used for each password is unique, if two users have the same password, e.g. football, then cracking one (password + salt) combination will not crack the other.

OWASP, a non-profit charitable organization dedicated to improving web application security has a list of the most common vulnerabilities found in web applications. Failure to adhere to two vulnerabilities from that list — security misconfigurations and sensitive data exposure — is what not only caused the Hello Kitty breach but also intensified the extent of the damage.

When it comes to the security of web-applications as well as databases, organizations must make sure that they at least try to mitigate the weaknesses described in the OWASP top 10 list. Looking at the bigger picture, thorough security policies must be formulated and adhered to by companies in order to protect them, as well as their customers, from cyber-attacks.

As for the end users, trying to use stronger passwords might help. If remembering passwords is a problem, then using password managers such as LastPass and 1Password is recommended. These tools have the ability to create extremely random, long, and complex passwords on the fly. Most importantly though, users must avoid password reuse across multiple accounts to avoid collateral damage.