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).

BankBot: Weak Banking App Protection?

The BankBot Trojan is back in the news, targeting German mobile banking apps as well. While most articles ask how this Trojan could bypass Googles reviews and Google Play Protect on-device checks, we miss a consideration of protection measures implemented by mobile banking apps.

Before looking at the app protection side, one has to consider that this Trojan requires three critical Android OS settings to be configured:  the smartphone user (1) has to opt-in for app sideloading, (2) has to acknowledge the installation of an additional component and (3) has to grant the device administration permission to the Trojan. However, in more advanced attacks these settings could have been configured even without notice of the user, as found in the TOASTAMIGO malware. After applying these settings, the Trojan has critical privileges, but is far away from the dreaded root privileges. Chances are still good that app protection mechanisms would make it harder to successfully perform an unauthorized transfer.

From a banking app developer’s point of view, a first line of defense would be to implement a so called tapjacking protection. This way, the Trojan would not be able to redirect touch events of a crafted overlay to the exported activity of the mobile banking app below the overlay.

However, only 5.2% of the analyzed Android banking apps currently have implemented this protection (Appicaptor Top 2000 Report, November 2017). Even worse, about 67.4% still contain unencrypted HTTP requests (btw: redirecting these requests on server side to HTTPS is by far no effective protection). These requests commonly are not used for the main banking interaction functionality but often are found for additional services, such as address finders or terms of conditions pages. Unencrypted HTTP communication could be abused in the trusted bank app context for dangerous phishing attacks.

The effort for implementing proper tapjacking protection and removing HTTP requests within the mobile banking app is quite low compared to the obtained improved security gain. But these measures would not prevent Trojans from displaying a fake UI over the real one of the mobile banking app, like the BankBot Trojan does. We already have committed a security patch to the Android Souce Code repositories in order to stop tapjacking attacks on the Admin Device Permission Request window, however this does not prevent more sophisticated attacks exploiting “Toast type” overlays. The latter overlay attacks are fixed with Android’s security patch level of 2017-09-05. Additional improvements are integrated in Android 8 Oreo, which prevent apps from overlaying the smartphone’s status bar and display a persistent notification about apps running in the background. However, there are already apps in Google Play Store, which offer the option to remove these “annoying App X in background notifications”. Trojans would also be able to hide “their” app in background notification, too.

This shows that the Android OS and its app environment is not ready for combining separated banking channels: the transaction and the authorization channel. This separation was introduced for good reasons, but the current trend for mobile banking apps indicate a strong demand for using both channels on a single device. However, the observed security quality of current mobile banking apps does not reflect the required protection level for the introduced risks.