Responding To A Security Incident - Technibble
Technibble
Shares

Responding To A Security Incident

  • 05/31/2006
Shares

Earlier this week, a friend inconvenienced by a response to an security incident. The IT Services department (of his University) noticed an attack over the weekend, and as a result several user accounts were compromised. Their response? To give everyone two grace logins before their password expired and their account locked. A message was to be displayed on login, to this effect, asking users to change their passwords before they log in again.

There are numerous ways to log into the system. If you’re on campus, you can use one of the provided computers. Here, a message comes up during the login sequence and you get to enter a new password directly. If, however, you use the web based e-mail or University website protected areas, a popup message appears asking you to change your password.

Now, imagine, for a minute, you’re using Mozilla Firefox, which blocks popups, or you have a popup killer running. What, then, are you going to see when you log in? Nothing out of the ordinary. You’ll do what you went there to do, log out, and think nothing of it. Of course, you only have to do that twice, and your account gets locked.

Even worse is the fact that the e-mail accounts allow remote POP3 access. If you have Outlook or Mozilla Thunderbird configured to regularly check your e-mail, they will automatically make the requisite two logins, and from then on you will be locked out. You wouldn’t even realise why!

Adding to this the fact that you needed only two pieces of information to phone IT Services and re-enable your account: a university ID number, readily available on exam result postings, assessed work, etc. and a date of birth, also available through various University systems.

Given those two pieces of information, you could re-enable anyones account, and be told their temporary password. In fact, the IT Services people actually read the account name to you over the phone. So you don’t even need to find that out.

I’ve heard no statistics yet, but I do wonder how many accounts have been taken over by others. I didn’t try this myself, but there will be others that have, of that I am certain.

When responding to a security incident, the goal should be to improve security, not to reduce it. Think through your response plans, make sure you’re not opening the system up even more.

Of course, convenience to users is an issue, but most of the accounts that got locked could have been prevented if IT Services had displayed messages inline in the pages people had logged into, instead of relying on popups which many users would have missed! E-mailing each user would have eliminated the POP3 mail problem; after the first automated login you’d have an e-mail explaining the situation, so you’d be able to respond before your e-mail client made its second attempt, locking you out.

There are many ways to respond to mass password changing. This was not one of the best!

>