Static Analysis

Android Static Analysis

Android Static analysis, also called static code analysis, is a method of debugging that is done by examining the code without executing the Android application. The process provides an understanding of the code structure, and can help to ensure that the code adheres to industry standards.

Static Analysis results are displayed in json objects with the following names:

  • kind“: Type of analysis test (static or dynamic)
  • key“: Contains the value of the static analysis test title used for testing purposes
  • title“: Title of the specific static analysis test
  • category“: Category of the specific static analysis test
  • summary“: Summary of the specific static analysis test
  • cvss“: Common Vulnerability Scoring System (CVSS) The universal, open and standardized method for rating IT vulnerabilities and determining the urgency of response
  • regulatory“: Security and compliance regulations

Under the regulatory category will display a json array with the following names:

  • cwe“: The “CWE” or “Common Weakness Enumeration category is displayed in a json array with id and url of each specifc software weakness(es) found during static analysis.

  • owasp“: The “OWASP” or “Open Web Application Security Project” category is displayed in a json array with id and url of each specific mobile security risk(s) found during static analysis.

Example:

{
    "kind": "static",
    "key": "dynamic_code_loading_check",
    "title": "Dynamic Code Loading",
    "category": "code",
    "summary": "\n    Checks for the use of dynamic code loading within the APK. This mechanism allows a developer to specify which components of the application should not be loaded by default when the application is started. Typically, core components and additional dependencies are loaded natively at runtime, however, dynamically loaded components are only loaded as they are specifically requested. While this can have a positive impact on performance, or grant additional functionality (i.e. a non-invasive update feature), it can also open the application to serious security vulnerabilities if not implemented properly.\n  ",
    "cvss": 4.3,
    "regulatory": {
      "cwe": [
        {
          "id": 545,
          "url": "https://cwe.mitre.org/data/definitions/545.html"
        }
      ],
      "owasp": [
        {
          "id": "Mobile Top 10: M7-Client Side Injection",
          "url": "https://www.owasp.org/index.php/Mobile_Top_10_2014-M7"
        }
      ]
    }

If an application was not found to be vulnerable or affected by this specific static analysis test, the results will display in json objects with the following names and values:

  • affected“: Boolean value (true or false) that states whether the application is affected by the specific static analysis test
  • severity“: If the application is not vulnerable to a specific static analysis test, the severity value will display “pass”
  • description“: Description of the static analysis test result

Example:

"affected": false,
    "severity": "pass",
    "description": "\n    Your application was signed using a key length of more than 1024 bits.\n  "
  }

If an application was found to be vulnerable and affected by this specific static analysis test, the results will display in json objects with the following names and values:

  • affected“: Boolean value (true or false) that states whether the application is affected by the specific static analysis test
  • category“: Category of the specific static analysis test
  • severity“: If the application is vulnerable to a specific static analysis test, the severity values range from “high”, “medium”, and “low”
  • cvss“: Common Vulnerability Scoring System (CVSS) The universal, open and standardized method for rating IT vulnerabilities and determining the urgency of response
  • title“: Title of the specific static analysis test
  • cwe“: The “CWE” or “Common Weakness Enumeration category is displayed in a json array with id and url of each specifc software weakness(es) found during static analysis.
  • description“: Description of the static analysis test result
  • recommendation“: Recommendation on how to fix the issue or vulnerability

Example:

"affected": true,
    "issue": {
      "category": "code",
      "severity": "medium",
      "cvss": 4.3,
      "cwe": [
        {
          "id": 545,
          "url": "https://cwe.mitre.org/data/definitions/545.html"
        }
      ],
      "owasp": [
        {
          "id": "Mobile Top 10: M7-Client Side Injection",
          "url": "https://www.owasp.org/index.php/Mobile_Top_10_2014-M7"
        }
      ],
      "title": "Dynamic code loading detected",
      "description": "\n    Your application was found to be using dynamic code loading. While this\n    is not a vulnerability per se, it is not a secure code practice and can\n    lead to code injection or malicious side-loading of code.\n  ",
      "recommendation": "\n    It is strongly discouraged to load code from outside of the application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management, application testing and can make it impossible to verify the behavior of an application. Dynamically loaded code runs with the same security permissions as the application APK. If the modules are included directly within the APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. There can be instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow modification of the content in transit, or another application to modify the content on the device, respectively.\n  ",
      "pass": "\n    Your application is either not using dynamic code loading or has\n    implemented it securely.\n  "
    },
    "severity": "medium",
    "description": "\n    Your application was found to be using dynamic code loading. While this\n    is not a vulnerability per se, it is not a secure code practice and can\n    lead to code injection or malicious side-loading of code.\n  ",
    "recommendation": "\n    It is strongly discouraged to load code from outside of the application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management, application testing and can make it impossible to verify the behavior of an application. Dynamically loaded code runs with the same security permissions as the application APK. If the modules are included directly within the APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. There can be instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow modification of the content in transit, or another application to modify the content on the device, respectively.\n  ",
    "context": {
      "title": "Code Locations",
      "rows": [
        {
          "class": "Lcom/google/android/gms/internal/bc;",
          "method": "b",
          "signature": "()V"
        },
        {
          "class": "Lcom/google/android/gms/internal/al;",
          "method": "a",
          "signature": "(Ljava/lang/String;)Z"
        }
      ],
      "fields": {
        "class": {
          "title": "Class"
        },
        "method": {
          "title": "Method"
        },
        "signature": {
          "title": "Signature"
        }
      }
    }
  }