Student Hacks System to Alter Grades

This is an interesting story:

A UCSB student is being charged with four felonies after she allegedly stole the identity of two professors and used the information to change her own and several other students' grades, police said.

The Universty of California Santa Barbara has a custom program, eGrades, where faculty can submit and alter grades. It's password protected, of course. But there's a backup system, so that faculty who forget their password can reset it using their Social Security number and date of birth.

A student worked for an insurance company, and she was able to obtain SSN and DOB for two faculty members. She used that information to reset their passwords and change grades.

Police, university officials and campus computer specialists said Ramirez's alleged illegal access to the computer grading system was not the result of a deficiency or flaw in the program.

Sounds like a flaw in the program to me. It's even one I've written about: a primary security mechanism that fails to a less-secure secondary mechanism.

Posted on April 1, 2005 at 2:36 PM • 19 Comments

Comments

John LadwigApril 1, 2005 3:00 PM

The system account password management is clearly at fault here, but it's notable that the modification was caught as part of a normal business process, which involved sending notification back to the faculty member(s) and to the Registrar.

It's important that the update-notification not only go back to the faculty member, because though the student accessing the faculty account may not have known about the notification (via email, perhaps? seems not-unlikely) she might have known, and thus been able to lower the chance of detection.

Since prevention isn't foolproof, it's nice to see that detection was in place and worked here.

Davi OttenheimerApril 1, 2005 3:14 PM

Good one. This continues the ongoing theme of rediculously poor password and key management. We know users hate them, but developers just shoot themselves in the foot by doing the wrong thing and caving to user demands with a quick-fix.

Developers should know better than to weaken the system through a maintenance loophole or backdoor. But amazingly it still happens. The right thing to do bring more security into the development lifecycle and have someone dedicated to stand ground and/or raise awareness that systems require truly secure reset options (see the guidelines at www.owasp.org) or multi-factor authentication.

I wonder when we'll start to see a mandatory "crash-test dummy" review of software, or a five-star rating system...

Israel TorresApril 1, 2005 4:15 PM

She obviously didn't think her plan through when it would come to the point of where the authorized users would realize their password had changed, thus bringing questions, thus bringing forth an audit... and if she just changed her own grades and not a enough to mask her activity (say about 300?)... at least state that she must have had a malicious AOL virus that zombied her own account and prove her alibi... geesh... plans people... make plans.

Israel Torres

Chris WalshApril 1, 2005 4:25 PM

Stay tuned as cutthroat students take it to the next level by raising each other's grades in an attempt to get their rivals expelled. :^)

anonymous (sort of)April 1, 2005 7:43 PM

The system no longer allows users to change their own password. It now takes human intervention and verification.

As much as UCSB is spinning this as 'the system worked because it caught it', there is still the privacy issue, in that the attacker had access to all student grades in all courses taught by the two profs.

C. DiminoApril 1, 2005 11:59 PM

A student at the high school I attend attempted something of this nature. The student had changed his grades all the way back to ninth grade. The student was only caught when a teacher noticed something amiss on the report card that marking period (after the report cards had been distributed). The only punishments received were two weeks of athletic suspension and the revocation of computer privileges for the remainder of high school. Not that bad of a punishment, considering the offense.

Alex KruppApril 2, 2005 11:13 AM

I'd have to disagree somewhat with Bruce's analysis here. From what I understand and have read elsewhere, the grades were audited automatically because they were changed. Thus the worst any student can really do is to trigger an audit and hope the professor doesn't notice it. Not completely secure, but not entirely unreasonable either.

Now the smart thing to do would be to change the professors password and then give yourself a grade in a class you never took in the first place. Then you could take no classes, get a 4.0, and not worry about triggering the automatic auditing system :)

bpApril 2, 2005 12:31 PM

This is just another example of why single factor authentication based only on something you know is inadequate when it comes to protecting something valuable (such as student grades, in this case). Stuff you know ultimately can't be kept secret; bad guys will find a way to discover it. Yet bank accounts are protected only with PINs or passwords, and new credit accounts can be opened with only knowledge of SSNs, birthdates, etc. The only way to address these problems, it seems to me, is through stronger forms of authentication based on at least two authentication factors.

Presumably the professors at UCSB have other accounts or resources at the school that are password protected. What's needed is a way to issue each professor some sort of token (a OTP token, soft token, or even a paper card containing a grid of random numbers), and to enable that token to be usable for authentication at each account that needs to be protected. So while each account might require its own PIN or password, all accounts would require the professor to demonstrate possession of the same token.


Carl Furp von HeisterApril 2, 2005 2:39 PM

Ha, so why did the insurance company allow the student unfetted db query access, surely some form of inference/rbac access control should have been in place (cough-giggle). Lots of problems here:

1. One factor authentication, failed by the trivial security questions to create a new password.

2. A failed multilateral authentication system via the insurance company employing the intern.

3. Education system so macho, you have to cheat.

4. Typical teenage America.

Stu SavoryApril 3, 2005 12:23 PM

Here's another student security scare, just surfacing in our German press:-

http://www.spiegel.de/netzwelt/netzkultur/...

Outline : Student buys a used hard disc on eBay. It turns out to contain police files from the Ministry of the Interior, emergency terrorism plans, phone numbers etc of all the emergency staff for such crises, and a list of spooks.

Oops!

anonymousApril 3, 2005 2:05 PM

Notice the presumption that if somone can supply a matching SSN and birthdate, then it means that they are the individual with that SSN and birthdate. There was an incident where a Yale college Web site required students to enter an SSN and birthdate for access. Officials at Princeton had SSNs and birthdates for a number of students. As such, they were able to gain unauthorized access. See http://www.theregister.co.uk/2002/07/26/... Also, notice that recording access to the site (in terms of IP addresses) did have some value.

QuadroApril 3, 2005 6:36 PM

My school uses Apple's Powerschool system, in which teachers enter their grades on an internal website. However, the server is also accessible externally so that students and parents can view grades from home. A student could easily use a password cracker to compromise a teacher's account and change grades. The attempts would be logged, but the technology department is far too busy to regularly check the logs. Given the extra stress produced by many teachers needing help to enter grades at the end of a quarter, it seems fairly easy for a student's changed grades to make it to report cards if timed properly. And considering that every teacher has a network login with a password, there are numerous other avenues of attack that could yield a password to change grades.

On a related note, the same system is also used for attendance. Of course, if a teacher isn't in, they can't log in to take attendance, so the system has a feature built in for substitutes to take attendance. Since subs don't have accounts like teachers, however, (even though we rely on teachers to proctor others' classes instead of having fixed subs, the system remains the same) there is a single fixed password for all substitutes, which allows unrestricted access to attendance for any class. What happens if students discover this password?

On a different topic, in response to the question about allowing complete access to the database: I agree that it's stupid, but it's not uncommon. A student I know at this school (high school, so we're talking about a 17 year old kid here) has a part-time job at a bank, and has access to the bank's entire customer database. Why? Why would a teller need that? Of course, why would a teller need the code to the vault where they keep the money?

PS: Don't worry about this bank, they don't give their tellers everything, for instance the code to the second vault where they keep... T-shirts!

Christian GruberApril 6, 2005 10:26 AM

When I was a lad in the late 80s, I hacked the QNX lab using the old over-the-teacher's-shoulder method. I spoke to the teacher who ran the network about it, and expressed an interest, and so he gave me (tacitly) free reign on the system. Personally, I thought this was a wonderfully enlightened approach. So some schmuck that cajoled me into teaching him how to do such things managed to erase the password file in an attempt to deny his friend access as a joke. Now that was my fault. I was a geeky teenager with self-esteem problems, so I was quite susceptible to this sort of wet hacking. So I nearly got arrested, after the whole thing blew apart, since the password file's erasure caused a complete inability to access the network. (Yes, really old-school unix). Why am I mentioning this? Because the reaction was to threaten my arrest, suspend me from computer activities for the remainder of the year, and have me clean up the yard for the same period. The problem was fixed in hours, and I had actually gone a long way towards further securing the system as part of my meandering around the system. Fair? Sort-of.

Apart from griping about my childhood, there's a larger point here. We have a judiciary (in most Euro or post-Euro democracies) that are entirely uneducated, and don't know how to deal with such things. We don't have standards about what constitutes crimes at what levels in the digital world. Worse, we have knee-jerk reactions of politicians designed to convince the public that they are acting responsively to new threats. The modern legal systems need a bit of a reset and recalibrations. What is serious and what isn't? And who gets nailed?

For example, was I guilty? I hacked the system, but fessed, and was not "charged" when my crime was first discovered. My crime was teaching someone else how to do it. That I certainly do own, and I don't think I should have "gotten away with it." However, why would this other person not be subject to censure? Hi actions actually caused the damage. What about the teacher who let it happen. What about the QNX vendor who had unencrypted password files that I could edit from a teacher's account? Yes... unencrypted password files. Yes... editable from a staff account. Yeesh.

So back to the article. The student clearly has a bunch of responsibility here. The intent to deceive and defraud was clear. But what about the insurance company, as mentioned above? What about the school that allowed an authentication method that anyone with a connection to the internet can break? And to what extent is the level of damage a factor in the charge and in the punishment? Are all such frauds and/or identity theft identical in severity? Should they all be punished similarly? Even murder has degrees and levels (premeditated, accidental, incidental, etc.) There are a lot of factors that lawmakers and executors and judges seem quite willing to downplay in their race to the press releases and media scrums. I suspect that no one will be safe, secure, or justly treated until we (and our representatives and governments) stop with the panic and start analyzing and thinking.

cg.

DarkOpzApril 1, 2006 2:35 PM

The best thing to do would be to gain access to the student database. If you are able to bypass any triggers in the system someone's grades could be changed and would never be audited. What would be even worse is if some how the username / password was directly related to the database that is used in the main system. Then the student could have gained access directly to the database. And this does happen, I worked for a company in which we were required to develop the software to directly use the database as an authentication system.

The fact they had everything being audited is much better than many systems I've seen. Their auditing system at least worked. Now the fact the student was able to obtain their SSN and other related information at her job is much worse.

text me onlyJanuary 29, 2008 9:09 AM

im a highschool student, i just found the teachers internal website url login for powerschool for my school, it required a bit of trial and error for the url, but i figured out how to get to the login

http://powerschool.~yourschoolnamehere.org/...

just change ~yourschoolnamehere to the name of your school, the load the page. i deleted the name of my school for security reasons. also changing your grades to all a's is stupid, because that will be noticed. just change like a homework assingment or give yourself another point on a project or something. if you have a response, feel free to text me your email address so that i can email you, this way no email addresses are posted on this site, again for security reasons.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..