Wednesday, January 21, 2009

Classroll.com - [in]Security for students

[Just to re-iterate this again... opinions and thoughts expresed here on this blog are mine, and only mine, unless otherwise quoted or cited. This means they are not the opinion of my mother, friends, co-workers, employers, or anyone else...]

In case you missed it, I wrote an article a few days ago on my other blog (Following the White Rabbit) where I addressed the issue of the Pottsville, PA student "hacking" of the grading and online classroom system from Classroll.com.

I then thought a little more on the topic and figured I'd take a quick peek at the overall security of the Classboard.com login page where students and teachers as well as administrators go to log into the system. After an initial look, I wasn't shocked by what came next.

First off, the login page is a little scarry... after that, there were Cross-Site Scripting (XSS) issues all over the place. I got worried and decided that the best thing to do was call their support, and see if I could get through to someone who spoke security. I wasn't surprised by the result.

After trying twice unsuccessfully to leave a message and have someone call me back, I decided to get aggressive and pursue someone to talk to - a Mr. Ken Stith was going to be the Security Guy according to the girl in support that gave me his name, number and extension.

Ken seemed like a nice enough fellow, but very quickly I came to understand that we weren't necessarily speaking the same language. I had to explain what Cross-Site Scripting (XSS) was, and after a few tries we were on the same page. Next came having to convince him that even though his login and password boxes weren't necessarily XSS'able (at least not that my cursory check found) the other parameters on the page were open to exploitation... and that this was a problem. I will admit it's been a while since I've had to explain to a person in charge of security why Cross-Site Scripting (XSS) is a problem... but on the bright side Ken was polite enough to point out to me that his team was diligent about fixing issues and had already fixed the "SQL scripting thing"... he meant SQL Injection (SQLi). Before the end of the conversation we were on the same page, and Ken understood that I could, using a simple javascript reference tag in one of his parameters, redress the page or even redirect potential users to a different site where I [if I was a malicious user, or a desperate student - of which I am neither] could harvest student, employee, or parent login credentials. I'm not sure why this didn't register as a big deal with Ken... but he offered to me that the issue would be fixed, in short order and that he would address it with his staff.

True to his word, that particular vulnerability vector (notice the wording there) is mitigated. Now when someone attempts to exploit that specific vector they are greeted by this:


... which is a not-so-polite way of telling the attaker that you're onto them.

I do have some other issues that I really wish ClassBoard would address, but Ken alerted me to the fact that he won't be responding to my query for additional information because giving out information may lead to someone being able to exploit them easier... I'm not sure I buy that.
  1. Why on God's green earth would you ever allow a Non-Secure Login? Ken's original phone-interview response was that some users have incompatible browsers and when this feature was turned off, people flooded their support lines with help - so the option was re-enabled.
  2. Please sanitize all your variables. As an example, the DistrictID variable should be numeric (as far as I can tell) so there should be a nice input filter [on the server side] to simply eliminate any character from the user's input stream that is not a number. This would solve/mitigate your unnecessary risks.
  3. There should absolutely be separate login interfaces for staff and parents/students... absolutely. It's common sense and industry best-practice to not allow people who can administer the system to log in on the same interface as those who use the system. I will be happy to write up why in case anyone disagrees.
Of interesting note, since I can... I looked at some of the source ("view source" option in the browser) and noticed that there are some interesting tidbits hidden in there... Mr. Michael Stith...please review your source code?

1 comment:

s0ndra said...

R,
S3curityg1rl here..
can you believe all the bad source code flaws (viewable source code) out there? can't someone help these poor companies out? Some pay for protection - HaHaHacker Safe? other breaches occur on PCI compliant networks..(Heartland) is there a problem? Ya think?

I predict the days of bad coding will end very soon. Lets work to totally evict bad coding from internet sites everywhere!

There is no reason why everyone cannot write secure code. Let's make it harder for hackers:)

Our "Challenge": Security University is looking for Top Security Coders to hunt website code flaws from viewable source code. Are you a qualified coder who can find XSS, variable input flaws and other top 25 code flaws?

Exciting times, Challenge to be revealed at ShmooCon 09! whats a Challenge without monetary reward?

cya! S3curityg1rl

Google+