Symantec Enterprise Firewall (SEF) SMTP proxy inconsistencies

From: Martin O'Neal (BugTraqat_private)
Date: Wed Feb 20 2002 - 13:04:28 PST

  • Next message: Russell Fulton: "Re: Cert Advisory 2002-03 and HP JetDirect"

    -- Corsaire Limited Security Advisory --
    
    Title: Symantec Enterprise Firewall (SEF) SMTP proxy inconsistencies
    Date: 18.01.02
    Application: Symantec Enterprise Firewall (SEF) 6.5.x 
    Environment: WinNT, Win2000
    Author: Martin O'Neal [martin.onealat_private]
    Audience: General distribution
    
    
    -- Scope --
    
    The aim of this document is to clearly define some issues related to 
    a some SMTP proxy inconsistencies within the Symantec Enterprise 
    Firewall (SEF) environment as provided by Symantec [1]. 
    
    
    -- History --
    
    Vendor notified: 18.01.02 
    Document released: 21.02.02
    
    
    -- Overview --
    
    The SEF firewall product uses an application proxy strategy to provide
    enhanced security features for a variety of common protocols. For the
    SMTP proxy, part of this additional functionality allows the firewall 
    to restrict the sender / recipient domains and to hide internal 
    infrastructure information from external recipients.
    
    However, when the firewall is configured to provide network address 
    translation (NAT) to an SMTP connection (effectively hiding the internal 
    server behind a publicly routable address), this might not always be 
    conducted as desired.
    
    
    -- Analysis --
    
    The SMTP proxy works by analysing the SMTP format and optionally rewriting 
    some of the headers to achieve the desired aim.
    
    When an inbound or outbound SMTP connection is NATed to an address other 
    than the one assigned to the physical firewall interface, then the SMTP 
    proxy still uses the physical interface name and address within the SMTP 
    protocol exchange.
    
    This has two potential issues:
    
    The first issue is that there is now a potential information leak; 
    additional information is contained within the SMTP protocol exchange that
    could aid an attacker in analysing the firewall configuration.
    
    The second issue is that any receiving / sending host that is configured 
    to enforce strict checks on the SMTP protocol exchange, might not accept 
    the connection due to the inconsistencies in the fields.
    
    
    -- Proof of concept --
    
    To reproduce this issue, place an SMTP host on an internal interface of the 
    SEF firewall. Create a rule that allows inbound and outbound traffic to this
    
    host, then create an address translation and redirection entry that maps 
    SMTP connections to and from an external address other than the physical 
    interface address.
    
    smtp address (internal)                1.1.1.1 (twist.dance.org)
    firewall address (external physical)   2.2.2.2 (waltz.dance.org)
    firewall address (external SMTP NAT)   2.2.2.254 (foxtrot.dance.org)
    firewall name                          tango
    firewall domain                        dance.org
    
    redirect                               2.2.2.254 -> 1.1.1.1 (for SMTP only)
    NAT                                    1.1.1.1 -> any (use 2.2.2.254)
    NAT                                    any -> 1.1.1.1 (use client address)
    rule                                   1.1.1.1 -> any (for SMTP only)
    rule                                   any -> 1.1.1.1 (for SMTP only)
    
    For inbound connections to 2.2.2.254:
    -> 220 tango.dance.org Generic SMTP handler
    
    For outbound connections from 2.2.2.254:
    <- 220 ...
    -> HELO waltz.dance.org
    <- 250 ... talking to foxtrot.dance.org ([2.2.2.254])
    
    
    -- Recommendations --
    
    The SMTP proxy behaviour should be revised to resolve the information 
    within the protocol exchange to the correct host / address combination.
    
    
    -- References --
    
    [1] http://enterprisesecurity.symantec.com/products/products.cfm?ProductID
        =47&PID=9674250&EID=0
    
    
    -- Revision --
    
    a. Initial release.
    
    
    Copyright 2002 Corsaire Limited. All rights reserved. 
    
    
    
    -----------------------------------------------------------------------------------------------------------------------
    CONFIDENTIALITY:  This e-mail and any files transmitted with it are
    confidential and intended solely for the use of the recipient(s) only.
    Any review, retransmission, dissemination or other use of, or taking
    any action in reliance upon this information by persons or entities
    other than the intended recipient(s) is prohibited.  If you have
    received this e-mail in error please notify the sender immediately
    and destroy the material whether stored on a computer or otherwise.
    -----------------------------------------------------------------------------------------------------------------------
    DISCLAIMER:  Any views or opinions presented within this e-mail are
    solely those of the author and do not necessarily represent those
    of Corsaire Limited, unless otherwise specifically stated.
    -----------------------------------------------------------------------------------------------------------------------
    
    Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF
    Telephone: +44(0)1483-226000  Email:infoat_private
    
    This footnote confirms that this e-mail message has been swept by
    MIMEsweeper for the presence of computer viruses.
    



    This archive was generated by hypermail 2b30 : Wed Feb 20 2002 - 16:17:42 PST