Mistaken Goal: Where Student Affairs & Technology Meet

In the past month, two events related to “hacking” on residential computer networks have been reported and discussed.

First is a court case in which a university employee investigated a student’s computer in relation to security incidents at the institution and elsewhere. In 1999, an official at Qualcomm reported to the FBI and the University of Wisconsin at Madison that a computer at the University of Wisconsin was being used to hack into Qualcomm systems. A University of Wisconsin system administrator located the computer on the university’s residential computer network, noticed that it was also being used to attack computers at the university, and blocked the computer. The student evaded the block and the system administrator logged into the student’s computer to verify that it was indeed the computer he had originally blocked. The FBI showed up with a warrant and discovered that the student already had 15 minutes of fame as an infamous hacker interviewed by Forbes.

The student, Jerome Heckenkamp, attempted to have his conviction overturned since the University of Wisconsin sysadmin had searched his computer without a warrant. In an opinion filed on April 5, the Court of Appeals for the Ninth Circuit ruled denied Heckenkamp’s appeal. This case appears to be pretty important for ResNet professionals so let’s enumerate some of the specific findings:

• Heckenkamp “had a legitimate, objectively reasonable expectation of privacy in his personal computer.”
• “The act of attaching his computer to the network did not extinguish his legitimate, objectively reasonable privacy expectations.” The government even tried to argue that the usage policies of the University of Wisconsin network eliminated Heckencamp’s expectations of privacy. The court didn’t buy it: “When examined in their entirety, university policies do not eliminate Heckenkamp’s expectation of privacy in his computer. Rather, they establish limited instances in which university administrators may access his computer in order to protect the university’s systems.”
• Although Heckencamp had an expectation to privacy, an expectation not waived when using the University of Wisconsin’s network, the court concluded that the sysadmin’s “search of the computer was justified under the ’special needs’ exception to the warrant requirement…. [He] was acting to secure the Mail2 server, and that his actions were not motivated by a need to collect evidence for law enforcement purposes or at the request of law enforcement agents [and thus] a search warrant was not necessary because Savoy was acting purely within the scope of his role as a system administrator.”

Legal experts interviewed by The Chronicle of Higher Education’s called this ruling “a win for privacy.” However, it’s worth considering a slightly different viewpoint. Wired’s Threat Level blog was one of many voices labeling the University of Wisconsin’s actions “counter-hacking;” their analysis of the court case was a bit drier than that of the Chronicle but it was enough to elicit a response from a University of Wisconsin sysadmin. Although I’m sure that many would bristle at the notion of a good-faith, limited investigation of a computer attacking one’s network as “counter-hacking” that viewpoint is worth considering as it is held by many. Also worth reading is the analysis of Jennifer Granick, an attorney who represented Heckencamp early in the case.

The second incident is the suspension of a University of Portland student for his involvement with a program designed to circumvent his institution’s network access control. In this instance, the institution used Cisco Clean Access, a system that requires most computers on the network to install a program that checks to see if the computer meets the requirements set by the University of Portland for computers on its network. This commonly involves checking to see if anti-virus software is installed and up-to-date, verifying that operating system patches are installed, and checking other similar security-related settings and properties. Like all other computer programs, there are known flaws in Cisco Clean Access and there are programs available to circumvent many of those flaws. From the story published by the campus newspaper, it appears that this student not only wrote a new program to exploit some of those flaws but he also distributed the program to a handful of friends (and a professor - ???).

The most likely effect of this program was to allow this student and others using the program to log onto the network without having their computer examined. Is this something for which he should be suspended for a semester? As with all campus judicial proceedings, we’ll never know the full details of what happened and why. It’s possible that this student had a previous history of misbehavior. Or there may be an ongoing problem with misbehavior and non-compliance on the University of Portland computer network(s). Or this may be a huge over reaction on the part of a judicial officer not knowledgeable about network technology and security. Or… We could go on all day. We’ll never know and it would be folly to second guess or over analyze this incident without more information - information unlikely to be forthcoming. It’s simply an interesting data point and a curious glimpse at what may be an interesting story that we’ll never hear.

Although I’m sure this student is distraught over the situation, he may have a bright future in network security! Many bright and promising student employees first earned notoriety by exploiting network security flaws before being drawn into the fold and learning to use their powers for good.

Update: Bryon Fessler, Vice President for Information Services for the University of Portland, has publicly commented on the incident on the ResNet-l listserv. Although he is “bound by law and professional ethics such that [he is] not able to comment on the specifics of this case,” he has revealed that “the incidents were very serious, entirely ‘black hat’ in nature, and involved far more than just CCA.”  He also points out a recent NetworkWorld article with more technical details.