New Appicaptor Release

We have released a new version of Appicaptor that we were working on over the last months. Based on our research it comes with multiple improvements, such as a new analysis engine for Android apps as well as many iOS and Android test case refinements and extensions.
For example:

  • Processing of privacy policies (GDPR) extended (iOS and Android)
  • Search for insecure SSL/TLS usage improved (Android)
  • Analysis depth increased for Objective-C binary code (iOS)
  • Analysis of static constants for cryptographic functions extended (Android)
  • Detection of privacy relevant resource accesses reworked (iOS and Android)
  • Library detection enhanced: tracking-, advertisement- and development libraries (Android)
  • Detection of privacy critical tacking services extended by more than 100 additional providers (iOS and Android)
  • Web front-end usability improved for simple result access (iOS and Android)

Appicaptor will utilize its new analysis engine from now. Detailed internal tests showed that the new engine is reliable and provides dependable test results.

Appicaptor Security Index 2018

The use of apps in enterprises requires a critical consideration of the risks. Today, we have published results of automated Appicaptor analyses for the top 2,000 free iOS and Android apps.

Chart of blacklisted apps per category, Appicaptor Security Index 2018
Blacklisted apps per category. The bars for each exemplary selected function class show the respective proportion of the three risk classes.
Appicaptor Security Index, September 2018

When assessing the fitness for corporate use, it is not very surprising that apps for processing of corporate data are quite critical. In particular, the functional class of the File Manager apps shows a significant risk of usage with 73% iOS apps classified as unsuitable for corporate use (see figure). This is even higher with Android at 86%. The reasons for the blacklisting of both platforms are a very high ratio of IT security weaknesses and privacy relevant risks.

The report also shows new test insights about security characteristics of apps using the MultipeerConnectivity API from iOS. This API allows developers to easily implement a direct exchange of data between devices via wireless communication. This can be done both authenticated and encrypted, but the appropriate options have to be used by the developer.

iOS peer-to-peer transmission with lack of encryption and authentication
Poor / Missing cryptography: Endangerment of company data during peer-to-peer transmission due to lack of encryption and authentication. Demonstrated here with AirDroid for iOS (version 1.0.3)

The Appicaptor analyses show that 40% of the iOS Apps with this functionality neither encrypt the transmission nor authenticate the communication partners. As illustrated by the example of the AirDroid iOS App (version 1.0.3), an attacker can passively read the transmissions. For 20% of the iOS Apps with this functionality the transmission is at least encrypted, but without checking the authenticity of the communication partner. An active man-in-the-middle attack would then still be possible.

Download the complete Appicaptor Security Index 2018.

Presentation at it-sa 2018

Appicaptor was part of the largest IT security fair named it-sa “Home of IT-Security” in Nuremberg, Germany. Besides presenting the benefits of Appicaptor at our Fraunhofer booth, the Head of our Department, Dr. Jens Heider, presented the key aspects of automated app analysis for enterprise protection to the target audience.

Firstly, the talk focused on vulnerabilities that are based on overseeable but critical implementation errors that open the attack surface for substantial risks for smartphone managed data.

In the second part he presented strategies how enterprises can deal with the App dilemma: how to enable employee’s app usage without putting the company’s security at incalculable risk.

Here you can find his talk (in German).

Wireless Peer-to-Peer Communication: Many Apps still vulnerable to Attacks

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 EncryptionEncryption OptionalEncryption Required
without Authenticationpassive sniffingactive MitMactive MitM
with Authenticationpassive sniffingactive 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

Enhanced App-Rating Overview

Screenshot of the new Appicaptor app detail view for an example app
Screenshot of the new Appicaptor app detail view for an example app

Today we have changed the detail view of Appicaptor app analysis results to provide an improved overview. The new overview section summarizes the related meta-data, violations of security requirements and general risks for enterprise usage. The blacklisted or compliant symbols now provide the rating at a glance and the compact summary is more clearly separated from the more detailed analysis data.

The well-tried list of detailed information on the app’s security quality is presented below the overview section, following the similar design of the new PDF-Report that was already introduced earlier.

This design change is a next step of the migration to our new Appicaptor version that will provide new analysis engines for iOS and Android. These allow for an even deeper detection of bad app security quality.

The new version will be shown at it-sa fair 9 – 11 October 2018 in Nuremberg, Germany.

Huge amount of passwords found in Android Apps

Well, no big surprise but still another investigation on the topic how developers deal with the password problem: A scan of 1.8 million Android Apps revealed 20,000 apps with insecure keys built in, such as PGP keys, VPN access codes and hardcoded admin passwords.

Positive trend for crypto weaknesses in Top 2000 Android Apps during the last year (Appicaptor 04/2018)

Embedded static encryption keys in apps were also identified by Appicaptor in 17.2% of the Top 2000 Android Apps in April 2018. Those keys can be extracted by attackers to target the security mechanism it is used for, e.g., to revert the utilized encryption or fake content signatures.

Constant initialization vectors for encryption mechanisms, which allows an attacker to infer relationships between segments of encrypted messages with the same key and initialization vector, were identified in 14.1% of those apps.

A third weakness regularly found are low numbers of applied iteration rounds within key derivation functions. A key derivation function (or KDF) derives one or more secret keys from a secret value such as a master key, a password, or a passphrase using a pseudorandom function. So, the difficulty of a brute force attack increases with the number of iterations the KDF is executed, which should be at least 1,000. However, 31.5% of the most popular Android apps still use fewer iterations.

The good news is a positive trend for these weaknesses for the last years, but the total number of the found weaknesses does not indicate that the correct handling of cryptographic secrets and key derivation is already thoroughly understood from app developers (even at widely applied apps such as the Android Top Apps).