When Does a Student Become a ‘Hacktivist?’

 [originally published in Educational IT, a UBM/DeusM publication ]

The case of Montreal college student Hamed Al-Khabaz, expelled by Dawson College last November for having used vulnerability testing software on its Web servers without authorization, brings to a head all the myriad questions about lines being crossed, how, and when.  When is the use of commercial security software by outside actors considered “hacking?”  When is the discovery of a clear and present threat to students’ security considered, unto itself, a clear and present threat to students’ security?  If a security hole is obvious to a computer science student, is that student obligated to refrain from calling attention to it?

And as if those weren’t enough questions:  When should a service provider step in front of its client’s own public relations, and make “amends” for the repercussions that client’s policies may have on its own brand?

Hamid Al-Khadiz (used with permission) 

Hamid Al-Khadiz (used with permission) 

It Could Happen Anywhere

I spoke with Al-Khabaz on Wednesday [January 30, 2013].  His story is this:  Last September, as part of a school project to build a mobile app, Al-Khabaz was tasked with data integration: specifically, “scraping” data from the Omnivox consolidated portal, which is provided for Dawson by Skytech.  He was doing something your students may be doing right now, whether it’s assigned to them or not: creating a mobile app that lists students’ class and activity schedules.

Al-Khabaz needed to know how the data was generated.  In inspecting Omnivox’ code, he learned it was using a class of HTML and JavaScript that may have been state-of-the-art in the 1990s.  “It was a bit sluggish, and it took long to load.  And I knew that the portal was unmaintained,” he tells me.

That triggered his curiosity, which in its raw form can be a dangerous thing from any student.  “Does anybody even check for this?  Even if they’re not updating the Web site, they’re probably not even auditing their own system.  So I thought it would be a good idea to run a scanner.”

Many a post-mortem has begun with the phrase, “I thought it would be a good idea.”  Al-Khadiz used a commercial Web vulnerability scanning product called Acunetix (PDF available here), whose own customer list includes Ohio State University, Penn State University, and NASA.  The vulnerability scan triggered a sequence of events leading to Dawson’s IT department being notified, and Al-Khabaz’ account being briefly suspended.

But that cloud lifted soon, and the project resumed.  Three weeks later, Al-Khabaz tells me, in a discovery that did not derive from the initial Acunetix scan, he realized that the URLs generated by Omnivox contained student ID numbers.  If such a URL was included in a hyperlink or an e-mail message with the ID number intact, anyone else could see the same page without needing to log in first.

“It was really sloppy coding from them – no authentication or checking for session IDs,” he says, warning that a properly formed URL could lead to a student’s identity being lifted from the portal — a URL that could conceivably be guessed by anyone who writes down another student’s ID number from a card.

“This isn’t like Google, that just stores your e-mail address and your phone number and your name,” remarks Al-Khadiz.  “It’s a third-party company that stores our Social Insurance Numbers [the Canadian SSN].”

Can You Demonstrate a Leak Without Leaking?

In response to Al-Khabaz’ discovery, Dawson’s IT department supervised a round of tests conducted by him and one other student, using a special test server set up for this exclusive purpose.  As Al-Khadiz confirmed, “Skytech had no clue we were working on this.”

But once the tests were concluded, Skytech got a full demonstration.  “It took only five minutes to demo them how I could compromise my own data without being logged in,” says Al-Khadiz.

The key phrase there is “without being logged in.”  If indeed this characterization holds up under legal scrutiny, as it may yet receive, although student data (his own) was compromised by way of demonstration, no infiltration took place.  Such is the nature of security leaks.

As Al-Khabaz goes on to explain, Skytech was grateful for the demo, and actually patched the problem within a few days.  But then he performed a subsequent follow-up test, and it’s this second test that got him in the most trouble, leading to his suspension from Dawson College.

“I wanted to make sure it was still not vulnerable to SQL injection,” he explains, referring to the extremely common class of attack that particularly plagues older, or unmaintained, server software.”  He used Acunetix again, and without supervision.

“The reason was to get their attention,” he explains, “because they didn’t get back to me.  I left them an e-mail and my contact number, and they never called me back.  They took 48 hours, my patience was [waning], I really wanted to get permission to continue.  So I thought it would be a good idea to grab their attention on the test server, when I ran Acunetix with the same vector of attack as the first time, not being logged in, from the outside, for five to ten minutes, just so it could alert them.”

The key word there is “attack.”  Real attacks cause damage.  Can one conduct an attack-by-Acunetix?  I asked Sophos Labs’ senior security advisor Chet Wisniewski, who tells me:

The problem with these tools is that they often have unintended side effects that can crash the servers and cause denial of service.  Nothing [Al-Khabaz] did was legitimate research, as legitimate research begins with asking permission.  In fact, many of these tools make you acknowledge a disclaimer that you will not use them on systems that are not yours, or for which you haven’t gained appropriate permission.

Indeed, as I confirmed, the licensed Consultant Editions of Acunetix make that very stipulation; the Evaluation Edition only tests for cross-site scripting vulnerabilities.  Al-Khabaz also admitted he was aware of this stipulation.


Still, the once-and-future student says, the alarm bells rang.  Skytech collaborated with Al-Khabaz to voluntarily fix the flaws he uncovered on the second round, the details of which we agreed should not be revealed.  However, he said, the extent of any breach may have been massive:  “You could have banned a student or teacher from logging in; you could have reset somebody’s password; you could have seen your classmate’s address, phone number, and full name.”  There were other more minor repercussions, though he said he concentrated on these.

From Dawson’s point of view, Al-Khabaz crossed lines, and thus was enabled to take punitive action.  But while we’re on the subject of line-crossing, Skytech then went so far as to side-step Dawson’s handling of the matter by offering Al-Khabaz a scholarship for another college, and a job once he graduates.  It’s an act that places Skytech on the side of the hero in the latest cause célèbre, and puts the black hat of shame on its customer.

The lessons here for colleges and universities everywhere are these:

  • Everybody needs permission from everyone else.  Just because some of us want the Internet to be free and open does not give everyone perpetual license to catch each other with their breeches down.
  • Even old, good software is a security breach waiting to happen.  Old architecture in this new environment is a hazard unto itself.
  • The vast majority of students just want to help.  Sometimes they exercise bad judgment, but that can be said of almost any student.  The problem with resisting help from students is that it leads to student resistance, which is already well documented as society’s most uncontrollable force.