Vulnerabilities / Threats

12/1/2015
08:00 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
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.
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Lessons from My Strange Journey into InfoSec
Lysa Myers, Security Researcher, ESET,  7/12/2018
What's Cooking With Caleb Sima
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14339
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the MMSE dissector could go into an infinite loop. This was addressed in epan/proto.c by adding offset and length validation.
CVE-2018-14340
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, dissectors that support zlib decompression could crash. This was addressed in epan/tvbuff_zlib.c by rejecting negative lengths to avoid a buffer over-read.
CVE-2018-14341
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the DICOM dissector could go into a large or infinite loop. This was addressed in epan/dissectors/packet-dcm.c by preventing an offset overflow.
CVE-2018-14342
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the BGP protocol dissector could go into a large loop. This was addressed in epan/dissectors/packet-bgp.c by validating Path Attribute lengths.
CVE-2018-14343
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the ASN.1 BER dissector could crash. This was addressed in epan/dissectors/packet-ber.c by ensuring that length values do not exceed the maximum signed integer.