Tag: Security

Peer-to-peer communication provides the possibility for easy data transfer between nearby devices, as no network infrastructure is required. Apps with this feature can advertise a service, host or join a session, detect nearby devices, connect to two or more peers and exchange data via Wifi or Bluetooth, which is convenient to develop and use. However, for security relevant information, this communication still has to be protected against sniffing and manipulation.

The iOS MultipeerConnectivity Framework (MPC) supports encryption and authentication for peer-to-peer sessions. Unfortunately, Apple decided to provide an API that allows to use the framework without encryption and authentication, resulting in the same situation as with unprotected HTTP connections: only tests can evaluate if an app exchanges data in a secure way.

Only using encryption together with authentication could prevent active attacks, even if perfect forward secrecy is not granted in any case:

	No Encryption	Encryption Optional	Encryption Required
without Authentication	passive sniffing	active MitM	active MitM
with Authentication	passive sniffing	active MitM (via Downgrade)	no Perfect Forward Secrecy

Missing perfect forward secrecy is a likewise small problem, compared to the current Appicaptor test results, which revealed, that still nearly half of the apps does not even use encryption, leaving the peer-to-peer communication prone even to passive sniffing attacks.

The following decompiled excerpt of a vulnerable app illustrates the critical parameter of the call to initWithPeer:securityIdentity: encryptionPreference:. In this case, the second parameter 0LL indicates, that no securityIdentity is used for authentication. The third parameter 2LL indicates usage of a MCEncryptionPreference with constant MCEncryptionNone

// ObjC Encryption Preferences
typedef NS_ENUM (NSInteger, MCEncryptionPreference) {
    MCEncryptionOptional = 0,                   // Session prefers encryption but will accept unencrypted connections.
    MCEncryptionRequired = 1,                   // Session requires encryption.
    MCEncryptionNone = 2,                       // Session should not be encrypted.
} NS_ENUM_AVAILABLE (10_10, 7_0)

// Swift Encryption Preferences
public enum MCEncryptionPreference : Int {
    case optional // Session prefers encryption but will accept unencrypted connections.
    case required // Session requires encryption.
    case none // Session should not be encrypted.
}

A secure app therefore would implement authentication and encryption by using:

//ObjC
MCSession *session = [[MCSession alloc] initWithPeer:localPeerID
                                securityIdentity:myIdentity
                            encryptionPreference:MCEncryptionRequired];
//Swift
MCSession(peer: self.myPeerId, securityIdentity: self.myIdentity, encryptionPreference: .required)

We created a simple proof-of-concept setup to sniff peer-to-peer communication of vulnerable apps.

In our setup we introduced an active attacker who controls the WiFi access point, thus is enabled to at least read any data transferred between two clients. We could additionally find a target app, as there currently are several apps in the App Store that transfer data via MPC in an unprotected manner, as described earlier.

In order to read the data we rerouted the UDP and TCP-Traffic of the connected apps, extracted and analysed any data sent over the local WiFi access point. With just little knowledge about the semantics of the given app, we could derive the content types of the sent data and therefore intercept and display e.g. text messages or images transferred via the iOS MPC-Framework between two or more devices.

Although the weakness within an insecure implementation of the iOS MPC-Framework Methods was already described in a talk at Black Hat USA 2014, we could still find apps in the App Store today, that were vulnerable and could be attacked with a simple setup via a rogue hot-spot. We could identify that out of the Top 2000 App Store apps that use the MPC-Framework 45% were still completely vulnerable as they neither used encryption nor authentication options.

We’ll show a live demonstration at the upcoming it-sa expo in Nuremberg, Hall 10.0 / 10.0-110