Knowledge Base

List of JNI methods

Risk: info

Description

Java Native Interface (JNI) allows Java code to interact with native applications and libraries written in Rust, C, C++ and assembly.

Improper use of the Java Native Interface renders the application vulnerable to security flaws present in other programming languages, like memory corruption.

Recommendation

Native code must adhere to Secure Coding best practices to protect against vulnerabilities in unmanaged code like memory corruption.

APK attack surface

Risk: info

Description

List of componenets potentially accepting user input:

  • service: Service.
  • activity: Activity.
  • reciver: Broadcast Receiver
  • provider: Content Provider

Recommendation

This entry is informative, no recommendations applicable.

Backup mode enabled

Risk: potentially

Description

Android performs by default a full backup of applications including the private files stored on /data partition. The Backup Manager service uploads those data to the user's Google Drive account.

Recommendation

if the application contains sensitive data that you don't want to be restored, you can disable backup mode by setting the attribute android:allowBackup to false in the application tag.

Application certificate information

Risk: info

Description

List of all information related to the application signing certificate.

Recommendation

This entry is informative, no recommendations applicable.

Application signed with an expired certificate

Risk: medium

Description

The Application signing certificate has expired.

Recommendation

You need to re-sign your app with a valid certificate, otherwise, users will not be able to install it from an App Catalog

Application checks rooted device

Risk: info

Description

Presence of strings and methods indicating potential check for rooted device

Recommendation

This entry is informative, no recommendations applicable.

Classes list

Risk: info

Description

List of all Java classes declared in the application.

Recommendation

This entry is informative, no recommendations applicable.

Application components list

Risk: info

Description

List of all the components used in the application.

Recommendation

This entry is informative, no recommendations applicable.

Hardcoded strings list

Risk: info

Description

List of all hardcoded strings used in the application.

Recommendation

This entry is informative, no recommendations applicable.

Debug mode enabled

Risk: high

Description

The application is compiled with debug mode enabled. This allows attackers to access the application filesystem and attach a debugger to access sensitive data or perform malicious actions.

For instance attach a Java (JDWP) debugger:

$adb forward tcp:7777 jdwp:$(adb shell ps | grep "package-id")
$jdb -attach localhost:7777

To access the applicatin filesystem:

$adb shell
$run-as package-id
$...insert malicious action...

Attacker can debug the application without access to source code and leverage it to perform malicious actions on behalf ot the user, modify the application behavior or access sensitive data like credentials and session cookies.

Recommendation

Disable debug mode by setting the attribute android:debuggeable to false in the application tag.

<application android:icon="@drawable/icon" android:debuggable="false">

Exported activites, services and broadcast receivers list

Risk: important

Description

List of all exported components in the application. Exported component are accessible to external applications and present an entry point to the application.

Recommendation

This entry is informative, no recommendations applicable.

Exported activites, services and broadcast receivers list

Risk: important

Description

List of all exported components in the application. Exported component are accessible to external applications and present an entry point to the application.

Recommendation

This entry is informative, no recommendations applicable.

ELF binaries do not enforce secure binary properties

Risk: medium

Description

RELRO: RELRO is a memory protection technique to harden against memory corruption exploitation techniques. RELRO prevents GOT overwrite attacks.

ASLR: ASLR is a memory protection technique to harden against memory corruption exploitation technique. ASLR randomizes the address space of binary to prevent controlled address jumps.

No eXecute: Mark memory region as non-executable to harden against memory corruption exploitation technique.

Stack canary: Add a canary to memory that gets overwritten in the case of a memory corruption. The canary is checked at runtime to prevent the exploitation of the memory corruption vulnerability.

Recommendation

If Stack canary is missing, Compilers such as GCC enable this feature if requested through compiler options:

  • -fstack-protector: Check for stack smashing in functions with vulnerable objects. This includes functions with buffers larger than 8 bytes or calls to alloca.
  • -fstack-protector-strong: Like -fstack-protector, but also includes functions with local arrays or references to local frame addresses.
  • -fstack-protector-all: Check for stack smashing in every function.

Exported activites, services and broadcast receivers list

Risk: important

Description

List of all exported components in the application. Exported component are accessible to external applications and present an entry point to the application.

Recommendation

This entry is informative, no recommendations applicable.

Keywords exposed in logs

Risk: medium

Description

Recommendation

This entry is informative, no recommendations applicable.

Implementation of a FileObserver

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Insecure file system persistence

Risk: medium

Description

Recommendation

This entry is informative, no recommendations applicable.

Insecure file system permissions

Risk: high

Description

Recommendation

This entry is informative, no recommendations applicable.

APK files list

Risk: info

Description

APK files are an archive file in ZIP format based on the JAR file format. The APK file usually contains the following directories:

  • META-INF directory:
    • MANIFEST.MF: the manifest file
    • CERT.RSA or CERT.DSA: the certificate of the application
    • CERT.SF: list of ressources and SHA-1 digest
  • lib: directory containing compiled code. The directory is split into more directories for each processor architecture (x86, x86_64, armeabi, arm64-v8a ...)
  • res: directory containing not compiled resources
  • assets: directory containing application assets
  • AndroidManifest.xml: binary XML file describing the application (permissions, version, libraries ...)
  • classes.dex: file in the DEX file format containing compiled Java code
  • resources.arsc: file containing precompiled resources

Recommendation

This entry is informative, no recommendations applicable.

Hardcoded SQL queries list

Risk: info

Description

List of all hardcoded SQL queries constant strings in the application.

Recommendation

This entry is informative, no recommendations applicable.

Hardcoded urls list

Risk: info

Description

List of all hardcoded URLs constant strings in the application.

Recommendation

This entry is informative, no recommendations applicable.

Abuse of mobile network connection

Risk: medium

Description

The download manager is a system service that handles long-running HTTP downloads. The application should not force using only the mobile network connection

Recommendation

The application should allow the users to use either the Wi-Fi or a mobile network connection. A common strategy for apps is to only fetch large data if a Wi-Fi network is available.

Command Injection

Risk: high

Description

Command injection is an attack in which the goal is execution of arbitrary commands on the Android operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to the system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

Recommendation

The application should allow the users to use either the Wi-Fi or a mobile network connection. A common strategy for apps is to only fetch large data if a Wi-Fi network is available.

Insecure Network Configuration Settings

Risk: medium

Description

Android Network Security Configuration enables a declarative setting of the application network security.

The features enable configuring:

  • Custom Certificate Authority with support for debug only settings
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>
  • Declarative opt-out for cleartext traffic
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">secure.example.com</domain>
    </domain-config>
</network-security-config>
  • Declartive setting of certificate pinning keys
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Recommendation

It is strongly recommended to add a Network Security Configuration settings enabling encrypted traffic only.

Use of a custom Certificate Authority with certificate pinnging increases the security of you application and is recommended for security sensitive application.

Android Class Load Hijacking

Risk: medium

Description

The applications loads jar/apk stored in an insecure location.

This load process can be hijacked, allowing access to private data and unexpected arbitrary code execution by malicious applications

Recommendation

If you use DexClassLoader to load and execute additional DEX code:

  • Do NOT use a world-writable directory (such as the SD card) for the dexPath
  • Do NOT use a world-writable directory (such as the SD card) for the ODEX (optimized DEX which is the second paramter of the DexClassLoader constructor)

If you use PathClassLoader to load and execute additional jar/resources:

  • Do NOT use a world-writable directory (such as the SD card) for the path
  • Do NOT use a world-writable directory (such as the SD card) for the libpath. By default, the external storage is mounted with the noexec flag to prevent the execution of any native binaries on the mounted file system.

Unused permissions (overprivileged)

Risk: low

Description

The application requests permissions, but never uses the resource granted.

Recommendation

Remove unused permissions

Declared permissions list

Risk: info

Description

To protect the system's integrity and the user's privacy, Android runs each app in a limited access sandbox.

If the app wants to use resources or information outside of its sandbox, the app has to explicitly request permission.

Depending on the type of permission the app requests, the system may grant the permission automatically, or the system may ask the user to grant the permission.

Recommendation

This entry is informative, no recommendations applicable.

Android Manifest

Risk: info

Description

The manifest file presents essential information about your app to the Android system, information the system must have before it can run any of the app's code. Among other things, the manifest does the following:

  • It names the Java package for the application. The package name serves as a unique identifier for the application.
  • It describes the components of the application - the activities, services, broadcast receivers, and content providers that the application is composed of.It names the classes that implement each of the components and publishes their capabilities (for example, which Intent messages they can handle).These declarations let the Android system know what the components are and under what conditions they can be launched.
  • It determines which processes will host application components.
  • It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
  • It also declares the permissions that others are required to have in order to interact with the application's components.
  • It lists the Instrumentation classes that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they're removed before the application is published.
  • It declares the minimum level of the Android API that the application requires.
  • It lists the libraries that the application must be linked against.

Recommendation

This entry is informative, no recommendations applicable.

Application code not obfuscated

Risk: medium

Description

Obfuscation refers to methods to obscure code and make it hard to understand. Compiled Java classes can be decompiled if there is no obfuscation during compilation step.

Adversaries can steal code and repurpose it and sell it in a new application or create a malicious fake application based on the initial one.

Code obfuscation only slows the attacker from reverse engineering but does not make it impossible.

Recommendation

Design the application to add the following protections and slow reverse engineering of the application:

  • Obfuscate Java source code with tools like Proguard or Dexguard
    buildTypes {
            release {
                minifyEnabled true
                proguardFiles getDefaultProguardFile('proguard-android.txt'),
                'proguard-rules.pro'
            }
        }
  • Verification application signing certificate during runtime by checking context.getPackageManager().signature
  • Check application installer to ensure it matches the Android Market by calling context.getPackageManager().getInstallerPackageName
  • Check running environment at runtime
    private static String getSystemProperty(String name) throws Exception {
        Class systemPropertyClazz = Class.forName("android.os.SystemProperties");
        return (String) systemPropertyClazz.getMethod("get", new Class[] { String.class }).invoke(systemPropertyClazz, new Object[] { name });
    }
    
    public static boolean checkEmulator() {
    
        try {
            boolean goldfish = getSystemProperty("ro.hardware").contains("goldfish");
            boolean qemu = getSystemProperty("ro.kernel.qemu").length() > 0;
            boolean sdk = getSystemProperty("ro.product.model").equals("sdk");
    
            if (qemu || goldfish || sdk) {
                return true;
            }
    
        } catch (Exception e) {
        }
    
        return false;
      }
  • Check debug flag at runtime
    context.getApplicationInfo().applicationInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE;

Obfuscated methods

Risk: info

Description

Obfuscation refers to methods to obscure code and make it hard to understand. Compiled Java classes can be decompiled if there is no obfuscation during compilation step.

Adversaries can steal code and repurpose it and sell it in a new application or create a malicious fake application based on the initial one.

Code obfuscation only slows the attacker from reverse engineering but does not make it impossible.

Recommendation

Design the application to add the following protections and slow reverse engineering of the application:

  • Obfuscate Java source code with tools like Proguard or Dexguard
buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } }
  • Verification application signing certificate during runtime by checking context.getPackageManager().signature
  • Check application installer to ensure it matches the Android Market by calling context.getPackageManager().getInstallerPackageName
  • Check running environment at runtime
    private static String getSystemProperty(String name) throws Exception {
        Class systemPropertyClazz = Class.forName("android.os.SystemProperties");
        return (String) systemPropertyClazz.getMethod("get", new Class[] { String.class }).invoke(systemPropertyClazz, new Object[] { name });
    }
    
    public static boolean checkEmulator() {
    
        try {
            boolean goldfish = getSystemProperty("ro.hardware").contains("goldfish");
            boolean qemu = getSystemProperty("ro.kernel.qemu").length() > 0;
            boolean sdk = getSystemProperty("ro.product.model").equals("sdk");
    
            if (qemu || goldfish || sdk) {
                return true;
            }
    
        } catch (Exception e) {
        }
    
        return false;
      }
  • Check debug flag at runtime
    context.getApplicationInfo().applicationInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE;

Services declared without permissions

Risk: potentially

Description

service is an application component that can take care of actions to be done in the background, without user interaction. service can also be used to expose functionalities to other applications. This corresponds to calls to Context.bindService() to establish a connection to the service and interact with it.

Unprotected services can be invoked by other applications and potentially access sensitive information or perform privileged actions

Recommendation

service can expose several methods to external componenets. It is possible to define arbitrary permissions for each method using the method checkPermission.

It is also possible to seperate services and restrict access by enforcing permissions in the manifest's <service> tag.

<permission android:name="co.ostorlab.custom_permission" android:label="custom_permission" android:protectionLevel="dangerous"></permission>

<service android:name="co.ostorlab.custom_service" android:permission="co.ostorlab.custom_permission">
    <intent-filter>
        <action android:name="co.ostorlab.ACTION" />
    </intent-filter>
</service>

The service can enforce permissions on individual IPC calls by calling the method checkCallingPermissionbefore executing the implementation of that call.

Decompiled source code

Risk: important

Description

Decompiled source of the application using standard open-source applications.

Recommendation

This entry is informative, no recommendations applicable.

Implementation of a WebViewClient

Risk: info

Description

List of Webview client implementations.

Recommendation

This entry is informative, no recommendations applicable.

AWS sensitive information hardcoded in the application

Risk: high

Description

AWS credentials hardcoded in the application

  • CWE-259 - Use of Hard-coded Password: The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.

Recommendation

Instead of hardcoding credentials in your apps, apply procedures to securely encrypt, store, and retrieve credentials for your services. You can for example use AWS Secrets Manager to encrypt and retrieve your credentials whenever needed

Backend Stacks

Risk: info

Description

List of technologies used in the backend

Recommendation

This entry is informative.

Binary disassembly

Risk: info

Description

Disassmbly of listed binaries.

Recommendation

This entry is informative, no recommendations applicable.

Apache Cordova Framework detected

Risk: info

Description

Apache Cordova is an open-source mobile development framework that uses web technologies such as HTML5, CSS3, and JavaScript to build cross-platform mobile applications.

Cordova Framework allows access of most functionnalities through Javascript and could be extended thorough native plugins to add more complex features.

Recommendation

This entry is informative, no recommendations applicable.

Apache Cordova < 4.1.1 suffers from multiple vulnerabilities

Risk: high

Description

Apache Cordova below version 4.1.1 suffers from multiple vulnerabilties:

  • CVE-2015-5256: Android applications created using Apache Cordova that use a remote server contain a vulnerability where whitelist restrictions for urls using protocols http and https are not properly applied. Whitelist cannot block network redirects from a whitelisted remote website to a non-whitelisted website.
  • CVE-2015-1835: Android applications built with the Cordova framework that don't have explicit values set in Config.xml can have undefined configuration variables set by Intent. This can cause unwanted dialogs appearing in applications and changes in the application behaviour that can include the app force-closing.

Recommendation

Migrate the application to Cordova 4.1.1 or higher.

Cordova Cross-Site Scripting (XSS)

Risk: high

Description

Mobile Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted content. XSS attacks occur when an attacker can inject malicious code through:

  • Untrusted Inter-Process Communication (IPC) input
  • Man-in-the-Middle attack
  • Untrusted content stored on the webserver application
  • Untrusted local file input

Example script to test presence of XSS

<script>alert("Ostorlab XSS!")</script>
<img src="http://ostorlab.co/js_xss2" onerror=alert(document.cookie);>

XSS vulnerabilties for Cordova applications are critical as they allow access to native functionality on the target phone and could lead to unauthorized access to contacts, messages, camera, audio and location.

Recommendation

The application must validate all provided input and use secure HTML formating API. The recommended approach is defining a list of acceptable characters and allow only those characters. Acceptable characters would be upper case letters, lower case letters, and numbers (i.e. a-z, A-Z, and 0-9).

Frameworks offer methods to validate input and prevent XSS vulnerabilities and modern frameworks (Angular JS 2, React JS) automatically escapes user input:

To escape input using Sencha Ext JS, the following methods could be used:

  • Ext.util.Format.stripTags
  • Ext.util.Format.stripScripts
  • Ext.util.Format.htmlEncode/Decode

Insecure Cross-Origin Resource Sharing (CORS) policy

Risk: high

Description

Cross-Origin Resource Sharing (CORS) uses HTTP headers to let a web client gain access resources from a server on a different domain. Browsers restrict cross-origin HTTP requests initiated from within scripts for security purposes.

If another domain is allowed by the policy, then that domain can attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can retrieve content from the application, and carry out actions within the security context of the logged in user.

Recommendation

CORS is an appropriate choice for cross domain sharing, access must be however restricted to authorized domains only, particularly if Access-Control-Allow-Credentials is enabled.

All unauthorized domains must be restricted in addition to domains that allows running untrusted code like jsfiddle.com.

Cryptographic Vulnerability: Insecure Algorithm

Risk: medium

Description

The mode of operation used to encrypt the data is vulnerable

Recommendation

We recommend AES for general-purpose use. If you're willing to go against the grain and are paranoid, you can use Serpent, which isn't quite as fast as AES but is believed to have a much higher security margin.

If you really feel that you need the fastest possible secure solution, consider the SNOW 2.0 stream cipher, which currently looks very good. It appears to have a much better security margin than the popular favorite, RC4, and is even faster. However, it is fairly new. If you're highly risk-adverse, we recommend AES or Serpent. Although popular, RC4 would never be the best available choice.

Cryptographic Vulnerability: Hardcoded key

Risk: medium

Description

The data is encrypted using a weak key

Recommendation

We recommend AES for general-purpose use. If you're willing to go against the grain and are paranoid, you can use Serpent, which isn't quite as fast as AES but is believed to have a much higher security margin.

If you really feel that you need the fastest possible secure solution, consider the SNOW 2.0 stream cipher, which currently looks very good. It appears to have a much better security margin than the popular favorite, RC4, and is even faster. However, it is fairly new. If you're highly risk-adverse, we recommend AES or Serpent. Although popular, RC4 would never be the best available choice.

Cryptographic Vulnerability: Insecure mode

Risk: medium

Description

The algorithm used to encrypt the data is vulnerable. If AES is used without specifying the mode, the default mode is the insecure ECB mode.

Recommendation

We recommend AES for general-purpose use. If you're willing to go against the grain and are paranoid, you can use Serpent, which isn't quite as fast as AES but is believed to have a much higher security margin.

If you really feel that you need the fastest possible secure solution, consider the SNOW 2.0 stream cipher, which currently looks very good. It appears to have a much better security margin than the popular favorite, RC4, and is even faster. However, it is fairly new. If you're highly risk-adverse, we recommend AES or Serpent. Although popular, RC4 would never be the best available choice.

Use non-random initialization vector (IV)

Risk: medium

Description

Use of a non-random initialization vector makes the application vulnerable to dictionary attacks.

The following example demonstrates improper settings of hardcoded static IV:

public class InsecureExample {
    @Override
    public void run() throws Exception{
        byte[] IV = "0123456789abcdef".getBytes();
        String clearText = "Jan van Eyck was here 1434";
        String key = "ThisIs128bitSize";
        SecretKeySpec skeySpec = new SecretKeySpec(key.getBytes(), "AES");
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, skeySpec, new IvParameterSpec(IV));
        byte[] encryptedMessage = cipher.doFinal(clearText.getBytes());
        Log.i(TAG, String.format("Message: %s", Base64.encodeToString(encryptedMessage, Base64.DEFAULT)));
    }
}

Recommendation

Properly initialize the IV with a secure random value

Call to Android Security API

Risk: info

Description

List of all API calls to the Android Keystore and Keychain API.

Recommendation

This entry is informative, no recommendations applicable.

Call to Crypto API

Risk: info

Description

List of all calls to cryptographic methods.

Recommendation

Do not use insecure or weak cryptographic algorithms. For example, the Data Encryption Standard (DES) encryption algorithm is considered highly insecure

Do not use Object.equals() to compare cryptographic keys

Cryptographic keys should never be serialized

Call to delete file API

Risk: info

Description

Call to file.delete() do not securely erase the file unless overwritten. Due to way NAND manages block allocation, traditional file overwriting approaches are inefficient.

Recommendation

This entry is informative, no recommendations applicable.

Call to dynamic code loading API

Risk: info

Description

List of all dynamic code loading API calls in the application. Loading code from untrsuted sources could allow the execution of malicious code in the context of the current application.

Recommendation

This entry is informative, no recommendations applicable.

Call to command execution API

Risk: info

Description

List of all command execution API calls

Recommendation

This entry is informative, no recommendations applicable.

Call to External Storage API

Risk: info

Description

List of all external storage API calls. Insecure storage of sensitive information by setting insecure permissions or storing data without encryption might expose this information to an attacker.

Recommendation

This entry is informative, no recommendations applicable.

Call to Inter-Process-Communication (IPC) API

Risk: info

Description

List of all calls to Android IPC API.

Recommendation

This entry is informative, no recommendations applicable.

Call to logging API

Risk: info

Description

List of all logging API calls in the application.

Recommendation

This entry is informative, no recommendations applicable.

Call to native methods

Risk: info

Description

List of all calls to methods using Java Native Interface to interact with native code (written in C/C++).

Recommendation

Data passed to NewStringUTF must be in Modified UTF-8 format

UTF-16 strings are not zero-terminated

Object references should never be compared using == or != in native code. When testing for object equality, the IsSameObject() function should be used instead of ==.

Call to Random API

Risk: info

Description

List of all calls to methods that return pseudo-random values.

Recommendation

Do not seed Random with the current time because that value is more predictable to an attacker than the default seed.

The java.util.Random class must not be used either for security-critical applications or for protecting sensitive data. Use a more secure random number generator, such as the java.security.SecureRandom class.

Call to Reflection API

Risk: info

Description

List of calls allowing the application to examine and modify the structure and behavior of an object at runtime.

Recommendation

This entry is informative, no recommendations applicable.

addJavaScriptInterface Remote Code Execution.

Risk: high

Description

The addJavascriptInterface() method on API level JELLY_BEAN or below can be abused via reflection to execute commands remotely in the context of the running application

The addJavascriptInterface method exposes a supplied Java object from within a WebView to JavaScript. For applications compiled or linked against and API level less than 17; all public methods (including the inherited ones) can be accessed. Through the use of reflection it is also possible to invoke any other unregistered Java class.

Recommendation

This issue has been resolved in applications developed for Android 4.2 (API level 17) and above. Starting from Android 4.2 (API level 17) and above, only methods explicitly marked with the @JavascriptInterface annotation are available to JavaScript code within the WebView. The @JavascriptInterface annotation must be added to any method that is intended to be exposed via the native bridge (the method must also be public). An example is presented below:

    @JavascriptInterfacepublic void method() {dostuff();}

To resolve the issue, you need to build you application for API 17 or above and redistribute it. The users would need to upgrade their applications to use the new non-vulnerable application.

Call to Socket API

Risk: info

Description

List of all calls to Server Socket API.

Recommendation

This entry is informative, no recommendations applicable.

Call to SQLite query API

Risk: info

Description

Improper SQL query construction could lead to SQL injection. An SQL injection attack consists of injecting of an SQL query via the input data from the client to the application

Recommendation

This entry is informative, no recommendations applicable.

Call to SSL/TLS API

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Call to dangerous WebView settings API

Risk: info

Description

List of all WebView methods used in the application.

Recommendation

If your application accesses sensitive data with a WebView, you may want to use the clearCache() method to delete any files stored locally.

Any URI received via an intent from outside a trust-boundary should be validated before rendering it with WebView

Call to XML parsing API

Risk: info

Description

Improper XML parsing could lead to several vulnerabilities which could to arbitrary file access (External XML Entities injection, XML injection) or denial of service (Billion laughs, quadratic blowup).

Recommendation

This entry is informative, no recommendations applicable.

Call to ZIP API

Risk: info

Description

List of all ZIP handling API.

Recommendation

This entry is informative, no recommendations applicable.

Expansion APK enabled

Risk: info

Description

For applications with more than 100MB, using expansion files can be a good alternative to store additional APK assets.

The application can have two expansion files and each expansion file can be up to 2GB in size.

Unlike APK files, any files saved on the shared storage can be read by the user and other applications.

Recommendation

This entry is informative, no recommendations applicable.

External DNS interaction

Risk: potentially

Description

User-controlled parameters has resulted in triggering a server side DNS request. The ability to control server-side is not a vulnerability, however it is a serious indication of potential high risk vulnerability.

An attacked may leverage this functionality to send requests to remote systems for denial of service attacks or to remotely exploit potential vulnerabilities. It is also potentially possible to access internal systems protected with external network filtering.

Recommendation

Server-side triggered DNS requests might be an intended behavior, it is recommended to review the purpose of the service and evaluate the potential risks, like the participation in distributed denial of service (DDoS) attack, and interaction with remote services,

If this functionality is not an intended behavior, it is recommended to disable the service if possible or enforce whitelist-based filtering blocking all unauthorized domains.

Ext JS Framework detected

Risk: info

Description

ExtJS is a JavaScript framework for building rich UI application.

Recommendation

  • Don't use eval() unless you know what you're doing.
  • Do not cache sensitive data
  • Validate all user input.
  • Use InAppBrowser for outside links.
  • Avoid Global Variables.

ImageMagick is a software suite to create, edit, compose, or convert bitmap images

Risk: info

Description

ImageMagick is a software suite to create, edit, compose, or convert bitmap images

Recommendation

This entry is informative, no recommendations applicable.

ImageMagick < 7.0.1-0 suffers from multiple vulnerabilities

Risk: high

Description

This vulnerability exploits a shell command injection in the way "delegates" (commands for converting files) are processed in ImageMagick versions <= 7.0.1-0 and <= 6.9.3-9 (legacy). Since ImageMagick uses file magic to detect file format, you can create a .png (for example) which is actually a crafted SVG (for example) that triggers the command injection. Tested on Linux, BSD, and OS X. You will want to choose your payload carefully due to portability concerns. Use cmd/unix/generic if need be.Module type : exploit Rank : excellent Platforms : Unix

Recommendation

Migrate the application to ImageMagick 7.0.1-1 or higher.

Call to command execution API

Risk: high

Description

Insecure command execution API calls

Recommendation

Android Class Loading Hijacking

Risk: high

Description

Android provides APIs that allow an application to dynamically load code to be executed. For example, an application may support plug-ins that are downloaded and then loaded at a later time. Unfortunately, if these plug-ins are stored in an insecure location, this process can be hijacked, allowing access to private data and unexpected arbitrary code execution by malicious applications

Two classes allow the loading of additional code:

    DexClassLoader (String dexPath, String dexOutputDir, String libPath, ClassLoader parent)
    PathClassLoader (String path, String libPath, ClassLoader parent)

Recommendation

When loading additional code in Android applications, a developer should ensure that both the loaded code and the generated alternative versions of the code are placed in a secured directory, typically within the application's private directory

Insecure password storage

Risk: high

Description

Insecure storage of password could lead to account compromise. The vulnerability is the result of storing password using insecure methods that are susceptible to unauthorized access or compromise.

The following example shows insecure storage of password credentials in cookies:

response.addCookie(new Cookie("password", password));

Recommendation

Mobile applications must use secure API to store credentials. Android applications may AccountManager to store account credentials. It also highly recommended for mobile application to use OAuth-based authentication to avoid storing credentials and prevent attacks like password reuse.

To implement OAuth-based authentication, Cordova application may use the jquery-cordova-oauth2 library. Android application may use AccountManager API and iOS application may use OAuth2Client library.

Insecure Filesystem Access

Risk: high

Description

The application handles files using insecure permissions (world readable or world writable).

World readable may present a risk if they store sensitive information that may present a risk if access by unauthorised party, like bank account statement or session key storage file.

World writable may present a risk if it is to perform sensitive actions, like URL list or session parameters.

Recommendation

Use of world access permissions should be used only when strictly required. Other means of sharing data between applications are recommended instead of sharing file using insecure permissions.

Insecure Shared Preferences Permissions

Risk: high

Description

Setting Shared Preferences with insecure permissions either world readable or world writable may expose sensitive information stored in shared preferences to arbitrary read or write by a malicious attacker.

Recommendation

Shared Preferences are XML files to store private primitive data in key-value pairs. Data Types include Booleans, floats, ints, longs, and strings.

Shared preferences must be set with the permission MODE_WORLD_READABLE, unless explicity required for sharing information across apps.

Insecure Random Seed

Risk: medium

Description

Random number generator is seeded using constant value which results in the generation of predictable numbers.

Recommendation

Do not seed Random with the current time because that value is more predictable to an attacker than the default seed.

The java.util.Random class must not be used either for security-critical applications or for protecting sensitive data. Use a more secure random number generator, such as the java.security.SecureRandom class.

Intent Spoofing

Risk: high

Description

The application is vulnerable to intent spoofing which could result in the access and exploitation of unauthorized components.

Recommendation

It is recommended to apply proper input validation and parameter filtering on intent action.

Automatic Reference Counting (ARC) not enforced

Risk: medium

Description

Automatic Reference Counting (ARC) is a memory managment that autmates objects managemnt by the compiler to unburden the developer.

Recommendation

Automatic Reference Counting (ARC) may be explicitly enabled with the compiler flag -fobjc-arc.

Address Space Layout Randomization (ASLR) not enforced

Risk: medium

Description

Address Space Layout Randomization (ASLR) is a memory protection that randomizes the layout space to to mitigate memory exploitation techniques.

Recommendation

Address Space Layout Randomization (ASLR) is enabled by default on XCode. Do not disable it

Mach-o files class dump

Risk: info

Description

Class, categories and protocols declarations.

Recommendation

This entry is informative, no recommendations applicable.

Mach-O encrypted

Risk: important

Description

Apps distributed by the AppStore are encrypted using an encryption scheme similar to the FairPlay DRM.

The encryption is specific to the device that retrieved the application from AppStore and can only be decrypted on that device.

Encrypted applications are impossible to analyze and will limit the scan results of Ostorlab.

Recommendation

Please provide an unencrypted application with tools like lldb-dumpdecrypted or Clutch.

Mach-O entitlements

Risk: info

Description

Entitlements are used to grant privileges to applications, like enabling Apple Pay, Push notifications, debugging privileges, running unsigned code, etc.

Reviewing this list to identify the application capabilities and attack surface.

Recommendation

This entry is informative, no recommendations applicable.

IPA files list

Risk: info

Description

IPA file is an iOS application archive in ZIP format. The IPA file usually contains the following directories:

  • Payload: directory containing all application data
  • iTunesArtwork and iTunesArtwork@2x: iTunes Artwork file containing the application's icon
  • iTunesMetadata.plist: file in binary PLIST file format describing the application (developpers's name and ID, bundle identifier, name ...)

Recommendation

This entry is informative, no recommendations applicable.

IPA Frameworks list

Risk: info

Description

List of Swift frameworks included in the application.

Recommendation

This entry is informative, no recommendations applicable.

Insecure App Transport Security (ATS) Settings

Risk: high

Description

App Transport Security (ATS) enforces best practices in the secure connections between an app and its back end. ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt; it is also on by default in iOS 9 and OS X v10.11. You should adopt ATS as soon as possible, regardless of whether you're creating a new app or updating an existing one.

  • NSAllowsArbitraryLoads: If set to YES, disables all ATS restrictions for all network connections, apart from the connections to domains that you configure individually in the optional NSExceptionDomains dictionary. Default value is NO.
  • NSAllowsArbitraryLoadsForMedia: If set to YES, disables all ATS restrictions for media that your app loads using the AV Foundation framework. Employ this key only for loading media that are already encrypted, such as files protected by FairPlay or by secure HLS, and that do not contain personalized information. Default value is NO.
  • NSAllowsArbitraryLoadsInWebContent: If set to YES, disables all ATS restrictions for requests made from web views. This lets your app use an embedded browser that can display arbitrary content, without disabling ATS for the rest of your app. Default value is NO.
  • NSExceptionAllowsInsecureHTTPLoads: If set to YES, allows insecure HTTP loads for the named domain, but does not change Transport Layer Security (TLS) requirements and does not affect HTTPS loads for the named domain. Default value is NO.
  • NSExceptionMinimumTLSVersion: Specifies the minimum TLS version for network connections for the named domain, allowing connection using an older, less secure version of Transport Layer Security.

Recommendation

If you're developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn't follow this requirement, an error is thrown. If your app needs to make a request to an insecure domain, you have to specify this domain in your app's Info.plist file.

IPA Plist files

Risk: info

Description

Property list files are files that store serialized objects. They often store users settings. They are also used to store information about bundles and applications.

Recommendation

This entry is informative, no recommendations applicable.

Stack smashing protection not enforced

Risk: medium

Description

Stack Smashing Protection is an exploit mitigation that helps detect buffer overflows being exploited and abort execution beforce malicious code is executed. This feature is implemented by selecting appropriate functions, storing a canary canary at the function prologue and checking the value at the epilogue

Recommendation

Eanble Stack Smashing Protection (SSP) by specifying the -fstack-protector-all compiler flag.

IPA symbol table

Risk: info

Description

List of Mach-o exported symbols.

Recommendation

This entry is informative, no recommendations applicable.

URL Scheme list

Risk: info

Description

URL schemes expose an attack surface that can be triggered by visiting a malicious website in Safari or from a malicious application. It is important that the application validates parameters and restricts actions permitted from the URL scheme.

Recommendation

This entry is informative, no recommendations applicable.

Personally Information were detected on the system

Risk: medium

Description

Personally Identifiable Information (PII) is, according to NIST Special Publication 800-122, a collective term for any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

Recommendation

  • Securely delete PII when there is no longer a business need for its retention on the device
  • Do not cache sensitive data
  • Minimize the frequency of asking for user credentials.
  • Minimize the use of APIs that access sensitive or personal user data
  • Consider a logical way to hash the user data
  • Some jurisdictions may require you to provide a privacy policy for accessing personal information.

Trace call from source to sinks

Risk: important

Description

Recommendation

This entry is informative, no recommendations applicable.

MoPub Framework detected

Risk: info

Description

MoPub is an ad server for mobile application publishers

Recommendation

This entry is informative, no recommendations applicable.

MoPub < 4.4.0 suffers from multiple vulnerabilities

Risk: medium

Description

MoPub is an ad server for mobile application publishersThe vulnerability is due to unsanitized default WebView settings. An attacker may exploit this vulnerability by serving a malicious JavaScript code in an advertising creative, making it possible to infer the existences of privacy-sensitive local resources on the devices. For Android devices with the prior versions of API 16, the attacker can even access local resources.

Recommendation

Migrate the application to MoPub 4.4.0 or higher.

Network Port Scan

Risk: info

Description

List of identified open ports which corresponds to the application internet facing attack surface.

Recommendation

This entry is informative, no recommendations applicable.

OpenSSL Vulnerabilities

Risk: high

Description

The OpenSSL version your are using in you app (or in a 3rd party library) contains a security vulnerability wich allows attackers to launch a Man-in-the-middle (MITM) attack to decrypt and modify traffic from the attacked client and server

Recommendation

Migrate your app to an updated version of OpenSSL as soon as possible and increment the version number of the upgraded APK

Use of Outdated Vulnerable Component

Risk: low

Description

The application is using an outdated component with publicly known vulnerabilities. Exploitation of this issue varies from easily accessbile off the shelf exploit to requiring custom exploit.

Recommendation

Update to the latest versions to fix the issue. It is also recommened to implement a patch management process to prevent future similar issues and remove all unused dependencies.

Remote Exploitation of the Cordova Framework

Risk: high

Description

Apache Cordova below version 3.5.0 suffers from multiple vulnerabilties:

  • Apache Cordova Android before 3.5.1 allows remote attackers to change the start page via a crafted intent URL
  • Phonegap whitelisting can be bypassed by an attacker by using Websockets through Webview
  • Apache Cordova Android before 3.5.1 allows remote attackers to bypass the HTTP whitelist and connect to arbitrary servers by using JavaScript to open WebSocket connections through WebView
  • Javascript can also be executed by loading a malicious site by starting an application with errorurl set to the malicious site
  • Phonegap whitelisting can be bypassed by an attacker. For example, if foo.com is whitelisted, foo.com.evil.com will pass the check.

Recommendation

Migrate the application to Cordova 3.5.1 or higher.

Cordova debug mode enabled

Risk: high

Description

"Phonegap application log is set to DEBUG, this may cause it to leak too much information to Android logs"

Recommendation

Disable debug mode

Insecure whitelist

Risk: medium

Description

The application's whitelist may be bypassed since the url may be used as a prefix to another domain. Eg: 127.0.0.1* may be bypassed by accessing the domain 127.0.0.1.badsite.net

Recommendation

Cordova offer a powerful security model to provide developers with the tools to prevent unauthorised access and Cross-Site Scripting vulnerabilities

Cordova whitelist manages network security access and must authorise explicitly accessible ressources only.

Insecure whitelist configuration

Risk: medium

Description

The application's whitelist allows unrestricted access to all ressources *.

Recommendation

Cordova offer a powerful security model to provide developers with the tools to prevent unauthorised access and Cross-Site Scripting vulnerabilities

Cordova whitelist manages network security access and must authorise explicitly accessible ressources only.

Calls to Privacy API

Risk: info

Description

Ostorlab Mobile Application Security Scanner checks multiple privacy features:

Telephony identifiers leakage:

  • The application reads the Location Area Code value.
  • The application reads the Cell ID value.
  • The application reads the phone's current state.
  • The application reads the current location of the device.
  • The application reads the type of activity on a data connection.
  • The application reads the current data connection state.
  • The application reads the unique device ID, i.e the IMEI for GSM and the MEID or ESN for CDMA phones.
  • The application reads the software version number for the device, for example, the IMEI/SV for GSM phones.
  • The application reads the phone number string for line 1, for example, the MSISDN for a GSM phone.
  • The application reads the neighboring cell information of the device.
  • The application reads the ISO country code equivalent of the current registered operator's MCC (Mobile Country Code).
  • The application reads the numeric name (MCC+MNC) of current registered operator.
  • The application reads the operator name.
  • The application reads the radio technology (network type) currently in use on the device for data transmission.
  • The application reads the device phone type value.
  • The application reads the ISO country code equivalent for the SIM provider's country code.
  • The application reads the MCC+MNC of the provider of the SIM.
  • The application reads the Service Provider Name (SPN).
  • The application reads the SIM's serial number.
  • The application reads the constant indicating the state of the device SIM card.
  • The application reads the unique subscriber ID, for example, the IMSI for a GSM phone.
  • The application reads the alphabetic identifier associated with the voice mail number.
  • The application reads the voice mail number.

Location lookup:

  • The application reads location information from all available providers (WiFi, GPS etc.).

Connection interfaces exfiltration:

  • The application reads details about the currently active data network.
  • The application tries to find out if the currently active data network is metered.
  • The application reads the WiFi credentials.

Telephony services abuse:

  • The application sends SMS messages.
  • The application intercepts the incoming SMS.
  • The application disables incoming SMS notifications.
  • The application makes phone calls.

Audio video eavesdropping:

  • The application records audio from mobile sources.
  • The application captures video from mobile sources.

Personal information manager data leakage:

  • The application reads or edits contact data.
  • The application reads the SMS inbox.

Recommendation

This entry is informative, no recommendations applicable.

Process crashes

Risk: low

Description

A crash is the result of unexpected or unhandled behaviours. It might be the result of missing input validations, incorrect serializations, or unallowed operations etc.

An attacker may try to find the code path that leads to the faulty procedure and attempt to execute arbitrary code through potential vulnerabilities.

Crashes may give an attacker valuable information about the system and its internal details. Crashes may also create temporary vulnerabilities or leave unprotected files (e.g. memory dumps) that may be exploited.

Recommendation

  • Catch all the errors and handle them correctly
  • Validate the type and the length of all the inputs
  • DO NOT generate logs or throw errors containing personal information

Redis Library detected

Risk: medium

Description

Redis library is not suited for mobile applications since the Redis framework only has one user and the application needs to be given access to the users credentials

Recommendation

This entry is informative, no recommendations applicable.

Sencha Touch Framework detected

Risk: info

Description

Sencha Touch is a JavaScript framework for building cross-platform mobile web applications.

Recommendation

  • Don't use eval() unless you know what you're doing.
  • Do not cache sensitive data
  • Validate all user input.
  • Use InAppBrowser for outside links.
  • Avoid Global Variables.

Sensitive material exposed

Risk: potentially

Description

The application may expose unintentionally sensitive material like API keys, secret keys, etc.

Recommendation

Sensitive data must not be package with the application. If access to this data is required, it must protected with proper on the server backend with proper mechanisms and must be packaged with the final application.

Source to Sink

Risk: potentially

Description

Source method or user controlled parameter is used to call a sink method.

Recommendation

Validate input before accessing sink method.

SQL injection

Risk: medium

Description

Improper SQL query construction could lead to SQL injection. An SQL injection attack consists of injecting of an SQL query via the input data from the client to the application

Recommendation

Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks or access unauthorized content.

Stack traces reveal technical information

Risk: medium

Description

When the server application receives unexpected input, an error is triggered returning technical information about the application internals.

An attacker can use this information to understand how the application is handling inputs. It becomes possible to investigate the inner workings and formulate further attack strategies. Information leakage should be suppressed to discourage attackers and prevent access to potential critical information.

Recommendation

A custom exception page should be returned that does not include technical information. The exception should be logged server side but not visible to a user. The stack trace should never be included within the page's HTML source even if client side source code viewing has been disabled as it is still possible to recover this information though other mechanisms.

Strings Bplist files

Risk: info

Description

Property list files are files that store serialized objects. They often store users settings. They are also used to store information about bundles and applications.

Recommendation

This entry is informative, no recommendations applicable.

Anonymous unauthenticated server accepted

Risk: high

Description

List of all files shipped in the application.

Recommendation

Buffer messages until entire an HTTP request/response has arrived.

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Suspicious strings found in requests

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Drops SSL connections vulnerability

Risk: medium

Description

List of all files shipped in the application.

Recommendation

Drops TLS connections vulnerability

Risk: medium

Description

List of all files shipped in the application.

Recommendation

Early CCS vulnerability (CVE-2014-0224)

Risk: high

Description

List of all files shipped in the application.

Recommendation

Heartbleed (CVE-2014-0160)

Risk: high

Description

List of all files shipped in the application.

Recommendation

Heartbleed is a security bug in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. It was introduced into the software in 2012 and publicly disclosed in April 2014.

Heartbleed may be exploited regardless of whether the vulnerable OpenSSL instance is running as a TLS server or client. It results from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension, thus the bug's name derives from heartbeat. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed.

Clear text HTTP request

Risk: medium

Description

Mobile Applications must use Secure Sockets Layer SSL / Transport Layer Security TLS to provide encryption at the transport layer and ensure the confidentiality and integrity of data in transit.This application does not use SSL/TLS and is vulnerable to traffic interception and modification.

An attacker performing a man-in-the-middle (MITM) attack may:

  • Passively intercept the communication to access any sensitive data in transit like usernames, passwords or credit card number
  • Actively inject or remove content to forge and omit information or inject malicious scripts
  • Actively redirect the communication to the attacker in the context of the initial trusted party

Recommendation

It is recommended to ensure the use of an encrypted channel for requests transmitting sensitive data, it is however highly recommended to encrypt all requests made by the application, as the interception and modification of non sensitive requests could be leveraged to access sensitive data.

The encrypted channel should use secure protocols and cipher suites, do not develop custom encryption protocols or algorithms.

Authorization headers in HTTP requests

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Insecure TLS Ciphers supported

Risk: medium

Description

Sockets Layer / Transport Layer Security (SSL/TLS) starts by the client requesting a secure connection and presenting a list of suppored cipher suites.

Cipher suite is a list of authentication, encryption, message authentication code (MAC) and key exchange algorithms. Each algorithm serve a specific role during the protocol negotiation. Use of a week algorithm might ciriticaly impact the security of the whole channel.

It was identified that the endpoint supports a combination of cipher suites and Secure Sockets Layer / Transport Layer Security (SSL/TLS) protocols that suffer from known cryptographic weaknesses. Therefore they should not be relied upon for effective transport layer security. An attacker with the ability to eavesdrop the connection could influence or even decrypt the traffic that is passing by.

Cryptographic weaknesses have been demonstrated for all the following configurations:

  • Support for deprecated SSL protocol (v2 or v3)
  • Support of cipher suites offering keys smaller than 128bit
  • Support of cipher suites offering CBC mode in combination with TLS protocol lower than version 1.1 vulnerable to the BEAST attack
  • Use of compression within TLS vulnerable to the CRIME attack
  • Support of cipher suites offering RC4 as cipher
  • Support of cipher suites offering DES as cipher
  • Support of cipher suites offering MD5 as signature algorithm

Recommendation

The recommended SSL/TLS configuration should enforce the following recommendations:

  • Restrict to TLSv1 and above, with TLS1.2 being preferred
  • If SSLv3 is required, it is advised to implement the TLS Fallback SCSV feature to prevent protocol downgrade attacks
  • Disable Anonymous Diffie-Hellman (ADH)
  • Disable aNULL and eNull cipher suites
  • Disable Export key exchange suites
  • Remove RC4 support
  • Remove DES support
  • Remove MD5 support
  • Prefere SHA256 over SHA1
  • Prefer AES128 over AES256 as 256 offer little security advantages and is less robust to timing attacks
  • Disable Client-Initiated Renegotiation
  • Disable TLS compression
  • Offer only ciphers with a key length of greater than 128bit
  • Offer cipher suites with Perfect-Forward Secrecy protocol properties (DHE, ECDHE)
  • Use custom Diffie-Hellman group to protect against Logjam attack
  • Implement the HTTP Strict Transport Security header field
  • Implement OSCP stapling

Sample of a secure SSL/TLS configuration for Nginx generated with Mozilla SSL Configuration Generator

    server {
        listen 443 ssl;
    
        # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
        ssl_certificate /path/to/signed_cert_plus_intermediates;
        ssl_certificate_key /path/to/private_key;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
    
        # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
        ssl_dhparam /path/to/dhparam.pem;
    
        # modern configuration. tweak to your needs.
        ssl_protocols TLSv1.1 TLSv1.2;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
        ssl_prefer_server_ciphers on;
    
        # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
        add_header Strict-Transport-Security max-age=15768000;
    
        # OCSP Stapling ---
        # fetch OCSP records from URL in ssl_certificate and cache them
        ssl_stapling on;
        ssl_stapling_verify on;
    
        ## verify chain of trust of OCSP response using Root CA and Intermediate certs
        ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    
        resolver <IP DNS resolver>;
    
        ....
    }

Insecure TLS certificate domain name validation

Risk: high

Description

The application does not perform proper SSL/TLS certificate validation which makes it vulnerable to man-in-the-middle attacks.

Recommendation

It is recommended to apply proper SSL/TLS certificate validation. Compliant solution depends on actual implementation.

Insecure TLS certificate validation (accept self-signed certificate)

Risk: high

Description

List of all files shipped in the application.

Recommendation

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.

SSL server key substitution vulnerability

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

TLS/SSL Server Configuration Settings

Risk: info

Description

SSL/TLS scan listing supported ciphers, protocols and checks for known vulnerabilities.

Recommendation

This entry is informative, no recommendations applicable.

Authentication credentials in SMTP traffic

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Suppress STARTTLS in SMTP

Risk: high

Description

List of all files shipped in the application.

Recommendation

Insecure SSL Ciphers supported

Risk: high

Description

List of all files shipped in the application.

Recommendation

Suppress STARTTLS in XMPP streams

Risk: info

Description

List of all files shipped in the application.

Recommendation

This entry is informative, no recommendations applicable.

Untrusted External Storage File Access

Risk: medium

Description

Files saved to the external storage prior to Android 4.1 are world-readable. Prior to Android 1, files saved to external storage are world-writable. From Android 1 to Android 4.3, only the WRITE_EXTERNAL_STORAGE permission is required for an app to write to any external storage file stored by any app. Starting with Android 4.4, groups and modes of files are created based on a directory structure, which allows an app permission to manage/read/write files within a directory structure based on its package name. Starting with Android 4.4, users (including apps as users) are isolated from primary external storage spaces of other apps controlled by the Android device.

Consequent to the lack of restrictions described above, files written to external storage can be modified or read by other apps installed on the device (for the Android versions which allow read/write) and by anyone with access to the files if stored on an off-device external storage device such as a PC (or if the in-device external storage media is removed and mounted elsewhere).

Source: CERT Secure Coding

Recommendation

It is recomended to set proper permissions on file stored on the external storage and encrypt sensitive data that may need to be stored on the external storage.

Risk: info

Description

Malware analysis by multiple Antiviruses using VirusTotal MD5 hash based search.

Recommendation

This entry is informative, no recommendations applicable.

Vitamio < 5.0.0 suffers from multiple vulnerabilities

Risk: medium

Description

Vitamio is an open multimedia framework for Android and iOSThe vulnerability is due to the Vitamio SDK containing world-writable code.

Recommendation

Migrate the application to Vitamio 5.0.0 or higher.

Vungle < 3.3.0 suffers from multiple vulnerabilities

Risk: medium

Description

Vungle Advertisement SDK library version prior to 3.3.0 may allow an attacker to gain code execution to your app via MITM and modify server responses to device requesting resources

Recommendation

Migrate the application to Vungle 3.3.0 or higher.

Generic web vulnerability

Risk: potentially

Description

Generic web vulnerability.

Recommendation

This entry is informative, no recommendations applicable.

HTTP headers checks

Risk: info

Description

Recommendation

Insecure Access Control

Risk: high

Description

The application does not enforoce propoer access control, allowing an attacker to access unauthorized data or perform unauthorized business functions.

Access control vulnerabilities may be caused by:

  • Referencing content using primary keys and lack of validation of the content access permissions.
  • CORS misconfiguration allowing unauthorized API access.
  • Metadata manipulation, such as replaying or tampering with a access control tokens.

Recommendation

Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

  • With the exception of public resources, deny by default. l* Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
  • Unique application business limit requirements should be enforced by domain models.
  • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
  • Log access control failures, alert admins when appropriate (e.g. repeated failures).
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout. Developers and QA staff should include functional access control unit and integration tests.

Insecure Object Serialization

Risk: high

Description

The application uses an insecure deserialization scheme from untrusted data.

Insecure object deserialization may result in

  • Arbitrary remote code execution
  • Modification of the application logic
  • Data tampering, such as bypassing access control

Exploitation of deserialization vulnerabilties is difficult, due to the absence of off the shelf exploits and the need to to tweak them for the targetted exploit.

Recommendation

To prevent object serialization vulneravilities, the application must either:

  • Accept serialized objects from trusted sources only
  • Use serialization primitive data types only

If these measures are not possible, consider the following:

  • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
  • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
  • Isolating and running code that deserializes in low privilege environments when possible.
  • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitoring deserialization, alerting if a user deserializes constantly.

Intersting response

Risk: info

Description

The backend response is considered as interesting. This is not necessarily a vulnerability, but is worth investigating the cause of the response.

Recommendation

This entry is informative, no recommendations applicable.

Javascript code injection

Risk: high

Description

Recommendation

Java Freemarker template injection

Risk: high

Description

Recommendation

Java Velocity template injection

Risk: high

Description

Recommendation

NodeJs Pug template injection

Risk: high

Description

Recommendation

PHP file inclusion

Risk: high

Description

Recommendation

PHP Mustach template injection

Risk: high

Description

Recommendation

PHP Smarty template injection

Risk: high

Description

Recommendation

PHP Twig template injection

Risk: high

Description

Recommendation

Python Code Injection

Risk: high

Description

Recommendation

Python Jinja template injection

Risk: high

Description

Recommendation

Python Mako template injection

Risk: high

Description

Recommendation

Python Object Serialization injection

Risk: high

Description

Recommendation

Python Tornado template injection

Risk: high

Description

Recommendation

Ruby code injection

Risk: high

Description

Recommendation

SQL Injection

Risk: high

Description

Recommendation

Cross-Site Scripting (XSS)

Risk: high

Description

Cross-site-scripting (XSS) vulnerabilities occur when unsanitized user-controlled input is served to user.

XSS vulnerabilities bypasses same-Origin-Policy, which is a core principal of web security. SOP ensures that a page from http://evil.com can't access the content of a page from http://bank.com.

XSS are commonly separated into 3 familities

  • Reflected: the user-controlled input is directly reflected in the page response
  • Stored: the user-controled input is stored on the server-side, for instance in a database, and is later returned to user
  • DOM-based: the user-controlled input is injected on the client-side to the DOM, triggering the injection of malicious JavaScript

XSS vulnerabilities allow an attacker to perform a variety of malcious actions, like exfiltration of personal data, including user session or account information; perform actions on behalf of the user.

Recommendation

In general cases, preventing XSS vulnerabilities requires a 2-step protection:

  • Input validation: user-controlled input should be validated to forbid all unauthorized characters, phone number should for instance only contain numbers; names should only contain alphabetical characters, etc.
  • Output encoding: all input shown to user is properly encoded using standard proven API. Use of safe template engines with native support for output encoding and secure defaults is highly recommended.