OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: QA-List (qa-listCENTRINITY.COM)
Date: Mon Feb 26 2001 - 11:36:51 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Matias,

    Thank you for bringing this matter to our attention. At Centrinity, we take
    pride in the security of our FirstClass software, and therefore take these
    reports very seriously.

    It is important to note that this method could not be used to extract sensitive
    information outside of an FC system because the reply never goes back out to
    the internet. For example, if an internet user uses this method to spoof the
    Administrator and requests a password, the reply would not go back to the
    internet user, it would go to the real Admin (if it goes anywhere at all).

    Nevertheless, this is a serious bug that could be exploited for malicious
    purposes, or at the very least could cause disruption on a FirstClass system.

    We have fixed this in the next release of FirstClass Internet Services.

    __________________

    Jim Gelcer
    Senior QA Analyst, Centrinity Inc.
    905.415.7122 (Unified Communications - Voice/Fax)
    Visit us at www.centrinity.com | jimcentrinity.com

    >The email gateway included in FirstClass 5.50 can be tricked into
    >sending mail appearing to the users of the firstclass system as coming
    >from a local user on the server, including a priviliged user. Doing a
    >manual sending to the stmp-server specifying <username_on_system> as the
    >origin of the email will do but will be caught by the server
    >spamfilters, either discarding them or adding "Spam:" to the topic
    >depending on configuration. The requierment for a default configured
    >server not to view incoming mails as spam seems to be the presence of a
    > in the From: header line. Using a bogus address including an
    >outside of the <> in the From: field and adding the shorthand adress
    >form <>, which is expanded by the server to the adress specified with
    >MAIL FROM: during earlier smtp transaction will be delivered and marked
    >as coming from the specified user. The expanding behaviour is correct
    >iirc, not validating the origin (at all) is the problem.
    >
    >Example:
    >-------------------------------------------------------------
    >220 mail.skynet.foo FirstClass ESMTP Mail Server v5.50 ready
    >MAIL FROM:<Admin>
    >250 Admin... Sender ok
    >RCPT TO:<userskynet.foo>
    >250 userskynet.foo... Recipient ok
    >DATA
    >354 Send your message, end with <CRLF>.<CRLF>
    >To: <userskynet.foo>
    >From: evilsocialengineer <>
    >Subject: Gimme you password
    >
    >Preferably now!
    >.
    >250 F1FEEACC Message accepted, transient identifier was 20
    >-------------------------------------------------------------
    >
    >The above message will appear to user as a message from the local admin.
    >The ways to spot the message is in the firstclass "History" function
    >which specifies the mail as "Created by Admin" and "Routed from" an ip
    >adress, which normally does not exist. It's also spottable when the
    >headers, not shown by default, are viewed and that the info for the
    >Admin user is not opened correctly when accessed from that message.
    >Works on both Windows and MacOS versions of the server.
    > //Mattias From