Advisory: WhatsApp for Android Privacy Issues with Handling of Media Files [CVE-2017-8769]

Summary

WhatsApp Messenger for Android does not delete sent and received files from the SD card on the device when chats are cleared, deleted or the application is uninstalled from the device. Additionally, the application stores sent and received files in the SD card without encryption where they are accessible to any applications with storage permissions.

The vendor (Facebook) doesn’t consider these to be security issues and does not plan to fix them. MITRE has assigned CVE-2017-8769 for these issues. It is also unclear whether platforms other than Android are affected.

Background

WhatsApp Messenger is a popular cross-platform communication tool that allows users to send and receive messages without using more expensive protocols like SMS. Additionally the application allows sending and receiving of files including audio, contacts, images, videos and arbitrary documents. It is estimated that WhatsApp has over 1 billion active users and it is owned by Facebook, which also operates the largest social networking site in the world.

One of the main selling points that WhatsApp makes is their commitment to user privacy which revolves around the implementation of end-to-end encryption via the Signal protocol originally developed by Open Whisper Systems. This encryption makes it impossible for Facebook to monitor and capture message traffic flowing between users. In some extreme cases, Facebook executives have been placed in jail for the failure to allow access to messaging data when requested by governments.

Because of the high expectation of privacy by WhatsApp user, it is important that the security of the application on the device is also properly implemented. In regards to messages, WhatsApp stores them in encrypted database but it fails to do the same for files. WhatsApp also does not clear files received or sent by the user when the chats are cleared. This can result in user data being leaked or stolen by malicious applications, law enforcement during illegal searches or unwanted actors having access to the device (“evil maid scenario”).

Vulnerability Details

As mentioned above, WhatsApp has ability to send and receive files in addition to regular messages. This functionality includes arbitrary documents from the file system, contacts, location information, and various type of multimedia files including two separate audio formats (voice notes and recordings), images and videos. There is also more recent functionality around “status” images which disappear after 24 hours. In order for WhatsApp to access the SD card, users must grant storage permissions but in practice most users do so in order to be able to exchange files.

In our research, we have found that WhatsApp for Android stores these files on the SD card where they are accessible to other applications and does not delete them when chats are cleared, deleted or the application is uninstalled. Both sent and received files are retained. They are retained on the SD card in the following folder:

  • /WhatsApp/Media/

We have observed that the following file types are retained and not deleted:

  • /WhatsApp/Media/.Statuses/
  • /WhatsApp/Media/WhatsApp Audio/
  • /WhatsApp/Media/WhatsApp Documents/
  • /WhatsApp/Media/WhatsApp Images/
  • /WhatsApp/Media/WhatsApp Video/
  • /WhatsApp/Media/WhatsApp Voice Notes/

Screenshot_20170512-000800

To replicate the issue:

  1. Install WhatsApp for Android.
  2. Login and exchange messages with another user that contain any of the file type listed above.
  3. Then, install any file manager for Android.
  4. Navigate to the SD card, and observe the files sent and received being located in the directories described above.

As the next step, try to delete a chat by tapping on the chat, holding until the delete option comes up. Delete the chat, and go back to the file manager to check.

As the next step, try going to “Settings”, “Chats”, “Chat History” and selecting either “Clear all chats” or “Delete all chats”. Go back to the file manager and observe the media files still being present.

Screenshot_20170512-000723

As the next step, uninstall WhatsApp. Go back to the file manager, and observe the media files still being there.

All testing was done on Android 7, and WhatsApp Messenger v2.17.146. It is unclear whether other platforms are affected.

Vendor Response and Mitigation Steps

The vendor (Facebook) doesn’t consider these to be security issues and has no plans to fix them. Vendor response is as follows:

Thanks again for your report. We contacted the WhatsApp team about your report, and they confirmed that the behavior you describe is intentional. They designed the Android app to optimize for the storage space available on devices and allow media in WhatsApp to be visible in other apps like the Google Photos gallery. WhatsApp doesn’t assume that clearing the chat means clearing the media files as well. While the behavior might change in the future, we currently don’t have any plans to do so.

The vendor also noted that on Windows Phone, there is a setting that stops the application from saving media files that are received by the user.

It is recommended that users regularly check the folders listed above on the SD card and empty them as needed. For those users who desire higher security, it may be prudent to reformat or encrypt the SD card, or destroy the SD card if needed in order to delete these files.

References

CVE ID: CVE-2017-8769
CWE IDs: CWE-359 (“Exposure of Private Information”)
Facebook security reference # 10101277738643365

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-04-09: Initial report to Facebook
2017-04-14: Email exchange with the vendor
2017-04-20: Email exchange with the vendor
2017-04-03: Email exchange with the vendor
2017-05-09: Email exchange with the vendor
2017-05-16: Email exchange with the vendor
2017-05-17: Email exchange with the vendor
2017-05-17: Public disclosure

Advisory: Google I/O 2017 Android App Doesn’t Use SSL for Some Content [CVE-2017-9045]

Summary

Google I/O 2017 Application for Android does not use SSL for retrieving some information to populate the app. This would allow an MITM attacker to inject their own content into the application. The vendor (Google) fixed the issue in v5.1.4 of the application.

Details

The Google I/O 2017 application for Android is a companion app produced by Google for their annual I/O conference that takes place in May. This particular version was produced for I/O conference in May of 2017.

While performing network level testing of various Google applications, we discovered that the content for the application did not use SSL. This would allow an MITM attacker to inject their own content into the application using a method like ARP spoofing, DNS takeover, etc.

To replicate the issue on v5.0.3:

  1. Install the application
  2. Setup the proxy without an SSL certificate and point the Android device to it.
  3. Go to the application and select the “feed” option (middle icon on the bottom).
  4. Go back to the proxy and observe captured traffic.

Screenshots of the feed before and after the data is loaded:

Screenshot_20170516-205242  Screenshot_20170516-220959

Network traffic captures appear as follows:

Screenshot_20170511-202707   Screenshot_20170511-202713

The specific URL was “http://storage.googleapis.com/io2017-festivus/manifest_v1.json” which then causes the device to download additional URLs. The following URLs are downloaded:

This can also be seen in the source code of the I/O 2016 application on Github as follows:

google_github

All testing was done on Android 7, Google I/O version 5.0.3. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Proof of Concept

All testing was done on Ubuntu v17.04 and Android 7:

  1. Install nginx – “sudo apt-get install nginx”.
  2. Install dnsmasq – “sudo apt-get install dnsmasq”
  3. Find out the IP address of your computer via ifconfig.
  4. Add the IP address mapping to the hosts file: “192.168.1.x  storage.googleapis.com”
  5. Create and download the files from Google to the NGINX directory:
    1. cd /var/www/html
    2. mkdir io2017-festivus
    3. cd io2017-festivus
    4. wget http://storage.googleapis.com/io2017-festivus/manifest_v1.json
    5. wget http://storage.googleapis.com/io2017-festivus/blocks_v4.json
    6. wget http://storage.googleapis.com/io2017-festivus/map_v4.json
    7. wget http://storage.googleapis.com/io2017-festivus/session_v1.70.json
  6. Modify “blocks_v4.json” to add your content.
  7. Install version 5.0.3 of the application on the Android device.
  8. Change DNS on the device to point to the Ubuntu machine.
  9. Open the app, skip sign in, and on the main screen choose the feed icon.
  10. Switch back to the first section and observe injected content:

Screenshot_20170516-223446

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 5.1.4.

References

CVE ID: CVE-2017-9045

Google I/O 2016 source code: https://github.com/google/iosched

Bounty Information

Pending…

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-13: Fixed version released by the vendor
2017-05-16: Draft advisory sent to vendor for comment
2017-05-17: Public disclosure

Advisory: Insecure Transmission of Qualcomm Assisted-GPS Data [CVE-2016-5341]

Summary

Assisted GPS/GNSS data provided by Qualcomm for compatible receivers is often being served over HTTP without SSL. Additionally many of these files do not provide a digital signature to ensure that data was not tampered in transit. This can allow a network-level attacker to mount a MITM attack and modify the data while in transit. While HTTPS and digitally-signed files are both available, they are newer and not widely used yet.

There are also some attacks that allow the device to be crashed and those have been fixed by both Qualcomm and Google.

Background – GPS and gpsOneXtra

Most mobile devices today include ability to locate themselves on the Earth’s surface by using the Global Positioning System (GPS), a system originally developed and currently maintained by the US military. Similar systems developed and maintained by other countries exist as well including Russia’s GLONASS, Europe’s Galileo, and China’s Beidou.

The GPS signals include an almanac which lists orbit and status information for each of the satellites in the GPS constellation. This allows the receivers to acquire the satellites quicker since the receiver would not need to search blindly for the location of each satellite. Similar functionality exists for other GNSS systems.

In order to solve the problem of almanac acquisition, Qualcomm developed the gpsOneXtra system in 2007 (also known as IZat XTRA Assistance since 2013). This system provides ability to GPS receivers to download the almanac data over the Internet from Qualcomm-operated servers. The format of these XTRA files is proprietary but seems to contain current satellite location data plus estimated locations for the next 7 days. Most Qualcomm mobile chipsets and GPS chips include support for this technology. A related Qualcomm technology called IZat adds ability to use WiFi and cellular networks for locations in addition to GPS.

Additional diagram of the system as described in Qualcomm’s informational booklet:

gps

Background – gpsOneXtra Data Files

During our network monitoring of traffic originating from an Android test device, we discovered that the device makes periodic calls to the Qualcomm servers to retrieve gpsOneXtra assistance files. These requests were performed every time the device connected to a WiFi network, and originated from an OS-level process. Our examination of network traffic and the Android source code revealed that the network calls did not use SSL or any other encryption or authentication technology, and that the specific files we tested were not digitally signed. Our testing was performed on Android v6.0, patch level of January 2016, on a Motorola Moto G (2nd gen) GSM phone.

As discovered by our research and confirmed by the Android source code, the following URLs were used:

http://xtra1.gpsonextra.net/xtra.bin
http://xtra2.gpsonextra.net/xtra.bin
http://xtra3.gpsonextra.net/xtra.bin

http://xtrapath1.izatcloud.net/xtra2.bin
http://xtrapath2.izatcloud.net/xtra2.bin
http://xtrapath3.izatcloud.net/xtra2.bin

WHOIS record show that both domains – gpsonextra.net and izatcloud.net are owned by Qualcomm. Further inspection of those URLs indicate that both domains are being hosted and served from Amazon’s Cloudfront CDN service (with the exception of xtra1.gpsonextra.net which is being served directly by Qualcomm). We observed that the gpsonextra.net domain is serving v1 of the XTRA data files, while the izatcloud.net domain is serving version 2 of the data files, named XTRA2.

Qualcomm has clarified to us that both sets of servers are actually serving three different types of files:

  • xtra.bin – XTRA 1.0 files, providing GPS assistance data (protected by a CRC checksum)

  • xtra2.bin – XTRA 2.0 files, providing GPS and GLO assistance data (protected by a CRC checksum)

  • xtra3grc.bin – XTRA 3.0 files, providing GPS, GLO, and BDS assistance data (protected by a digital signature). These files have been available since 2014.

On the Android platform, our inspection of the Android source code shows that the file is requested by an OS-level Java process, which passes the data to a C++ JNI class, which then injects the files into the Qualcomm modem or firmware. We have not inspected other platforms in detail, but suspect that a similar process is used.

Vulnerability Details and Implications

Issue #1 – Because the XTRA and XTRA2 data files are served over HTTP without SSL, this allows an attacker to mount a MITM attack on the network level and modify the GPS assistance data while in transit. While XTRA2 files do use a CRC checksum, it would be possible to re-calculate it.

Issue #2 – because both XTRA and XTRA2 files do not use a digital signature, the receivers of this data would have no way to verify that it is in fact correct. While XTRA2 files do use a CRC checksum, it would be possible to re-calculate it.

This issue affects all devices with gpsOneXtra capability unless they are using the XTRA3 files. One implication of this type of attack would result in a denial of service in the receiver by forcing a manual search for  GPS signal, thus delaying a GPS lock. Further research is needed to determine if other types of attacks are possible via this channel.

Issue #3 – see also our earlier advisory on CVE-2016-5348 about how large XTRA data files can be used to crash Android devices remotely. This was fixed in the Android code back in October of 2016 and was fixed in the Qualcomm binary code used by Android in December 2016.

Mitigation Steps

For Android devices, users should apply the October and December 2016 security patches.

For all other devices and based on information provided by Qualcomm, the following mitigation steps are available:

  • For receivers that support XTRA and XTRA2 formats, switching to HTTPS is recommended using the following URLS:

    https://xtrapath1.izatcloud.net/xtra.bin
    https://xtrapath2.izatcloud.net/xtra.bin
    https://xtrapath3.izatcloud.net/xtra.bin
    https://ssl.gpsonextra.net/xtra.bin

    https://xtrapath1.izatcloud.net/xtra2.bin
    https://xtrapath2.izatcloud.net/xtra2.bin
    https://xtrapath3.izatcloud.net/xtra2.bin
    https://ssl.gpsonextra.net/xtra2.bin

  • Receivers are encouraged to switch to the use of the new XTRA3 digitally signed format in conjunction with HTTPS. Details on the file format and how the digital signature is verified is available to OEMs directly from Qualcomm. The following URLs are available:

    https://xtrapath1.izatcloud.net/xtra3grc.bin
    https://xtrapath2.izatcloud.net/xtra3grc.bin
    https://xtrapath3.izatcloud.net/xtra3grc.bin
    https://ssl.gpsonextra.net/xtra3grc.bin

Vendor Responses

Qualcomm has acknowledged the issue as being known since 2014 and has released guidance for their OEM customers on fixing the issue. The fix includes the use of SSL servers to retrieve the XTRA and XTRA2 data files, and the eventual switchover to the new XTRA3 data format which includes a digital signature as described above.

Google has acknowledged that this issue affects the Android OS. A fix for this issue is included in the December 2016 Android bulletin.

Apple and Microsoft have indicated to us via email that GPS-capable devices manufactured by them including iPad, iPhones, etc. and Microsoft Surface and Windows Phone devices are not affected, since they use an internal secure delivery mechanism for this data, and do not retrieve data directly from Qualcomm’s servers.

References

Android security bulletin: December 2016
CERT/CC tracking: VR-179
CVE-ID: CVE-2016-5341
GNSS sample almanacs: here
Google: Android bug # 211602 / AndroidID-7225554
gpsOneXTRA information booklet: archived version here
Our earlier advisory: crashing phones with large XTRA data files

CVE Information

The following information is being provided by Qualcomm to the primary CNA:

CVE-ID: CVE-2016-5341
Affected Projects: Assisted GNSS capable receivers
Access Vector: Network
Security Risk: High
Vulnerability: CWE-287 Improper Authentication
Description: Improper Validation while injecting specific versions of XTRA Data.
Change summary: allow enforcing XTRA version check using the QMI API.

Note: XTRA3 data includes a cryptographic signature, providing integrity and authenticity protection of the assistance data.

Credits

We would like to thank CERT/CC for helping to coordinate this process, and all of the vendors involved for helpful comments and a quick turnaround.

Timeline

2016–05-29: Android bug report filed with Google
2016-05-31: Android bug confirmed
2016–05–29: Bug reported to Qualcomm security and CERT via email
2016-05-30: Reply received from Qualcomm and tracking number assigned
2016-06-01: Reply received from CERT and tracking number assigned
2016-06-20: Bug confirmed and CVE reserved by Qualcomm
2016-09-06: Coordination with Google on public disclosure
2016-09-12: Coordination with Qualcomm on public disclosure
2016-12-02: Public talk at BSides Philly 2016
2016-12-05: Android bulletin published; public disclosure of this advisory

Advisory: Crashing Android devices with large Proxy Auto Config (PAC) Files [CVE-2016-6723]

Summary

Android devices can be crashed forcing a halt and then a soft reboot by downloading a large proxy auto config (PAC) file when adjusting the Android networking settings. This can also be exploited by an MITM attacker that can intercept and replace the PAC file. However, the bug is mitigated by multiple factors and the likelihood of exploitation is low.

This issue has been fixed in the November 2016 Android security bulletin.

Background – Proxy Auto Config (PAC) Files

Proxy Auto Config (PAC) files are text files that can be used as part of the network settings configuration to allow a web browser and other software that accesses the web. These files define which proxy servers should be used for which types of requests. They usually contain a Javascript function which can be called by the web browser to determine the type of proxy server to use. An example PAC file appears here:

function FindProxyForURL(url, host) {
  if (isResolvable(host))
    return "DIRECT";
  else
    return "PROXY proxy.mydomain.com:8080";
  }
}

A related standard called Web Proxy Auto-Discovery Protocol (WPAD) allows devices to find the locations of PAC files via DHCP and/or DNS. However, WPAD is not currently supported on Android.

Vulnerability Details

When configuring a network in Android, one of the options available in the “Advanced” section is ability to indicate a Proxy Auto Config (PAC) URL which will point to a PAC file described above. The current code in Android does not check whether the PAC file may be too large to load into memory, which allows an MITM attacker to replace a known PAC file (if served without SSL) with a large one of their own and crash the Android phone.

Example of settings dialog in Android:

pac-screen

The vulnerability is that the Java code does not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution, this code path can potentially be exploited for such attacks and would require more research.

The vulnerable code resides here – (PacManager.java, lines 120-127):

private static String get(Uri pacUri) throws IOException {
  URL url = new URL(pacUri.toString());
  URLConnection urlConnection = url.openConnection(java.net.Proxy.NO_PROXY);
  return new String(Streams.readFully(urlConnection.getInputStream()));
}

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Because this attack require a user to configure a PAC file, and an attacker to be present and know about that file, and the file needs to be served without SSL to make the attack work, the possibility of an attacker pulling this off is low. This is also true because Android, unlike other operating systems does not support the WPAD protocol to retrieve PAC files automatically which can be exploited using a rouge access point or network.

Steps To Replicate (on Ubuntu 16.04)

1. Install NGINX:

sudo apt-get install nginx

2. Use fallocate to create a large PAC file in “/var/www/html/”

sudo fallocate -s 2.5G test.pac

3. Go in to advanced network settings on the Android device and add the following URL as the PAC URL: http://192.168.1.x/test.pac

Save the settings which will trigger the bug. Once the phone starts downloading the files, the screen will go black and it will reboot.

Mitigation Steps

Users should apply the November 2016 Android bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.

References

Android security bulletin: November 2016
CVE-ID: CVE-2016-6723
Google: Android bug # 215709 / AndroidID-30100884
Netscape PAC file format definition: here (via the Internet Archive)
WPAD Internet Draft: here
WPAD not supported on Android: see bug report here

Credits

Bug discovered by, and advisory written by Yakov Shafranovich.

Timeline

2016-07-11: Android bug report filed with Google
2016-07-19: Android bug confirmed as high
2016-08-18: Bug priority downgraded to moderate
2016-09-15: Coordination with Google on public disclosure
2016-11-07: Android security bulletin released with fix
2016-11-07: Public disclosure

Advisory: Crashing Android devices with large Assisted-GPS Data Files [CVE-2016-5348]

Summary

Android devices can be crashed remotely forcing a halt and then a soft reboot by a MITM attacker manipulating assisted GPS/GNSS data provided by Qualcomm. This issue affects the open source code in AOSP and proprietary code in a Java XTRA downloader provided by Qualcomm.

The Android issue was fixed by in the October 2016 Android bulletin. Additional patches have been issued by Qualcomm to the proprietary client in September of 2016.

This issue may also affect other platforms that use Qualcomm GPS chipsets and consume these files but that has not been tested by us, and requires further research.

Background – GPS and gpsOneXtra

Most mobile devices today include ability to locate themselves on the Earth’s surface by using the Global Positioning System (GPS), a system originally developed and currently maintained by the US military. Similar systems developed and maintained by other countries exist as well including Russia’s GLONASS, Europe’s Galileo, and China’s Beidou.

The GPS signals include an almanac which lists orbit and status information for each of the satellites in the GPS constellation. This allows the receivers to acquire the satellites quicker since the receiver would not need to search blindly for the location of each satellite. Similar functionality exists for other GNSS systems.

In order to solve the problem of almanac acquisition, Qualcomm developed the gpsOneXtra system in 2007 (also known as IZat XTRA Assistance since 2013). This system provides ability to GPS receivers to download the almanac data over the Internet from Qualcomm-operated servers. The format of these XTRA files is proprietary but seems to contain current satellite location data plus estimated locations for the next 7 days, as well as additional information to improve signal acquisition. Most Qualcomm mobile chipsets and GPS chips include support for this technology. A related Qualcomm technology called IZat adds ability to use WiFi and cellular networks for locations in addition to GPS.

Additional diagram of the system as described in Qualcomm’s informational booklet:

gps

Background – Android and gpsOneXtra Data Files

During our network monitoring of traffic originating from an Android test device, we discovered that the device makes periodic calls to the Qualcomm servers to retrieve gpsOneXtra assistance files. These requests were performed almost every time the device connected to a WiFi network. As discovered by our research and confirmed by the Android source code, the following URLs were used:

http://xtra1.gpsonextra.net/xtra.bin
http://xtra2.gpsonextra.net/xtra.bin
http://xtra3.gpsonextra.net/xtra.bin

http://xtrapath1.izatcloud.net/xtra2.bin
http://xtrapath2.izatcloud.net/xtra2.bin
http://xtrapath3.izatcloud.net/xtra2.bin

WHOIS record show that both domains – gpsonextra.net and izatcloud.net are owned by Qualcomm. Further inspection of those URLs indicate that both domains are being hosted and served from Amazon’s Cloudfront CDN service (with the exception of xtra1.gpsonextra.net which is being served directly by Qualcomm).

On the Android platform, our inspection of the Android source code shows that the file is requested by an OS-level Java process (GpsXtraDownloader.java), which passes the data to a C++ JNI class (com_android_server_location_GnssLocationProvider.cpp), which then injects the files into the Qualcomm modem or firmware. We have not inspected other platforms in detail, but suspect that a similar process is used.

Our testing was performed on Android v6.0, patch level of January 2016, on a Motorola Moto G (2nd gen) GSM phone, and confirmed on a Nexus 6P running Android v6.01, with May 2016 security patches.

Qualcomm has additionally performed testing on their proprietary Java XTRA downloader client confirming this vulnerability.

Vulnerability Details

Android platform downloads XTRA data files automatically when connecting to a new network. This originates from a Java class (GpsXtraDownloader.java), which then passes the file to a C++/JNI class (com_android_server_location_GnssLocationProvider.cpp) and then injects it into the Qualcomm modem.

diagram

The vulnerability is that both the Java and the C++ code do not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution in either the Qualcomm modem or in the Android OS, this code path can potentially be exploited for such attacks and would require more research.

To attack, an MITM attacker located anywhere on the network between the phone being attacked and Qualcomm’s servers can initiate this attack by intercepting the legitimate requests from the phone, and substituting their own, larger files. Because the default Chrome browser on Android reveals the model and build of the phone (as we have written about earlier), it would be possible to derive the maximum memory size from that information and deliver the appropriately sized attack file. Possible attackers can be hostile hotspots, hacked routers, or anywhere along the backbone. This is somewhat mitigated by the fact that the attack file would need to be as large as the memory on the phone.

The vulnerable code resides here – (GpsXtraDownloader.java, lines 120-127):

connection.connect();

int statusCode = connection.getResponseCode();

if (statusCode != HttpURLConnection.HTTP_OK) {

if (DEBUG) Log.d(TAG, “HTTP error downloading gps XTRA: “

+ statusCode);

return null;

}

return Streams.readFully(connection.getInputStream());

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Additional vulnerable code is also in the C++ layer – (com_android_server_location_GnssLocationProvider.cpp, lines 856-858):

jbyte* bytes = (jbyte *)env->GetPrimitiveArrayCritical(data, 0);

sGpsXtraInterface->inject_xtra_data((char *)bytes, length);

env->ReleasePrimitiveArrayCritical(data, bytes, JNI_ABORT);

Once again, no size checking is done.

We were able to consistently crash several different Android phones via a local WiFi network with the following error message:

java.lang.OutOfMemoryError: Failed to allocate a 478173740 byte allocation with 16777216 free bytes and 252MB until OOM
at java.io.ByteArrayOutputStream.expand(ByteArrayOutputStream.java:91)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:201)
at libcore.io.Streams.readFullyNoClose(Streams.java:109)
at libcore.io.Streams.readFully(Streams.java:95)
at com.android.server.location.GpsXtraDownloader.doDownload(GpsXtraDownloader.java:124)
at com.android.server.location.GpsXtraDownloader.downloadXtraData(GpsXtraDownloader.java:90)
at com.android.server.location.GpsLocationProvider$10.run(GpsLocationProvider.java:882)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)

(It should be noted that we were not able to consistently and reliable achieve a crash in the C++/JNI layer or the Qualcomm modem itself)

Steps To Replicate (on Ubuntu 16.04)

1. Install DNSMASQ:

sudo apt-get install dnsmasq

2. Install NGINX:

sudo apt-get install nginx

3. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):

192.168.1.x xtra1.gpsonextra.net
192.168.1.x xtra2.gpsonextra.net
192.168.1.x xtra3.gpsonextra.net
192.168.1.x xtrapath1.izatcloud.net
192.168.1.x xtrapath2.izatcloud.net
192.168.1.x xtrapath3.izatcloud.net

4. Configure /etc/dnsmasq.conf file to listed on the IP:

listen-address=192.168.1.x

5. Restart DNSMASQ:

sudo /etc/init.d/dnsmasq restart

6. Use fallocate to create the bin files in “/var/www/html/”

sudo fallocate -s 2.5G xtra.bin
sudo fallocate -s 2.5G xtra2.bin
sudo fallocate -s 2.5G xtra3.bin

7. Modify the settings on the Android test phone to static, set DNS to point to “192.168.1.x”. AT THIS POINT – Android will resolve DNS against the local computer, and serve the GPS files from it.

To trigger the GPS download, disable WiFi and enable Wifi, or enable/disable Airplane mode. Once the phone starts downloading the files, the screen will go black and it will reboot.

PLEASE NOTE: on some models, the XTRA file is cached and not retrieved on every network connect. For those models, you may need to reboot the phone and/or follow the injection commands as described here. You can also use an app like GPS Status and ToolboxGPS Status and Toolbox.

The fix would be to check for file sizes in both Java and native C++ code.

Mitigation Steps

For the Android platform, users should apply the October 2016 Android security bulletin and any patches provided by Qualcomm. Please note that as per Qualcomm, the patches for this bug only include fixes to the Android Open Source Project (AOSP) and the Qualcomm Java XTRA downloader clients.

Apple and Microsoft have indicated to us via email that GPS-capable devices manufactured by them including iPad, iPhones, etc. and Microsoft Surface and Windows Phone devices are not affected by this bug.

Blackberry devices powered by Android are affected but the Blackberry 10 platform is not affected by this bug.

For other platforms, vendors should follow guidance provided by Qualcomm directly via an OEM bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.

References

Android security bulletin: October 2016
CERT/CC tracking: VR-179
CVE-ID: CVE-2016-5348
GNSS sample almanacs: here
Google: Android bug # 213747 / AndroidID-29555864; Android patch here
gpsOneXTRA information booklet: archived version here

CVE Information

As provided by Qualcomm:

CVE: CVE-2016-5348
Access Vector: Network
Security Risk: High
Vulnerability: CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’)
Description: When downloading a very large assistance data file, the client may crash due to out of memory error.
Change summary:

  1. check download size ContentLength before downloading data
  2. catch OOM exception

Credits

We would like to thank CERT/CC for helping to coordinate this process, and all of the vendors involved for helpful comments and a quick turnaround. This bug was discovered by Yakov Shafranovich, and the advisory was also written by Yakov Shafranovich.

Timeline

2016–06-20: Android bug report filed with Google
2016-06-21: Android bug confirmed
2016-06-21: Bug also reported to Qualcomm and CERT.
2016-09-14: Coordination with Qualcomm on public disclosure
2016-09-15: Coordination with Google on public disclosure
2016-10-03: Android security bulletin released with fix
2016-10-04: Public disclosure

Advisory: Insecure transmission of data in Android applications developed with Adobe AIR [CVE-2016-6936]

Summary

Android applications developed with Adobe AIR send data back to Adobe servers without HTTPS while running. This can allow an attacker to compromise the privacy of the applications’ users. This has been fixed in Adobe AIR SDK release v23.0.0.257.

Details

Adobe AIR is a developer product which allows the same application code to be compiled and run across multiple desktop and mobile platforms. While monitoring network traffic during testing of several Android applications we observed network traffic over HTTP without the use of SSL going to several Adobe servers including the following:

  • airdownload2.adobe.com
  • mobiledl.adobe.com

Because encryption is not used, this would allow a network-level attacker to observe the traffic and compromise the privacy of the applications’ users.

This affects applications compiled with the Adobe AIR SDK versions 22.0.0.153 and earlier.

Vendor Response

Adobe has released a fix for this issue on September 13th, 2016 in Adobe AIR SDK v23.0.0.257. Developers should update and rebuild their application using the latest SDK.

References

Adobe Security Bulletin: ASPB16-31
CVE: CVE-2016-6936

Credits

Bug discovered and advisory written by Yakov Shafranovich.

Timeline

2016-06-15: Report submitted to Adobe’s HackerOne program
2016-06-16: Report out of scope for this program, directed to Adobe’s PSIRT
2016-06-16: Submitted via email to Adobe’s PSIRT
2016-06-17: Reply received from PSIRT and a ticket number is assigned
2016-09-09: Response received from the vendor that the fix will be released next week
2016-09-13: Fix released
2016-09-14: Public disclosure

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

Summary

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.

screenshot_crosswalk
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.

References

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

Credits

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.

Timeline

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

Research: Crashing Browsers Remotely via Insecure Search Suggestions

Summary

Intercepting insecure search suggestion requests from browsers, and returning very large responses leads to browser crashes (but not RCE). Affected browsers are FireFox on the desktop and Android, and Chrome on desktop and Android – other Chromium and FireFox derived browsers maybe affected. Internet Explorer and Safari are not affected. The issue is exploitable remotely, albeit not easily.

Background – Search Suggestions

Most browsers, desktop and mobile, support a feature which allows users to type either in the address bar or the search box and see a list of “search suggestions”. These are similar to the search suggestions provided by most search engines within their homepages and search bars. Examples of search suggestions in the browser and search engine webpage appear below:

The protocol that underlies this mechanism is OpenSearch Suggestions Extensions, a JSON protocol running over HTTP (as defined here). This protocol allows browsers and other applications to send simple keyword queries to the search engine servers which return JSON responses translated by the browser into results in the search bar. It should be noted that some search engines define their own APIs instead of OpenSearch, which browsers then implement.

Search engines can also publish OpenSearch description documents (as defined here) and embed those in their webpages, which browsers can automatically discover and use. The discovery of new search engines happens automatically in some browsers when the user visits a particular site (Chrome and IE Edge [SSL only]), or triggered manually by the user via an icon in the search bar (FireFox). FireFox and Internet Explorer (prior to Edge) also support plugins and APIs for doing this as well.

An example of an open search description document defining the suggestion protocol from AOL Search (original from here) – note the bolded part that defines the search suggestion protocol:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
                       xmlns:moz="http://www.mozilla.org/2006/browser/search/">
    <ShortName>AOL Search</ShortName>
    <Description>The AOL Search engine delivers great search results so
    you can search less and discover more.</Description>
    <Language>en-us</Language>
    <InputEncoding>UTF-8</InputEncoding>
    <Image width="16" height="16" type="image/x-icon">http://search.aol.com/favicon.ico</Image>
    <Url type="text/html" method="get" template="http://search.aol.com/aol/search?q={searchTerms}&amp;s_it=opensearch"/>
    <Url type="application/x-suggestions+json" template="http://autocomplete.search.aol.com/autocomplete/get?output=json&amp;it=opensearch&amp;q={searchTerms}"/>
    <moz:SearchForm>http://search.aol.com/aol/webhome</moz:SearchForm>
</OpenSearchDescription>

Background – Search Engines and HTTPS

Even in the the post-Snowden era, many popular search engines still do not support encryption (HTTPS). Other search engines may support HTTPS but also still support non-HTTPS connections and do not redirect users automatically to HTTPS. Because browser vendors tend to include the most popular search engines in specific countries by default, they end up including multiple search engines which are not using HTTPS. This also applies to the search suggestions endpoints used by browsers.

Some examples (for English locale, US only):

  • Android AOSP stock browser (source)
    • Bing (non-SSL version)
    • Yahoo (non-SSL version)
  • Chrome (desktop and Android) (source)
    • AOL Search (does not support SSL)
    • Ask.com (does not support SSL)
  • FireFox (desktop only) (source)
    • Ebay (does not support SSL)

Exploit Details

Because browsers include multiple non-HTTPS search engines with insecure search suggestions endpoints, it would be possible for an attacker on the network level to intercept the traffic flowing between the browser and the search engine endpoints, and substitute their own. If a very large response is returned (2+ GBs), the browser can run out of memory and crash. This is due to the fact that browsers do not check for sizes in the search suggestions responses. Obviously, this is more of an issue for mobile devices which have lower memory than desktops.

For Android AOSP browser and Chromium, this issue appear to be directly tied to the processing code of search engine responses. For FireFox, this is a more generic issue around large XMLHTTPRequest responses, which is what the browser is using internally for search suggestions. Our bug reports with the vendors provide more details on which code is causing this. This re-enforces the fact network traffic SHOULD NEVER be trusted.

The following crashes were observed – we have not been able to cause an RCE or a buffer overflow:

  • Android AOSP stock browser on Android (v4.4) – application crashes
  • Chrome v51 on Android (v6.01) – application crashes
  • Chrome v51 on desktop Linux (Ubuntu v16.04) – the entire computer freezes requires a reboot (this maybe to due to swapping being disabled with an SSD drive)
  • FireFox v47 on desktop Linux (Ubuntu v16.04) and Android (v6.01) – application crashes

Safari v9.1 and Internet Explorer 11 and Edge appear not to be are not affected, although a similar bug has happened before with Safari. We did not test prior versions of either Safari or IE. We also did not test any other browsers derived from Chromium or FireFox.

The practical exploitation of this issue is mitigated by several factors:

  • The attacker must have control over DNS and the network traffic of the victim machine. This is most likely in cases of a rogue WiFi hotspot or a hacked router.
  • Most browsers have a rather short timeout for search engine suggestions response, not allowing sufficient time for the large response packet to be transferred over network
  • Due to the very large response size needed to trigger this issue, it is only exploitable over broadband or local networks such as rogue WiFi hotspot

Vendor Responses

Google response re: Android AOSP browser:

The team reviewed this issue and don’t believe there is a security vulnerability here. It seems the worse things that can happen is the browser crashes due to resource exhaustion. The phone is still usable so there isn’t a denial of service.

Google response re: Chromium:

We don’t consider DoS to be a security vulnerability. See the Chrome Security FAQ:

https://www.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs-

Mozilla / FireFox response has been to remove the security restriction on this bug, therefore indicating that this is not a security issue.

Steps to Replicate

(This is for Chrome but is similar for other browsers)

1. Install DNSMASQ and NGINX:
sudo apt-get install dnsmasq nginx
2. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):
192.168.1.x ss.ask.com
3. Configure /etc/dnsmasq.conf file to listen on the IP:
listen-address=192.168.1.x
4. Restart DNSMASQ:
sudo /etc/init.d/dnsmasq restart
5. Use fallocate to create a file in “/var/www/html/”
sudo fallocate -l 5G query
6. Modify DNS settings on the test machine or the same machine to point to “192.168.1.x”. If same machine, modify resolve.conf as follows:
nameserver 192.168.1.x
7. Start Chrome, go to settings and choose “Ask.com” as the default search provider.
8. Open new tab and try to type something in the omnibox.

References

Android bug reports: 214784 and 214785
Chromium bug reports: 624779 and 624794 (patch accepted)
FireFox bug reports: 1283675 and 1283672
OpenSearch description document: doc here
OpenSearch Suggestions extension v1.1: doc here
Safari Search Suggestions bug: see ArsTechnica story here

Credits

Researched and written by Yakov Shafranovich.

Timeline

2016-06-30: Bug filed with Android
2016-06-30: Bug filed with Chromium
2016-06-30: Bug filed Mozilla/FireFox
2016-06-30: Response from Chromium, Won’t Fix
2016-07-12: Response from Android, not a security issue
2016-07-13: Android team is ok with disclosure
2016-07-14: Mozilla removes security restrictions on the bug
2016-07-26: Public disclosure

Research: Securing Android Applications from Screen Capture


Summary — TL, DR

Apps on Android and some platform services are able to capture other apps’s screens by using MediaProjection API. Because of the way this API implements “securing” sensitive screens, there exist some possible security issues. The best way to secure your Android app is to use FLAG_SECURE on sensitive screens and DO NOT use the virtual keyboard (here is why).

MediaProjection API

Since Android 5.0, there exists a new MediaProjection API that allows apps to record videos and take screenshots of screens belonging to other apps. The API is described as follows:

Android 5.0 lets you add screen capturing and screen sharing capabilities to your app with the new android.media.projection APIs. This functionality is useful, for example, if you want to enable screen sharing in a video conferencing app. The new createVirtualDisplay() method allows your app to capture the contents of the main screen (the default display) into a Surface object, which your app can then send across the network. The API only allows capturing non-secure screen content, and not system audio. To begin screen capturing, your app must first request the user’s permission by launching a screen capture dialog using an Intent obtained through the createScreenCaptureIntent() method.

(On Android versions prior to 5, there are other methods such as undocumented APIs, and ADB, we are focusing on Android 5+)

This API also drives several other functions in the OS:

All of these functions as well as the MediaProjection API can take screenshots and videos of other apps. For apps to use the API, special permission is required, for platform features, no special permission is needed. Additionally, any applications signed by the system key (Google apps) can use this API without permission as well.

A good open source example of an application that uses the API can be found here:

https://github.com/JakeWharton/Telecine

Secure and non-secure content

As mentioned in the Google docs above, “the API only allows capturing non-secure screen content”. What exactly is “secure” and “non-secure” content?

This refers to a special flag which can be applied to views in Android, called FLAG_SECURE. It is described in Android docs as follows:

Treat the content of the window as secure, preventing it from appearing in screenshots or from being viewed on non-secure displays

Setting this flag on Android view will prevent screenshots from being taken manually, and any other app or platform service will show a black screen. This functionality is not global for the entire app, but can be set on specific screens which can be more sensitive, and not set on others. There is no other way or permission that can mark an entire app or any part of it from being excepted from screen capture or recording.

NOTE: Even on views marked with FLAG_SECURE, the virtual keyboard is ALWAYS visible. This is due to a known Android bug which Google has so far refused to fix:

https://code.google.com/p/android/issues/detail?id=129285

How screen capture really works in Android

The term “secure” as used in this context does not mean that the content of the app cannot be captured, rather that it cannot be “viewed on non-secure displays”. This is because screen capture and the concept of secure / non-secure isn’t what developers may think it is.

Behind the scenes, this API and related platform services use the concept of Casting (similar to AirPlay). Apps that capture screenshots and record videos, must create a virtual display to which then the device content is cast to. The FLAG_SECURE flag is also not used for security but rather means copyrighted content in context of DRM and displays — i.e. secure content would be something like a DVD, and a secure display would be an HDTV.

This is clear on the device itself — when an app begins to record the screen, the cast icon is turned on in the notification bar. This is also clear from the Android source code and this doc:

Display flag: Indicates that the display has a secure video output and supports compositing secure surfaces. If this flag is set then the display device has a secure video output and is capable of showing secure surfaces. It may also be capable of showing protected buffers. If this flag is not set then the display device may not have a secure video output; the user may see a blank region on the screen instead of the contents of secure surfaces or protected buffers.

That would means that an Android device casting to a DRM-protected display like a TV would always display sensitive screens, since the concept of secure really means “copyrighted”. For apps, Google forestalled this issue by preventing apps not signed by the system key from creating virtual “secure” displays, but not for physical devices. There is also an existing Android bug asking for the concept of DRM and screen security to be separated into different flags:

https://code.google.com/p/android/issues/detail?id=93026

Security issues with the current API

First of all, a basic foundation of mobile app security is a clear separation between apps. One Android app is should never able to read the preferences, data or capture cloud notifications of another app. This paradigm breaks down in case of screen capture/recording. An app gaining access to the MediaProjection API or any of the platform services using it, is able to capture screen output from other apps including PIN numbers, passwords, credit card numbers, etc.

Second, by using a flag used for marking copyrighted content, it would make it easier to subvert the system. Some ways this can be subverted include:

  • Gaining permissions to create a virtual display marked as secure would show all secure content. Right now this is preventable by using the system key, but a rooted phone or some other way that fools the system into creating such display would by pass this protection.
  • Also, casting to a physical secure display, or perhaps a wireless one, would also display content

Third, even with the FLAG_SECURE in use, some parts of the screen can still be captured. The virtual keyboard is one existing example, but there may be others (perhaps notifications?).

[ADDED 06/24/2016: Mark Murphy from CommonsWare points out several other issues with FLAG_SECURE child objects – see his blog post here]

Fourth, there is no clear indication to the user they are being recorded other than the cast icon. Clicking on the icon shows no devices since virtual devices aren’t going to be listed. A better warning may be needed.

A better solution as suggested in this bug report, would be to define a separate flag and never allow any app or system service to see its output under any reason, and also to blank out the entire screen even if other apps or service display anything on it. An even better solution would be to make this opt-in for apps, instead of opt-out.

Attack vectors

There are several possible avenues of attack which would result in an app being installed on a user’s phone recording their app activity. These include:

  • Malicious apps in the app store that masquerade as legit casting apps requiring record permission — since users don’t know that casting apps can also record their screen
  • Remote install via compromised desktop as described in this paper
  • Overlaying permission screens as described here

To record even non-secure screens, the following can be tried but they are not practically feasible:

  • On rooted phones, creating a virtual display marked as “secure”
  • Fooling the system into thinking that a given app is a system app, allowing it to create secure displays

All of these would result in an app sitting on the phone and recording user activity. However, other than the last two methods, FLAG_SECURE views would not be recordable, although the virtual keyboard is. The only indicator to the user would be the cast icon, but when they click on it, no devices would be listed.

Conclusion — Protect Your Apps

To protect your apps from being recorded by other apps, FLAG_SECURE should be used on any views containing sensitive data. Additionally, since the virtual keyboard is also vulnerable, it is recommended that these screens either use a custom keyboard, or if feasible to use an on-screen custom layout (for numeric input like PIN numbers).

We have surveyed many of the top apps in the Google Play store, and many of them including some Google-owned apps do not use FLAG_SECURE or if they do, do not secure the keyboard.

We also hope that Google would lock down this API and solve the issues highlighted in this article.

Credits

Researched and written by Yakov Shafranovich.

References

Google CID: 3–5606000008769

Advisory: Arro and Other Android Taxi Hailing Apps Did Not Use SSL

Overview

Arro and possibly over 100 other Android taxi hailing apps did not SSL to secure communications between the application and its servers.

Background

Arro is a taxi hailing service allowing users to hail yellow taxis in New York from their smartphones. The service also allows users to pay for their ride via the application while they are in a taxi. The underlying technology is a white branded version of an application called Taxi Hail, made by a company called Mobile Knowledge, in Ottawa, Canada, a subsidiary of Creative Mobile Technologies, LLC (CMT) of New York, NY. Both are providers of technology solutions for the taxi industry. At least 100 other white branded taxi applications run on the same platform as Arro, with a link to a non-exhaustive list appearing later in this document.

Details

While monitoring network traffic from an Android smartphone, we observed that most communications between the Arro Android application and servers was unencrypted and did not use SSL. Instead, regular HTTP calls were being used. Further investigation showed that the underlying application and servers were a white branded version of TaxiHail, developed by Mobile Knowledge.

Information observed included:

  • Username and passwords for the users of the application
  • User profile including address and phone number
  • Credentials for various APIs and payment gateways used by the application
  • Latitude and longitude of the user requesting a taxi
  • Last four digits and expiration date of the user’s credit cards on file
  • When adding a new credit card — full credit card information

Payments were made via a separate gateway that uses SSL and were not at risk. However, adding credit cards would be done without SSL.

A secondary minor issue was also discovered:

The GoArro app created a text log on the SD Card of the device being tested. This log, located in “/TaxiHail/errorlog.txt” contained GPS locations for the user, which would accessible to applications on the same phone without location access. This issue has also been fixed.

References

Arro website: https://www.goarro.com/
CERT/CC ID: VU# 439016
CMT website: http://creativemobiletech.com/
List of white branded apps: https://play.google.com/store/search?q=com.apcurium.MK&c=apps&hl=en
TaxiHail website: http://www.mobile-knowledge.com/products/passenger-solutions/taxihail/

Credits

This has been originally discovered and written by Yakov Shafranovich via collaboration with Shaftek Enterprises Security Research Team. Thank you to Garret Wasserman of CERT/CC for helping to communicate with the vendors.

Timeline

2015–10–14: Arro notified
2015–10–14: Initial vendor response
2015–10–15: Followup communications to Arro, no response
2015–10–20: CERT/CC notified
2015–10–23: CERT/CC response
2015–11–06: Mobile Knowledge acknowledged the problem via CERT/CC
2015–11–30: Fix deployed by vendor
2015–12–01: Fix confirmed
2015–12–08: Public disclosure, coordinated with CERT/CC