The Dangers of Plain HTTP Links in Mobile Apps

November 27, 2017 nightwatchcyber Research Android

When dealing with browser security, there is a concept called “the line of death“. This concept means that a user can only trust content that appears within the browser’s address bar or above, and nothing below that line (there is an excellent article from Eric Lawrence who is a Chrome developer explaining this in detail). What that means is that users can click on content above that line safely, but not below since the content appearing below the line may be fake or modified by the attacker. However, it is clear that the rest of the browser UI including menus, settings sections, about box, etc. are static and should be static and safe (unless modified by extensions).

The same concept would apply to mobile apps – part of the UI that are static should be safe as well, although it is harder to tell the static and non static parts apart. This leads add to the issue at hand – what happens when the static parts of the app have hyperlinks that don’t use HTTPS? A user of the app would normally trust those links but if they are on a hostile network, clicking on a plain HTTP link would in fact expose them to a potential MITM attack either via DNS hijacking or MITM interception. That means that if they are using a network where the attacker controls the DNS or the network connection itself, these links can be easily hijacked. You can easily image a scenario, where an attacker blocks WhatsApp or Facebook traffic but redirects users who use the HTTP versions to their own malicious site.

On the other hand, when HTTPS is used for these links, the mobile browser will check if SSL certificates are being served on that link, and whether they are signed by a real CA.

Thoughts?

Advisory: Private Internet Access (PIA) Android App Can Be Crashed via Large Download [CVE-2017-15882]

October 25, 2017October 25, 2017 nightwatchcyber Advisories Android, pia, vpn

Summary

The Android application provided by Private Internet Access (PIA) VPN service can be crashed by downloading a large file containing a list of current VPN servers. This can be exploited by an MITM attacker via intercepting and replacing this file. While the file is digitally signed, it is not served over SSL and the application did not contain logic for checking if the provided file is very large.

The vendor has fixed this issue in v1.3.3.1 and users should install the latest version. MITRE has assigned # CVE-2017-15882 to track this issue.

Vulnerability Details

Private Internet Access (PIA) is a commercial VPN service operated by London Trust Media, Inc. The vendor provides a privacy service to encrypt Internet connections via VPN tunnels and have them terminate on anonymous IP addresses. PIA provides official clients for multiple operating systems including Windows, Chrome, macOS, Linux, iOS and Android.

While monitoring network traffic of a test device running Android, we observed that the official PIA Android client application downloaded from the Google Play store made network calls to a PIA server to retrieve a list of current VPN servers in JSON format. This call was done over HTTP without the use of SSL / TLS. However, the resulting server file was digitally signed via a base-64 encoded signature appearing on the bottom of the file. Example URL:

https://www.privateinternetaccess.com/vpninfo/servers?version=60&os=android

File layout:

[JSON packet with server info]
[newline]
[Base-64 encoded signature]

Because the file download is done without SSL / TLS, it is possible for an MITM attacker to intercept this traffic and inject their own data. If the data packet is larger than the memory on the device, the application will crash since it did not include a size check to avoid large downloads.

Because of the digital signature, we were not able to modify the actual server data within the JSON packet but we were successful in crashing the application by injecting a large packet.

Steps To Replicate (on Ubuntu 17.10)

1. Install the PIA application on the Android device, sign up for an account and login via the application. DO NOT activate the VPN. Flick away the app.

2. Install dnsmasq and NGINX on the Linux host:

sudo apt-get install dnsmasq nginx

3. Modify the /etc/hosts file to add the following entry to map PIA’s domain name to the Linux host:

192.168.1.x www.privateinternetaccess.com

4. Configure /etc/dnsmasq.conf file to listen on the IP and restart DNSMASQ

listen-address=192.168.1.x
sudo /etc/init.d/dnsmasq restart

5. Use mkdir and fallocate to create a large server file in “/var/www/html/” (you may need to use sudo):

cd /var/www/html
mkdir vpninfo
cd vpninfo
fallocate -l 2.5G servers

6. 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 Linux computer and serve the large servers file

7. Re-open the PIA app and observe the crash.

All testing was done on v1.3.3 of the Android application using a Linux host running Ubuntu v17.10 and Android test devices running Android v7 and v8.

Vendor Response and Mitigation

To fix this issue, the vendor (London Trust Media / PIA) had added a size check when downloading and processing the file containing a list of VPN servers. This fix is available in v1.3.3.1 or later, and has been deployed to the Google Play store. Users should install the latest version to fix this issue.

Bounty Information

This bug has fulfilled the requirements of the vendor’s bounty program and a bounty has been paid.

References

CVE-ID: CVE-2017-15882
CWE: CWE-400 – Uncontrolled Resource Consumption (‘Resource Exhaustion’)

Credits

We would like to thank the vendor for the quick turnaround and fix for this vulnerability. Text of the advisory written by Yakov Shafranovich.

Timeline

2017-10-03: Email sent to support about the process for reporting security issues because we were not aware of their disclosure guidelines
2017-10-18: Initial reply from the vendor asking for more information
2017-10-18: Information about vulnerability provided to the vendor
2017-10-20: Follow-up communication with the vendor confirming the vulnerability in the latest version; vendor acknowledgement of the vulnerability
2017-10-21: Follow up communication with the vendor
2017-10-22: Fixed version provided by the vendor for testing; fix confirmed
2017-10-23: Bounty payment received
2017-10-24: Follow-up communication regarding public disclosure; fixed version deployed to the app store
2017-10-24: Draft advisory provided to vendor for review
2017-10-25: Public disclosure

Zoho Site24x7 Mobile Network Poller for Android Didn’t Properly Validate SSL [CVE-2017-14582]

September 27, 2017 nightwatchcyber Advisories Android, zoho

Summary

Zoho Site24x7 Mobile Network Poller for Android did not properly validate SSL certificates, and accepted self-signed certificates. This can potentially result in exposure of sensitive data including usernames and passwords to an MITM attacker. The vendor fixed this issue and users should install the latest version (1.1.5 or above). MITRE has assigned CVE-2017-14582 to track this issue.

Details

Zoho Corporation is a SAAS provider of business applications including a service called Site 24×7 for monitoring uptime of websites. As part of this service, the vendor makes available an Android application that can act as a mobile poller to monitor and feed data into the Site 24×7 service. This application requires a Zoho account to use it.

While performing network level testing, we discovered that the calls made by the application to the server during login did not properly validate SSL and accepted self-signed certificates. This potentially exposed the usernames and passwords of those using the app to an MITM attacker.

To replicate the issue on v1.1.4:

Install the application on the device.
Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
Start the proxy. At this point all network traffic will be going through the proxy with the SSL traffic being encrypted by a self-signed certificate which is not trusted by the device.
Go back to the app, and try to login.
Flick away the application.
Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application version 1.1.4. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Screenshots appear below:

screen1 screen2

Vendor Response

The issue was reported to the vendor via their bug bounty program. The vendor fixed the issue in v1.1.5 and released the fixed application in Google Play.

References

CVE ID: CVE-2017-14582
Google Play Link: Google Play Store
Zoho Bug Reference # ZVE-2017-0879

Bounty Information

This bug satisfied the requirements of the Zoho Bounty program and a bounty payment is pending.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-09-10: Initial report to the vendor
2017-09-18: Vendor is working on a fix
2017-09-20: Fixed version released to the Play store
2017-09-20: Re-test on the fixed version
2017-09-23: Request for publication sent
2017-09-27: Request for publication granted
2017-09-27: Public disclosure

UI Changes to WhatsApp for Android Mitigate CVE-2017-8769

September 6, 2017 nightwatchcyber Advisories Android, whatsapp

Details available in our updated advisory here

Chrome for Android Didn’t Use FLAG_SECURE for Credit Card Prefill Settings [CVE-2017-5082]

July 27, 2017 nightwatchcyber Advisories Android, chrome, google

Summary

Chrome for Android did not use the FLAG_SECURE flag in the credit card prefills settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in Chrome M59. Google has assigned CVE-2017-5082 to track this issue.

Details

Chrome for Android is a version of the Chrome browser for Android platforms. It used to be part of the Android OS, but is now a separate application deployed by Google through the Google Play store. Chrome has a credit card pre-fills section in settings where users can store credit card information that can be used to pre-fill certain forms.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the credit card prefills section in Chrome for Android did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likehood of exploitation is low.

To reproduce:
1. Open Chrome.
2. To go Settings, Autofill and payments, Credit Cards.
3. Tap on “Add credit card”.
4. Press Power and volume down to capture screenshot.
5. Confirm that a screenshot can be taken.

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Chrome v58.0.3029.83 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in Chrome release M59 and assigned CVE-2017-5082 to track it.

References

CVE ID: CVE-2017-5082
Chromium Bug # 721579

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-15: Issue patched by the vendor
2016-05-30: CVE assigned by the vendor
2016-06-05: Fixed version released
2016-07-16: Request for public disclosure sent to the vendor
2017-07-26: Permission to disclose received
2017-07-27: Public disclosure

Boozt Fashion Android App Didn’t Use SSL for Login [CVE-2017-11706]

July 27, 2017 nightwatchcyber Advisories Android, boozt

Summary

Boozt Fashion App for Android did not use encryption (SSL) for information transmission during login, exposing usernames and passwords to anyone monitoring the network. The vendor fixed this issue and users should install the latest version (2.3.4 or above). MITRE has assigned CVE-2017-11706 to track this issue.

Details

Boozt Fashion / Boozt.com is a Nordic-based, EU-spanning online store selling various fashion brands. The vendor makes available an Android application that allows users to shop, checkout and pay for their orders.

While performing network level testing, we discovered that the calls made by the application to the server during login did not use any kind of encryption (SSL). This potentially exposed the usernames and passwords of those using the app to a network-level attacker. According to the vendor, financial information like credit card numbers were not exposed since SSL was used during the checkout process.

To replicate the issue on v2.0.2:

Install the application on the device (may be restricted to EU-only users and require sideloading).
Open the application, tap on the “person” icon until you reach the login screen.
Setup an MITM proxy but do not install the SSL certificate on the device (we used PacketCapture).
Start the proxy. At this point all network traffic will be going through the proxy with the SSL traffic being encrypted by a self-signed certificate which is not trusted by the device.
Go back to the app, put in a fake username and password, and tap the Login button.
Flick away the application.
Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application version 2.0.2. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Vendor Response

The issue was reported to the vendor via HackerOne. The vendor provided the following comments:

Thanks for the report. At the moment that is an accepted risk. We only have https on the checkout part of the site (most sensitive). However we have a planned change in the roadmap regarding HTTPS introduction in the customer login part.

…

We are not arguing that the report is not valid. We just inform you that based on our program guidelines this is considered as non-qualifying report. This is because we are aware of the issue and are already working on rolling HTTPS through out the site.

Follow-up testing in July 2017 showed that this was fixed in current version (2.3.4) but may have been fixed earlier as well.

References

CVE ID: CVE-2017-11706
Google Play Link: Google Play Store (may not be available outside of Europe)
HackerOne Report # 166712

Bounty Information

The vendor classified this bug as being outside the guidelines of their bounty program and no bounty was paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-09-07: Initial report to the vendor via HackerOne
2016-09-08: Report triaged by the vendor and closed via HackerOne
2016-09-08: Follow-up communication with the vendor via HackerOne
2016-09-18: Request for disclosure sent via HackerOne
2016-09-19: Follow-up communication with the vendor via HackerOne
2017-07-27: Public disclosure request granted via HackerOne
2017-07-27: Re-testing, CVE request and publication

Advisory: Google’s Android News and Weather App Doesn’t Always Use SSL [CVE-2017-9245]

July 18, 2017 nightwatchcyber Advisories Android, google

Summary

Google News and Weather Application for Android does not use SSL for some server calls, exposing authentication tokens (OAuth) to anyone monitoring the network. It is not clear if the tokens belong to the user’s account or a service account. The vendor (Google) fixed the issue in v3.3.1 of the application and users should install the latest version. MITRE has assigned CVE-2017-9245 to track this issue.

Details

The Google News and Weather application for Android is an application developed by Google which aggregates news from multiple sources. This application was originally included as part of the stock Android operating system but was separated into its own application around August 2014.

While performing network level testing of various Google applications, we discovered that some of the calls made by the application to Google’s server did not use SSL. Furthermore, analysis of the captured traffic showed that an authentication token (OAuth) was sent as part of those calls, thus exposing it to an attacker that is monitoring the network. It is not clear from our testing whether this token belonged to the user using the application, or was some sort of a service account.

We also did not test earlier versions of the application, so it is also unclear whether this issue affects older versions of Android where this is part of the stock operating system.

To replicate the issue on v3.1.4:

Install the application and open it.
Flick away the application.
Setup the proxy without an SSL certificate and point the Android device to it.
Go back to the application and select any news feed, and then click on a news article from a site that doesn’t use SSL.
Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application v3.1.4. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Screenshots below – note that sensitive data has been blanked out:

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 3.3.1 which was released in late June 2017. It is not clear if older versions of Android that include this as part of the OS are affected and/or fixable.

References

CVE ID: CVE-2017-9245
News and Weather App: Google Play Store

Bounty Information

This bug satisfied the rules of the Google Vulnerability Reward Program (VRP) program and a bounty was paid.

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-26: Bounty decision received from vendor
2017-06-29: Fixed version released by the vendor
2017-07-12: Fixed version tested to confirm the fix
2017-07-12: Draft advisory sent to vendor for comment
2017-07-18: Public disclosure

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

May 17, 2017December 10, 2017 nightwatchcyber Advisories Android, facebook, whatsapp

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.

[UPDATE: 09/06/2017 – a recent update to WhatsApp for Android now displays an option to delete media files when deleting chats and that option is checked by default. The change to the UI mitigates the issues discussed in this advisory. Users are encouraged to update to v2.16.323 or later.]

[UPDATE: 12/05/2017 – the checkbox to delete media files when deleting chats doesn’t always work. Users are encouraged to delete the WhatsApp directory on the SD card using a file manager to make sure all media files are removed and be aware of issues with erasing flash memory in general. Facebook has refused to acknowledge this as a security issue and has not plans to fix it.]

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/

To replicate the issue:

Install WhatsApp for Android.
Login and exchange messages with another user that contain any of the file type listed above.
Then, install any file manager for Android.
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.

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.

[UPDATE: 09/06/2017] – a recent update to WhatsApp for Android now displays an option to delete media files when deleting chats and that option is checked by default. The change to the UI mitigates the issues discussed in this advisory. Users are encouraged to update to v2.16.323 or later.

New response from the vendor:

>> We published on this back in May. It looks like that the most recent version of WhatsApp for Android adds a mitigation for this issue. Can you confirm?

Yes, The WhatsApp team indeed added a background job to clear media.

Screenshots of the new UI:

New response from the vendor:

Thank you clarifying more. According to the post you linked to, Facebook had informed that the CVE-2017-8769 was not considered a security risk. Since what you describe doesn’t appear to be a security vulnerability, you can report a general software bug by contacting WhatsApp at: [email protected]

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
2017-09-06: Updated with details of the new UI changes in the Android app that mitigate these issues
2017-09-11: Email exchange with the vendor

2017-12-05: Followup exchange with the vendor

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

May 17, 2017May 17, 2017 nightwatchcyber Advisories Android, google, io17

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:

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

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

Network traffic captures appear as follows:

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:

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:

Install nginx – “sudo apt-get install nginx”.
Install dnsmasq – “sudo apt-get install dnsmasq”
Find out the IP address of your computer via ifconfig.
Add the IP address mapping to the hosts file: “192.168.1.x storage.googleapis.com”
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
Modify “blocks_v4.json” to add your content.
Install version 5.0.3 of the application on the Android device.
Change DNS on the device to point to the Ubuntu machine.
Open the app, skip sign in, and on the main screen choose the feed icon.
Switch back to the first section and observe injected content:

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]

December 5, 2016December 7, 2016 nightwatchcyber Advisories Android, gps, qualcomm

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