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.

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)

O’Reilly Fluent Conference: Web App Testing For Everyone

I’m happy to announce here that I’ll be speaking about web app security testing at this year’s O’Reilly Fluent Conference (April 20-22, SF) .

Web applications are under constant attack and intrusions and data breaches are on the rise. Though attacks can be complex and sophisticated, many of the most common vulnerabilities are straightforward to observe and exploit.

In this presentation, Tony Porterfield will describe ways for users without extensive security experience to test for common vulnerabilities in web applications using only a browser and free software tools. These techniques will be illustrated with examples of actual vulnerabilities that he has observed while testing educational web applications. He will present a test plan that can be used to survey a site’s security in a short amount of time, and describe how it relates to the OWASP ASVSand Top 10 list.

DirectoryBurst – XSS and caching.

First a word about disclosure and vendor response.  I sent a couple of emails to DirectoryBurst about the problems in this post.  Though I never heard back from them, I observed that they fixed the XSS problem described below.  I describe the other less serious ones here too, in part so that users who see this can be aware and take steps to protect their information.

DirectoryBurst is an online school directory service.  It stores lots of personal information including full name, address, phone numbers, and parent email addresses.  I took a look at the site and saw a few problems.

The first one, now fixed, is that they were storing unvalidated user input for later display on their website.  Entering a directory name (to a demo admin account) that included the string “<script>alert(document.cookie);</script>” caused the following window to pop up each time this directory was viewed.  I’ve redacted the cookie values but kept the cookie names in the screen shot.

Screen Shot 2014-11-25 at 8.59.48 PM

This means that the script included in the directory name was executed in the browser when the page was viewed.  Popping the cookies up in an alert window is innocuous but a different script could forward these cookies to an attacker’s server, which could pose a real risk.  The defense against this attack is to inspect all user input and convert any code or scripts to printable, not executable formats.  For instance, the script text above was converted as follows for display on this blog post. (I’ve highlighted the converted characters).

&lt;script&gt;alert(document.cookie);&lt;/script&gt

Notice that there are two JSESSIONID cookies on the list of cookies?  Those are session IDs that could be used in a “session hijack” attack to take control of the user’s account.   The reason the script could read them is that the httpOnly flags were not set to protect them from this sort of attack.  I describe this problem in more detail in my post on session cookies.

Screen Shot 2014-11-25 at 9.08.03 PM

Another thing an attacker could do with this vulnerability is include malicious HTML in the page sent to users who load the directory.  As an illustrative example, entering a directory name including the HTML for a link to sfgate.com results in this HTML being served to the user.

Screen Shot 2014-11-25 at 9.16.09 PM

Which looks like this on the page – the text ‘click’ is a live link.  An attacker could set such a link to point to a malicious site or otherwise change the content of the page.

Screen Shot 2014-11-25 at 9.31.24 PM

Finally, DirectoryBurst is not preventing directory information from being stored in the browser’s disk cache. This means that someone can view them in a browser even if the browser has been closed and restarted. It also means that someone can hit the ‘back’ or ‘history’ buttons and view the directory details loaded by a user even after a user has logged out of the site.   (The fix is to include the “Cache-control: no-cache, no-store, must-revalidate” directives in response headers to prevent disk caching of sensitive data).  If your school uses DirectoryBurst, you should be careful about accessing it from a shared computer, and should clear the browser’s history and cache if you do use it on a shared computer.

Session cookies

We all know that we need to protect our usernames and passwords.  Session cookies are nearly as valuable to a hacker.  I’ll explain why, and how an end user can check to see if session cookies are being protected properly by a web site.

When we log in to websites we give our usernames and passwords once, then the site “remembers” that we are logged in for the requests that come later, until we log out.   Session cookies are what makes this work.  On the initial login the server returns a “session ID” in a cookie, and this ID is associated with the current login session on the server side.  The browser stores this cookie and sends it with the transactions that follow.  The server recognizes it and uses it to allow access and to return the information associated with that account.

If an intruder gets the session ID he can install it in his browser and “impersonate” the user it belongs to.  Some sites defend against this but in many cases, when the server gets the hacker’s requests it will behave the same way as it would if the account owner had logged in to the site.  Our intruder now has full control of the account and can browse its pages at will.  This type of attack is called “session hijacking”.  To make matters worse, many sites don’t invalidate session cookies when a user logs out.  In that case logging out will not stop someone from accessing your account with a stolen cookie.

In May, 2013 I worked with Dana Liebelson on a story in Mother Jones about lack of SSL on popular team sharing sites.  As part of that we made a video demonstrating how a hacker could use a free software program called CookieCadger to automate the process of stealing session cookies and using them to access other users’ accounts. You can watch that here.  This problem was also covered for education-related web sites by Natasha Singer in NY Times in June of 2013.  Before CookieCadger, a browser extension called Firesheep first called widespread attention to the problem.

Now that we see why session cookies are important, how can an end user check to see how well they are protected by a web site?  The first thing is to know how to look at them. There are a number of browser extensions that allow users to examine cookies, such as EditThisCookie for Chrome.  Session IDs have different names on different sites but usually the name indicates it’s a session cookie – ‘sessid’, ‘phpsessid’, ‘sid’ are some examples.  Here are some other things you can look for.

  1. Check whether the site is using SSL/https the whole time you’re logged in.  The first step to protecting the session cookies is encrypting them as they travel between your browser and the website. A URL starting with ‘https’ is your sign that the site is using encryption.  Some sites will use https for the page that collects the username and password and then switch back to http. THIS IS NOT ENOUGH! If the site switches back to http it’s sending your session cookies back and forth without encryption, ready to be stolen by anyone who can monitor the network traffic.  (Such as an open wifi network).  If the site is not using https at all, this is even worse – your username and password are also being sent in a way that others can see it.
  2. Check to see if the session cookie’s flags are set correctly.  Cookies have security-related flags that can be set by the website.  The ‘secure’ flag prevents the cookie from being sent over an unencrypted connection. For a site that uses https, this protects against unintended transmission over http.  A common example of this is when a user enters the site’s name in a new tab while already logged in — browsers typically default to http, and if the secure flag is not set, cookies will be sent and exposed over http during the redirect from http to https.  The ‘httpOnly’ flag prevents the cookie from being read by a script embedded in the page. This protects against an attack called XSS or Cross-Site Scripting, that can read a session cookie and send it to an attacker.  There are occasions when a website’s implementation prevents setting these flags but you’re always safer if they are set (and most of the time it’s an oversight if they are not).  Here’s an example of a google session ID that has both flags set.                                                                                         Screen Shot 2014-11-25 at 3.50.17 PM
  3. Look for the session ID in the url.  A URL can be logged in a server log or browser history even if sent with encryption.  If the website puts your session ID in the URL, it gets stored with the URL.  From there it could be read and used by an attacker to gain access to your account.

More on TRUSTe – Serving Seals without SSL

SSL/HTTPS provides encryption, but the protocol also provides assurance that the website on the other end of the connection is who they say they are, and that the information they send has not been tampered with by someone in the middle.  In other words it means you can have much more TRUST in the information’s authenticity.

The screen shot below shows an example of what Chrome displays when you click the lock icon next to an HTTPS URL.  Identity Verified

Screen Shot 2014-11-20 at 12.10.49 AM

TRUSTe’s site that verifies the privacy seals allows HTTP connections without SSL.  If a page with the seal is an HTTP page, clicking the TRUSTe seal will take you to an HTTP lookup page. You can try it here.  TRUSTe’s page for looking up which sites have its seals is an http page.  You can see that here.

Here is a screen shot of what Chrome says about the identity of the TRUSTe page for looking up certified companies. Identity not verified

Screen Shot 2014-11-20 at 12.31.09 AM

So, TRUSTe is providing a privacy certification, but allows the certificate to be sent over a connection that does not verify their identity or protect against tampering with the information between their server and your browser.  How can a user trust that it’s authentic?

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.”

Transparency and disclosure

I see lots of security problems with educational web sites and apps.

Sometimes problems like these get reported in the press.  For example in the past couple of years, Shutterfly, Schoology and Edmdodo have been in the press for not using SSL to protect user accounts and the information that they contain about kids.  Often, even if they are fixed, the companies don’t report that their users were exposed to security vulnerabilities.   This sort of thing is not as serious as an actual data breach, but parents and educators can’t make informed decisions without transparency and information about the security practices of the sites they are considering.  Many companies and sectors do make a practice of disclosing their security problems responsibly.  But this is not something I’ve seen in the ed-tech space.

Talking about things that are already fixed adds transparency and openness.  There are differing opinions about the best way to disclose security problems that have not yet been fixed.     This post by Troy Hunt lays out a good set of guidelines for when it makes sense to publicly disclose security problems.  He weighs the consequences to the site’s operators and users. It’s worth a read, and Troy’s blog, www.troyhunt.com is a great resource for those who’d like to learn more about security.