A Student's Privacy Security Survey

by Pip Macki

This is a survey of the security of private student information on college campuses.

The particulars in this case were collected at the California State University, Chico.  Rather than undergoing a comprehensive security audit, these are only the vulnerabilities that are casually apparent.  Most of these issues have been observed by students during the regular course of registering for classes, checking grades, etc.  The scope of this survey only includes network and administrative policy, and network security.  While there may be machines on these networks running services that are vulnerable to attack, all of the issues raised in this survey exist independent of any exploitable services.

Numerous university databases contain personal student information.  Most of these databases receive information at one point or another from the mainframe (CHIMVS).  This machine hosts the Student Information System (SIS+), a database that contains, among other things, information on the enrollment status, grades, test results, and immunization records for all Chico State students since the system was put into place.

CHIMVS is running OS/390 with a front-end called Telescreen.  Telescreen has C2 certification, but only when it is properly configured.  University administrative staff connect directly to Telescreen via a TN3270 client.  This access method is used for everything from reserving a room to changing a student's enrollment status.  Not only does TN3270 use plain-text authentication, there are no apparent TCP Wrappers implemented, no firewalls (or a non-configured firewall), and many unsecured machines on the same LAN which still contains numerous non-switching hubs.  Essentially, traffic is wide open to the entire world, with little if any distinction between trusted and non-trusted networks.

It would be trivial to install SSH or tunnel TN3270 through an encrypted layer.  Such basic steps would eliminate an intruder's ability to pilfer passwords from a compromised machine from which users do not directly access CHIMVS.  Packet sniffing would still be a threat even if the server were separated from the Internet and student networks.  There are currently no secure means available for accessing CHIMVS.  All users are forced to login without encryption.  Physical access to Ethernet cables is also not difficult for a determined intruder to obtain.

Given the current setup, all IP addresses are allowed to connect to CHIMVS and potentially login.  CHIMVS' direct and unfiltered connection to the Internet greatly increases the number of people who are able to access SIS+ without any possible legitimate reason for having access.

Only trusted computers on the correct interface should be able to connect to CHIMVS.  However these computers (and their users) aren't worthy of trust themselves.  Currently these workstations are just as exposed as CHIMYVS, but are far more vulnerable to attack because they are also being used to access the world wide web and retrieve email while running notoriously insecure operating systems such as Microsoft Windows 95 and Windows NT.  Some of the Windows workstations have a virus scanner like Network Associate's VShield installed and prevent the long-term installation of new programs by re-mastering the hard drive from a central file server after each reboot.

Should the central file server be compromised, the results could be devastating.  All it takes is one workstation infected with a Trojan horse like BackOrifice 2000 (BO2K) to permit an intruder to sniff the network traffic for passwords and student information, log users' keystrokes as they enter their login and password, and use the trusted machine as a proxy to connect to CHIMVS.  Since BO2K is open-source, it can easily be modified and recompiled to slip pass conventional virus scanners.

Upon submitting forms to the Admissions and Records Department, students have been known to have a clear view of the terminal's screen.  One such screen displayed a TN3270 client (showing the record of the previous student) and a minimized session of the Microsoft Outlook email client with the user's email address visible.

There is a long list of methods for delivering a Trojan, and programs like Microsoft Outlook and Internet Explorer make it very easy for a user to unwittingly execute hostile code simply by viewing a document or going to a web site.  While the monitors can be repositioned so that they are no longer visible to shoulder surfing students, finding out a user's email address is as easy as calling on the phone and asking their name.

A complete and searchable directory of users' email addresses, names, phone numbers, and departments is accessible from the Chico State web page at www.csuchico.edu/cgi-bin/address.  Department secretaries and other staff are still susceptible to shoulder surfing and social engineering.

Any machine containing sensitive information should have no Internet connection whatsoever - it is an unnecessary risk and of questionable value.  Failing that, a properly configured firewall is essential.  Setup of all incoming connections should be denied, with outgoing connections limited to preapproved TCP ports, like 80 for HTTP, etc.

Onsite Mischief

There is still the issue of sharing information with other databases.

Campus Computing and the College of ECT maintain a user database that uses Student ID (SID) numbers copied from SIS+ for tracking and identifying email and shell accounts.  Student ID cards contain a Globally Unique Identifier (GUID) that is a different number than the SID (which in the vast majority of cases are Social Security numbers).

The Student ID card system is used as positive identification for students, faculty, and staff.  Their magstripes and barcodes contain the non-SID GUID and are used as a means of authentication for creating email accounts and to toll meals from dining hall meal plans.  This database is maintained on a system known as ICAM which ties Student ID card numbers to SIDs (obtained from SIS+), along with a photograph of the person and meal information.

When a meal is used, the card is swiped at a point of sale terminal connected to ICAM or some intermediary computer via a serial port.  An observant student would notice a serial cable going from the magstripe reader into an exposed and accessible punch-down junction box in the basement rec room.  It is a simple matter of plugging the serial cable into one serial port of a laptop, and the other serial port into the junction box and running a sniffer to pilfer Student ID card numbers, which can then be used to rewrite a magstripe in order to steal meals or create email accounts as someone else.  The ICAM system itself fails in many of the same ways as CHIMVS because of its lack of isolation and protection.

The College of ECT breaches students' privacy by associating their full name, obtained from SIS+, with their system user name, and publishing it in a public directory.  It is impossible for a student to modify this entry, as it exists independently of the system password file.  The email account system currently uses SIDs to keep track of user accounts.  It regularly checks SIS+ for the major and enrollment status of each account holder to verify which machine their account should be on.

If SIS+ used the Student ID card number as the SID, it would eliminate the need to cross-reference the two GUIDs.

It is possible to obtain a non-SSN SID.  However, if one first registers under their SSN and then changes to a fictitious number, it is still cross-referenced with the original SSN and there is no system in place to enforce the change in all of the various databases - causing much confusion and generally breaking things.

It is also possible for a student to change the PIN (set to their date of birth by default) with which they access their accounts via TRACS to register for classes and to check account information via the Student Personal Information web page.  The combination of SSN and DOB as a means of authentication are very poor choices.  They are easily obtained and guessed (respectively) pieces of personal information.

CNS, the Communications Network Services (www.csuchico.edu/csrv/cns), which provides telephone service for students living on and off campus uses Social Security numbers to identify students' accounts.  They have been known to hand people their phone bill (containing full account information) without checking a photo ID - only their phone number.  Once a person's SID has been discovered, it is a simple task to automate sequential dialing (wardialing) of TRACS (www.csuchico.edu/schedule/tracs_book) until the right PIN is entered.

Alternatively, one could theoretically write a program to sequentially enter PINs to the www-sis2.csuchico.edu/SalvoC/mvstart2.htm web page login.  Limited testing did not indicate a login retry limit per IP address.

Like a traditional dictionary attack, the pool of possibly PINs can be narrowed significantly.

First, by limiting it only to valid dates and a range of years consistent with the possible ages of the target.  In the rare case of someone actually having a non-DOB PIN, the chances are it is still six digits and one can work down from that.  The Student Personal Information web page's CGI has numerous potential vulnerabilities, most of which were not tested conclusively, not the least of which include buffer overflows and "man-in-the-middle" attacks.

The login page for the CGI is displayed in a JavaScript pop-up window and encrypted via SSL.  Various measures are taken to try to protect users' sessions, the login and PIN must be reentered each time a new request is made, and sessions timeout in a short amount of time.  But despite using SSL, the mistake is made of transmitting the login and PIN via the GET request of an HTML <form> tag, rather than the POST method.

Thus the login and PIN become part of the URL the browser goes to, and it is saved in the browser's history file and any bookmarks that are made of the page.  Bugs present in both Internet Explorer and Netscape allow previously accessed URLs to be erroneously reported as a referring URL to subsequently visited sites - further increasing potential exposure.  Checking the history files of public lab computers around grade reporting time could prove quite fruitful.

After taking the training course for using SIS+, it is not uncommon for users to write their password on the inside cover of their user manual.  Asking to borrow a department secretary's manual is one very easy technique for gaining access - the Chico State web page (www.csuchico.edu/tlp/resources/oncampus/master/rmavailres.html) even offers this friendly advice for those seeking to reserve a room:

"Most department secretaries have an account and password to access SIS+.  Below is a list of steps to access SIS+ for anyone who has a computer, a network connection, and a SIS+ account and password..."

In a red-tape filled bureaucracy like a university, sometimes the easiest way to analyze security is from the outside.

However, to perform a truly comprehensive security audit, proprietary knowledge of the University's database management would be needed, along with a whole lot of permission.