Findings¶

Analyzing 3^rd party frameworks¶

Versions of Third Party frameworks are usually stored in the info.plist file. Find out if these have security Vulnerabilities.

Firebase¶

Make sure there is no private key file for the SDK. An example is listed below.

Firepwn is a tool made for testing the Security Rules of a firebase application.

gps-points-394bc-firebase-adminsdk-mxx28-e50183ee68.json:

{
  "type": "service_account",
  "project_id": "gps-points-394bc",
  "private_key_id": "e50183ee32[REMOVED]",
  "private_key": "-----BEGIN PRIVATE KEY-----\n[REMOVED]-----END PRIVATE KEY-----\n",
  "client_email": "[email protected]",
  "client_id": "107755009498[REMOVED]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/firebase-adminsdk-mxx28%40gps-points-394bc.iam.gserviceaccount.com"
}

Screenshots are Not Disabled¶

Overview¶

The does not prevent the user from taking screenshots when applications are in the foreground. This can lead to information leakage in the event that a user or an attacker with physical access to the user’s device take a screenshot of information displayed within an application. In this scenario, the screenshot will be saved outside of the protections provided by .

Remediation Procedure¶

The application team should disable screenshots from being taken for all Android applications.

Currently, Apple does not provide developers with a way to disable screenshots for iOS. This issue has been logged to ensure that is aware of the potential for information leakage through this avenue.

Sensitive Data Remains in Memory after Application Timeout¶

Overview¶

The Android Token application maintains sensitive data in memory even after timeout. A malicious user who gains access to the device and is able to get root access without requiring a reboot, would be able to dump the application’s heap contents and extract the sensitive data. Although, most modern exploits require a reboot due to performing modifications to the firmware of the device, should assume that a similar piece of malware may appear in the future.

The application allows users to change their passwords; however, the new password that is chosen remains in memory, even after the application is locked. This can allow an attacker that has gained access to the device to dump the application memory and retrieve the user's password. This finding was confirmed during testing by running debugserver on the iOS device and lldb on the local testing machine.

Remediation Procedure¶

Data written to the heap using the String object will only be wiped from memory when garbage collection is performed by the JVM. It is recommended that sensitive data is not stored using the String object and instead char arrays should be utilized. The data in memory should also be overwritten with random data when the application timeout is reached.

Sensitive Data stored in Application Binary¶

Overview¶

The application binaries contain valid KerberosIDs (e.g. landonf) in multiple locations. It is possible to extract the information by using the 'strings' command-line utility on each of the binaries. An attacker can use the extracted information (e.g. ID and folder structure) for targeted phishing attacks against employees.

Remediation Procedure¶

The Lagoon framework team should ensure that the production version (i.e. release) of the binaries do not contain sensitive information such as a KerberosID.

Insecure Crypto Implementation¶

Overview¶

Remediation Procedure¶

Android Backup Flag Enabled¶

Overview¶

When the 'android:allowBackup' flag is set to true within the 'AndroidManifest.xml' file, it is possible to backup private data stored within the application directory by simply plugging the device into a PC and using ADB (Android Debug Bridge) tools to initiate the backup process. It should be noted that the user does not need to have root access in order to copy private data off of the device when the 'android:allowBackup' flag is enabled. This may allow an attacker (with physical access to the device) to exfiltrate private data stored in the application directory.

References:
http://developer.android.com/reference/android/app/backup/BackupManager.html#attr_android:allowBackup

Remediation Procedure¶

The 'android:allowBackup' flag should be explicitly set to 'false'.

Encrypted Data Susceptible to Tampering¶

Overview¶

Encrypted data elements used by the Browser application are not protected from tampering attacks. Encryption algorithms such as Triple DES and AES are designed to protect the confidentiality of information, but do not specifically protect against manipulation or tampering of the underlying data. For cases where cipher text must also be protected from tampering attacks, consider using an additional data integrity mechanism such as a Hash-Based Message Authentication Code (HMAC). A properly generated HMAC, sometimes referred to as a keyed hash function, can be used to ensure the integrity of the encrypted ciphertext before decryption occurs.

Encryption algorithms using CBC mode without properly validating the integrity of the cipher text prior to decryption may be susceptible a "Padding Oracle" attack. Padding Oracle attacks can result in the ability to both decrypt any encrypted data and encrypt arbitrary data.

Refer to the following website for additional information on the "Padding Oracle" attack
- http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html

Remediation Procedure¶

The encrypted ciphertext should be coupled with an HMAC to authenticate the encrypted payload before decryption (commonly referred to as authenticated encryption). The HMAC is a keyed hash that can be used to verify the integrity of the payload and detect if an adversary has potentially tampered with the encrypted data. The HMAC should b

Application caches HTTP Requests and Responses¶

Overview¶

Remediation Procedure¶

OKHttp or another HTTP library caches sensitive data on the phone. The HTTP libraries usually cache this data biased on the Cache Header in the Response by default.

Either Set OKHttp to not cache data. An example of overwriting the server Cache Header to disable Storing the Request and Response can be seen below.

@Test
public void whenSendPostRequest_thenCorrect() 
  throws IOException {
    RequestBody formBody = new FormBody.Builder()
      .add("username", "test")
      .add("password", "test")
      .build();
 
    Request request = new Request.Builder()
      .url(BASE_URL + "/users")
      .cacheControl(CacheControl.FORCE_NETWORK)
      .post(formBody)
      .build();
 
    Call call = client.newCall(request);
    Response response = call.execute();
     
    assertThat(response.code(), equalTo(200));
}

Application caches NSUrlConnection Responses¶

Overview¶

When making HTTP requests through the NSURLConnection method, the client application caches HTTP responses from the server. Any sensitive data contained in these responses is written to disk and may be susceptible to offline attacks.

Remediation Procedure¶

This can be fixed by adding setting the proper cache headers for sensitive data if that data is from a server you control.
If you do not control the server than implementing the connection:willCacheResponse: method and have it return nil to prevent response caching.

ObjectiveC Example:

- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse*)cachedResponse {
    // Return nil to indicate not necessary to store a cached response for this connection
    return nil;
}

Android Application Code Not Obfuscated¶

Overview¶

Mobile code for sensitive portions of the application are not obfuscated. This can facilitate reverse engineering of application logic from decompiled Dex byte code using publicly available tools. Code obfuscation increases the level of effort required to reverse engineer application logic and should be used as part of an overall defense-in-depth strategy.

Remediation Procedure¶

Consider obfuscating all possible code deployed to end user systems. Obfuscation of Android byte code and Cordova code should not be relied upon as a primary security defense mechanism; however, it can provide a secondary defense mechanism to help prevent reverse engineering of application behavior. Ideally, the obfuscation method used should perform both code and data flow obfuscation. The following solutions are available for Android applications:

• Proguard - http://proguard.sourceforge.net - Free solution that provides a decent bare minimum for obfuscated Java byte code and support for Cordova
• Dexguard - http://www.saikoa.com/dexguard - Affordable commercial solution with additional obfuscation and anti-tampering within Android applications

Lack of URL Whitelisting in Cordova¶

Overview¶

The Apache Cordova application has not been properly configured to whitelist specific URLs for content loading. Any data that is injected into the application either server side or via locally modified files will be executed and rendered on the mobile device. This is especially dangerous when the application itself executes in a JavaScript container that has a native binding layer. This effectively gives an attacker remote code execution abilities on the mobile device itself within the context of the application.

Remediation Procedure¶

Edit the Cordova config.xml file to restrict allowed URLs to only those associated with the domain.

Example:

<allow-navigation href="*.example.com" />