Vulnerable Library Warning: TwitterKit for iOS

The Twitter Kit framework through 3.4.2 for iOS does not properly validate the TLS certificate for api.twitter.com. That’s a finding found with our static binary analysis and reported to Twitter.

There will be no fixed version, as this library is no longer supported by Twitter, but this vulnerable library was still found in many apps. It is urgently advised that their app developers switch to alternative APIs.

Such issues are a likewise common, which illustrates the need to check for vulnerable or outdated 3rd party code.

What makes this issue a bit special is the way the developers broke the validation of TLS certificates. Apparently, they wanted to increase the security by implementing a public key pinning of trusted root certificate authorities (CA), such as VeriSign, DigiCert and GeoTrust. So they created the following array with entries of 21 public key hashes for the CAs:

"1a21b4952b6293ce18b365ec9c0e934cb381e6d4",  // "VERISIGN_CLASS3_G2"
"2343d148a255899b947d461a797ec04cfed170b7",  // "VERISIGN_CLASS1"
"5519b278acb281d7eda7abc18399c3bb690424b5",  // "VERISIGN_CLASS1_G3"
"1237ba4517eead2926fdc1cdfebeedf2ded9145c",  // "VERISIGN_CLASS2_G2"   
"5abec575dcaef3b08e271943fc7f250c3df661e3",  // "VERISIGN_CLASS2_G3"    
"22f19e2ec6eaccfc5d2346f4c2e8f6c554dd5e07",  // "VERISIGN_CLASS3_G3"
"ed663135d31bd4eca614c429e319069f94c12650",  // "VERISIGN_CLASS3_G4"
"b181081a19a4c0941ffae89528c124c99b34acc7",  // "VERISIGN_CLASS3_G5"
"3c03436868951cf3692ab8b426daba8fe922e5bd",  // "VERISIGN_CLASS4_G3"
"bbc23e290bb328771dad3ea24dbdf423bd06b03d",  // "VERISIGN_UNIVERSAL"
"c07a98688d89fbab05640c117daa7d65b8cacc4e",  // "GEOTRUST_GLOBAL"
"713836f2023153472b6eba6546a9101558200509",  // "GEOTRUST_GLOBAL2"
"b01989e7effb4aafcb148f58463976224150e1ba",  // "GEOTRUST_PRIMARY"
"bdbea71bab7157f9e475d954d2b727801a822682",  // "GEOTRUST_PRIMARY_G2"
"9ca98d00af740ddd8180d21345a58b8f2e9438d6",  // "GEOTRUST_PRIMARY_G3"
"87e85b6353c623a3128cb0ffbbf551fe59800e22",  // "GEOTRUST_UNIVERAL"
"5e4f538685dd4f9eca5fdc0d456f7d51b1dc9b7b",  // "GEOTRUST_UNIVERSAL2"
"d52e13c1abe349dae8b49594ef7c3843606466bd",  // "DIGICERT_GLOBAL_ROOT"
"83317e62854253d6d7783190ec919056e991b9e3",  // "DIGICERT_EV_ROOT"
"68330e61358521592983a3c8d2d2e1406e7ab3c1",  // "DIGICERT_ASSUREDID_ROOT"
"56fef3c2147d4ed38837fdbd3052387201e5778d",  // "TWITTER1"

On every new connection, TwitterKit for iOS checks in method evaluateServerTrust whether the received certificate chain contains a certificate with a fitting public key of the list above. This way, certificates for api.twitter.com issued by possibly untrusted CAs should be blocked. However, this approach lacks a very important verification: The domain name of the leaf certificate is not verified by iOS, as TwitterKit for iOS implemented an own delegate method for its public key pinning functionality. In this case, iOS only verifies, that the certificate chain is valid regarding signatures. All other checks have to be performed by the delegate method, to provide the flexibility for alternative verification methods. A simple fix would have been additionally calling the iOS method secTrustEvaluate and utilize its result value to reject certificates for other domains.

Because of the missing domain name verification, any valid certificate chain containing a certificate with a public key hash of that list is accepted by the app. An attacker with a valid certificate for his own domain, issued by one of these CAs, can use this certificate for man-in-the-middle-attacks against apps communicating via the Twitter Kit for iOS with api.twitter.com. As the implementation does not check the position inside the chain, the matching public key could also be in the middle of the chain, such as in case of an intermediate certificate.

We used a matching legitimate certificate, issued by DigiCert for a domain under our control to verify the impact of the vulnerability. So we redirected the traffic for api.twitter.com to our server, that answers the request with our own certificate. The received content is logged and transmitted to the ‘real’ Twitter servers. The server’s response is also logged and transmitted back to the app. However, as the login process for Twitter involves a WebView, which does not use the vulnerable pinning functionality, it would not accept our certificate. As the WebView loads its content via the same domain name, we had to distinguish TLS connections based on differences in ALPN extension of the TLS Client Hello and route WebView connections without interception, to create a fully working proof of concept attack.

During the Login with Twitter process, our man-in-the-middle proxy recorded for a vulnerable news app the OAuth 1.0 oauth_token_secret together with the authorized oauh_token. This enabled us to fully use the provided Twitter API with these long term secrets. Attackers could perform actions like changing content of the profile, creating fake tweets and direct messages or abusing the account to push tweets via fake likes. It would also be possible to read private direct messages sent or received within the last 30 days. We could not retrieve the password nor set it to a known value, so an attacker could not use the vulnerability to lock out a user from his account. However, by changing the Twitter password a victim would also not be able to invalidate the sniffed OAuth tokens. For this it is required to revoke the app’s authorization within the Twitter settings.

Further, on every app start the vulnerable app checks the validity of the Twitter account by invoking the Twitter API account/verify_credentials.json. In case the credentials are valid, the response contains detailed information about the victims Twitter profile, such as ID, name, location and last activities. As the response can be read in our attack scenario, the information can be used to collect information about the victim to track him or dynamically create targeted phishing attacks.

We will demonstrate the vulnerability and its detection at it-sa 2019 fair in Nuremberg, Germany at Hall 9, Booth 234.

Unwanted Functionality Apps in Google Play Store

Once again, a list of apps in Google Play Store with unwanted functionality was published. This list holds apps forcibly displaying ads on the user’s lock screen, triggering video and audio advertisements even while the phone was asleep, and displaying out-of-app ads that interfere with a user’s interaction with other applications on their device. This unwanted functionality did not immediately appear after app installation, but became visible at least 24 hours after the application was launched. Some apps wait patiently 2 weeks after installation to impede the occurring disturbances to be brought into connection with the liable app.

We have checked the published list and found 7 unique apps on it that have been analyzed in the last months by Appicaptor. All of them were blacklisted by Appicaptor’s standard policy intended for medium security requirements. The rating is based on generic rules regarding a correlation between the app model, extracted by machine learning from the app’s description text, and static analyzed properties of app content.

Although the unwanted functionality has not being directly identified by Appicaptor, we are pleased to see that Appicaptor’s standard policy had identified these apps as not compliant with business requirements. This shows the informative value of the standard Appicaptor policy set that is continuously revised and updated over the last years.

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