[VOIPSEC] Security Vulnerability in the Grandstream HandyTone devices.

[Anon Anon]

The HandyTone ATA (Analogue Terminal Adapter) is a very common 
device among its type. Its often sold or lent to users from their 
VoIP providers. The device is easy to use partially because of its 
auto-configuration feature. Once the user receives the device it 
can be directly plugged into a broadband modem or into the DMZ of a 
router (NAT), at which point the device goes out and fetches the 
configuration data. This system is convenient not just for the user 
but also for the VoIP providers as they do not have to deal with as 
many user configuration problems. However, this system is not 
secure and leaves a lot of potential for abuse.

The device can be configured in different ways this discussion will 
focus on how its generally used in large scale deployments. When 
the HandyTone is turned on, it sends an HTTP (or HTTPS) request to 
the manufacturers configuration server asking for a configuration 
file (cfg000B82XXXXXX) based on the MAC address. This configuration 
file changes the default configuration server from that of the 
manufacturer (fm.grandstream.com/gs) to that of the provider. Once 
again, the HandyTone requests a config file, but this time from the 
provider. The VoIP configuration file, among other things, contains 
the SIP account credentials. The only information provided to both 
of the configuration servers is the MAC address of the device.

Grandstream provides a small java application which can be used to 
generate configuration files. It takes a input config file, strips 
out the comments, and converts the ASCII text into ISO-8859-1. The 
application then enciphers the data with AES-128-CBC with an 
auto-generated key. The key itself is generated from several pieces 
of information: the length of the encrypted data, the MAC address 
of the device, a random 2-byte number, and finally a checksum of 
the data. For the device, deciphering the data without this 
information would be impossible. So, all of this information (minus 
the MAC address) is prepended as a 16 byte header to the encrypted 
configuration file! Obviously, the MAC address does not have to be 
transmitted to the device as it already knows it, (non-the less, 
the name of the configuration file usually contains the MAC 
address.) So, by using the header of the configuration file one can 
easily generate the key that was used to encipher the data. And 
since a sy
mmetric encryption algorithm is used it can also be used to decrypt the data.

The configuration files, or more accurately the SIP credentials 
within can be obtained by preforming a man-in-the-middle attack on 
a device. That is, an attacker can monitor the communication 
channel of the device as it requests the configuration file 
(assuming HTTP and not HTTPS is used). This attack is not very 
interesting because intercepting traffic on a large scale is not 
feasible. The more interesting approach is for the attacker to 
pretend to be the device and do request the configuration file 
directly from the server (via HTTP or HTTPS). All the information 
one needs to preform this attack is the MAC address of the device, 
which can be obtained from network broadcasts or by simply guessing 
MAC addresses. If the MAC addresses are assigned in a linear 
fashion by Grandstream, then it makes this attack very easy to 
preform. If not, there are only ~17 million possible Grandstream 
MAC addresses. An exhaustive search for MAC addresses would not be 
infeasible. Although Grands
tream and VoIP providers could implement some code to prevent 
exhaustive searches on their database it would not be very 
effective, since an attacker could simply use a botnet or even TOR.

In a few words, the consequences of this blatantly insecure 
authentication system allows anyone with little ambition to extract 
thousands of SIP credentials. Affected users are those who 
subscribe to VoIP providers which make use of this 
auto-configuration system, and there are plenty of providers out 
there, some of which have a very large subscriber base.

The quick fix to this problem is to shut down the 
auto-configuration servers both those of the providers and those of 
Grandstream. Unfortunately as a result of this, the users will have 
to configure the devices manually. A better fix would be to use 
asymmetric cryptography scheme, pre-load a unique private key onto 
the device and make a database of the public ones. The problem is 
that the key would have to be stored permanently on the device 
which, depending on the hardware, might not be feasible.

Attached is a utility for decrypting the encrypted config files.

PS.
I have contacted grandstream about this issue, unfortunately they 
did not appear to be overly concerned.

--YAE


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com