From: Scheidell at secnap.com (Michael S. Scheidell)
Subject: [VU#317417] Denial of Service condition in vxworks ftpd/3com nbx

Information:
Name:  3com NBX IP phone system Denial of Service Attack
Systems: 3com NBX IP Phone Call manager, FW Versions  through 4_1_4
Severity:  Critical
Category: Denial of Service
Classification: Boundary Condition Error
Vendor URL:   http://www.3com.com
Author:   Michael S. Scheidell (scheidell@...nap.net)
Date:   December 2nd, 2002
Notifications: (3com, WindRiver and CERT) Notified October 31st, 2002
Contact with 3com October 31st, November 1st, 5th, 6th, 15th and November 22nd
Contact with WindRiver: October 31st, November  6th, 22nd, and 24th. No response from WindRiver.

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 aix_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 bugtraq id 679.

By sending a specific string of data to the ftp server, an attacker can disable not only 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 *nix operating system, and 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 (ftpd version 5.4.2) and this bug seems to be present in both systems.

Vendor Response:
3com confirmed problem and received a field patch, TSR(296292) from vxworks 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.

Please contact 3com for further information.

Solution:
There is no known fix.  If you have information about a fix, please contact security@...nap.net

There appears to be on way to turn off the build in ftp server in this version of the software, no way to do ip address limits via tcp wrapper or acls, and if there is a build in firewall, there is no documented way to access it.  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 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 Information:
A tcpdump/pcap packet of the sploit and ftpd/nbx response can be found at
http://www.secnap.net/private/nbx.pcap

A copy of this report can be found at http://www.secnap.net/security/nbx001.html
and at http://www.kb.cert.org/vuls/id/317417
If you have snort or ISS's trons IDS, a signature to detect this attack can be found at
http://www.snort.org/snort-db/sid.html?sid=337

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 http://cgi.nessus.org/plugins/dump.php?id=11185

For a report on Security Risk Factors with IP Telephony based Networks see:
'http://www.sys-security.com/archive/papers/Security_Risk_Factors_with_IP_Telephony_based_Networks.pdf'

Also reference article "is VoIP vulnerable"? http://www.nwfusion.com/news/2002/0624voip.html 

Copyright:
Above Copyright(c) 2002, 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 or at www.secnap.com

-- 
Michael  S. Scheidell
SECNAP Network Security www.secnap.com
scheidell@...nap.net  / 1+561.368.9561, 1131

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6013 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20021202/a7ff4dcf/attachment.bin

Powered by blists - more mailing lists