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.
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).
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.
The use of apps in enterprises requires a critical consideration of the included risks in order to be able to effectively counteract the threats through an analysis and approval mechanism. Today, we have published results of automated Appicaptor analyses for the top 2,000 free iOS and Android apps.
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 2017
When assessing the fitness for corporate use, it is not very surprising that apps for the processing of corporate data are quite critical. In particular, the functional class of the File Manager apps shows a significant risk of usage with 76% iOS apps classified as unsuitable for corporate use (see figure). This is even higher with Android at 88%. The reasons for the blacklisting of both platforms are a very high ratio of IT security weaknesses and privacy relevant risks (see report for further analysis details).
The report also shows new insights about security characteristics of hybrid apps, which affect resources such as the phone book, calendar, clipboard, position data and even access to local data storage in the sandbox of the vulnerable app. For the ratio of analyzed Cordova iOS apps, 81.6% (Android 80.3%) currently have the precondition for manipulating the app via web content to attack the JavaScript bridge to smartphone resources.
Even 14 months after the release of a serious vulnerability in the AFNetworking library for iOS, 20% of the free top 2,000 apps containing AFNetworking use vulnerable versions. After 30 months, 12% of the AFNetworking versions used are still vulnerable. In hybrid apps, vulnerable Cordova versions are also being used. (Appicaptor, September 2017)
The effects vary greatly depending on the smartphone resources used and the data processed. However, the ability to include these factors in a code analysis automatically allows for a more accurate risk assessment, so that only those apps that pose a specific risk are excluded from use in the company.
Other risks for Cordova apps are also the use of known vulnerable Cordova versions, which are used by 23.5% of iOS and 7.2% of Android Cordova apps. This makes it possible for attackers, e.g. under Android in Cordova versions prior to 3.5.1 to launch the Cordova app with other HTML page content via a link in order to misuse the available plug-ins with access to critical resources for their purposes.
But also the ratio of known vulnerable JavaScript libraries in Cordova Apps is a major problem with 36.7% (Android 38.3%). For example, using the vulnerable Angular. js version 1.4.4 allows attackers to break out of a secure ng-bind-html environment by manipulating user input. This environment normally allows only HTML formatting to be used, calls of JavaScript or other active content are prevented. The known weakness of this version allows attackers to bypass the protection mechanism, which again allows all available permissions of the app to be abused by an attacker.
We present details about our Appicaptor service and specific security findings based on corresponding app security research at the IT Security Expo it-sa 2017 (10 to 12 October 2017 in Nuremberg, Germany). Visit our booth in Hall 9 / 9-410 to get a live tour on how Appicaptor provides you with everything you need to make informed decisions in app approval processes and see insightful live demos of attacks on hybrid apps.
In the absence of security quality, attackers can easily modify the functionality of hybrid apps, generated using HTML, JavaScript, CSS and native plugins for access to smartphone resources. Appicaptor already detects related attack entry points such as unprotected communication, insecure SSL certificate validation or vulnerable third party libraries and correlates the inferred app model with the app’s permissions to draw Appicaptor customer’s attention to the resulting risks.
We demonstrate this attack by showing how trustworthy but flawed hybrid apps can be modified on the fly to generate wiretapping devices, just by injecting new functionality that unnoticeable records the smartphone’s ambient audio to an attacker’s cloud storage. According to our published analysis results that will be published for it-sa 2017, hybrid apps for iOS and Android are packed with flaws that allow attackers to do this by using malicious WiFi-hotpots or crafting special user input.
The automatic import of app lists to be analyzed by Appicaptor is now available for AirWatch Mobile Device Management System customers. Besides AirWatch, Appicaptor supports MobileIron and Sophos Mobile Control.
This new integration automatically returns the Appicaptor analysis results to your AirWatch MDM using black- and whitelists. This simplifies the process for app approval processes and enables full automation of the app review process.
With the help of the comprehensive AirWatch settings, the automatically generated black- or whitelists can then be assigned to all employees or individual user/device groups. All administrators can use actions provided by AirWatch to enforce corporate policies.
