CHAPTER 16
Identifying BlackBerry Application Issues

The preceding chapters discussed how to start analyzing BlackBerry 10 apps and how you might go about attacking them. This chapter covers specific classes of vulnerability and how you go about identifying them within the apps being assessed.

BlackBerry apps are not radically different from apps on any other platform. Thus the classes of issue that they are potentially susceptible to are not radically different compared to other platforms either.

When you do practical and risk-aware assessments of apps, you are primarily concerned with attacks that fall into five categories:

  • App permissions—The permissions requested by the app need to be proportional and essential to the functionality the user expects. Determine whether the permissions requested are excessive in nature.
  • Data storage—The app should store data in such a way that information is not exposed unnecessarily, and data that is accessible should not undermine the app's security.
  • Data transmission—Data should be transmitted by the app in a secure and integral manner proportional to the sensitivity of the data.
  • Personally Identifiable Information (PII) handling and privacy—Where PII data or other privacy-infringing data is processed and transmitted by the app, developers should be respectful of the user's privacy and opt for providing informed consent.
  • Secure development—Developers should write the app in a broad and secure fashion to mitigate against vulnerabilities that may lead to the compromise of the app itself either via local or remote means. This category primarily deals with the lower-level programming language, operating system, and packaging primitives. Check that developers haven't introduced security weaknesses or omitted mitigations.

Each of these five core categories may be comprised of many subcategories. These subcategories include things such as cryptographic operations in the case of data transmission; this subcategory will in turn have a subelement that ensures that the pseudorandom number generator source used for key material generation is correct. Another example might be in relation to secure development with a subcategory of intellectual property protection with a subelement of obfuscation or jailbreak detection.

Finally, a very broad category of consideration is privacy of the user beyond just PII. For example, tracking users in apps that do not handle sensitive PII may still violate user privacy. The GSM Association provides some good guidelines on this topic in the publication from 2012 titled, “Privacy Design Guidelines for Mobile Application Development” (http://www.gsma.com/publicpolicy/privacy-design-guidelines-for-mobile-application-development). Vodafone also provides some privacy guidelines in the form of an online reference (http://developer.vodafone.com/develop-apps/privacy/privacy-guidelines/).

Limiting Excessive Permissions

Permissions form an application's first line of defense because they not only inform the user what the app needs but also limit the impact if an app is compromised. In Chapter 14 we discussed application capabilities, which are the manifestations of permissions on the BlackBerry platform. Also in Chapter 14 we discussed the app packages and BAR files. MANIFEST.MF is the app's manifest file, which defines the permissions or capabilities the apps needs. You define permissions within the manifest in Entry-Point-User-Actions.

To audit permissions:

  1. Obtain the BAR file and/or MANIFEST.MF.
  2. Where a BAR file is obtained, extract it as a Zip file.
  3. Review MANIFEST.MF, specifically the Entry-Point-User-Actions, against the published list of capabilities from BlackBerry ( http://developer .blackberry.com/native/documentation/core/com.qnx.doc.native_sdk .devguide/topic/c_appfund_accessing_restricted_functionality.html).

Determining whether an app is requesting too many permissions will normally involve a discussion with the developers unless the app is obviously overly aggressive.

Resolving Data Storage Issues

The common types of data storage security issues include the following:

These classes of issues can potentially impact the security or privacy of the user or potentially the app and its supporting services. Over the years we've seen numerous examples of apps that embed secrets the developers did not expect to be discoverable, however when pointed out required a significant re-architecture of the app in order to resolve in a robust manner.

Auditing Shared Files

The easiest way to audit for issues involving shared files is to use SSH (Secure SHell) access to the device to take a listing of the pre- and post-installation and usage (ls -RLlathttp://www.qnx.org.uk/developers/docs/6.3.0SP3/neutrino/utilities/l/ls.html). An alternate method is to use one of the many file browsers available in the App Store. For further information on shared files and accessing files refer to Chapter 15 and the section titled, “Files.”

In addition to checking shared files, you should also check the system logger or slogger (http://developer.blackberry.com/native/reference/core/com.qnx.doc.neutrino.utilities/topic/s/slogger.html) to see whether sensitive information is being logged.

Checking BAR Files

Auditing for sensitive information contained in BAR files is simple:

  • Obtain the BAR and/or MANIFEST.MF.
  • Where a BAR file is obtained extract it as a Zip.

You should then review each file for sensitive files, taking care to understand and investigate that any data or files are actually archives or encoded in some manner (for example, BASE64). A useful tool for identifying file types of common binary formats is the Linux file utility or any other utility that uses libmagic (http://sourceforge.net/projects/libmagic/).

Reviewing the Application Sandbox

To be able to identify files that contain sensitive information in the app's sandbox, you first need to perform a backup of the device using BlackBerry Link so you can access information that is not shipped as part of the BAR file. You must then decrypt this backup file using a tool such as Elcomsoft Phone Password Breaker Forensic Edition. The “Accessing App Data from a Device” section of Chapter 14 covers how to use this tool.

After you decrypt the backup file you are left with a .bbb file that contains three .tar files. The appdata.tar contains the information you are interested in. Inside appdata.tar is a subdirectory for each of the installed applications, including the app's private sandbox storage. You can then locate the subdirectory for the app in which you are interested and review it. As with BAR files, carefully reviewing files that are not ASCII is important because they also may contain easily decodable sensitive information.

Checking Data Transmission

When assessing an application's data transmission mechanisms you are interested in the following:

Encryption and/or integrity checks are required if the protocol versions or ciphers used are known to be weak.

Encryption

To assess whether the transport security from the device to an online service is present, you first need to be in a position to intercept traffic. How to do this is covered the section, “Network Traffic Analysis and Interception” in Chapter 14. Analyze all traffic to and from the app for the presence of cleartext data that is weakly encoded or encrypted, or that uses encrypted connections that are easy to intercept. The general rules are

  • Authentication-related information should be encrypted, including credentials and session tokens for services protected by such mechanisms.
  • Sensitive PII including unique device or user tracker identifiers should be encrypted in transit.
  • Any encryption mechanism used to protect transport data should mitigate both active (man-in-the-middle) and passive (traffic analysis) attacks.

The most common way to implement transport security is to use SSL (Secure Socket Layer) or TLS (Transport Layer Security). Where possible, all apps should utilize TLS 1.2 or higher, which was introduced in OpenSSL 1.0.0h and OpenSSL 1.0.1. If TLS 1.1 needs to be supported for server compatibility, it can be, however given the disclosure of the Poodle vulnerability (https://www.us-cert.gov/ncas/alerts/TA14-290A). SSL 3.0 and lower should not be supported.

With regards to TLS usage within an app, you want to understand the following:

  • Which protocol versions are supported and whether protocol downgrade or renegotiation attacks are possible
  • Which ciphers are supported
  • Whether certificate validation is performed up to a trusted Certificate Authority
  • Whether Certificate Authority path validation is performed to verify that it chains to an expected CA
  • Whether certificate pinning is performed to pin to a specific certificate

This list goes from the highest level defenses and arguably what is considered mandatory (the first three) through to the lowest level and least technically sophisticated to implement (the last two).

To validate these mitigations, you can use tools such as mitmproxy (http://mitmproxy.org/) combined with tools such as Burp Proxy, Mallory, or Canape.

In situations where proprietary protocols are used, you typically must employ a mixture of traffic analysis and reverse engineering to understand the following constructs:

  • Key generation and storage
  • Key exchange/agreement
  • Ciphering and mode of operation
  • Data integrity and mode of operation, if required

One important consideration is even though data is encrypted, it may not be afforded integrity protection. Although SSL and TLS provide this capability through the use of Hash-based Message Authentication Codes (HMACs), other protocols may not. This can be important in, for example, a mobile payments app where an attacker might be able to change the amount being transferred even though he might not be able to reliably control the amount.

One way to validate an app's susceptibility to encrypted traffic modification is to first determine that the data the app is sending is encrypted, stored, and reflected back to the app. You can then bit-flip the encrypted content to see whether the content is accepted by the server and whether the content reflected back to the app changes. If the data is obviously BASE64 or similarly encoded, decode it prior to bit-flipping. Then re-encode it before transmitting it to the server. You can make these modifications programmatically to traffic sent between the app and server using tools such as Mallory or Canape.

Integrity

As mentioned in the previous section, integrity is important, and protocols such as TLS automatically provide mechanisms to provide integrity. In some situations a protocol does not need to be encrypted, but it does need integrity validation. For example, developers who don't want to pay for TLS or provide a certificate for their domain might employ integrity checks to allow the use of a Content Distribution Network (CDN).

When you're using cleartext protocols, analyzing them is important to identify whether the data being modified in transit has a negative security impact on the device. You must also verify that where integrity is provided it has an HMAC. Other integrity mechanisms such as CRC32, MD5, SHA1, or SHA2, while useful to validate corruption, do not provide a way of reliably validating integrity.

Handling Personally Identifiable Information and Privacy

When assessing an app for PII handling, referencing the guidelines on this topic produced by the GSM Association in its publication from 2012 titled, “Privacy Design Guidelines for Mobile Application Development” is a good idea (http://www.gsma.com/publicpolicy/privacy-design-guidelines-for-mobile-application-development). Vodafone provides privacy guidelines as well (http://developer.vodafone.com/develop-apps/privacy/privacy-guidelines/). If you are reviewing apps for certain markets, local or regional guidelines may exist, such as the “Privacy On the Go” guidelines from the California Attorney General's office (http://oag.ca.gov/sites/all/files/agweb/pdfs/privacy/privacy_on_the_go.pdf).

Validating how PII is handled involves analyzing three distinct aspects of the app:

Understanding which PII the app has access to is important. You typically deduce this information from reviewing the capabilities and permissions the app has. The following permissions are PII or privacy related:

How to identify issues with regards to the first two have already been covered earlier in this chapter. For the last (which exposes PII- or privacy-impacting data to other apps) understanding the IPC mechanisms available to BlackBerry apps is important (see Chapter 15). You must analyze each mechanism to understand whether it exposes PII or privacy data. Examples include:

Although local exposure to other apps of sensitive information might be less severe due to the need to have a malicious app on the device it should still be considered a risk. This risk stems from the fact that an installed malicious app may be able to access this sensitive information via the target app even though it does not have the appropriate capabilities and permissions itself. Historically, we've seen numerous examples of this on platforms such as Android.

Ensuring Secure Development

Beyond the specific topics already discussed in this chapter there are also more generic classes of issue that are valuable to identify and articulate to developers. These classes of issues have the ability either to introduce vulnerabilities themselves or significantly ease the exploitation of other issues present in the app.

Missing Compiler and Linker Defenses

For native Cascade and WebWork apps that use Cordova plug-ins you should assess whether the necessary compiler/linker defenses are in place. (See Chapter 17.) To do this you use the cross-compiler objdump that comes with the IDE and checksec.sh from Trapkit (http://www.trapkit.de/tools/checksec.html).

You must first obtain and extract the BAR files, and then run checksec.sh across the native binaries (including libraries) looking for any omissions. In addition to checking for these important in-depth features, this bash script checks for RPATH and RUNPATH. I made this addition while at BlackBerry. RPATH and RUNPATH are used by the loader:

. . . All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects that are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath isn't used when linking an ELF executable, the contents of the following directories are searched in order:

LD_LIBRARY_PATH 
_CS_LIBPATH.

http://www.qnx.org.uk/developers/docs/6.4.0/neutrino/utilities/l/ld.html

This functionality is the equivalent to the DLL Search Order on Microsoft Windows (http://msdn.microsoft.com/en-gb/library/windows/desktop/ms682586(v=vs.85).aspx) but provides a mechanism for developers to override it and quite frankly do something crazy. Because of its ability to provide (in theory) an RPATH / RUNPATH of an untrusted location and thus undermine the security model, auditing it if present is important.

Vulnerable Third-Party Libraries

Another key consideration for native, Cascade, and WebWork apps that use Cordova plug-ins is the version of any third-party native libraries that they ship with within the BAR, or worst case are statically linked into the main ELF file.

Identifying these vulnerable third-party external or statically linked libraries involves two approaches. The first is the use of a utility such as strings to extract any ASCII or UNICODE version strings that might be included and then cross referencing these extracted strings with the author's sites and vulnerability databases to determine whether these strings are vulnerable.

If the preceding approach doesn't yield anything, either version strings are omitted or are otherwise inconclusive, then the second approach is to fall back to reverse engineering, at least initially, to compare or develop binary signatures in Yara (https://yara.readthedocs.org/) that represent the vulnerable and non-vulnerable function.

I discuss how to write robust Yara rules to detect statically linked, Heartbleed-vulnerable OpenSSL in the blog post, “Writing robust Yara detection rules for Heartbleed” (https://www.nccgroup.com/en/blog/2014/06/writing-robust-yara-detection-rules-for-heartbleed/). The basic concept behind the approach is to compile a non-vulnerable version and disassemble it, as shown in Figure 16.1.

images

Figure 16.1 Disassembly of vulnerable function in IDA Pro

You extract the byte that doesn't reference things that can change, such as registers and addresses. These are highlighted in Figure 16.1.

You then replicate the process used for the vulnerable version of the function and get a signature string such as this:

Ru`le HeartBleedARM 
{ 
     strings: 
            $opensslminiARM = {04 ?? ?? ?? E9 1C 4F EA 18 22 C3 
1C 07 46 80 F8 02 \ 
80 02 20 7A 70 42 46 38 70 18 46 ?? F7} 
     condition: 
		 	$opensslminiARM 
}

Over time, your signature set will grow, enabling you to quickly scan apps for vulnerable dynamically and statically linked third-party libraries.

Native Code Vulnerability Classes

The topic of discovering native code vulnerabilities classes would fill a book. When we refer to native code vulnerabilities classes we primarily mean memory corruption, such as buffer overflows, underflows, double frees, format strings, use-after-frees, and similar items.

The primary method for discovering these is fuzzing. Fuzzing is the nomenclature used for automated, negative test case generation and execution, and automated bucketing or triaging, about which entire books have been written. What you fuzz and how depends on the purpose of app. For example, for an image-parsing app, your target would be the image formats that it supports. You would most likely fuzz via the Invocation Framework or by writing a custom test harness around the app's image-processing library.

If you wanted to use the Invocation Framework (see Chapter 15 in the “Invocation Framework” section) you would first inspect the application's manifest and look for invocation targets, the bb.action.OPEN action, and then (if supported) either common image extensions or MIME types. If these are present then you would be able to use the Invocation Framework to supply your generated test cases to the app. BlackBerry provides a sample invocation client app that shows you how to use the framework to save development time (https://github.com/blackberry/Cascades-Samples/tree/master/invokeclient).

When there isn't an invocation target for the functionality you want, then the next avenue to explore is writing your own instrumentation harness (i.e., a binary wrapped that is able to load the library, supply data and monitor for crashes, etc.) around the target libraries if they are external to the app. If the library is open source (you could code review) this will simply be a case of getting the headers. If the library is proprietary, you must revert to reverse engineering to create your own headers so you can use the library.

After you have the ability to invoke the functionality you want to fuzz, it is then a case of executing the harness within the simulator (which allows higher degrees of performance/parallelism) or the real device. The core files for any issues appear in logs/*.core.

When you assess for native code issues there are obviously native and Cascade apps; however, equally important are WebWorks apps, which use Cordova plug-ins. As discussed in Chapter 14 these plug-ins are native code with a JavaScript bridge to a native function that are then callable from the app. The attack path will be app-dependent but might include assets downloaded over HTTP connections or an injection vulnerability that allows you to inject JavaScript. You're looking to obtain arbitrary code execution.

Injection Vulnerability Classes

Apps that are potentially susceptible to injection vulnerabilities will primarily be Cascade and WebWorks based. In both cases you need to identify a source of tainting that gets you into a position to influence the scripting engines.

When considering injection vulnerabilities look for traditional JavaScript injection, DOM-based injection, and HTML or markup injection.

Again, entire books are written on this subject, but a common and quite effective way to identify such issues is to walk through the app identifying strings that appear to originate from external sources in the network, a local file, or the IPC mechanisms. You then attempt to taint these strings either at the source or via interception and modify them with common payloads to demonstrate vulnerability. A good reference for these strings is the OWASP Filter Evasion Cheat Sheet (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Within Cascades apps things can get quite complex because you have the ability to expose C++ objects to QML and vice versa (http://developer .blackberry.com/native/documentation/cascades/dev/integrating_cpp_qml/). As a result understanding this functionality which is available and going beyond standard cross-site-scripting classes is important. As noted in the QML security document, assessing all instances of the following is important:

  • Uses of import to ensure they don't import QML or JavaScript that could be intercepted or otherwise tainted by an attacker.
  • Uses of Loader to ensure they do not import QML or JavaScript that could be intercepted or otherwise tainted by an attacker.
  • Uses of XMLHttpRequest to ensure they do not load data that an attacker can control and then execute.

Normally, you conduct assessments in these cases at a source level by extracting the BAR and inspecting the underlying code.

Logic Issues

The final primary class of vulnerability to consider is logic issues. These vulnerabilities are highly dependent on the functionality of the app. This class of issue includes everything from the weird to the wonderful to the downright crazy. To discover these issues you must have a good understanding of all facets of the app and all the topics documented in Chapters 14, 15, 16, and 17.

Logic issues really can be anything from the supporting of negative order amounts which result in the app giving you money through to user interface spoofing and everything in between. As a result it is imperative to understand the function of the app, how the user will interact with it, likely implicit security boundaries, and how any of these can be misused.

Summary

In this chapter you looked at the common types of vulnerabilities to which BlackBerry 10 apps can be susceptible and how to go about identifying whether an app is vulnerable. We've tried to provide specific guidance to common point issues, and in places provide guidance on the types of things to consider and how to assess for them.

This topic is almost limitless and as such potential vulnerabilities will be highly dependent on the app you are trying to hack. Understanding the app, its core function, attack surface, development language, and the services it interacts with is important. This understanding allows you to develop representative attack threat models and thus accurate attack trees (conceptual diagrams showing how an asset, or target, might be attacked) to use against the app.