[Full-Disclosure] 3com NBX IP Phone Call manager Denial of Service - Update

From: Michael Scheidell (scheidell_at_secnap.net)
Date: 04/27/03

  • Next message: Michael Scheidell: "[Full-Disclosure] Anyone have the SECURITY admin email for Frontrange/Goldmine?"
    To: bugtraq@securityfocus.com
    Date: Sat, 26 Apr 2003 21:37:43 -0400 (EDT)
    

    Revision Date: April 25, 2003
    Reason for Revision: 3com updated nbx firmware to 4_1_21, Add bugtraq-id

    Systems: 3com NBX IP Phone Call manager, FW Versions through 4_1_21
    Severity: Critical
    Category: Denial of Service
    Classification: Boundary Condition Error
    BugTraq-ID: 6297
    CERT VU#:[VU#317417]
    Vendor URL: www.3com.com, www.windriver.com
    Author: Michael S. Scheidell, SECNAP Network Security
    Original Release date: December 2nd, 2002
    Notifications: (3com, WindRiver and CERT) Notified October 31st, 2002
    Last contact with 3com: November 22nd, 2002
    Attempted contact with 3com: April 15th, 2003
    Last contact with WindRiver: December 6rd, 2002

    Discussion: (From 3com's and WindRiver's web site)

    3Com® SuperStack® 3 NBX® and 3Com NBX 100 networked telephony solutions
    offer wide-ranging price/performance alternatives to fit your business
    needs today and tomorrow. 3Com® SuperStack® 3 NBX® Networked Telephony
    Solution Delivers robust, full-featured business communications for up to
    1500 devices (lines/stations) Ensures high system availability with the
    Wind River VxWorks real-time operating system (also used in pacemakers and
    artificial hearts), so server and PC downtime does not impact your
    telephone service.

    VxWorks and pSOSystem are the most widely adopted real-time operating
    systems (RTOSs) in the embedded industry -- for good reason. They are
    flexible, scalable, reliable, and available on all popular CPU platforms.
    They are also, by most measures, the fastest RTOSs available today.

    Exploit: It was possible to make the remote FTP server crash by issuing
    this command :

    CEL aaaa[...]aaaa where string is 2048 bytes long. This can be done with
    netcat, a windows client by telnetting to the nbx server on port 21 or by
    running the vxworks_ftpd.nasl test in nessus (www.nessus.org)

    The 3com NBX uses VXWORKS Embedded Real time Operating system and what
    appears to be their own internal ftp server. This buffer overflow problem
    seems to be one similar to the AIX ftpd reported in CVE 1999-0789 and has
    been assigned bugtraq id 6297

    By sending a specific string of data to the ftp server, an attacker can
    not only disable the ftp server, but the integrated web based
    administrative console and the call manager preventing diagnostics,
    control and all incoming, outgoing or internal calls. Any calls in
    progress cannot be disconnected, and in the case of long distance calls,
    could result in excessive long distance bills and extended loss of use of
    the phone system.

    This condition is not recovered without a Hard reboot (power off/on).
    Since the 3com nbx is based on an embedded Unix operating system
    (vxworks), an abrupt power off could cause loss of data, including
    corruption of voice mails in progress or logs.

    A company who uses the VoIP features for remote locations, and who has the
    call manager located on the outside of their firewall, or has no firewall
    can have their voice communications disrupted easily. Even if the company
    has call manager located on internal network, people with internal network
    access can also disrupt communications. We have tested 3com nbx firmware
    version 4_0_17 (with ftpd version 5.4) and nbx firmware version 4_1_4 and
    4_1_21 (ftpd version 5.4.2) and this bug seems to be present in all three
    systems.

    3com Response:
    3com confirmed problem and received a field patch, TSR(296292) from
    WindRiver to address the problem. Neither WindRiver nor 3com has provided
    a test bed or access to a fixed system for us verify fix. 3com will be
    working to integrate this TSR into a future release of the nbx build but
    has no date yet for release. Also, since ftpd is only used for debugging
    and diagnostics, a future firmware will allow the administrator the
    ability to turn off ftpd if not used.
    We contacted 3com on Febuary 28th and March 14th to obtain above firmware
    and then again on April 15th to report that Firmware 4_1_21 did not yet
    fix the problem.
    No response from 3com yet.

    VxWorks Response:
    The defect has been corrected. A solution has been provided to and is
    being used by 3COM. We will be providing an update to CERT. We also plan
    to issue patches to our population of customers for Tornado 2.0.2 /
    VxWorks 5.4 and Tornado 2.2 / VxWorks 5.5. Testing on all CPU architecture
    platforms for T2.0.2 and T2.2 is started now and we anticipate the patch
    for T2.0.2 to be completed before Christmas and T2.2 by mid-Jan, 2003

    CERT Response:
    Cert has assigned VU #317417 and stated that as soon as they get vendor
    confirmation they will publish report.

    Solution:
    Please contact vendor once new software is released

    Workaround:
    There appears to be on way to turn off the built in ftp server in this
    version of the software, nor anyway to do ip address limits via tcp
    wrapper or acls. The only way we know of to prevent a denial of service
    attack on the 3com nbx is to place it behind its own firewall. If call
    manager is placed on the Internet side of the firewall or in the DMZ, care
    should be taken to prohibit any access to ftp port (tcp port 21) This may
    be impossible on an internal network unless 3com nbx is itself placed
    behind a firewall, or on a separate VLAN or network segment. Care should
    be taken in this approach, since some firewalls may interfere with the
    VoIP operations.

    see "Firewall limits vex VoIP users" at Nwfusion
    http://www.nwfusion.com/news/2002/0625bleeding.html

    Credit:
    This problem was originally found during a routine security audit by
    Michael Scheidell, SECNAP Network Security, www.secnap.net using the
    Nessus vulnerabilities scanner, www.nessus.org.,
    Additional assistance by Leonid Rosenboim [lr24@actcom.co.il] in verifying
    that this may be an old bug, already fixed in current vxworks sources but
    might not have been tested by 3com yet.

    Additional Information:
    A tcpdump/pcap packet of the exploit and ftpd/nbx response can be found at
    http://www.secnap.net/private/nbx.pcap
    If you have snort or ISS's trons IDS, a signature to detect this attack
    can be found at on www.snort.org

    To test your systems for this vulnerability, you can use Nessus at
    www.nessus.org. Either update your signatures, or download this nessus
    signature: vxworks_ftpd.nasl at
    http://cgi.nessus.org/plugins/dump.php?id=11185

    For a report on Security Risk Factors with IP Telephony based Networks
    see:
    Security_Risk_Factors_with_IP_Telephony_based_Networks
    Also reference article "is VoIP vulnerable ?"on NWfusion.com
    http://www.nwfusion.com/news/2002/0624voip.html

    Original copy of this report can be found here
    <http://www.secnap.net/security/nbx001.html>

    Copyright:
    Above Copyright(c) 2002, 2003, SECNAP Network Security, LLC. World rights
    reserved.

    This security report can be copied and redistributed electronically
    provided it is not edited and is quoted in its entirety without written
    consent of SECNAP Network Security, LLC. Additional information or
    permission may be obtained by contacting SECNAP Network Security at
    561-368-9561

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: Michael Scheidell: "[Full-Disclosure] Anyone have the SECURITY admin email for Frontrange/Goldmine?"