Results 1 to 5 of 5

Thread: Mitigate against user enumeration vulnerability

  1. #1
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default Mitigate against user enumeration vulnerability

    Hi folks,

    as some of you might already know, ZCS 7 is vulnerable against user enumeration attacks:

    In short terms:

    It's possible - without any prior authentication - to probe whether certain user exists via soap calls.
    ZCS will tell you whether that user exists, and for an existing one it also tells you the internal UID,
    which is also used for auth token generation. (so the cleartext of the hmac-encrypted auth-tokens
    are easily predictable).

    In general, all requests should be denied for unauthenticated users (except the login, of course ;-)).

    Needless to mention that this is a serious security problem, but Zimbra upstream has scheduled
    this bug for Zimbra 9 (probably released in several years), so we need at least some migitation
    against that.

    Does anyone have an idea how to solve this problem ?


    One option would be forking the source and fixing it there on our own, dropping NE completely,
    but I'd like to explore other options first, before we're going that step.

  2. #2
    Join Date
    Aug 2012
    Posts
    2
    Rep Power
    3

    Default

    In reality how serious are enumeration attacks though?


    It's possible - without any prior authentication - to probe whether certain user exists via soap calls.
    ZCS will tell you whether that user exists, and for an existing one it also tells you the internal UID,
    which is also used for auth token generation. Especially with online shop using any ecommerce website builder (so the cleartext of the hmac-encrypted auth-tokens
    are easily predictable).
    Last edited by david24uk; 02-12-2013 at 08:10 AM.

  3. #3
    Join Date
    Apr 2012
    Posts
    101
    Rep Power
    3

    Default

    Quote Originally Posted by david24uk View Post
    In reality how serious are enumeration attacks though?
    Once you have verified the correct login for a user, it's trivial then to start the dictionary attacks.

    It's a hole worthy of some attention now rather than later.

    Until its fixed I suppose I have to force all my clients to connect to the zimbra server over their vpn and block off the world facing port 443. <sigh>

  4. #4
    Join Date
    Oct 2009
    Location
    Dublin, IRELAND
    Posts
    712
    Rep Power
    7

    Default

    What is the bugzilla number ? More votes would likely get the issue promoted to an earlier fix target.

  5. #5
    Join Date
    Jan 2009
    Posts
    66
    Rep Power
    6

    Default

    Quote Originally Posted by Brad_C View Post
    Once you have verified the correct login for a user, it's trivial then to start the dictionary attacks.

    It's a hole worthy of some attention now rather than later.

    Until its fixed I suppose I have to force all my clients to connect to the zimbra server over their vpn and block off the world facing port 443. <sigh>
    Wouldn't the lockout policy, if enabled, mitigate this? e.g. more than 10 failed logins in an hour would move the account's status to lockout.
    Release 7.2.0_GA_2669.UBUNTU10_64 UBUNTU10_64 FOSS edition

Similar Threads

  1. Trying to mitigate problems with OS X Server
    By jbuell in forum Installation
    Replies: 6
    Last Post: 01-14-2011, 02:14 PM
  2. Vulnerability check for zcs 6.0.6.1
    By chandu in forum Administrators
    Replies: 1
    Last Post: 06-11-2010, 04:57 AM
  3. Spamassassin vulnerability
    By iway in forum Administrators
    Replies: 1
    Last Post: 03-17-2010, 05:55 PM
  4. vulnerability issue
    By chandu in forum Administrators
    Replies: 9
    Last Post: 02-23-2009, 05:04 AM
  5. -=ClamAV Vulnerability=-
    By SpEnTBoY in forum Administrators
    Replies: 0
    Last Post: 06-04-2007, 09:07 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •