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:

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