Insecure Defaults in Adobe’s Mobile SDKs

nightwatchcyber Research,

Summary

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.

Details

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": "http://example.com/subscriptions/{%mcid%}",
        ...
      },
      ...
    },
  ],
  "remotes": { 
        "analytics.poi": "http://assets.adobedtm.com/staging/42a6fc9b77cd9f29082cf19b787bae75b7d1f9ca/scripts/satellite-53e0faadc2f9ed92bc00003b.json", 
        "messages": "http://assets.adobedtm.com/staging/42a6fc9b77cd9f29082cf19b787bae75b7d1f9ca/scripts/satellite-53e0f9e2c2f9ed92bc000032.json" 
    }
 }

Examples

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 (https://github.com/Adobe-Marketing-Cloud/acp-sdks), 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:

https://aep-sdks.gitbook.io/docs/version-4-sdk-end-of-support-faq

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:

https://github.com/nightwatchcybersecurity/truegaze

References

Adobe tracker # PSIRT-9709
Vendor documentation: see here

Credits

Advisory written by Y. Shafranovich.

Timeline

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

3 thoughts on “Insecure Defaults in Adobe’s Mobile SDKs”

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.