Visual Voicemail (VVM) is a common feature of phone providers which allows accessing the good old voice-mailbox through the phone’s visual interface. In contrast to the classical voicemail approach, VVM allows intuitive navigation through voice-messages without dealing with an automated voice which tells you about message count and possible options. However, this implies the need of actually loading the messages of missed calls on the phone. The VVM-app displays missed calls and downloads corresponding messages which have been left by the initial caller. The software comes with your iPhone and is not intended for uninstallation. However, providers have to support it and will have to activate it for supporting clients. This feature is available on iPhones since August 2009 and became available on BlackBerrys and few Nokia phones later. Android doesn’t implement VVM in general. However some telecommunication providers offer their own apps to add this feature. Since version 4.0, Android offers an official Voicemail Provider API enabling better integration for the mobile OS.
Lately we had a deeper look at a VVM client. The client is integrated (on iPhones) into the phone app but has to be activated by the provider (and a special backend is needed). We assume it’s handled through a stealth SMS or alike, since related network traffic is not visible. Also most providers charge you for this feature. Some contracts include VVM, but typically it has to be activated initially. Even if connection to a wireless LAN exists, the traffic between phone and the VVM backend is routed through the 3G interface and doesn’t pass the Wi-Fi connection. This is interesting, since actually the Wi-Fi connection is typically preferred. This allows the providers to limit the backend access to their own „IPs used on the 3G networks“, meaning only customers with a SIM card from the corresponding provider can access the mailbox system. From a corporate point of view this also means, that a phone connected to a wireless LAN with an active VPN connection would certainly bypass its „default way to the Internet“ and consequently also bypass potentially present security controls like proxy servers.
After actual VVM usage, we jailbroke the phone and installed assessment tools. In addition we installed Cydia (third party app store), an SSH daemon (to connect remotely) and tcpdump (to sniff network traffic). Cydia makes use of the packet management as known from “Debian GNU/Linux”. So we used “dpkg -i” to install the local packet (.deb) of KeychainViewer, which was not available through the repository.
By sniffing the network traffic it was possible to examine the IMAP protocol revealing username and the corresponding hashed password (which allows to repeat a successful login) and of course all voicemail files. We want to highlight, that all the voicemail files have been transferred unencrypted. In addition we had a look at the keychain entries of the app. This revealed information (used protocol, port and server IP) already known from sniffing the network traffic and some new details. The first thing we recognized was the format of the account name (as already seen in network traffic) as well as the password, which is stored in cleartext. Knowing the server IP address, we already reach the critical amount of sensitive information becoming available through sniffing the network traffic. As the IMAP protocol on port 143 is used for communication, we were able to test the retrieved connection data and credentials by using a standard email client. Unsurprisingly it worked out well. The screenshots show how we used thunderbird to read the folder structure of the mailbox itself. Voice calls are basically implemented as emails with an .amr audio file attached.
In addition we found, that after activation of the VVM feature, the configuration (.plist) file is stored at /var/mobile/Library/Voicemail/com.apple.voicemail.imap.parameters.plist
containing the username, protocol information, the state of the voicemail account and the server IP. Having the username and server IP, which depends on the provider but can typically be figured out very easily, an attacker can run brute force attacks against the email server which is exposed to the Internet.
Furthermore the whole data transfer turned out to be unencrypted. One could argue that sniffing 2G/3G isn’t that easy when compared with sniffing Wi-Fi traffic. But even though eavesdropping or MITM attacks are not as likely as on Wi-Fi networks, they shouldn’t be completely ignored. Unfortunately login credentials tend to be long-living data. Once intercepted, these data will give an attacker the opportunity to access mailboxes and corresponding applications for a long time.
Providers still seem to rely on the non-interceptable properties of their networks. Even though intercepting isn’t easy, several publications have proofed them wrong in the last years. Thus this thread model is at least questionable.In addition scenarios exist, in which traffic is routed through untrusted areas e.g. in case of roaming. Considering the increasing importance of TCP/IP, traffic will more and more pass untrusted areas. In addition the trust model seems not to imply the actual user as a threat against sensitive data stored on the device (such as credentials for the VVM server). Last but not least, finding sensitive information such as login credentials unencrypted/unhashed still comes with a sobering taste.
All this has to be kept in mind, when using such technologies and may lead to the question, if the providers trust/thread model matches your own or those of your environment/company.
Have a nice day,
Sergej
About two months ago the Bluetooth SIG 
