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 email to teachers

Today Raz-kids sent an email to its updates@learninga-z.com mailer list for users of its service.  The full text of the email is at the end of this post.  In this post I’ll address statements that are counter to my observations, with screen shots showing why.

“SSL encryption,…has always been used on Raz-Kids’ teacher-facing accounts”

I have proxy session files and screen shots taken as recently as March 4th that show teacher credentials sent without SSL, and authenticated teacher account sessions served without SSL.  The current SSL certificate on http://www.raz-kids.com was issued on February 11th of this year.  I observed certificate errors flagged by the browser when attempting to force HTTPS/SSL on http://www.raz-kids.com during January of this year.   The certificate information with validity date is shown below.

Screen Shot 2015-03-06 at 4.59.22 PM

My March 4th blog post on raz-kids security problems includes a screen shot of a teacher login page, including the code for the login form, served without SSL, and the credentials sent without SSL.  It was captured on March 4th and I’ve included it again here. The ‘world’ icon on the URL bar shows that the page including the code for the login form was served with http.

Screen Shot 2015-03-06 at 4.23.41 PM

Here is a new screenshot taken today. Notice that today the lock icon indicates this page was served with https.  I confirmed that the credentials are posted with https today as well and that is also a change from yesterday.

Screen Shot 2015-03-06 at 4.22.21 PM

The following screenshot was captured on March 2 and shows a logged-in teacher session served with http.

Screen Shot 2015-03-07 at 7.14.58 PM

A copy of the page cached by Google yesterday shows that as recently as yesterday the link embedded in the teacher login button was http, meaning at a minimum that http was the default.  This is consistent with my observations.

Screen Shot 2015-03-06 at 9.02.25 PM

Older cached copies of this same page on the Wayback Machine show the same thing.

“SSL encryption.. has now been added to the student-facing side of Raz‑Kids and its mobile applications. It is recommended that users of a previous mobile app download the latest update to utilize this enhancement.”

Correct but there is one important detail. The older version of the app still works, and users who have not updated still transmit full class rosters with plain text passwords without encryption every time a student logs in.  The underlying interface can also still be exploited from a browser, using a teacher username to extract the names and passwords of an entire class. Raz-kids could disable this interface and force users to upgrade the apps but thus far has not done so.  Details of this were included in my March 4th post and a screen shot of the response including student passwords in plain text is shown below. This screen shot was captured on March 2 but I have confirmed today that this interface is still active.

Screen Shot 2015-03-04 at 1.19.05 AM

“This additional encryption provides a comparable level of security found on various eCommerce sites.”

e-Commerce sites must adhere to the Payment Card Industry Data Security Spec (PCIDSS), a rigorous set of security requirements, including around encryption and overall transport layer security.  As I reported yesterday, the Qualys SSLLABs SSL checker gives http://www.raz-kids.com a score of ‘F’ because of an unpatched vulnerability to POODLE TLS.  (You can check the current status here.).  Though not directly related to encryption, there are numerous other security flaws with the raz-kids site that would cause a failed PCIDSS audit.

A screen shot of the Qualys SSLLABS report is shown below

Screen Shot 2015-03-06 at 4.47.55 PM

“An inaccuracy was recently discovered in Learning A‑Z’s Student Data Security and Confidentiality Statement. Despite what was stated there, Learning A‑Z does not require teachers or parents to add a student’s first name, last name, or identification number. All that is required is a student login handle. This statement has been revised.”

My observation is that student accounts set up prior to February 11 do not have such a “login handle” and use the students full names as the “login handle”, or username.  This seems to indicate that the change noted to the Student Data Security and Confidentiality Statement corresponds to a material change in the service.

On February 11th and before, I observed that the “Add Student” page had entry fields for First Name and Last Name with no option for “login handle/class chart name” or other identifier for the student other than first name and last name. The screenshot below was taken on February 11th.

Screen Shot 2015-03-06 at 5.05.24 PM

Today the same page looks like this (red boxes are mine).  “Class Chart Name” is the “login handle” referenced in the email.

Screen Shot 2015-03-06 at 5.03.17 PM

Prior to February 11th, it appears that teachers had no option to add a “class chart name”, only a student’s first and last name.  Today I opened an existing teacher trial account and added a new student, “Iwas Addedtoday” with “class chart name” of “iwasadded”.  Here is how the class roster looks. Notice that the new student Iwas has (iwasadded) below the first and last name and that Betsy and Robbie, set up prior to Feb 11th do not.  This situation is hard to explain if the “login handle/class chart name” had always been a required field.

Screen Shot 2015-03-06 at 1.13.22 PM

The “login handle” for each of the two pre-Feb-11th students is in fact the first and last name as shown here. Only the new student has a “login handle” of “iwasadded”. Robbie and Betsy’s login handles are their full names.

Screen Shot 2015-03-06 at 5.14.08 PM

I believe that any teacher using Raz-Kids can confirm this by logging in and going to the Class Roster page under Manage Students.  If a class was set up prior to Feb 11th I expect that the students won’t have “class chart names”, and that there is no way to add one to an existing student.  This seems to show that “class chart name” was not a field, required or otherwise, when the class was created.

“Learning A-Z believes all student data is important and needs to be protected. This includes student voice recordings, reading level information, and student login handles, which Raz‑Kids does collect for educational use.”

Company representatives have publicly stated in the NYTimes that raz-kids doesn’t collect “Sensitive” personal information and on twitter that Raz-Kids “holds no personal information”.   This statement discussing student information collected by Raz-Kids seems to contradict those public statements.

The full text of the mail sent today from Raz-Kids to teachers is below.

Learning A-Z’s Raz-Kids reading product has received even more security enhancements to protect student data. Learning A‑Z’s mission to empower teachers to help students succeed will not be impacted and product functionality will not be compromised.
Privacy and data security are core values of Learning A‑Z. As such, after proactively seeking out and then successfully completing a third-party audit to verify Family Educational Rights and Privacy Act (FERPA) compliance in December 2014, it was found that Cambium Learning and its products “successfully addressed the various applicable FERPA requirements.” The audit did make some suggestions for additional enhancements and those enhancements are detailed below.
Additional enhancements to Raz-Kids and Learning A-Z’s other student-facing technology products include:
Parent access to a student’s Raz-Kids account now requires teacher approval. This preventative step is designed to add additional security to the student account from people posing as parents.
SSL encryption, which has always been used on Raz-Kids’ teacher-facing accounts and Learning A‑Z’s eCommerce site, has now been added to the student-facing side of Raz‑Kids and its mobile applications. This additional encryption provides a comparable level of security found on various eCommerce sites. It is recommended that users of a previous mobile app download the latest updateto utilize this enhancement.
An inaccuracy was recently discovered in Learning A‑Z’s Student Data Security and Confidentiality Statement. Despite what was stated there, Learning A‑Z does not require teachers or parents to add a student’s first name, last name, or identification number. All that is required is a student login handle. This statement has been revised.
Learning A-Z believes all student data is important and needs to be protected. This includes student voice recordings, reading level information, and student login handles, which Raz‑Kids does collect for educational use. Raz‑Kids has never stored or required student email addresses, physical addresses, or Social Security Numbers. Any other student information, like first and last name, is not required, though teachers could choose to add this information to best support their educational objectives.
Learning A-Z will continue to address ever-changing issues brought up by parents and educators. As part of an ongoing security effort, Learning A‑Z and Cambium Learning’s other business units have already signed the Student Data Privacy Pledge recently promulgated by the Future of Privacy Forum and the Software and Information Industry Association.
As the issue of data security and student privacy continues to evolve, Learning A‑Z encourages curious or concerned educators or parents to contact John Jorgenson, SVP, Marketing at any time to learn more(520-232-5070 / john.jorgenson@learninga-z.com).

Update 3/7/15:

I noticed an error in the screen shot from 3/2/15 showing a logged-in teacher session using http.  I have replaced it with a correct screen shot also taken on 3/2/15.

A Starting Point: A Web App Security Test Plan for End Users

In an earlier post I discussed why we need security standards for education-related web apps.  Today we really don’t have any. Student privacy legislation typically requires “reasonable” security.  (This is due in part to the fact that legislation moves at a slower pace than technology and today’s requirements might not outlast the legislative cycle.) Industry-driven student privacy standards also tend to speak of “reasonable” security with few specifics. TRUST-e’s definition of kids privacy does not require protection of students’ personal information and academic activity, just their credit cards and SSNs.  Nobody has really specified what reasonable security means.   In this post I’ll share a starting point, based on the OWASP Application Security Verification Standard (ASVS) and my own observations of web app security problems.

Securing web applications takes effort, and attack methods grow more sophisticated all the time.  But the blueprint for providing a baseline of strong security is well defined.  The OWASP ASVS spells out a comprehensive list of requirements for designing and verifying a secure web application and defines different levels of verification.  A security standard appropriate for apps collecting students’ personal information and academic activities should incorporate most of the requirements from the ASVS ‘Standard’ level of verification.   Many requirements for the Standard level of verification require access to the inner workings of a web service’s operations.    The test plan I’m presenting here focuses on the ‘Opportunistic’ level of verification that can be observed by end-users of the web application.   My outlook is that the rigor of the practices we *can* observe is an indicator of the practices we *can’t* observe as end users.  So by assessing the health of a service against the observable security practices we can create a yardstick to compare sites and make decisions about whether to use them.

To perform the tests in this plan, no special access is needed beyond an account with the service, and no special equipment is needed beyond a computer and some free software programs.   Every item on the test presents some level of security risk. Many of them are minor but as a whole they paint a picture that’s often more important than the individual weaknesses cataloged in the test.  Having said that, if every education-related web app met this test standard, it would be a big leap forward from where we are today.

It’s my hope that this test plan might be adopted by parents, administrators and teachers as a yardstick or minimum set of requirements for apps that collect our children’s and students’ information.   It’s embedded below for viewing and downloading.

Web-App-Security-Test-Form-Feb15 (downloadable PDF)

TRUSTe and data security

I wasn’t too surprised to see the recent news that TRUSTe had settled with FTC for failure to reevaluate sites yearly for compliance.

Over the past couple of years I’ve filed several complaints with TRUSTe against sites that were subject to COPPA but not using SSL to protect the transfer of children’s personal information and the usernames, passwords and session identifiers for the accounts.  I got some surprising responses.

TRUSTe’s children’s privacy program requirements state that web services in the program must:

Use reasonable encryption methods such as Secure Socket Layer for transmission and storage of information if the inappropriate use or disclosure of that information could cause financial, physical, or reputational harm to an Individual.

Let’s start with reputational harm.  If an intruder gets usernames and passwords, or session IDs, the intruder can impersonate students or teachers in the service’s forums.  It’s not hard to see how that could lead to reputational harm.  Many educational and kids sites hold information about a child’s address or school, and pictures of the child.  Physical access can lead to physical harm.  Enough said there

As you’ll see in the responses below, TRUSTe has a children’s privacy program that does not consider children’s personal information to be sensitive data worthy of encryption.  What?  They also say that they don’t require SSL for things like passwords that are commonly sent unencrypted in emails.  One bad practice does not excuse another.  It’s like saying there’s no point in putting a fence around a pool because people often forget to close the gate.

These are actual quotes from TRUSTe’s responses:

Here they state that children’s PII is not considered sensitive information under their Children’s Privacy Program.

“We require encryption in transit for information we consider sensitive
under our program. Examples would include social security number,
credit card information, and medical laboratory results.

We do not require encryption for information we do not consider
sensitive under our program, or for passwords in transit if they
control access to only information that is not sensitive.

Based on the categories of information the  site is
collecting, which do not qualify as sensitive under our program, we do
not have authority to require the change you reference regarding HTTPS
in transit.”

Here, they reason that SSL is not needed to protect info that might be sent unsecurely by other means, and  state again that encrypting children’s personal info or the things that control access to it are not a requirement of their program

 “we do not consider that we have authority under our program requirements to require the service to use encryption to encrypt web traffic in transit for categories of information that are commonly sent unencrypted via e-mail to the account holder, or for passwords/cookies etc. used to access only this category of information, even though we understand that a technology-capable eavesdropper sitting in a coffee shop who chooses to violate federal and potentially other laws could possibly intercept unencrypted information sent unencrypted such as over HTTP or e-mail.

Additionally, just because information contains personally identifiable
information pertaining to a child under 13 years old does not
necessasrily require HTTPS encryption in transit under TRUSTe‘s
program (or under COPPA).

Therefore, based on the categories of information the service is
collecting, we do not have authority to require the service to encrypt
in transit:

1) the login form; or
2) after login, session cookies and data which include
or control access to children’s personal infromation.”

Here, another response where they state that encryption is not required for personal information of kids under 13.

“COPPA does not require that the service have site-wide HTTPS encryption.TRUSTe‘s program requires encryption where disclosure “could cause financial, physical, or reputational harm to an individual.” TRUSTe‘s current program requirements do not require site-wide encryption simply because the information being exchanged includes information about children under 13. However,TRUSTe strongly encourages the use of site-wide encryption even in situations where the nature of the information does not rise to this level.”

Why we need standards: Part one of many

The other day, I heard that some classes at our school were considering using an online service to share updates and photos about what happens at school during the day.   I took a look at the site and the first thing I noticed was that the site was not using SSL at all.  In fact, the site’s developers seemed to have spent more effort on protecting against disclosing parents’ email addresses to each other than to protecting against unauthorized access by outsiders.

Uh oh.  This means that the site transmits usernames and passwords, links to photos, comments, and personal information unencrypted – visible to anyone who is able to see the network traffic.   This also means the site is vulnerable to session hijacking, where an attacker can take full control of a victim’s account.  More on that in an upcoming post.

I sent a note to the company and got a quick (and a bit indignant) response from the CEO, saying that SSL was coming within days but had not been implemented yet because the site was not collecting any “highly sensitive” information such as credit cards or home addresses, and thus did not need SSL.

Really?  The site collects students’ first and last names, parent emails, and allows photos to be uploaded and shared.  Though COPPA does not apply here, I view the list of COPPA-protected personal information as one good yardstick for what sorts of student information requires secure handling, and all of these are on that list.

However, there is no real standard for data security in educational technology.  Laws such as COPPA and California’s SOPIPA require “reasonable” security, but do not define what “reasonable security” is.   The edtech industry has not come forward with a meaningful standard.   Without a standard, edtech implementors don’t have a clear target to aim for and educators and parents don’t have visibility in to the security practices of the companies that collect their children’s information.

In upcoming posts I’ll share thoughts on what the standards might look like and examples of why it’s important to have them.

More reading:

OWASP  (Open Web Application Security Project) has lots of information about securing web applications.  Here’s a link to their Transport Layer Security cheat-sheet, which includes the following about using SSL/TLS for login and authenticated pages.

Rule – Use TLS for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the “login landing page”, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user’s credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user’s authenticated session.