When it comes to device security analysis, Austin-Tex.-base security researcher Shawn Merdinger is not a minor voice. Today at the Computer Security Institute's 32nd Annual Conference, this former Research Engineer with Cisco Systems' Security Technologies Assessment Team (STAT) and Security Evaluation Office made a presentation in which he ran down a list of reported VoIP handset security vulnerabilities, and the current state of fixed and patches (not good).
Merdinger has just emailed me the highlights of his hour-long presentation. Much was drawn from postings made over the last couple of days on the Full Disclosure mailing list maintained and distributed at SecLists.org.
The Cisco 7920 Wireless IP Phone contains two vulnerabilities. The first vulnerability is an SNMP service with fixed community strings that allow remote users to read, write, and erase the configuration of an affected device.
The second vulnerability is an open VxWorks Remote Debugger on UDP port 17185 that may allow an unauthenticated remote user to access debugging information or cause a denial of service.
Cisco has made free software available to address these vulnerabilities for affected customers. There are workarounds available to mitigate the effects of the vulnerability.
This advisory is posted at
Next, we have the Senao SI-680H VOIP WIFI Phone. This phone has a vulnerability with no fix.
According to the alert, "An undocumented open port, UDP/17185, VxWorks WDB remote debugging (wdbrpc) is left in from development. This open port may allow an attacker unauthenticated access to the phone's OS, perhaps yielding sensitive information, creating opportunities for DoS, etc. There appears to be no workaround to disabling this open port."
Two down, three to go. Next up: the Zyxel P2000W (Version1) VoIP Wi-Fi phone.
According to the alert, which was first reported to the vendor on June 28 but has drawn no response so far, the security risk is with undocumented port UDP/9090.
The alert states:
The Zyxel P2000W v.1 VOIP WIFI phone has an undocumented port, UDP/9090, that provides an unauthenticated attacker information about the phone, specifically the phone's MAC address and software version is returned upon connection. An attacker can use this vulnerability to easily identify the phone and software version. Also, the undocumented open port may provide an avenue for DoS. There appears to be no workaround for this issue.
The Zyxel P2000W v.1 VOIP WIFI phone uses hardcoded DNS servers located in Taiwan for the phone's DNS configuration. Primary DNS IP is 22.214.171.124 resolving to dns.hinet.net. Secondary DNS IP is 126.96.36.199 resolving to dns.seed.net.tw
This configuration places every ZyXel phone using this software at risk of unintentional DoS if the DNS servers in Taiwan become unavailable. If the DNS servers are compromised, all Zyxel phone users worldwide are vulnerable to being redirected to malicious SIP servers, etc. For a temporary workaround users can manually input the IP address of a known, trusted DNS server via the keyboard at each phone start when configured for DHCP or PPOE, however, this will not persist once the phone is restarted.
Two more. Next, we need to look at the security assessment of the UTstarcom F1000 VoIP Wifi phone.
The alert cites three vulnerabilities, both of which were reported to the vendor in late June and to which the Full Disclosure list has not yet received a response.
The first vulnerabiity states that "UTStarcom F1000 VoIP Wifi phone SNMP daemon has default public read credentials and the daemon cannot be disabled."
Here are the details:
UTstarcom F1000 SNMP daemon default public credentials allows an attacker with access to the phone's SNMP daemon to read the phone's SNMP configuration. This can lead to sensitive information disclosure. In addition, the daemon's read/write credentials cannot be changed, nor can the daemon be disabled via the phone's physical interface (i.e. via keypad input). During testing, the SNMP daemon appeared consistently die when connecting via Snmpwalk, requiring rebooting the phone in order to restore SNMP service.
The second vulnerability assesses that the "UTstarcom F1000 VoIP Wifi Phone telnet server has known default user/password credentials."
The phone's operating system is Wind River's Vxworks. Default credentials for this OS are publicly known to be target/password. By default, the telnet daemon is listening on the phone (TCP port 23) providing WIFI network access to the phone's OS. Attackers can telnet to the phone and gain access to the phone's Vxworks OS using the known default credentials. Impact is full access to the Vxworks OS, including debugging, direct memory dumping/injection, read/write device, user and network configuration files, enable/disable/restart services, remote reboot.
For a workaround, the default lo-gin/password can be changed.
The third UTstarcom vulnerability is referred to as "UTstarcom F1000 VoIP Wifi Phone rlogin (TCP/513) unauthenticated access."
Again, the deets:
The phone's rlogin port TCP/513 is listening by default and requires no authentication. An attacker connecting to the phone via telnet/netcat is dropped into a shell without any log-in. The shell provides an attacker full access to the Vxworks OS, including debugging, direct memory dumping/injection, read/write device, user and network configuration files, enable/disable/restart services, remote reboot.
There appears to be no workaround as neither the service can be disabled, nor can authentication to rlogin be enabled.
OK, here's the last VoIP phone security alert. This one is for the Hitachi IP5000 VoIP Wifi phone.
The alert reports four security vulnerabilities, most of which have been partially but not fully addressed.
The first vulnerability is entitled "Hitachi IP5000 VOIP WIFI Phone handset hardcoded administrator password."
The Hitachi VOIP WIFI phone handset has a default administrator password of "0000" that the user enters in order to access administrator functions when programming the handset via the physical keys. This password appears to be hardcoded and presents a physical vulnerability. If an attacker can physically access the phone (borrow, phone rental scenario, theft, etc.) the attacker can derive sensitive information and modify the phone's configuration.
There appears to be no workaround for this vulnerability.
Next, we have a reported vulnerability entitled "Hitachi IP5000 VOIP WIFI phone HTTP server vulnerabilities."
The particulars are two-fold, in that:
1. Improper information disclosure: The HTTP daemon default index page discloses what the device is (Hitachi IP5000 phone), the phone software versions, phone MAC address, IP address and routing information. An attacker can use this to discover quickly what the device is and see if there are any associated vulnerabilities. Also, the disclosure of the phone's routing/gateway information can provide an attacker with information for a DoS attack. An attacker does not need to authenticate to the phone to obtain this information from the index page.
Workaround is to disable the HTTP server via the phone's physical interface or via the HTTP interface.
2. Web server default configuration does not require credentials to authenticate. This allows an attacker to access any of the various configuration pages of the phone, changing the phone configuration, etc. Workaround is to disable the HTTP server via the phone's physical interface or via the HTTP interface. The phone user may also set a password via the HTTP interface. Note that the password set page does not require the previous password (an attacker could lock out a user if the initial password is not set), nor does it require the new password to be entered twice (to avoid fat-fingering).
The third of four vulnerabilities on this device is entitled "Hitachi IP5000 VOIP WIFI Phone SNMP daemon vulnerabilities."
The Hitachi IP5000 VOIP WIFI phone SNMP v1/v2c daemon allows read/write access to the phone's SNMP configuration using any credentials. An attacker can use this vulnerability to access the phone's SNMP configuration, potentially reading/writing/erasing sensitive information.
There seems to be no workaround as it appears that the SNMP daemon can neither be disabled, nor can the SNMP daemon read/write strings be modified by the phone user.
The last of four security bugs reported in the Hitachi IP500- VoIP WIFI phone refers to an "undocumented port TCP/3390 Unidata Shell."
In this case, the devil really is in the details, namely that:
The Hitachi IP5000 phone has a undocumented open port, TCP/3390, that provides an unauthenticated attacker access to the Unidata Shell created upon connection. This may allow an attacker to access sensitive information and potentially impact the phone's operations in a DoS.
As a workaround, there appears to be no means to disable this port and service, so no workaround appears possible.
So what do you think, readers? Does any of this info discourage you from buying a VoIP WiFi handset? TalkBack to me.