VTech vs EDtech

This week we’ve seen news of a major breach of users’ data from an online service run by VTech.  What sets this one apart is that personal information was stolen from hundreds of thousands of children’s accounts, associated with some of the millions of adult accounts that were also compromised.

Troy Hunt has posted a detailed analysis of the breach and other problems with VTech’s web applications.  You can read it here on Troy’s site or here on Ars Technica.  I encourage you to read it.

Here is what Troy Hunt had to say about the severity of the breach: 

“When it’s hundreds of thousands of children including their names, genders and birthdates, that’s off the charts. When it includes their parents as well – along with their home address – and you can link the two and emphatically say “Here is 9 year old Mary, I know where she lives and I have other personally identifiable information about her parents (including their password and security question)”, I start to run out of superlatives to even describe how bad that is.”

When I read this paragraph, head nodding, I thought of the running list I keep of my own kids’ identifiable personal information I’ve been able to gain unauthorized access to through remote attack vulnerabilities in online services used at their schools. (A remote attack is something that does not require access to the user’s network traffic, and can be done from anywhere).

The list is below. I was able to collect all of this by exercising flaws in web pages and interfaces in the education-related services that hold my kids’ information.  It wasn’t all in one place like the VTech information but goes far beyond what was held there.

  • full name
  • gender
  • date of birth
  • in-class behavior records
  • reading level and progress assessments
  • math skill and progress assessments
  • in-class test and quiz scores
  • report cards
  • ability to send private message to a student through an app
  • voice recordings
  • usernames (some with passwords)
  • password hashes
  • school lunch assistance status
  • name and address of school
  • teacher name
  • classmate names (through class rosters)
  • class photos with students labeled by name
  • parent email addresses
  • parent names
  • home address
  • home phone number

My kids are still in elementary school.  Simply by going to school they’ve already had all of this information exposed to the possibility of unauthorized access and collection.

I don’t have knowledge that any of this information has been subject to unauthorized access — but the only difference between a responsible disclosure and a data breach is the ethics of the person who finds the vulnerability.   Most of these vulnerabilities exposed many thousands of students to potential breaches, some of them exposed millions of students to potential breaches of their personal and educational information.

This is a system-wide problem that educators, parents and technology providers must work together to address.  Things are improving but we have a long way to go.  Here are some previous posts on that topic:

Why we need standards: part one of many

A starting point: end-user web app security test plan

Edsurge: Why student data security matters

 

 

Raz-kids and data security

In this post I’ll be describing my recent observations of the data security of the Raz-Kids/LearningA-Z online reading instruction application. These problems were described in a NY Times article by Natasha Singer on February 8th.

Before jumping in, a few words about disclosure:  I first reported lack of SSL to LearningA-Z in October 2013. I got an acknowledgement of my inquiry but no further correspondence from the company.  On Feb 2 of this year I sent the detailed information spelled out below.  I’ve had some contact with the company since then and waited to disclose until now as they worked on fixes.  A month later, a number of serious problems remain open, and the company has left an insecure API open after releasing updated mobile apps that no longer need it to function properly.

As described in my previous post, Raz-kids collects information about students and their reading level and progress.  Some of this is visible from student accounts and all of it is visible from teacher and parent accounts.

My observations in early February included the following problems:

  • No SSL used for teacher, student or parent website access, or with the mobile apps
  • Passwords stored in plain text, not hashed at the server
  • Presenting teacher username to mobile app caused full class roster with plaintext passwords to be transmitted without encryption
    • This interface could also be exercised from the browser
  • Option to set up student accounts with no password required to enter the account
  • Once in a student account, it was possible to register as a parent with no verification needed by the teacher before access was granted to student reading assessment information

Since then, SSL has been added to student accounts but not teacher or parent accounts, teacher approval is now required before parent accounts can access student assessments, and new Android and iOS apps have been released that no longer transmit plain text passwords for an entire class (though this API is still functional and in use by older versions of the apps).

In the remainder of this post I’ll describe details of the problems that remain open.

SSL/Encryption

The student website and latest mobile apps now use SSL to encrypt credentials and data. (More on mobile below).  However the teacher and parent accounts do not.  Since the teacher account has access to many students’ assessment information and voice recordings, and the parent account has access to student assessment information, there is more risk of data exposure from these accounts than from the student accounts that are now encrypted.  The SSL configuration is also flawed. It receives Qualys SSLLABS score of ‘F’ for vulnerability to POODLE TLS attack, a TLS variant of the original POODLE SSLv3 attack.

The following screen shots show teacher and parent logins served without encryption, and a proxy log showing the username/passwords being sent without encryption for a teacher account.

Screen Shot 2015-03-04 at 12.30.34 AMScreen Shot 2015-03-04 at 12.38.42 AMWhen a parent account login is started from an HTTPS page, the browser actually notifies the user that the credentials are being sent without encryption. The proxy log  confirms this, and the rest of the parent session is served without SSL/HTTPS.

Screen Shot 2015-03-04 at 12.32.34 AM

Screen Shot 2015-03-04 at 1.24.09 AM

Here is a summary of the SSL report

Screen Shot 2015-03-04 at 12.50.11 AM

Passwords stored in plain text

The following screen capture shows a trial teacher account displaying a roster page with student names (redacted) and passwords. This establishes that Raz-Kids is not following the best practice of hashing passwords at the server.  Teacher and parent passwords are treated similarly. Notice also that the page has been served with HTTP, meaning no encryption as these are transmitted across the network.

Screen Shot 2015-03-04 at 12.57.39 AM

Class roster with plaintext passwords transmitted without encryption

Previous versions of the Android and iOS apps transmit entire class rosters with plaintext passwords, unencrypted, when presented with a teacher username, and rely on this interface to function.  Raz-Kids has chosen to leave this API functional even after releasing updated apps that don’t rely on this interface. This means that users are not forced to update, and if they still have the older versions they are still causing this information to be transferred.  The interface could also still be exploited by an attacker.  User agent filtering was added in mid-February, but it is straightforward to change a browser’s user agent string to match one of the mobile apps and exercise the interface from a browser.

A portion of this response structure, from a trial account, is shown below

Screen Shot 2015-03-04 at 1.19.05 AM

I’ll close this post with a quote from the company that develops Raz-Kids, as reported in the NY Times:

“We are confident that we have taken the necessary steps to protect all student and teacher data at all times and comply with all federal and state laws,”

Raz-kids *does* collect student personal information.

In my next post I’ll have more to say about security problems I’ve observed with Raz-Kids, but first I want to start with their recent statements that they don’t collect students’ personal information.  It’s important to document what information they do collect, and it’s relevant to the discussion of how their data security practices have put student personal information at risk.

In an article published February 8th in the New York Times about data security problems in ed-tech apps, a representative for Cambium Learning Group, the developer of Raz-Kids was quoted as saying that Raz-Kids does not store “sensitive” personal information about students like addresses or phone numbers.   Later on twitter, a company representative took it further, stating “Raz-Kids holds no personal data.”

Screen Shot 2015-03-03 at 11.15.32 PM

One of my kids has a Raz-Kids account and I have seen first-hand what information the service collects.

From the FTC COPPA FAQ Page, here is a summary of what qualifies as children’s personal information under COPPA. Though COPPA does not always apply in educational settings, I view this list as a very good yardstick for what defines student personal information. I’ve highlighted the line items most relevant to Raz-Kids.

What is Personal Information?

The amended Rule defines personal information to include:

  • First and last name;
  • A home or other physical address including street name and name of a city or town;
  • Online contact information;
  • A screen or user name that functions as online contact information;
  • A telephone number;
  • A social security number;
  • A persistent identifier that can be used to recognize a user over time and across different websites or online services;
  • A photograph, video, or audio file, where such file contains a child’s image or voice;
  • Geolocation information sufficient to identify street name and name of a city or town; or
  • Information concerning the child or the parents of that child that the operator collects online from the child and combines with an identifier described above.

Here’s a summary of what raz-kids collects, all of which is covered by the list above.  I believe common sense also tells us that the information below is personal information about a student, and that all of this information is worthy of data security protections.

Screen Shot 2015-03-03 at 10.33.40 PM

  • Raz-kids generates reading level assessments and other metrics of a child’s reading proficiency.  This falls under the last bullet above, information concerning the child that the operator collects online from the child and combines with one of the other identifiers.   Screen shots of the reading level progress chart (annotated) and a quiz result showing skills to work on are shown below.

Screen Shot 2015-03-03 at 10.56.13 PM

Screen Shot 2015-03-03 at 10.45.42 PM

More soon on data security.