Security Evaluation of Mobile Applications by Raul Siles ... · )) Copyright:!Raul!Siles!for!The!ESCAL!Institute!Of!Advanced!Technology!Inc.,!SANS!Institute,!8120!Woodmont!Avenue,!Bethesda,!20814,!MD,!USA

WWW.SANS.ORG Copyright: Raul Siles for The ESCAL Institute Of Advanced Technology Inc., SANS Institute, 8120 Woodmont Avenue, Bethesda, 20814, MD, USA

Security Evaluation of Mobile Applications using 'App Report Cards': Android By Raul Siles October 2015 This article introduces the SANS SEC575 mobile 'App Report Cards' project and provides details on some of the analysis techniques used to scrutinize Android mobile applications (or apps) when searching for security vulnerabilities and exploitation opportunities. It offers as well suggestions for app developers to implement the desired security features, including some code examples and references. The corresponding SANS webcast by the author Raul Siles is available to watch here: https://www.sans.org/webcasts/security-‐evaluation-‐mobile-‐applications-‐app-‐report-‐cards-‐100912 The mobile 'App Report Cards' is a scoring and reporting system, distributed as Microsoft Excel spreadsheets in the form of card templates, for a consistent and thorough security analysis and evaluation of Android and iOS mobile applications. Although the two most common mobile platforms worldwide Android and iOS are part of the project, the details of the iOS mobile report card won't be covered in this article, focusing just on some relevant Android checks. After taking an in-‐depth look at both reports cards, it is trivial to realize that some of the analysis items for evaluating Android apps do not differ from the items for analyzing iOS apps. The reason is there are multiple common security features in both platforms, notably the evaluation of network traffic, TLS validation, and certificate checks. Additionally, there are similar checks in both platforms although these have to be evaluated using different tools and techniques, such as the detection and mitigation of bypass techniques of rooted or jailbroken devices, the suppression of system log messages, the protection of sensitive data at rest, or the detection and/or prevention of a debugger attached to the app at runtime. Finally, other items only apply to one platform or the other, notably mitigations for custom Intent handling misuse in Android or for URL handler misuse in iOS. Therefore, the mobile 'App Report Cards', specifically designed as part of the "SANS SEC575: Mobile Device Security and Ethical Hacking" training (http://www.sans.org/sec575), provides penetration testers and mobile security analyst with a new guided security testing workflow to leverage the multiple tools and common techniques covered along the course to evaluate iOS and Android mobile applications. These techniques cover various aspects that influence the security posture of mobile apps, including storage and file system usage inspection, and network activity monitoring, interception and manipulation. This information is complemented with application static and automated analysis and reverse engineering techniques, combining app code and behavior analysis for effective app penetration testing. Additionally, opportunities to manipulate application behavior are identified as part of the analysis process by inspecting and modifying the app code, inspecting critical app definitions and interacting with its interfaces and components at runtime.


Complementary, the mobile 'App Report Cards' provides a significant benefit to mobile application developers. The report helps them to review and apply the recommended countermeasures and protections to resolve identified flaws and meet the security expectations of each report card, while the scoring allows them to evaluate and track how the app security capabilities progress and mature over time throughout different app versions. As a result, each of the individual testing items reflected within the mobile 'App Report Cards' implicitly has one or multiple recommended evaluation techniques associated with them. These have to be applied by mobile security analyst to identify security flaws. Similarly, each of the test items implicitly has one or multiple suggested security recommendations associated with them, sometimes in the form of source code that implements the required fix or a switch that enables the desired security feature. These can be applied by mobile app developers to improve the security posture of the app and address the identified threats. As a professional penetration tester, I'm aware that the end goal of my security assessments is not just the identification and exploitation of vulnerabilities that expose the customer environment, but to provide practical and actionable recommendations to be able to fix those findings and improve the overall security posture of the target environment, in this article, the target mobile app. The mobile 'App Report Cards' is an effective and easy to use tool that facilitates this goal by complementing the penetration test report with a list of checks that can be tracked by the main target audience, the developers. The developers, in collaboration with the security team, are the ones that will ultimately be in charge of fixing the discovered flaws. The following mobile application security considerations are a reduced subset of some of the analysis techniques and mitigations behind the mobile 'App Report Cards'. Evaluating App Traffic Encryption Requirements One of the most significant security problems in mobile apps is the use of unencrypted network traffic. Multiple mobile studies in the past have emphasized the lack of proper transport encryption for all or some of the sensitive traffic exchanged by mobile apps, both in apps from small developer shops as well as large-‐scale official apps. Even when the app relies on HTTPS (TLS), the validation of certificates can fail. In this author's experience when assessing the security of mobile apps, sometimes developers forget to restore back the original validation code, leaving in place the relaxed certificate verification practices used during development, and ending up with a vulnerable official app in Google Play that accepts any certificate as valid. In other cases, the app validates the certificate properly, but provides the user the option to continue despite displaying a certificate warning or error (e.g. a very common scenario in the traditional web browser world, unless using HSTS).


The most common scenario is when the app accepts as valid any trusted certificate, using a criteria based on the current list of trusted Certification Authorities (CAs) available in the Android device. Thus, as a pen-‐tester, the only requirement to be able to bypass the default certificate validation process is to import in the Android credential storage of the device the root CA associated to the interception proxy being used. Security conscious developers, instead of relying on potentially untrustworthy root and intermediate authority chains, or end-‐user trust decisions, leverage certificate pinning in their Android apps through a custom X509TrustManager (https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Android). Certificate pinning implements the validation of the TLS server identity by matching the public key (rather than the server digital certificate) embedded in the Android app. From a pen-‐tester perspective, bypassing certificate pinning requires manipulating the Android app Dalvik bytecode or using low-‐level hooking functions from inside the device, trying to disable certificate validations. The usage of this advanced analysis techniques requires having root access in the Android device. Two of the most common Android tools used for this purpose make use of two completely different hooking frameworks, Android SSL TrustKiller (https://github.com/iSECPartners/Android-‐SSL-‐TrustKiller) based on Cydia Substrate, and JustTrustMe (https://github.com/Fuzion24/JustTrustMe) based on Xposed. Additionally, Android apps might become vulnerable by implementing their own custom crypto functions or using known vulnerable crypto libraries, such as old versions of the OpenSSL library. In order to mitigate this risk, Google provides a default Dynamic Security Provider (named GmsCore_OpenSSL, http://appfoundry.be/blog/2014/11/18/Google-‐Play-‐Services-‐Dynamic-‐Security-‐Provider), via Google Play Services (GPS), to provide secure network communications. Apps simply need to call the corresponding Google Play Services methods to ensure that they are running on a device that has the latest provider (or library). The provider is automatically updated to protect against known SSL/TLS exploits, such as those targeting the CVE-‐2014-‐0224 vulnerability. This OpenSSL vulnerability leaves apps open to MitM (Man-‐in-‐the-‐Middle) attacks that can decrypt the TLS traffic and was fixed in GPS version 5.0 (https://developer.android.com/training/articles/security-‐gms-‐provider.html). Developers can benefit from these capabilities by using high-‐level methods for interacting with encrypted network communications, like HttpsURLConnection. Complementary, developers can update a device's security provider by using the ProviderInstaller class, and specifically do it synchronously or asynchronously by calling the installIfNeeded() or installIfNeededAsync() methods, respectively. The following asynchronous code sample checks if the provider is up to date, and updates it if necessary, when the app's is launched (main activity onCreate() method). It also implements the appropriate methods to manage different scenarios, such as when the


provider was already up-‐to-‐date or has been properly updated (onProviderInstalled(), proceeding to execute the secure network calls), or if the update process failed (onProviderInstallFailed()), although potentially it can be recovered by the user: public class MainActivity extends Activity implements ProviderInstaller.ProviderInstallListener { //Update the security provider when the activity is created. @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); ProviderInstaller.installIfNeededAsync(this, this); } /** * This method is only called if the provider is * successfully updated (or is already up-to-date). */ @Override protected void onProviderInstalled() { // Provider is up-to-date, app can make secure network calls. ... } /** * This method is called if updating fails; the error code * indicates whether the error is recoverable. */ @Override protected void onProviderInstallFailed(int errCode, Intent recoveryIntent) { if (GooglePlayServicesUtil.isUserRecoverableError(errCode)) { // Recoverable error. Show a dialog prompting the user to // install/update/enable Google Play services. ... } else { // Google Play services is not available. onProviderInstallerNotAvailable(); } } private void onProviderInstallerNotAvailable() { // This is reached if the provider cannot be updated for some // reason. App should consider all HTTP communication to be // vulnerable, and take appropriate action. ... } }

In certain scenarios, even when the developer has taken the proper precautions to encrypt the app's traffic and validate certificates adequately, other third-‐party components used by


the app, such as ad libraries, can weaken the overall security posture of the app due to the exchange of unencrypted traffic. In iOS 9.0, Apple introduced the Apple Transport Security (ATS) feature, expecting all apps to use TLS 1.2 by default and forcing app developers to specify exceptions if they need to use unencrypted network traffic. Similarly, in Android 6.0, Marshmallow, there is a new AndroidManifest.xml flag, usesCleartextTraffic, that might require all network traffic to be TLS encrypted. Unfortunately this feature is set to "true" implicitly, not requiring encryption by default. Security-‐aware Android developers can switch it to "false" and prevent (on a best effort basis) an otherwise well-‐intentioned app from accidently using plaintext network traffic: <manifest ... <application ... android:usesCleartextTraffic="false"> </application> ...

Additionally, the new NetworkSecurityPolicy class associated to the app, in relation to StrictMode, allows the app developer to detect places where the app is inadvertently sending clear-‐text data across the network via the detectCleartextNetwork() method (https://koz.io/android-‐m-‐and-‐the-‐war-‐on-‐cleartext-‐traffic). The developer has the option to log the raw contents of the packet that triggered the violation or block further traffic on that socket to prevent accidental data leakage (and crash the app). Although for most Android apps, switching from plaintext HTTP to encrypted HTTPS is a simple code change, it is a complex infrastructure change that affects most of, if not all, the back-‐end servers the app communicates with. However, the recent transport security features promoted in the main mobile platforms make this a necessary step. Today is the right time for mobile developers to jump in! Expanding the mobile 'App Report Cards' The benefit of the 'App Report Cards' is that they can be easily expanded in two very specific but different ways when new features and security mechanisms are made available in the mobile platforms, like in Android Marshmallow (or Android 6.0, API level 23). On the one hand, current checks already available in the 'App Report Cards', such as the first one ("Does the app declare the minimum number of permissions necessary?"), can be extended with more in-‐depth analysis focused on the evaluation of the permissions requested by the app and the new runtime permission model introduced in Android 6.0. On the other hand, new checks can be included in the 'App Report Cards' to extend the assessment to cutting-‐edge topics, such as the new auto app backup feature available in Android 6.0. The next two sections cover in detail these two features. Evaluating App Permissions Requirements Android developers must declare the permissions required by the app in the AndroidManifest.xml file. In the traditional Android permission model, users are prompted to accept all app declared permissions at install time.


Unfortunately, developers frequently add more permissions than what is needed for the functionality implemented in the current app version. An assessment of the current app version might not disclose serious concerns regarding the requested permissions and associated functionality. However, future app updates might add extra capabilities that take advantage of permissions granted in the current version of the app, introducing new security or privacy threats. Additionally, closed-‐source third-‐party libraries used within the app could leverage extra features associated to those extra permissions and increase the exposure of sensitive information about the app, the device, or the user. The app permissions can be easily evaluated by inspecting the AndroidManifest.xml file, after converting it to the ASCII format using the axmlprinter tool (https://github.com/rednaga/axmlprinter), a refactor of the original AXMLPrinter2 tool: $ java -jar ./tools/axmlprinter/axmlprinter-0.1.5.jar \ AndroidManifest.xml > AndroidManifest.txt.xml

Alternatively, the permissions can be assessed as part of a broader evaluation focused on minimizing the permission and component exposure of Android apps. The excellent Drozer tool by MWR InfoSecurity (https://www.mwrinfosecurity.com/products/drozer) allows the analyst to quickly identify the app permissions as well as the accessible app components (although this last topic is out of the scope of this article): dz> run app.package.info -a com.zillow.android.zillowmap Package: com.zillow.android.zillowmap Application Label: Zillow Process Name: com.zillow.android.zillowmap Version: 6.2.3378 Uses Permissions: - android.permission.INTERNET - android.permission.ACCESS_WIFI_STATE - android.permission.ACCESS_FINE_LOCATION - android.permission.ACCESS_COARSE_LOCATION - android.permission.READ_PHONE_STATE - android.permission.GET_ACCOUNTS - android.permission.WRITE_EXTERNAL_STORAGE ... dz> run app.package.attacksurface com.zillow.android.zillowmap 5 activities exported 5 broadcast receivers exported 0 content providers exported 2 services exported

Android 6.0 introduces a new runtime permission model (http://developer.android.com/guide/topics/security/permissions.html) where the user does not need to grant permissions at install or upgrade time. Instead, at runtime, the first time the app needs to invoke functionality that requires a particular permission, it presents the user a system dialog box requesting that specific permission.


Android permissions are divided into several protection levels, being the two most relevant ones normal and dangerous. Unfortunately, permissions belonging to the normal protection level are automatically granted at install time, as it is assumed by Google there is very little risk to the user's privacy or security. Besides that, the new runtime permission model does not provide a revoke option for normal permissions (PROTECTION_NORMAL). Normal permissions (http://developer.android.com/guide/topics/security/normal-‐permissions.html) include, between others, network and Internet access, perform operations over NFC or Bluetooth (including discovery and pairing), request the installation of packages, kill background processes or set the system time zone. Additionally, in mid 2014 Google introduced the concept of simplified permissions in Android, currently known as permission groups. All Android dangerous permissions belong to a specific group based on their nature and purpose, such as for example capabilities to read and write the user's contacts (Contacts group), or to read, send or receive SMS messages (SMS group): CONTACTS permission group: READ_CONTACTS WRITE_CONTACTS GET_ACCOUNTS SMS permission group: SEND_SMS RECEIVE_SMS READ_SMS RECEIVE_WAP_PUSH RECEIVE_MMS

If an app requests a dangerous permission listed in its manifest file, but the app has already obtained another dangerous permission in the same permission group (because the user has already approved it previously), the system immediately grants the new permission to the app without any interaction with the user. Developers should apply best programming and security practices (http://developer.android.com/training/permissions/best-‐practices.html) and minimize the number of permissions their app requests, only asking for permissions strictly needed. They can also even try to have their app use an Intent to request another app to perform a task, instead of have their app ask for permission to perform the operation itself.


With the new Android runtime permission model, it is crucial for developers to explain to the user why their app requests a specific permission before calling requestPermissions(), the method used to show the permissions dialog box. On the one hand, the developer can inform the user incorporating these requests into an app tutorial. On the other hand, the developer can inform the user programmatically through the shouldShowRequestPermissionRationale() method (http://developer.android.com/training/permissions/requesting.html). This method returns true, in order to show the user an explanation, if the app has requested that specific permission previously and the user denied the request. The method returns false if the user turned down the permission request in the past and chose the "Don't ask again" option in the permission request system dialog, or if a device policy prohibits the app from having that permission (trying not to disturb the user). The following code sample checks if the app has the RECORD_AUDIO permission to get access to the device's microphone. If it does not have it, it first explains the user why the permission is required, and then shows the dialog to request that specific permission: if (ContextCompat.checkSelfPermission(thisActivity, Manifest.permission.RECORD_AUDIO) != PackageManager.PERMISSION_GRANTED) { // Show an explanation if (ActivityCompat.shouldShowRequestPermissionRationale( thisActivity, Manifest.permission.RECORD_AUDIO)) { // Show an expanation to the user *asynchronously* ... } else { // No explanation needed, we can request the permission. ActivityCompat.requestPermissions(thisActivity, new String[]{Manifest.permission.RECORD_AUDIO}, MY_PERMISSIONS_REQUEST_RECORD_AUDIO); // MY_PERMISSIONS_REQUEST_RECORD_AUDIO is an // app-defined int constant. The callback method gets the // result of the request. } }

Once the user interacts with the system dialog box and approves or denies the requested permission, the app onRequestPermissionsResult() callback method will be invoked. The developer needs to carefully implement tasks for both scenarios, as the permission might have been turned up or down by the user, enabling or disabling the functionality that depends on this permission, and for each permission requested, identified by the MY_PERMISSIONS_REQUEST_RECORD_AUDIO constant in the previous code sample.


Finally, during the transition period, developers should manage and test for both permissions models. Their recently updated app targeting devices running Android 6.0, that takes advantage of the new runtime permission model, can also be installed in devices running previous versions of Android, and still using the traditional permission model. Evaluating the App's Backup Policy Android 6.0 implements new auto app backup capabilities to automatically backup the apps private data in Google Drive. This feature is available by default for all apps. The app's private data is supposed to be stored in the cloud in an encrypted format. Although the user has the option to opt-‐out globally via the Settings app (unfortunately, this is an all or nothing proposition, where it is not possible to opt-‐out individually per app), security conscious app developers managing sensitive data can disable it. App developers can disable the auto app backup feature completely, with the associated drawback that this action will disable ADB backups too, or they can define a selective backup policy through a backup scheme configuration XML file, that determines the data that will be included or excluded from backups. The following element from the app's AndroidManifest.xml file completely prevents automatic backups of any of the app's data and files: <manifest ... <application ... android:allowBackup="false"> </application> ...

The following attribute from the app's AndroidManifest.xml specifies an XML file located at "res/xml/backupscheme.xml" that contains the automatic backup rules for the app's data: <manifest ... <application ... android:fullBackupContent="@xml/backupscheme"> </application> ...

The syntax of the backup scheme configuration XML file specifying what files to include or exclude from backups is available at http://developer.android.com/training/backup/autosyncapi.html. The following "backupscheme.xml" file sample defines a backup scheme that allows backing up all app files (the default is to backup everything) except a shared preferences file named "profile.xml" and a database file called "sessions.db": <full-backup-content> <exclude domain="sharedpref" path="profile.xml" /> <exclude domain="database" path="sessions.db" /> </full-backup-content>


Android developers need to be aware of these new features and their security implications (http://android-‐developers.blogspot.com.es/2015/07/auto-‐backup-‐for-‐apps-‐made-‐simple.html), because as soon as their app targets the latest Android 6.0 version, API level 23, throughout the following manifest file directive, the device will automatically backup all the app data in Google Drive: <manifest ... <uses-sdk android:targetSdkVersion="23"/> <application ... ... </application> ...

Conclusion The process of thoroughly evaluating and analyzing the security of mobile applications can be a daunting and complex task. Sometimes, in the process of performing consistent testing by the analysts or applying all the recommendations by the developers, critical steps can be miss evaluated or miss implemented and leave applications exposed. To address these shortcomings, the 'App Report Cards' goal is to consistently apply a testing process and use specific techniques to identify and remediate common vulnerabilities in mobile applications. The 'App Report Cards' project, available at https://github.com/joswr1ght/MobileAppReportCard, includes a couple of completed app analysis samples: E.g. ooVoo for iOS and Zillow for Android. The format, scoring, and outline of these cards are open for feedback from the community. If you want to learn how to apply, evaluate and mitigate all the different items included in the mobile 'App Report Cards' leveraging specific tools and techniques, consider taking the SANS SEC575 course! Raul Siles will be teaching "SANS SEC575: Mobile Device Security and Ethical Hacking" at the end of this year in Dubai (Oct 17-‐22, 2015), http://www.sans.org/event/gulf-‐region-‐2015/course/mobile-‐device-‐security-‐ethical-‐hacking, and London (Nov 16-‐21, 2015), http://www.sans.org/event/london-‐2015/course/mobile-‐device-‐security-‐ethical-‐hacking. About the author Raul Siles is founder and senior security analyst at DinoSec. For over a decade, he has applied his expertise performing advanced technical security services and innovating offensive and defensive solutions for large enterprises and organisations in various industries worldwide. He has been involved in security architecture design and reviews, penetration tests, incident handling, intrusion and forensic analysis, security assessments and vulnerability disclosure, web applications, mobile and wireless environments, and security research in new technologies. Throughout his career, starting with a strong technical background in networks, systems and applications in mission critical environments, he has worked as an information security expert, engineer, researcher and


penetration tester at Hewlett Packard, as an independent consultant, and on his own companies, Taddong and DinoSec. Raul is a certified instructor for the SANS Institute, regularly teaching penetration testing courses. He is an active speaker at international security conferences and events, such as RootedCON, Black Hat, OWASP, BruCON, etc. Mr. Siles is author of security training courses, blogs, books, articles, and tools, and actively contributes to community and open-‐source projects. He loves security challenges, and has been a member of international organisations, such as the Honeynet Project or the SANS Internet Storm Center. Raul is one of the few individuals worldwide who have earned the GIAC Security Expert (GSE) designation, as well as many other certifications. Raul holds a master's degree in computer science from UPM (Spain) and a postgraduate in security and e-‐commerce. More information at http://www.raulsiles.com (@raulsiles) and http://www.dinosec.com (@dinosec).

Documents

Security Evaluation of Mobile Applications by Raul Siles ... · )) Copyright:!Raul!Siles!for!The!ESCAL!Institute!Of!Advanced!Technology!Inc.,!SANS!Institute,!8120!Woodmont!Avenue,!Bethesda,!20814,!MD,!USA