Weird one yesterday. We had a customer who had fallen foul of a phishing email and entered their username and password in a web form. Surprise surprise their account was compromised and used for sending a huge amount of SPAM. As soon as we became aware of the problem the user changed their password. Because the spammer had already established a connection as this user the password change did not affect them and they carried on. No major surprises there. We had to lapse the account (disable) for the connection to be dropped (I wish Microsoft would provide a tool for checking/closing active OWA/IMAP sessions in Exchange). The surprise came when we found the user could continue to login to OWA/IMAP using their old password, although it could not be used for any other resources. With some investigation it seems that once a user has authenticated to a CAS server with a password, as long as the connection remains active (and for some time after) the old password can still be used to authenticate (open new connections) to OWA/IMAP. This is alarming in my opinion. The most alarming thing is that all connections can be closed and you can still login using the old password (although I don't know for how long).
This issue is per CAS server. We usually have two, so this issue would not be as obvious normally (as the server the user logged into using the old password is the only server that will allow logins to continue using the old password).
I am going to log a urgent call with Microsoft about this. For info we are using Exchange 2007 SP1 RU5 on one front end and Exchange 2007 RU5 on all backends. The other front end has recently been upgraded to RU7, but the issue remains.
Anyone else seeing this?
Wednesday, 5 August 2009
Exchange 2007 Outlook Web Access Old Passwords
Subscribe to:
Post Comments (Atom)
3 comments:
I've been seeing a similar thing. I've tried going so far as disabling OWA/IMAP/POP/MAPI and the connection still stays open and the phisher keeps spamming. The only fix that I have found is to move the mailbox to another storage group which then breaks any connection/cache for the mailbox. The downside of this is that any of the recovered deleted items that were there are now gone and the user generally has lost the contents of their mailbox because the spammer kept getting rid of message to stay under the send quota.
Thanks Michael. Good idea on moving the mailbox. One to use in emergencies.
Microsoft did get back to me on this one and basically confirmed the behaviour. This only happens when using forms based auth due to the .Net authentication cache. The only thing you can do to mitigate this is to reduce the idle session timeout (not an option for us). To resolve the problem you can remove the token caching module. This will mean that there is very little authentication cache and most requests are authenticated against domain controllers, so network latency/problems will cause issues and your DCs will have an extra burden!
Post a Comment