Breaking

Assesment of Visual Voicemail on iPhones

VVM on iOS 5.0.1

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.

Mailbox with Thunderbird

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

Continue reading
Misc

Short iCloud Follow-Up

After the basic iCloud discussion in this post, I would like to add some more technical information. The following items are just a loose compilation of facts about the mentioned controls which allow the restriction of iCloud usage. The basic iCloud usage, consisting of backup, document sync, and photo stream, can be deactivated using the most recent version of the iPhone Configuration Utility:

Since there are no default settings for these values, it is necessary to include the disabled entries in existing configuration profiles.

Another new functionality which can be deactivated using configuration profiles is Siri. Even though this functionality is not directly related to the iCloud at first glance, it still bears a big threat potential. Looking at the SLAs of the iPhone 4s, the following paragraph gets relevant:
When you use Siri, the things you say will be recorded and sent to Apple to process your requests. Your device will also send Apple other information, such as your first name and nickname; the names, nicknames, and relationship with you (e.g., “my dad”) of your address book contacts; and song names in your collection (collectively, your “User Data”).

So Siri also uses cloud-based services in the background. The following screenshot shows the option to disallow the usage of Siri:

Thinking of this privacy relevant submission of data, another new option of the most recent tool version gets relevant: “Allow diagnostic data to be sent to Apple”. The two checked options in the following screenshots are also new features of the most recent version of the configuration utility:

That’s it for the short configuration option compilation of today, have a great week everybody,

Matthias

Continue reading