Some Platform Security Report
For Internal Purpose
Prepared For: com.foo.bar

Prepared by XYSec Labs Pte. Ltd. Portions of this document and the templates used in its production are the property of XYSec Labs Pte. Ltd. and cannot be copied without permission.

While precautions have been taken in the preparation of this document, XYSec Labs Pte. Ltd., the publisher, and the author(s) assume no responsibility for errors, omissions, or for damages resulting from the use of the information contained herein. Use of XYSec Labs Pte. Ltd. services does not guarantee the security of a system, or that intrusions will not occur.

Application Details
Application Namecom.foo.bar
PlatformSome Platform
Application Namespacecom.foo.bar
Version1.0
Audit Date2017-03-03 09:17:31.568149+00:00
Application SHA1 Hashd5341a898eb1d1e90a316d49e8f6b4f33ad08cf0
Application MD5 Hash97d83c689f2cb0118e1901054165e8fe

Table Of Contents

Report Summary
Audit Summary
Appknox Security Rating
Do not release apps that are debuggable
Noncompliant Code Example
Compliant Solution
Business Implication
Related Vulnerabilities
Do not release apps that are debuggable
Noncompliant Code Example
Compliant Solution
Business Implication
Related Vulnerabilities

Report Summary

Appknox conducted a security assessment of the mobile application for the Some Platform platform. This report contains all the findings during the automated auditing process. It also contains the process of discovering those vulnerabilities in the first place, and ways to remediate those issues.

Audit Summary
Application Debug Enabled

Debugging was enabled on the app which makes it easier for reverse engineers to hook a debugger to it. This allows dumping a stack trace and accessing debugging helper classes.

High Risk
Application Debug Enabled

Debugging was enabled on the app which makes it easier for reverse engineers to hook a debugger to it. This allows dumping a stack trace and accessing debugging helper classes.

High Risk
Priority LevelNumber of failed test cases
High Risk10
Medium Risk7
Low Risk8
Appknox Security Rating

Appknox Security Rating: 50.5% Unsecured

Do not release apps that are debuggable

Android allows the attribute android:debuggable to be set to true so that the app can be debugged. By default this attribute is disabled, i.e., it is set to false, but it may be set to true to help with debugging during development of the app. However, an app should never be released with this attribute set to true as it enables users to gain access to details of the app that should be kept secure. With the attribute set to true, users can debug the app even without access to its source code.

Risk Rating : High
Risk Assessment

Debugging was enabled on the app which makes it easier for reverse engineers to hook a debugger to it. This allows dumping a stack trace and accessing debugging helper classes.

This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/q;->b
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->a
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->d
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->f

Debug was enabled on the app which make it easier for attackers to hook a debugger, dump a stack trace and access debugging helper classes.

<application android:debuggable='true' Debug enabled for app
Noncompliant Code Example

This non-compliant code example shows an app that has the android:debuggable attribute set to true being accessed to reveal sensitive data.

$ adb shell
shell@android:/ $ run-as com.example.someapp sh
shell@android:/data/data/com.example.someapp $ id
uid=10060(app_60) gid=10060(app_60)
shell@android:/data/data/com.example.someapp $ ls files/
secret_data.txt
shell@android:/data/data/com.example.some $ cat files/secret_data.txt
password=GoogolPlex
account_number=31974286

Clearly, with the android:debuggable attribute set to true, sensitive date related to the app can be revealed to any user.

Compliant Solution

Ensure that the android:debuggable attribute is set to false before the app is released:

android:debuggable="false"

Note that some development environments (including Eclipse/ADT and Ant) automatically set android:debuggable to true for incremental or debugging builds but set it to false for release builds.

Business Implication

With Cordova 3.5.0 or prior, attackers may:

Para2 With Cordova 3.5.0 or prior, attackers may:

  • Open and send data to arbitrary applications.
  • Bypass the HTTP whitelist and connect to arbitrary servers.
  • Change the start page via a crafted intent URL.
Related Vulnerabilities

With Cordova 3.5.0 or prior, attackers may:

Para2 With Cordova 3.5.0 or prior, attackers may:

  • Open and send data to arbitrary applications.
  • Bypass the HTTP whitelist and connect to arbitrary servers.
  • Change the start page via a crafted intent URL.

Do not release apps that are debuggable

Android allows the attribute android:debuggable to be set to true so that the app can be debugged. By default this attribute is disabled, i.e., it is set to false, but it may be set to true to help with debugging during development of the app. However, an app should never be released with this attribute set to true as it enables users to gain access to details of the app that should be kept secure. With the attribute set to true, users can debug the app even without access to its source code.

Risk Rating : High
Risk Assessment

Debugging was enabled on the app which makes it easier for reverse engineers to hook a debugger to it. This allows dumping a stack trace and accessing debugging helper classes.

This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/q;->b
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->a
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->d
This application opens a socket and connects to it, which might be insecured, defined at Lcom/e/a/a/a/p;->f

Debug was enabled on the app which make it easier for attackers to hook a debugger, dump a stack trace and access debugging helper classes.

<application android:debuggable='true' Debug enabled for app
Noncompliant Code Example
  1. Facebook SDK for Android contained the following code which sends Facebook access tokens to log output in plain text format.

    Log.d("Facebook-authorize", "Login Success! access_token=" + getAccessToken() + " expires=" + getAccessExpires());

  2. Here is another example. A weather report for Android sent a user's location data to the log output as follows:

    I/MyWeatherReport( 6483): Re-use MyWeatherReport data I/ ( 6483): GET JSON: http://example.com/smart/repo_piece.cgi?arc=0&lat=26.209026&lon=127.650803&rad=50&dir=-999&lim=52&category=1000

    If a user is using Android OS 4.0 or before, other applications with READ_LOGS permission can obtain the user's location information without declaring ACCESS_FINE_LOCATION permission in the manifest file.

Compliant Solution

Ensure that the android:debuggable attribute is set to false before the app is released:

android:debuggable="false"

Note that some development environments (including Eclipse/ADT and Ant) automatically set android:debuggable to true for incremental or debugging builds but set it to false for release builds.

Business Implication

With Cordova 3.5.0 or prior, attackers may:

Para2 With Cordova 3.5.0 or prior, attackers may:

  • Open and send data to arbitrary applications.
  • Bypass the HTTP whitelist and connect to arbitrary servers.
  • Change the start page via a crafted intent URL.
Related Vulnerabilities