lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 6 Nov 2019 22:06:03 -0500
From: Nightwatch Cybersecurity Research <>
Subject: [FD] Insecure Defaults in Adobe’s Mobile SDKs

[Original post:]


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

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
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
- 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
- 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": {


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:


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:


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

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists