AudixShell.txt

`  
  
  
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  
  
`