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)

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.