Insecure Defaults in Adobe’s Mobile SDKs


Example/default configuration files provided by Adobe within their mobile SDKs include several insecure options. These have also been found in the wild in multiple mobile applications. When these options are used insecurely, attackers can view or modify information transmitted by the application back to Adobe’s cloud services.

Application developers are encouraged to check the configuration files within their own applications to make sure these options are set correctly. The vendor has updated some of these files with secure alternatives – for others, new SDKs are available with secure defaults.

We also have a tool available (“truegaze“) that can be used for static scanning of mobile applications with insecure defaults in their Adobe configurations.


Adobe provides multiple mobile SDKs intended for integration into mobile applications across multiple platforms. These SDKs communicate between the mobile apps and the vendor-provided cloud services. Some of the example/default configuration files include insecure settings. This can lead to applications copying these insecure settings into their own applications and we have observed this behavior in the wild. We are also working on automated tools to detect these files with insecure settings within mobile applications.

The main configuration file for these SDKs is called “ADBMobileConfig.json” and is usually packaged within the application file. There are several insecure settings included within this file which may lead to sensitive data being transmitted without SSL and can be seen or modified by an attacker with access to the network traffic. These include:

  • analytics -> ssl – Enables (true) or disables (false) the ability to send measurement data by using SSL (HTTPS). Default is false. This is the one most commonly found and should be changed to “true” by default.
  • mediaHeartbeat -> ssl – enables (true) or disables (false) the ability to send hearbeat data by using SSL (HTTPS). Default is false.

There are also additional settings which can be incorrectly set not to use SSL, but are not usually presented that way by default:

  • postback -> templateurl – configuration for the postback URL which are used to send data collected by the SDK to a third party server
  • remotes – defines the Adobe-hosted endpoints for dynamic configuration files including:
    • analytics.poi – endpoint for hosted POI configuration.
    • messages – endpoint for hosted in-app message configuration

This can also be configured via code as follows:

  • C/C++/Objective C – hbConfig.ssl = NO;
  • JS – MediaHeartbeatConfig.ssl = false

Here is an abbreviated example file with the insecure settings highlighted:

  "analytics": {
    "ssl": false,
  "messages": [
      "payload": {
        "templateurl": "{%mcid%}",
  "remotes": { 
        "analytics.poi": "", 
        "messages": "" 


The following examples/docs were reported to the vendor and were updated to have secure defaults:

The following have insecure defaults and are present within vendor-provided code, documentation or code samples. The vendor will not be fixing them:

Vendor Response and Mitigation

Application developers utilizing the Adobe SDK within their applications should check the configuration for the SDK to make sure all of the options are set securely.

The vendor provided the following response:

Thanks for reaching out to Adobe.  The configuration file you identified is an empty “sample” file, and we’re working with the owner to update that config to use SSL by default.  In practice, Adobe customers will either:

1. Download a file from Mobile Services (where SSL is on by default)
2. Engage Adobe professional services to create a configuration file (wherein SSL is recommended) or,  
3. Customers will create their own configuration (where the vast majority enable SSL)

Additionally, we’ve released a new version of the SDK (, configurable in Launch, where SSL is always turned on by default. 

The vendor also fixed most of these issues and provided the following response regarding the remaining unfixed issues:

Adobe has announced end-of-support for these vulnerable SDKs and encourages customers to move to our new version of the SDK where SSL is the default:

Static Scanning Tools

We have developed an open source tool that can be used for static scanning of mobile applications with insecure defaults in their Adobe configurations. You can find it here:


Adobe tracker # PSIRT-9709
Vendor documentation: see here


Advisory written by Y. Shafranovich.


2019-03-04: Initial report to the vendor
2019-05-06: Followup communication with the vendor
2019-07-28: Draft blog post sent to the vendor for review
2019-08-01: Follow-up communication with the vendor
2019-08-09: Follow-up communication with the vendor
2019-10-08: Follow-up communication with the vendor
2019-10-29: Follow-up communication with the vendor
2019-10-30: Ok to publish received from the vendor
2019-11-06: Public disclosure

Media Coverage

Advisory: Intel Crosswalk SSL Prompt Issue [CVE 2016-5672]


The Intel Crosswalk Project library for cross-platform mobile development did not properly handle SSL errors. This behaviour could subject applications developed using this library to SSL MITM attacks.

Vulnerability Details

The Crosswalk Project, created by Intel’s Open Source Technology Center, allows mobile developers to use HTML, CSS and Javascript to develop and deploy mobile apps across multiple platforms from the same codebase. The library packages the HTML assets provided by the developer and runs them inside a WebView on the device. The library also bridges some of the common APIs and services from the Javascript code in the WebView to the underlying platform. The project supports deployment to iOS, Windows Phone and Android. It is implemented in multiple apps, some of which can be found here.

For the Android implementation of CrossWalk – when an invalid or self-signed SSL certificate is used during communication with the server, the underlying library displays a prompt to the user asking them to grant permission or deny permission to this certificate. If the user allows the certificate, that choice is remembered going forward and from that point in, all subsequent requests with invalid SSL certificates are accepted by the application, and are not rechecked. This applies even to connections over different WiFi hotspots and different certificates. This may allow a network-level attacker to mount MITM attack using invalid SSL certificate and capture sensitive data.

Example of error dialog

The fix changes the behaviour to generate a programmatic error message not visible to the user  about an invalid SSL certificate. This issue has been fixed in the following versions of Crosswalk and all users of the library are encouraged to upgrade:

  • 19.49.514.5 (stable)
  • 20.50.533.11 (beta)
  • 21.51.546.0 (beta)
  • 22.51.549.0 (canary)

This issue was originally discovered while testing a third-party Android app using this library.


CERT/CC tracking: VR-180
CERT/CC vulnerability note: VU#217871
Crosswalk bug report: XWALK-6986
Crosswalk security advisory: see here
CVE ID: CVE-2016-5672
Intel blog: see post here


Thank you to CERT/CC for coordination on this issue, and to the Intel Open Source Technology Center for the fix. Bug discovered and advisory written by Yakov Shafranovich.


2016-05-25: Reported issue to the Intel PSIRT, got an automated reply
2016-05-30: Reached out to CERT/CC for help reaching Intel
2016-06-01: Request from CERT/CC for more details, provided details via secure form
2016-06-15: Response from CERT/CC that Intel is planning a fix within 45 days
2016-06-23: Direct contact from Intel
2016-07-01: Asking CERT/CC to reserve a CVE, CERT/CC assigns a CVE
2016-07-22: Intel fix is finished and ready for testing
2016-07-25: We confirm the fix and coordinate disclosure dates
2016-07-29: Coordinated public disclosure