Slashdot Mirror
UCSB Student Engineers Grade Hack
An anonymous reader writes "The UCSB Daily Nexus reports "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 article goes on to note that, though working a few tricks to get into the system, she was fairly unsophisticated, and in fact failed to conceal her IP address from authorities. With other computing snafus recently making headlines, are universities too careless with their data?"
I know the term has been bastardized and now encompasses a wide range of activities. However, this seems more like fraud than hacking to me. The term social engineering should be applied to obtaining information that deals with technology, not having someone change a grade. You could 'social engineer' clearing out your school by calling in a bomb threat, but that's hardly hacking...
time is a perception of a being's consciousness
time is your 6th sense, the wierd ones are 7+
She was caught because the university had a feedback system. The professors whose grades were changed were notified when the grades were changed. It didn't matter where she changed the grades from, the change would still have been noticed. Given the way she did it, she would still have been the prime suspect.
So, she wouldn't have got to keep the forged grades but she might have avoided a criminal record. Maybe.
i suppose i shouldn't be too surprised that a slashdot editor didn't bother to read the article they're posting, but i'd like to point out that in this case the problem was *not* a university being careless about data. the problem is that a student, by abusing her access to confidential data, was able to gain access to the same shared secrets that were used to authenticate network users. to the university's credit, they had an audit system in place which caught the problem.
SSL is insecure if the key exchange is sniffed.
Huh?
There are two SSL key exchange methods which are mostly used: (1) RSA and (2) ephemeral Diffie Hellman.
With (1), the client (browser) picks a random 48-byte key k, PKCS1 pads this, then raises it to the server's public exponent (e) mod N and sends that.
With (2), the client and server do a diffie hellman key exchange with the addition of the server signing his (so that the client can be sure he's talking to the server) with his RSA private key.
In neither case can the pre-master secret be obtained by a sniffer. In case (1), obtaining the pre-master secret from C = PKCS1( k )^e mod N implies being able to find e'th roots mod N (good luck with that). With the latter, the sniffer has: g^a mod p and g^b mod p, finding g^ab mod p is exactly the diffie hellman problem, good luck with that, too.
The problem is not breaking SSL. The problem is that tools like ettercap and CAIN (for Windows) can perform a Man In the Middle attack, where they use ARP cache poisoning to interpose themselves between the SSL client and SSL server BEFORE the session is established. Then, when the client tries to connect to the server, the MITM will fetch the client information, and use it to establish its own session to the server -- then quickly fake a certificate which it feedback back to the client.
Admittedly, most browsers will detect this, and throw up a dialogue box -- but due to poor training or understanding of security, 99% of users will simply click away the warning to get their application, and will happily login and access information, while the MITM steals all packets without having to attack the encryption.
SSL and SSHv1 are both vulnerable to this type of attack. SSHv2 and IPSEC will resist it, and fail the connection, which is correct behaviour.
Paul Gillingwater
MBA, CISSP, CISM
oh, and she knew how to use google also. http://www.google.com/search?q=university%20califo rnia%20santa%20barbara%20egrades