Recently, a client asked me to take a look at the cause of multiple TFTP (Trivial File Transfer Protocol) requests coming from unknown computers directed at their datacommunication switch gear. Not knowing if this was traffic initiated by a virus, they needed an in depth look. Their switch equipment manufacturer notified them, during a tech support call, that the TFTP requests could cause the switches OS to halt if the requests continued.
Identifying the problem
After connecting the analyzer onto the appropriate place on their network, I was able to locate the source/destination path for the TFTP traffic. It was identified that the TFTP traffic was coming from a group of approximately twelve workstations within a specific department. It was also identified that the TFTP data requests were not destined solely for the datacomm switches, but to all stations within the subnet. The workstations were sending TFTP requests to a broadcast MAC address, and requesting a specific file from any/all stations on their local network. Not good.
Further investigation found that these workstations were in a call center, and used an application specific for the phone systems call recording. Also, I looked at the specific TFTP request and found that it had a unique string. In researching this TFTP string, it was traced to the recently installed Avaya™ phone system.
Looking further at the packet decodes for this TFTP issue resulted in several additional findings of potential security issues within the various software modules supported on the Avaya™ system. Based upon this research, several trouble tickets were started with Avaya’s™ tech support department.
Problem resolved
Unfortunately, many times when small, medium, or large software and hardware manufacturers are alerted to deficiencies in their code (software or firmware), these companies take a hands off attitude for making corrections. In this case, Avaya™ stated that the TFTP’s broadcasts were essential to software modules the client was running, and this code could not be changed. Avaya™ communicated the TFTP broadcasts were used to activate the voicemail light on the phones at the customer site. This came as a surprise, since the phones at this organization were not connected to the data communications network (they were on a dedicated cable plant) and have no mechanism to ‘see’ these broadcasted TFTP packets. Instead of placing a checkbox within the Avaya™ software to turn this feature off, and stop the broadcasts (since the phones were not even connected to the same network), they decided it was ‘an integral function of the software’ and could not be changed. Too bad for Avaya™ customers.
In this case, since we were dealing with a non-responsive vendor, we had to take matters into our own hands and resolve the problem in a different manner. One of the least costly ways to correct this issue was to install personal firewall software on each of the one dozen workstations. The firewall on each workstation needed to be configured to disallow TFTP to a broadcast address. TFTP packets were allowed to be directed at specific systems (using unicast packets) since this transmission was required for their call recording and hunt group lists. With the firewall configured in this manner the phone system will continue to operate properly, and the data communication switches no longer are subjected to this barrage of TFTP file requests.
Post mortem
Based upon the analysis conducted on the Avaya™ phone system, I would highly recommend that organizations using this system (specifically the IP Office system) be aware of several known (and potentially unknown) security threats to this system. As of this writing, much of the communication between workstations and servers using the IP Office system uses TFTP for transferring data to/from the server. This communication is a base function of the system architecture, and can be seen each minute of the day (in the organization I looked at anyway). The majority of these connections DO NOT USE credentials to obtain this information. I could easily obtain phone system information connecting to the server and issuing ‘get’ commands. You can obtain various system information like hunt groups, user lists, system users, etc. and you can get this without using an analyzer or having a password.
Additionally, there are known problems with password hashing, where the hash of the password can be used, among other things, to reboot the IP Office server, when using specific commands like –
“tftp -i <Address of IP Office Server> get “/nasystem/reboot/<insert captured password hash>”
There are other security issues with the Avaya™ system related to local passwords being saved in clear text on the computer (find this using regedit), and snmp credentialing accepting any string that has the same number of characters as the proper credentials.
Some of these issues are being corrected by Avaya™, some are not, so make sure you have the latest IP Office software.
In summary, educate yourself to the specific vulnerabilities of your phone system.
