IXL Security Observations

In this post I’ll discuss my observations of the security practices of IXL.com.  IXL is a signatory of the Student Privacy Pledge. The Student Privacy Pledge website does not publish the dates that companies signed the pledge but I observed that IXL was added to the Student Privacy Pledge signatory page after February 11th.

Overview of the service

IXL.com is a math and English “adaptive learning” web service that also offers iOS and Android apps. Students play educational ‘games’ and extensive metrics are compiled to assess the students’ level and progress in math and english.

Summary of observations

The web site is served almost exclusively in HTTP. Usernames and passwords are sent with an HTTPS POST but the rest of the traffic is HTTP. Though the login credentials are protected, this still poses a significant risk of session hijack and data snooping attacks which could expose students’ names, affiliations and their assessment metrics as collected by the service. The risk is heightened by the fact that the teacher account has a roster page that displays the names and current passwords of all the students in a given class.  This roster is sent across the network without encryption if a teacher accesses it, and could be also be viewed by an attacker who has hijacked a teacher login session by sniffing the teacher’s authentication cookies off the network.

The mobile apps appear to have only a student-facing functionality. The lack of encryption for all but the the transaction that posts the username and password is consistent with that of the web app.

Authentication controls were in place to prevent remote attacks through enumeration of student or teacher IDs. Authentication tokens were invalidated when a user logged out of the session.

Notification and response

I notified the company of these observations on March 5th.  They got back to me a couple of days ago and have been very responsive since then.  I am including the company’s response to the observations I’d sent, with their permission:

As you noted, HTTPS is currently only used on IXL to protect login credentials and credit card data. Any risk created by using HTTP on the rest of the site is mitigated by the fact that, while technically possible, it is difficult for a determined hacker to “sniff” a user’s cookie value off of a modern network and navigate as if signed in as that user. However, we have been working to move our entire site over to HTTPS to eliminate this vulnerability. Though the vast majority of sites still use HTTP to serve up their content, we want to take every step we can to keep our site and our users secure.

Student passwords are intentionally stored in a reversible format to allow instructors to view them from their rosters. This allows instructors to retrieve them without making changes but, as you mentioned, makes them less secure when transmitted over HTTP. As we move to serve all IXL content over HTTPS, this risk will be eliminated, but it is worth noting that passwords for instructor-created students are the only passwords stored this way. Passwords for teachers, administrators, and parents who purchase their own accounts are all securely hashed when stored.

Thank you for pointing out that user credentials are included in the URL of the POST transaction when signing in on our Android app. Our engineering team has written a fix to remove this vulnerability, and we will patch it in once the update has been thoroughly tested by our Quality Assurance team.

I will add three thoughts of my own:

Sniffing cookies: For a determined hacker, sniffing cookies from a modern network and navigating a site as another user is not difficult at all. In 2011 a firefox plugin called “Firesheep” automated the process.  Today, a free program called “Cookie Cadger” automates the process and can be used with a stock Macbook Pro to execute this attack, called “Session Hijacking”.  In 2013 I worked on a story with Dana Liebelson of Mother Jones describing the problem and the short embedded video below, from that article, shows a demonstration.

The vast majority of sites still use HTTP to serve content:  Certainly true but it’s a flawed comparison.  The vast majority of sites don’t have usernames and passwords to create authenticated sessions, and don’t collect personal information from students.  The correct general use comparison here is social media or web-email sites, which typically do use encryption (well, since Firesheep anyway).  The OWASP Transport Security Layer (TLS) cheat sheet includes a rule to use TLS (another name for SSL) for all login pages and all authenticated pages.

Plaintext passwords:   Storing passwords in reversible formats is clearly counter to best practices for general use and transmitting them unencrypted makes it worse.  But, coupled with SSL perhaps it could be considered as a defined exception for classroom apps, so long as SSL+(HSTS required and secure flag if load balancers allow it) was there, and if personal information collected by the service was restricted to a less-sensitive subset. There is a practical reason behind it in this case. This is the sort of thing that might be in an edtech-specific security standard, if there was consensus that it is acceptable practice in defined circumstances.

Testing notes

I have access to my child’s paid student account, and also set up demo teacher and student accounts. Screen shots in this document are from the demo teacher and student accounts but all of the student account observations have been confirmed in the paid student account.

Detailed Observations

Sample reports
Screen shots of student assessment reports are shown below. In my demo accounts the data is sparse but the categories of data can be seen in these captures.

Student account

Screen Shot 2015-03-03 at 12.42.16 AM

Screen Shot 2015-03-03 at 12.43.39 AM

Teacher Account

Screen Shot 2015-03-03 at 12.50.30 AM

Screen Shot 2015-03-03 at 12.52.02 AM

Lack of encryption
The login form is served with HTTP, as are authenticated sessions. The username and password are sent with an HTTPS POST transaction. Though the login credentials are protected at login, this still poses a significant risk of session hijack and data snooping attacks which could expose students’ names, affiliations and their assessment metrics collected and compiled by the service.  (See my previous post on session cookies to read more about the risk of session hijacks posed by transmitting session cookies without encryption.)

Screen shots below show the login form and authenticated session, with URL indicating HTTP.  The session shown is a student account, but the teacher account I set up had the same behavior, as I will show later in the post.

Screen Shot 2015-03-03 at 12.54.15 AM

Screen Shot 2015-03-03 at 12.56.24 AM

A sample of the transactions is shown below. In the lower pane, the HTTPS POST of credentials and some HTTP responses from ixl.com are shown. The transaction selected in the proxy shows an HTTP GET, with user cookies sent without encryption.

Screen Shot 2015-03-03 at 1.06.57 AM

Transmission of plain text passwords without encryption
From a teacher account, a the ‘roster’ page loads a class roster and displays each student’s current password in plain text. This reveals that the passwords are not hashed at the server, and since the transfer is HTTP, it poses a risk that an attacker could obtain these passwords through direct observation of traffic or session hijack of a teacher account.  An additional observation is that encrypting usernames and passwords when users log in shows a recognition by the company that this information should be protected, but sending entire class rosters with plaintext passwords is a much larger risk than exposing a single user’s credentials.

The screen shots below show the class roster page in the browser, and the class roster data in the proxy

Screen Shot 2015-03-03 at 1.17.06 AM

Screen Shot 2015-03-03 at 1.21.27 AM

Notice also that the usernames contain the full first and last names of the students.  These are assigned by the service when the classroom is set up so there is no option for the teacher to make usernames that don’t include the students’ full names.

Mobile app transmits username and password in URL
When a user logs in from the mobile app, the username and password are included in the URL of the POST transaction used to authenticate the session. Though this information is encrypted in transit, best practice is to send all sensitive data in the HTTP message body, not in the URL.

This is documented in OWASP Application Security Verification Standard requirement 9.3, which is part of the lowest specified set of verification requirements, (Opportunistic).

Screen Shot 2015-03-08 at 11.04.55 PM

The OWASP Application Security FAQ has more information.  Consider that since the student usernames contain their full first and last names, logging as described below would capture the usernames and passwords, and the full names of the students.

Screen Shot 2015-03-12 at 10.06.42 AM

The proxy log below shows the HTTPS POST with credentials in URL, and that transactions after authentication are sent with HTTP, in a manner similar to the behavior of the web app.

Screen Shot 2015-03-03 at 1.37.59 AM

(Updated after posting to reorder the sections – no content changed)

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.

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.

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.