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:

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:

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