[Also posted online: https://wwws.nightwatchcybersecurity.com/2016/12/05/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. Background a GPS and gpsOneXtra Most mobile devices today include ability to locate themselves on the Earthas 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 Russiaas GLONASS, Europeas Galileo, and Chinaas 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. Background a 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 a gpsonextra.net and izatcloud.net are owned by Qualcomm. Further inspection of those URLs indicate that both domains are being hosted and served from Amazonas 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 a XTRA 1.0 files, providing GPS assistance data (protected by a CRC checksum) - xtra2.bin a XTRA 2.0 files, providing GPS and GLO assistance data (protected by a CRC checksum) - xtra3grc.bin a 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 a 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 a 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. (see also our earlier advisory on CVE-2016-5348 about how large XTRA data files can be used to crash Android devices remotely) 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. Mitigation Steps For Android devices, users should apply the 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 Qualcommas servers. References Android security bulletin: December 2016 CERT/CC tracking: VR-179 CVE-ID: CVE-2016-5341 Google: Android bug # 211602 / AndroidID-7225554 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 2016a05-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