[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