Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

08:00 AM
Connect Directly

The Grinch Who Exposed Your Kids' Identities

5 Ways VTech's Scrooge-like security spending put young users at risk.

This article was updated on 12/1 with the latest count of children affected by the breach as announced today by VTech: "In total 4,854,209 customer (parent) accounts and 6,368,509 related kid profiles worldwide are affected, which includes approximately 1.2 million Kid Connect parent accounts.  In addition, there are 235,708 parent and 227,705 kids accounts in PlanetVTech. Kid profiles unlike account profiles only include name, gender and birthdate."

As news unfolds about the huge data breach at toymaker VTech that exposed personal information and passwords for close to 5 million parents and personal information on more than 6 million children, it's becoming clear that sometimes the Grinch isn't the thief. Sometimes the Grinch is the company with poor security practices that makes it possible for thieves to take innocent consumers' data--especially when those consumers are minors.

The VTech breach, which was first reported in a Motherboard article last week, seems to have been carried out not to steal the data, but to prove a point through its exposure: VTech's security stinks, and there's loads of data at risk as a result. Included in the data dump were poorly encrypted passwords, secret questions stored in plaintext and names, birthdays, photos, and chat logs for children using VTech toys that were easily tied to their parents' identifiable information like home addresses.

"Fortunately, the damage appears to be limited in that this attacker hasn't shared the data, but there's no way of knowing whether other attackers may have already obtained the same data," says Shuman Ghosemajumder, vice president of strategy at Shape Security. "Parents in general should, of course, be very careful about who they give their children's information to, and should watch for telltale signs that a company isn't taking security seriously."

The attention garnered by the exposure has certainly drawn the security community's microscope over VTech and what it found isn't pretty.


Willful Ignorance On What Kind Of Data Is Valuable

"VTech is proud that no credit card or banking information was stolen, but the data that was stolen could potentially make this breach more damaging and dangerous over the long run," says Jeff Hill, channel marketing manager for STEALTHbits, who explains that while credit card information can be cancelled, personal information cannot.

As he explains, patient criminals can stash information like names, birthdays, and mailing addresses to carry out future attacks that take advantage of initially stolen informatoin. In particular, information on minors can be seriously valuable as parents are less likely to do credit checks on their kids than on their own identities--giving attackers a longer time to use a stolen minor's information without any repercussions.

"Much more disturbing, however, is the potential for child predators to obtain and exploit the children’s information," Hill says.


Atrocious Encryption Practices

In a thorough analysis of VTech's data collection practices and weaknesses observable through its Web applications' customer interface and through information from the breach's data dump, development security expert Troy Hunt dismantled the company's data security practices. One of the first glaring problems? VTech is encrypting all of its parent passwords using only an unsalted MD5 hash. 

"Once the passwords hit the database we know they’re protected with nothing more than a straight MD5 hash which is so close to useless for anything but very strong passwords, they may as well have not even bothered," he wrote.

As Hunt explains, VTech's encryption at rest is second only to no encryption at all--which is exactly the route the company chose to go with for data in transit.

"All communications are over unencrypted connections including when passwords, parent’s details and sensitive information about kids is transmitted," he says. "These days, we’re well beyond the point of arguing this is ok – it’s not." 

Similarly, all data surrounding password reset questions were also stored in plaintext.


No Data Retention Boundaries

Beyond the crummy encryption, though, is an even more endemic data governance problem at VTech. Given the volume and variety of data breached, its clear that no thought had been given about data collection and retention policies. Exhibit A on this is the news yesterday that chat logs were also left exposed on VTech servers--leading most security experts to wonder why that data was even available to take.

If the firm had some kind of philosophy with regard to either collection or retention, VTech likely would have thought twice about the risk it incurred by keeping this kind of sensitive information.

"You should only collect and store data for well understood use," wrote Mark Nunnikhoven, vice president of cloud research for Trend Micro in a blog discussing the breach. "Data should be evaluated for its overall value to the organization and—just as importantly—the risk it can pose to the organization."


Bad Data Design

VTech's data governance woes extended beyond just promiscuous collection and retention practices. Another huge flaw exposed by this breach is the sloppy data design that allowed sensitive information about kids to be tied to even more identifiable information stored about those kids' parents.

These kinds of considerations are absolutely huge for companies that collect data on children, says Beth Marcus, CEO and founder of children's app developer Playrific.

"Through the data access structure, it's crucial to prevent various data pieces from being put together by any external player - even when parental permission in given," Marcus says. "You have to break the link between the data and the child, and the links between the various pieces of the data vault containing different elements of the individual's data. When kids are involved, saying 'sorry we didn't think about that' doesn't cut it. Hackers may never exploit data the way you think they might, that's why you can't risk having identifying information and behavior information tied together anywhere in the system at rest."


SQL-Laden Error Messages

VTech has gone on record saying that the likely attack vector for the breach was the tried and true SQL injection. That's no surprise given the fact that the company's error messages are serving up attackers valuable infrastructure on a silver platter. According to Hunt, VTech's password error messages were returning SQL statements to users. That's pretty much putting out the welcome mat for SQLi attackers.

 "This breach is another sad example of a company ignoring some very basic application security best practices," says Chris Eng, vice president of research for Veracode. "Why are websites still vulnerable to SQL injection today? The industry has known about this for decades, is one of the OWASP Top 10 most dangerous vulnerabilities and they are not difficult to find or fix."



Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
12/3/2015 | 5:40:51 AM
Unsalted hashes
You'd think that companies would have learned this lesson about unsalted hashes in the wake of that huge Adobe breach.

You'd think.

So much of cybersecurity is learning from others' mistakes -- and yet many simply don't do that.
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...