This vulnerability is dedicated to my mother, who passed
	away on April 7, 2003. Mom, may God be with you.

	Avaya, a manufacturer of telecommunications products,
	makes a voicemail system called Intuity Audix.  This
	system is based on a Novell licensed version of
	Unixware v2.1.3 by SCO. The one used here comes with
	remote management capabilities over IP.

	This is not truly a 100% remote shell vulnerability,
	due to the fact that the user must either know the "sa"
	user password, or must be able to sniff the network
	that the Intuity Audix machine is on.  This will also
	work with the "vm" user, or any other user who wishes
	to authenticate over the network via telnet.

	Initially, one might scan for open ports, or use an SNMP
	browser, such as that commercially offered by Solarwinds,
	and discover many open ports on the machine. Using SNMP,
	the default community name of "public" is used. The services
	of interest are snmp, http, exec, and telnet.  Since telnet
	is running, and the Avaya ASA GUI-based admin piece uses
	port 23 as a default for the voicemail, we now know that
	authentication is done in the clear.  Using a network
	analyzer that filters text (the one used here was the
	Win32 port of dsniff), and being able to sniff the network
	that the box is on, one would hopefully obtain a username
	and password quickly.

	Now using rexec (for purposes here, since the Win32 port of
	dsniff was used, we will use command line rexec on Windows
	2000 Professional) we type as follows:

	rexec <ip address> -l(username) move /mtce/login/(username)/.profile
	       /mtce/login/(username)/.profile2

	for example:

	rexec 192.168.0.1 -lsa move /mtce/login/sa/.profile 
/mtce/login/sa/.profile2

	This will get us out of the restricted menu when telnetting into the box.

	If the user is root or admin, the game is over. If the user is sa, vm, or
	the ever guarded craft account (which oddly, does not have root 
privileges),
	then a vulnerable build of Apache server is on the machine.  If your 
version
	is patched, or does not appear to be vulnerable, then there are many more
	services running on this machine. root is just an exploit away.

	Fixes:

	Simple.... do not use SNMP v1, block access to SNMP, or just don't use it
	at all. Do not use exec, telnet, or shell.  Have the user authenticate over
	SSH2. Patch the web server portion, even if it's just a DoS to the machine.
	Since this is a proprietary system, Avaya will have to come up with a fix.
                Make sure the shell is restricted, and there is no way to 
exit the menu.

                Greets,

                Cushman

                This is a shortened version of the original posting.  The 
full post can be seen at:

                
http://www.securitynerds.org/html/resources/research/audix.html