Monday, April 23, 2007

Update to IU Phishing story

I had a really interesting lunch meeting with a senior IU member of the administration on Friday. They wanted to chat about the IU Phishing incident, which I blogged about last week.

While we didn't see completely eye to eye on all issues, there was a fairly significant amount of common ground. While I felt that I had been pretty clear in my initial blog post, there seemed to be some confusion, esp. once it had been parsed by those in the media.

Thus, I'd like to clarify a few things:

1. The university 'steel' cluster was not 'hacked' through the use of a security hole. The phishers, whoever they were, logged in using compromised usernames/passwords. That is, they had somehow gotten access to valid user accounts.

This could have been done through another phishing attack, by hacking into student personal computers, or by someone leaving their gmail account open at a public computer in the library. There are plenty of other ways this could happen.

There is very very little that IT staff can do to protect computers from people who have their usernames/passwords stolen. Much can be done to fix system security flaws, but if a user chooses to keep their password on a post-it note attached to their monitor, it is very difficult to keep those bad guys out of their account.

2. There is no forensic evidence that indicates that the phishers obtained their target list (those people they'd send the phishing emails to) by looking at the /etc/passwd file on 'steel'.

Yes, the /etc/passwd file exists, contains usernames (which directly relate to an IU email account for many of the users), and is readable by all users logged in to the machine. If the phishers had wished to, they could have downloaded this file, and gotten a large number of email addressed by doing so. However, there is no forensic information which proves that they did do this.

We know that they had a a large list of targets - but how they got it, to this day, remains a mystery. We know several ways that they -might- have got it, but we do not have evidence to firmly support any of those theories.

3. Since every user who has an account on steel has access to the /etc/passwd file, it would have been quite possible for a student to login to the machine, download the file, and give it to the phishers, or share it online. The phishers wouldn't necessarily need to login to steel to get this, if they could somehow convince a student to get it for them.

4. No one knows where the phishers came from. All that is known is that they bounced their connection through a machine in China. The evidence trail stops there. They very well could have been in Bloomington, and we'd never know.


I guess the main point that we both agreed on, was that this problem did not stem from IU technical staff not doing a good job. As soon as they noticed that those compromised accounts were doing bad things, the accounts were locked and the remote machine in china was blocked from connecting to the university network.

Phishing, as always, is a people problem. It is the age old art of deception moved to a new, and scarily flexible medium. The real take-home from this, I suppose, is that with even a minimal bit of information (someone's name and email address), a phisher can do some pretty significant damage. This makes the job of protecting our data even more critical, and it means that we must train the student body, our friends, and family to have their wits about them.


Anonymous said...

"I guess the main point that we both agreed on, was that this problem did not stem from IU technical staff not doing a good job."

I might disagree with that. Given a host with a lot of users on it, many of them naive, it's pretty much a certainty that a portion of those accounts will be compromised. I would be very surprised if they didn't have a minimum of several accounts per month compromised, given the size and composition of the user community.

It's incumbent on system administrators of systems like this one (a large system with a lot of shell accounts) to ensure that when the inevitable account compromises occur, sensitive information is not exposed.

If, as with me, you believe that those e-mail addresses were not sensitive information anyway, you can argue that in that particular respect the sysadmins did nothing wrong. If you believe that those e-mail addresses had some expectation of confidentiality, however, the sysadmins were in the wrong.

It is possible to configure (some) Unix systems to avoid giving out information about other users, but it's usually difficult. Normally I simply wouldn't give out shell accounts, and give out only POP3/IMAP/WebMail accounts instead.

Unknown said...

Why don't you fill out a form at IU to prevent your "directory information" from being released or published if you don't want it to be public?