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)

Student Privacy Pledge Signatories With Unencrypted Logins

On February 11th Natasha Singer reported in the NY Times that many companies that collect student information had signed the Student Privacy Pledge, while having logins that were not encrypted, exposing usernames and passwords — and the associated accounts — to unauthorized access.   The Student Privacy Pledge signatories promise to: (highlights are mine)

Maintain a comprehensive security program that is reasonably designed to protect the security, privacy, confidentiality, and integrity of student personal information against risks – such as unauthorized access or use, or unintended or inappropriate disclosure – through the use of administrative, technological, and physical safeguards appropriate to the sensitivity of the information.

The OWASP guideline and widely accepted best practice is to encrypt login forms, transfer of credentials and all subsequent authenticated transfers during the login session.  (This one of the things that SSL/HTTPS does).   It is one of the most elementary security measures a web service can implement.   Any form of student information is sensitive enough to be reasonably afforded this basic level of protection.

Today, I counted eight Student Privacy Pledge signatories that appear to hold personal information about students, yet do not encrypt the transmission of their users’ login credentials.  Seven of them had already signed when the story ran on February 11th and have not made changes, and one (Cambium Learning Group, covered in earlier posts) signed the pledge while having unencrypted logins, among many other security problems.

My method was the following:

  1. Visit the website of the signatory
  2. Decide if it appears to collect student information (has a student login, for example)
  3. If so, do a login attempt and confirm in a proxy that the username and password are sent plain text without encryption

Since I don’t have login accounts for most of these services I did not do further checks about what happens after login.

The sites I observed to still be sending usernames and passwords without encryption were:

[Updated 3/25/15 to show results of doing the same check, after I was contacted by a couple of services letting me know they’d added SSL]

brainhive  [No login encryption on 3/25]

code.org [No login encryption on 3/25]

edgenuity [No login encryption on 3/25]

writerkey [Encrypted login on 3/25]

myon [Encrypted login on 3/25]

orglib [Encrypted login on 3/25]

readorium [Encrypted login on 3/25]

raz-kids (Cambium Learning Group) [Encrypted login on 3/25]

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

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