Re: Dealing with compromised Zimbra accounts

[Adam Cody <ajcody@zimbra.com>]

Correction on the 3204 bug reference, should be:

http://bugzilla.zimbra.com/show_bug.cgi?id=32046


Adam

----- "Adam Cody" <ajcody@zimbra.com> wrote:

> Not sure if this was the one I was recalling or not:
> 
> http://bugzilla.zimbra.com/show_bug.cgi?id=34054
> probably related : http://bugzilla.zimbra.com/show_bug.cgi?id=3204
> 
> not sure about this one...
> http://bugzilla.zimbra.com/show_bug.cgi?id=34441
> 
> Looks like they need some Votes/Comments... do as you will.
> 
> Adam
> 
> ----- "Adam Cody" <ajcody@zimbra.com> wrote:
> 
> > FYI - don't have time to look it up atm, but I believe there's been
> > a/some rfe's filed to handle the disconnect web sessions and
> tracking
> > of info/details to handle the spam highjacker situation. I'll try
> to
> > remember to follow up and post rfe # if I get time later incase no
> one
> > else does.
> > 
> > Adam
> > 
> > ----- "Matt Mencel" <MR-Mencel@wiu.edu> wrote:
> > 
> > > My cohort can answer better than me as he's done most of the work
> > > concerning this.....but...we've kind of discovered a few things
> > about
> > > spammers using our Zimbra...
> > > 
> > > 1)  The spammers don't waste much time sending single messages,
> > except
> > > while testing which maybe helps our little trap.
> > > 2)  The spammers automation stuff only seems to work in the
> > > HTML(Standard) client.
> > > 
> > > So, when we find an outgoing message with an envelope that
> contains
> > > more than X (I think 50) recipients AND it's been sent from the
> > > HTML(Standard) client, we dump it into a queue and don't deliver
> > until
> > > it's manually reviewed by an administrator.
> > > 
> > > I'd guess we're catching almost 100% of the outgoing SPAM
> attempts
> > now
> > > when an account gets compromised.  The AJAX client may be too
> > > difficult for them to script around(I'm guessing), and they like
> to
> > > send to LOTS of recipients.  We've only found one or two valid
> > senders
> > > who have been caught so far....and they've either switched back
> to
> > the
> > > AJAX client or understand why we delay their multi-recipient
> > > messages.
> > > 
> > > Phishing is one of those issues that separates the regular people
> > from
> > > the idiots....and we seem to have our fair share of the latter
> here.
> > 
> > > Not only do they continue to respond after lots of training and
> > high
> > > profile example cases....but they respond when the message is
> > > delivered TO THE JUNK!! folder...AND...the subject line INCLUDES
> > some
> > > text that reads [Fraud Alert: Suspected SPAM]....
> > > 
> > > HELLOOO???  The lights are on but no one is home.....I imagine
> the
> > > thought process goes like this...
> > > 
> > >
> >
> ....must...fight...urge....but...I...have....no....common...sense...
> > > must...hit..."Reply"
> > > button....and...give...away...my...private...info...
> > > 
> > > 
> > > It's cause for much consternation....but we do get a few laughs
> out
> > of
> > > it sometimes.  Maybe immense public ridicule would work?  :)
> > > 
> > > Matt
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Tom Golson" <tgolson@tamu.edu>
> > > To: "Steve Hillman" <hillman@sfu.ca>
> > > Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> > > Sent: Tuesday, January 13, 2009 2:41:10 PM GMT -06:00 US/Canada
> > > Central
> > > Subject: Re: Dealing with compromised Zimbra accounts
> > > 
> > > It has been our experience that setting the zimbraAccountStatus
> to
> > > "locked" does kill the current session.  But you're right -- if
> > used
> > > as
> > > a "toggle" there's no useful effect.  The mailbox has to remain
> > > locked
> > > long enough for the spammer to lose interest.
> > > 
> > > We use a semi-automated process of monitoring outbound message
> > rates
> > > and
> > > triggering alerts.  Since our customers do have the unfortunate
> > habit
> > > of
> > >  sending mail to massive lists of people, we try to verify
> messages
> > > as
> > > being "spam" before we take punitive action.
> > > 
> > > If an account is compromised, one of our admins will trigger a
> > > process
> > > to scramble the customer's password, lock their mailbox and send
> a
> > > notice to our help desk so they can conduct "customer education".
> 
> > We
> > > do
> > > leave the mailbox locked until the customer has been contacted
> and
> > > reset
> > > their password.
> > > 
> > > Inbound, we make very heavy use of the anti-phishing-mail-reply
> > group
> > > that was spun off from the hied-email-admin list onto Google
> groups.
> > 
> > > It
> > > is an excellent resource.
> > > 
> > > --Tom
> > > 
> > > Steve Hillman wrote:
> > > > Hi folks,
> > > >   Now that we've moved all of our students over to our Zimbra
> > > implementation, we're starting to see Zimbra accounts get used
> for
> > > spamming (after being successfully phished) -- we've had 3 in the
> > last
> > > 3 days.
> > > > 
> > > > We're having to invent new ways of dealing with these -- simply
> > > changing the password or locking the account doesn't actually
> stop
> > the
> > > current session. Our session timeout is 12 hours, so this would
> > allow
> > > the spammer to keep functioning for quite awhile unless we can
> kill
> > > the session programmatically. 
> > > > 
> > > > I've found that setting the account to 'maintenance' mode will
> > > terminate the session *if* the end-user tries to do anything
> while
> > > it's in that state, but it's not enough to just flip the account
> > into
> > > maintenance and back out.
> > > > 
> > > > I'm just wondering if any other sites are dealing with this
> yet,
> > and
> > > if so, if you've figured out a semi-automated way of locking and
> > > unlocking the accounts?
> > > > 
> > > > (btw, we're also looking at Milters to do password detection
> (to
> > > prevent the phished account in the first place) and outbound rate
> > > limiting (to limit the damage the spammer can do), so if any of
> you
> > > are doing/done any work in this area, I'd love to hear about it
> > > too..)
> > > >