5
1 INTRODUCTION Today’s satellite navigation systems rely on constellations of satellites operating in medium earth orbits in several orbital planes. Each satellite broadcasts a signal containing orbital data and the precise time at which the signal was broadcast. The precise time is generated by a very accurate atomic clock on board the satellite. A satellite navigation receiver is able to determine its position very accurately from this information, if it is receiving signals from four or more satellites simultaneously. There are two types of satellite navigation system currently deployed – Regional Satellite Systems (RSS) or Global Navigation Satellite Systems (GNSS). GNSS constellations currently deployed include: • GPS - US system that became globally operational in 1994 and comprises up to 32 satellites deployed in 6 orbital planes • GLONASS – Russian Federation System comprising up to 31 satellites • Beidou – Chinese system comprising 15 satellites currently with 20 additional satellites planned. Currently Beidou is an RSS but is planned to be a full GNSS by 2020 • Galileo – European Union system planning to deploy 30 satellites in medium earth orbit in three orbital planes. Given our reliance on Global Navigation Satellite Systems (GNSS), in particular GPS, it is not surprising that its vulnerabilities are attracting a great deal of attention. In the past year there have been a number of well publicized incidents which have largely confirmed the theoretical and experimental work that predicted the vulnerabilities of GNSS. It is perhaps striking to review the evolution of threats to GNSS with the way threats in the Internet Protocol (IP) world developed. In a paper at ENC 2014 in Rotterdam, Theunissen [1] provided a compelling insight into the parallels between the manner in which IP threats have developed and the evolution of both jamming and spoofing attacks against GNSS. Theunissen argued that GNSS could reasonably expect the number of attacks against it to increase in the same manner that the number of internet hacking attacks has done in recent years, and that some of those attacks will likely become better organized. It is certainly becoming easier to mount attacks against GPS using jammers (as there are many sources of low cost jammers available to purchase online) or spoofers. Whilst it has often been stated that GNSS spoofing is too difficult and too expensive to undertake easily, this turns out not to be the case – in [2], Ghaddar et al demonstrated that GPS spoofing can be undertaken with an inexpensive Software Defined Radio (SDR). The authors stated that the aim of their project was “to prove that GPS is vulnerable to spoofing using commercial portable software radio platforms (e.g. NI-USRP 2920). In other words, we will use the NI- USRP 2920 to transmit GPS signals that override the actual satellite signals carrying a fake location of the GPS receiver.” The low signal strength of GNSS signals when received on the ground, is the reason that GNSS is vulnerable to attacks using the RF channel either to jam or spoof the target receiver. Sometimes the receiver is subject to unintended jamming or spoofing. TV transmitter harmonics can cause accidental jamming of GPS signals whereas a GPS repeater broadcasting on a GPS frequency could cause a nearby GNSS receiver to report an incorrect position. Consideration of the whole GNSS System as a whole, including ground stations, satellite uplinks and downlinks, augmentation systems and datalinks, is instructive as it allows us to see that in fact jamming and spoofing events are actually cyber-events, with GNSS jamming (if it causes receivers to cease functioning altogether) being the equivalent of a Denial of Service (DoS) event. In the event that multiple jammers, spoofers, or a combination of both are used, the attack would be equivalent to a Distributed Denial of Service (DDoS) attack. A cyber attack on the GNSS system could exploit the RF channels used by Receivers for GNSS signal reception, alternatively it could also (at least as easily) exploit the channel used by a Positioning, Navigation and Timing (PNT) system to report its position. In [3] Balduzzi showed how hackers could take advantage of the Automatic Identification System (AIS) employed by many vessels. As the datalink employed by AIS is unencrypted, the attacks that the author described are relatively straightforward to implement and in some cases could produce exactly the same results as a spoofing attack on the GNSS RF signal channel. Once it is understood that the evolution of GNSS threats does not only have clear parallels with the way that IP threats have evolved, but shares many of the features of a connected network, it can be seen that many of the lessons learned by the Information Security community apply equally as well to the GNSS community. GNSS Receivers and the Cyber –Threat: Lessons from the Information Security Community Guy Buesnel, David DeSanto, Spirent Communications

GNSS Receivers and the Cyber Threat

Embed Size (px)

Citation preview

Page 1: GNSS Receivers and the Cyber Threat

1

INTRODUCTION Today’s satellite navigation systems rely on constellations of satellites operating in medium earth orbits in several orbital planes. Each satellite broadcasts a signal containing orbital data and the precise time at which the signal was broadcast. The precise time is generated by a very accurate atomic clock on board the satellite. A satellite navigation receiver is able to determine its position very accurately from this information, if it is receiving signals from four or more satellites simultaneously. There are two types of satellite navigation system currently deployed – Regional Satellite Systems (RSS) or Global Navigation Satellite Systems (GNSS). GNSS constellations currently deployed include: • GPS - US system that became globally operational in 1994 and comprises up to 32 satellites deployed in 6 orbital planes • GLONASS – Russian Federation System comprising up to 31 satellites • Beidou – Chinese system comprising 15 satellites currently with 20 additional satellites planned. Currently Beidou is an RSS but is planned to be a full GNSS by 2020 • Galileo – European Union system planning to deploy 30 satellites in medium earth orbit in three orbital planes. Given our reliance on Global Navigation Satellite Systems (GNSS), in particular GPS, it is not surprising that its vulnerabilities are attracting a great deal of attention. In the past year there have been a number of well publicized incidents which have largely confirmed the theoretical and experimental work that predicted the vulnerabilities of GNSS. It is perhaps striking to review the evolution of threats to GNSS with the way threats in the Internet Protocol (IP) world developed. In a paper at ENC 2014 in Rotterdam, Theunissen [1] provided a compelling insight into the parallels between the manner in which IP threats have developed and the evolution of both jamming and spoofing attacks against GNSS. Theunissen argued that GNSS could reasonably expect the number of attacks against it to increase in the same manner that the number of internet hacking attacks has done in recent years, and that some of those attacks will likely become better organized. It is certainly becoming easier to mount attacks against GPS using jammers (as there are many sources of low cost jammers available to purchase online) or spoofers. Whilst it has often been stated that GNSS spoofing is too difficult and too expensive to undertake easily, this turns out

not to be the case – in [2], Ghaddar et al demonstrated that GPS spoofing can be undertaken with an inexpensive Software Defined Radio (SDR). The authors stated that the aim of their project was “to prove that GPS is vulnerable to spoofing using commercial portable software radio platforms (e.g. NI-USRP 2920). In other words, we will use the NI-USRP 2920 to transmit GPS signals that override the actual satellite signals carrying a fake location of the GPS receiver.” The low signal strength of GNSS signals when received on the ground, is the reason that GNSS is vulnerable to attacks using the RF channel either to jam or spoof the target receiver. Sometimes the receiver is subject to unintended jamming or spoofing. TV transmitter harmonics can cause accidental jamming of GPS signals whereas a GPS repeater broadcasting on a GPS frequency could cause a nearby GNSS receiver to report an incorrect position. Consideration of the whole GNSS System as a whole, including ground stations, satellite uplinks and downlinks, augmentation systems and datalinks, is instructive as it allows us to see that in fact jamming and spoofing events are actually cyber-events, with GNSS jamming (if it causes receivers to cease functioning altogether) being the equivalent of a Denial of Service (DoS) event. In the event that multiple jammers, spoofers, or a combination of both are used, the attack would be equivalent to a Distributed Denial of Service (DDoS) attack. A cyber attack on the GNSS system could exploit the RF channels used by Receivers for GNSS signal reception, alternatively it could also (at least as easily) exploit the channel used by a Positioning, Navigation and Timing (PNT) system to report its position. In [3] Balduzzi showed how hackers could take advantage of the Automatic Identification System (AIS) employed by many vessels. As the datalink employed by AIS is unencrypted, the attacks that the author described are relatively straightforward to implement and in some cases could produce exactly the same results as a spoofing attack on the GNSS RF signal channel. Once it is understood that the evolution of GNSS threats does not only have clear parallels with the way that IP threats have evolved, but shares many of the features of a connected network, it can be seen that many of the lessons learned by the Information Security community apply equally as well to the GNSS community.

GNSS Receivers and the Cyber –Threat: Lessons from the Information Security

Community Guy Buesnel, David DeSanto, Spirent Communications

Page 2: GNSS Receivers and the Cyber Threat

2

THE GNSS COMMERCIAL MARKET The use of GNSS has become almost pervasive in many sectors with the global installed base of GNSS devices passing 2 billion devices in 2013 and predicted to reach 7 billion units by 2022, an almost four-fold increase that would equate to almost one for every single person on the planet [4]. GNSS is already used by critical infrastructure such as utility providers, financial, transport sectors to provide timing or positional data and growth in new and market spaces such as the Intelligent Transport sector will use GNSS to provide data for use in safety critical applications. In all of these market segments the security of GNSS is of high importance as a hacking attack could achieve more than just reputational damage. In all of the applications where 4-dimensional information is required to enable system operation, the use of precise timing from GNSS will be essential for time stamping of transactions and significant damage could occur if incorrect time information is propagated. GNSS THREATS The GLONASS outage that occurred in April 2014 is an event that deserves some attention. In April 2014 (01 April) the entire GLONASS constellation commenced the transmission of incorrect broadcast messages. The messages were highly inaccurate (up to 200km). Whilst two of the satellites were corrected within an hour, the problem persisted much longer for the other orbiting satellites and problems lasted into 02 April. Many GPS + GLONASS Receivers were affected, in one way or another, with some systems completely failing to track both GLONASS and GPS satellites. Other GPS+ GLONASS Receivers were unaffected and continued to track normally. The reason for the failure is still unclear but has been attributed to incorrect software being uploaded to the GLONASS satellites. Whilst this event was attributable to human error, it is also clear that such an event could be caused by a malicious attack, which would probably require insider knowledge to carry out. The consequence of this event was a DDoS which affected many GNSS Receivers that used GLONASS satellites in their PNT solution. GPS jamming has become prevalent recently with many reports from Europe and around the world suggesting that the use of cigarette lighter type jammers in vehicles to avoid tracking has become widespread. Whilst these trackers are often advertised as having very limited range (in the order of 2m or so), this is for saturating the GPS Receiver input with RF interference so that it ceases to function. However many of the effects caused by jamming are more subtle. The output of hazardously misleading information and the fact that detection systems are able to pick up signals from the jammer at considerably greater distances tends to suggest that the ranges at which these small, portable jammers can cause disruption to GNSS receivers is much greater than the figure that is quoted in their specification. Whilst no instance of a deliberate spoofing attack has been confirmed thus far (excluding for demonstration or experimental purposes), it should be noted that there have

been instances of unintended spoofing being reported. Unintended transmission of incorrect GNSS signals can occur with use of a GNSS Repeater or similar which is radiating at a higher power level than the authentic GNSS signals. This can cause a GNSS receiver to lock onto the incorrect signals and report the position of the repeater as being the user position. Use of GPS repeaters in unsuitable locations, such as for production tests in an open workshop, have been reported to these authors. The risk is not just that GNSS interference could extend outside the building and affect users, but that a GPS receiver could be spoofed and tricked into reporting an incorrect position. Whilst there has been no official confirmation of a deliberate spoofing attack so far, [6] presented an interesting account of the Global Fishing Watch project. Global Fishing watch has been set-up to monitor illegal fishing boats globally and in real time. In this article it is claimed that there has been a 59% increase in the number of ships transmitting incorrect positioning over the past two years. An example is shown where a Satellite AIS Receiver, with a receiver footprint covering the Atlantic Ocean, is receiving data from two ships in the Pacific Ocean. As it is physically impossible for transmissions from AIS transponders in the Pacific Ocean to be received by this satellite, it is clear that they are spoofing their position in some manner. The author of the article believed that false navigational data had been entered into these ships’ AIS transmitter; however it is equally possible that the GPS receiver itself had been spoofed. EVOLUTION OF EXPLOITS AND VULNERABILITIES IN THE INFORMATION SECURITY COMMUNITY There has been much debate within the Information Security community for the past twenty years on how exploits targeting vulnerabilities within products were disclosed. Initially, these exploits were kept hidden and only shared amongst groups of hackers or security researchers. With the birth of online forums like Bugtraq [7], the world of full disclosure was born. These online forums allowed the creators of exploits of various levels of maliciousness to post their findings along with sample code for the users of the Internet to access. This allowed everyone from security researchers and enterprise administrators along with hackers to access details about vulnerabilities within applications and critical systems. Also, with this new level of unprecedented access, security researchers and hackers alike could earn levels of credibility for their findings. This validation continued the cycle with more and more public disclosure of vulnerabilities and the birth of additional online outlets for release of exploit content including mailing lists like the full disclosure mailing list in July 2002 [8]. With the proliferation of available exploit content along with information on its intended target, proof-of-concept (PoC) code started becoming the basis of more advanced tools including automation of attacks targeting these vulnerable targets lowering the bar for entry into the world of exploitation. The best definition of full disclosure comes from Jay Heiser in “Exposing Infosecurity Hype” [9] where he stated “The term ‘full disclosure’ is marvelously ambiguous,

Page 3: GNSS Receivers and the Cyber Threat

3

and therein lies much of the problem. It essentially means to ‘widely disseminate as much information about system vulnerabilities and attack tools as possible so that potential victims are as knowledgeable as those who attack them.’” Full disclosure, by its very nature, exposed the vulnerability to the product vendor the same time it did to the enterprise as well as the community at large (which included hackers). This was very unpopular amongst some enterprises, security researchers and product vendors who did not feel that exploit code needed to be available in wide distribution to help resolve vulnerabilities. Furthermore, it was aiding someone who had more of a nefarious purpose than it was an enterprise that wanted to validate that they were protected or vulnerable. Scott Culp discussed this issue in his paper “It’s Time to End Information Anarchy” [10] and began to build upon the building blocks of what is known today as responsible disclosure. Responsible disclosure, or coordinated disclosure, builds upon the core concept that security researchers should notify product vendors like is done with full disclosure. The main difference is that this disclosure is coordinated between the discoverer of the vulnerability and the product vendor affected first. This allows the affected vendor to begin preparing a software patch or update prior to the public announcement of the vulnerability. Once a reasonable amount of time has passed, the vulnerability is announced and sometimes is accompanied by a statement by the product vendor that a fix is available immediately or will be available soon. Responsible disclosure, like full disclosure, does include its flaws. Two main criticisms involve time to announcement of the vulnerability and research compensation. With responsible disclosure, it may take the product vendor days to months to patch the vulnerability (depending on the complexity). This leads to a false sense of security for the current users of the product who do not know this vulnerability exists until it is announced. Also, there is no financial compensation for the security researcher who has decided to release this vulnerability through responsible disclosure. This has been addressed through commercial vulnerability brokers like the Zero Day Initiative (ZDI) [11] who purchases the exploit and vulnerability research from the security researcher and then follows a responsible disclosure process to coordinate and announce the vulnerability. Even with full and responsible disclosure, there are parts of the Information Security community, including product vendors and security researchers, which believe that nondisclosure is still the best policy. The belief is that keeping this information secret will protect the enterprise better than full or responsible disclosure. With nondisclosure, the product vendor can address the vulnerability and release updates without public knowledge of exploitability. Vendors who build and commercialize exploit-based solutions also favor nondisclosure. Nondisclosure gives a false sense of security as the vulnerability is not disclosed in any fashion. As it is not disclosed, this means that there is no knowledge of who knows what within the Information Security community and there may be exploits targeting vulnerabilities in which

the product vendor may be unaware. Nondisclosure may, at times, be the equivalent to the ostrich sticking its head in the sand. HOW THE INFORMATION SECURITY COMMUNITY MANAGES VULNERABILITIES Regardless of the use of full or responsible disclosure, reported vulnerabilities need a system by which to track and measure items such as severity. Furthermore, there should be multiple ways for reporters to submit their found vulnerabilities. Common Vulnerabilities and Exposures (CVE) system [12] is a system maintained by the MITRE Corporation and vulnerabilities enumerated by CVE IDs are listed in multiple online repositories including the United States National Vulnerability Database (NVD) [13]. The CVE system was founded in 1999 to help bring common, standardized identifiers and metrics to vulnerabilities and exploits where initially every vendor and reporter handled everything differently. Each CVE ID provides a unique identifier, a description of the vulnerability, available PoC code when available and any pertinent resources. The CVE database is available free for public download and use. The CVE system, including its free availability, includes several other key components. It is comprised of participating CVE Numbering Authorities (CNA) which include MITRE, software vendors like Adobe, Microsoft, Cisco and Google as well as third-party coordinators including CERT/CC. It also includes a scoring system, Common Vulnerability Scoring System (CVSS), which is used for assessing the severity of the vulnerability on a scale of 0 to 10 with 7 to 10 considered high. The assessment criteria [14] measures the base metrics including the access vector, temporal metrics including the availability of exploitation techniques and environmental metrics including the collateral damage potential. MITRE outlines the CVE ID reservation process on their website [15]. The process is: • The security researcher, product vendor or incident response team requests the amount of CVE ID numbers needed • MITRE reserves the CVE ID(s), provides them to the requester and creates blank, content-free CVE ID(s) on the CVE website • The requester shares the provided CVE ID(s) with all parties involved • The requester includes the CVE ID(s) in all advisories • The requester makes the CVE ID(s) public and notifies MITRE • MITRE updates the CVE ID(s) on the CVE website to include the provided details For researchers who choose to not go through responsible disclosure and choose to pursue full disclosure, posts to forums such as Bugtraq will also receive CVE IDs. These will not go through the same coordination process listed above however will still end up within the same standardized structure the CVE system provides.

Page 4: GNSS Receivers and the Cyber Threat

4

A POSSIBLE REPORTING FRAMEWORK FOR GNSS VULNERABILITIES Following the assertion that vulnerability disclosure is in fact the correct course of action, responsible disclosure would outline the best option for the GNSS community. This will allow security researchers and product vendors to disclose vulnerabilities publicly. There are several options on how to properly set up a reporting framework for GNSS vulnerabilities. The GNSS community can build its own solution separate from the Information Security community where it can control the reporting structure and leave the system as close to nondisclosure as possible. This may limit product vendor exposure however as outlined this leads to a false sense of security. A reporting framework that is too closed will not support a community of researchers that are trying to improve the security of the GNSS industry. A reporting framework for GNSS vulnerabilities that leverages existing vulnerability reporting systems will allow the GNSS community to follow responsible disclosure practices. This reporting framework might include the following components: • Partner with MITRE to get the GNSS community set up in the CVE system • Communicate with incident response teams like CERT/CC and provide processes for working with GNSS product vendors on vulnerability disclosure • Identify key stakeholders within the GNSS community to become CNAs • Create a website similar to Open Sourced Vulnerability Database (OSVDB) [16] dedicated to GNSS vulnerabilities managed by the GNSS community with its own identifiers LESSONS THAT GNSS COULD LEARN FROM THE INFORMATION SECURITY COMMUNITY The GNSS community needs to act to not find to itself in the same place at the Information Security community did in the early stages of vulnerability disclosure. It is very easy to default to nondisclosure however this leaves customers and product vendors exposed to unknown vulnerabilities. The GNSS community has the advantage that the Information Security community has been working through these hurdles, and continues to, for the past two decades. Below are some lessons learned which the GNSS community can leverage: • Responsible disclosure allows everyone to win • Without some form of proper disclosure, threat actors will take the known threats and use them to leverage against consumers and product vendors • Disclosure of vulnerabilities within your product does not lead to credibility issues • Time to resolution is the key • Building a community-based framework will lead to better adoption within the community The GNSS community has an opportunity to come together, learn from the Information Security Community and adopt best practices to secure its customers.

REFERENCES [1] So you think you are safe, Theunissen, E, ENC 2014, Netherlands [2] Exposing GPS Vulnerabilities: Spoofing with Programmable Software Radios, Nadim Ghaddar, Marwan Mattar, Abdul-Amir Yassine, American University of Beirut, Online, https://feaapps.aub.edu.lb/feasac_submissions/fullpapers/2/660_Exposing%20GPS%20vulnerabilities_Spoofing%20with%20Programmable%20Software%20Radios.pdf [3] AIS Exposed Understanding vulnerabilities and attacks 2.0, Balduzzi, M, Wilhoit, K, Pasta, A, Trend Micro Research, Blackhat Asia 2014 [4] GNSS Market Report, Issue 3, European GNSS Agency (GSA), October 2013 [5] Jamming and Spoofing in GPS/GNSS Based Applications and Services – Threats and Counter Measures, Cuntz, M, Konovaltsev, A, Dreher, A, Meurer, M, Institute of Communications and Navigation, German Aerospace Center (DLR), Future Security: 7th Security Research Conference, Future Security 2012 [6] Spoofed Satellite Feeds Trouble Google’s Global Fishing Watch, Neal Ungerleider, Fast Feed, Online http://www.fastcompany.com/3038863/fast-feed/spoofed-satellite-feeds-trouble-googles-global-fishing-watch [7] Vulnerability Disclosure – How do we define Responsible Disclosure?, Shepherd, S., https://www.sans.org/reading-room/whitepapers/threats/define-responsible-disclosure-932 [8] Full Disclosure Mailing List – http://seclists.org/fulldisclosure/ [9] Exposing Infosecurity Hype, Heiser, J., Information Magazine, Online (from Wayback Machine), http://web.archive.org/web/20010203140700id_/http://infosecuritymag.com/articles/january01/columns_curmudgeons_corner.shtml [10] It’s Time to End Information Anarchy, Culp, S., Microsoft TechNet, Online (from Wayback Machine), http://web.archive.org/web/20011109045330/http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/noarch.asp [11] HP TippingPoint Zero Day Initiative – http://www.zerodayinitiative.com/ [12] Common Vulnerabilities and Exposures – https://cve.mitre.org/about/index.html [13] National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) – http://nvd.nist.gov/ [14] A Complete Guide to the Common Vulnerability Scoring System Version 2.0, Mell, P., Scarfone, K., Romanosky, S., Online, https://www.first.org/cvss/cvss-guide [15] Introduction to CVE Identifier Reservation – https://cve.mitre.org/cve/cna.html [16] Open Sourced Vulnerability Database (OSVDB) – http://osvdb.org/

Page 5: GNSS Receivers and the Cyber Threat

5

Guy Buesnel CPhys, AFRIN Market Segment Leader – Robust Positioning, Navigation and Timing Spirent Communications Guy has more than 16 years’ experience working protecting GNSS Receivers from emerging threats, having started his career as a Systems Engineer involved in developing GPS Adaptive Antenna Systems for Military Users at Raytheon Systems Limited in the UK. In 2007, Guy became European GNSS Product Line Manager at Rockwell Collins UK, responsible for UK and European GNSS Development activities, before moving to the Satellite Applications Catapult in June 2013 as Principal Satellite Navigation Systems Architect. In May 2014, Guy joined Spirent as Market Segment Manager–GNSS Vulnerabilities. Guy is responsible for developing Spirent’s approaches to Robust PNT including the development of test solutions for GNSS Jamming, Spoofing and Cyber-attack. Guy is a Chartered Physicist, a Member of the Institute of Physics and an Associate Fellow of the Royal Institute of Navigation. Guy is also a keen blues guitarist. David DeSanto Director, Product Management – Application Security Spirent Communications David is a network security professional with over 15 years of product management, security testing, software development and strategic innovation experience. At Spirent, David focuses on driving innovation by looking holistically at security testing and defining product requirements with the primary goal of making all results repeatable. David is a strong technical leader with firm understanding of TCP/IP as well as multiple layer 7 protocols including HTTP, SMTP and SIP. Prior to Spirent, David was the Director, Product Management at NSS Labs where his expertise guided the organization in creating leading security tests and solutions for enterprises, services providers and network equipment vendors. Prior to NSS, David was the Chief Innovation Strategist at ICSA Labs where he set the organization’s direction for testing Network Firewall, Web Application Firewall, Network IPS, IPSec VPN, Anti-Spam, Network Anti-Virus, Groupware Anti-Virus and other security technologies.