“Insecure Communication” in Mobile apps are placed under OWASP Top 10 vulnerabilities and can be exploited in performing MITM attacks on targeted users. In this case, an adversary in the same network would have been able to view or modify user related information transmitted from the Audible mobile application to Adobe’s cloud services. Also, the underlying ISPs and/or Wifi Access point providers would have been able to see these calls and the shared data.
I was looking at Amazon’s Audible app and noticed an HTTP call to a weird looking domain. After digging a little more, I found that it was owned by Adobe and seemed to be used for Adobe’s cloud based services for user behavior analysis.
User behavior analysis is very important to many online and app-based services and provides insights to product managers and marketers about their app/service usage.
An easy way to integrate this feature into mobile applications, is through the use of mobile SDKs. These software development kits/tools are available for different mobile operating systems and mobile developers can utilize these SDKs to implement specific functionalities in their apps, without worrying about the underlying operating system.
While searching for the cause of this behavior in Audible, I discussed it with nightwatchcybersecurity. We noticed that it was happening because Adobe SDK for mobile, was not using a secure connection for transmitting user data between SDK and Adobe Cloud services. Further investigation revealed that SSL setting was disabled by-default in Adobe SDK for mobile app.
Audible seemed to be using these default settings and hence SDK utilized by Audible was missing the SSL/TLS protection while connecting to Adobe Cloud Services. Because of that, user data was being transmitted on an insecure connection. I reported this to Amazon team and they were able to resolve this issue very quickly. They also kept me updated on the status of the fix and were very proactive on the communication front.
Coming back to the SDK, Adobe SDK for mobile comes with a configuration file named as ADBMobileConfig.json. This file comes with some pre-populated attributes and values, and SSL attribute is one of them. By default, this option was set as ‘false’ as mentioned here. Mobile Apps using this SDK and using the default values are missing the very important SSL protection.
NightWatch has written a detailed blog on this ‘insecure-default’ behavior and also has released a utility, to scan for this and some other settings.
Adobe has released new versions of the mobile SDKs, which can be found here:
The SDKs are configurable in Adobe Experience Platform Launch and require SSL for data transmission.
Thank you for your patience on the matter, we have no comments or change requests for the draft you have shared. We would appreciate if you can send us a link of your publication when you publish it.
Audible version 2.35 onward for Android
Amazon Case ID # PO135515801
CVE from MITRE # CVE-2019-11554
03/11/2019 – Reported this issue to Amazon
03/12/2019 – A case ID was assigned and additional questions were asked
03/14/2019 – Case manager informed that they were going ahead with the fix
04/04/2019 – Case manager informed that they had fixed the issue but were waiting for their users to upgrade the app.
04/23/2019 – Case manager informed that an updated version was made available to most of their users and they were closing this issue on their end.
11/06/2019 – Shared a draft report with nightwatchcyber for review.
11/06/2019 – Shared a draft report with Amazon.
11/07/2019 – Shared a draft report with Adobe.
11/07/2019 – Adobe acknowledged the email.
11/12/2019 – Shared an updated draft with everyone
11/12/2019 – Amazon acknowledged the email.
11/13/2019 – Adobe responded that if I could add their official response in my blogpost.
11/21/2019 – Amazon responded that I could go ahead with the post.
12/05/2019 – Published the blog post.
1) Audible iOS App:
2) Audible Android App:
3) New Versions of Adobe Mobile SDKs: