Moderator


3689427289?profile=original

Slashdot is carrying a story about new research published by the good folks at Carnegie Mellon and Coherent Navigation detailing a series of classes of GPS attacks beyond those previously demonstrated. 

Of particular note to this community, the research details vulnerabilities found in the uBlox 6H GPS receiver. 

The researchers go beyond the typical jamming and spoofing techniques, and also examine weaknesses in GPS messaging and in attacks against the embedded operating systems and applications which communicate with the GPS modules. 

The uBlox 6H does not fair as badly as some of the other modules, and besides spoofing, the only other identified issues is described as "Vulnerable Week #"

3689490884?profile=original

"Vulnerable Week Number Date calculations in GPS receivers are done using the Z-count, which consists of a 10 bit Week Number (WN) and 9 bit Time of Week field.

In our attack, we first set the week number to be one past the current week. No other data was changed in the navigation mes- sage. When the ephemeris expired (the IODC and IODE changed), all receivers except the eXplorist accepted the new week number. We were then able to set the week number to any value in the 10 bit range."

 

The researchers present a series of recommendations to combat these vulnerabilities, few of which will be news to seasoned software developers. The researchers break these recommendations into "Data-Level Protection," "OS-Defenses," and "GPS Dependent Systems" but the most valuable take away for our community is "input validation," "input validation," and "input validation" which gets added to the already well understood lessons (and not as easily conceived solutions) from GPS jamming and spoofing techniques. 

 

But should our community be concerned by these techniques? With an estimated cost of $2500 to create the equipment to exploit many of these weaknesses, and recent demonstrations of an ARDrone virus, it might not hurt to begin thinking more seriously about security at key input points (telemetry and GPS data streams, at least.) In our brave new world, a system crash could not be more aptly named. 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Moderator

    @ramboky: one does not need to be the intended target to be impacted. The attacks are all broadcast, and while some require more targeting to effective as intended, few need to be "effective as intended" to be disruptive to a nearby GPS receiver and/or GPS-dependant system. The low power rates and vast distances between the official transmitters and earth-based receivers means that even low power earth-based transmitters can have an impact on large numbers of nearby (hundreds to thousands of meters in radius) receivers.

    If we speculate that people were, actually, disrupting GPS receivers intentionally, then you can imagine that this might escalate, given the growing dependance on GPS-based devices in all sectors of daily use, from agriculture to theft prevention, location services, emergency services, communications infrastructure ... even a micro-cell, used to extend mobile phone services over IP for residents with poor coverage requires a good GPS signal to function. Consider a world in which GPS jamming becomes common, and you can expect law enforcement may begin to take an interest in detecting the jamming and/or meaconing. How better to find a car thief than to detect and locate his Lo-jack Silencer? In fact, if the people behind lo-jack are not already building a DF rig to locate GPS jammers, I would be somewhat surprised. But I digress. If you grant me this world, for a moment, then you will also imagine how simple jamming is a time-limited option, crude and effective right now, but as likely to attract the sort of attention that a tech-savey criminal would want to avoid in a few years time.... like putting out a large beacon that screams out "arrest me!" for a couple of square miles. This naturally leads to the use of more subtle, more complex attacks against GPS receivers being favored. 

    Now, if all this sounds extreme, a wild speculation based on a very thin "what if" situation, I would like to bring your attention to the Sentinel Project research published in February of this year. The project placed 20 sensors around the UK and monitored them. "We believe there's between 50 and 450 occurrences in the UK every day," "the project suggested that most jammers were small portable devices with an area of effect of between 200m and 300m." "Mr Curry said the research had also resulted in the detection and confiscation by the police of one jammer. We detected a pattern and they [the police] were able to go and sit and wait, he said. Mr Curry said the research was also able to establish that jammers were responsible for interference experienced by Ordnance Survey equipment." "In one location the Sentinel study recorded more than 60 GPS jamming incidents in six months."

     

    And so it seems that this imaginary world, in which mobile GPS jammers are routinely used by criminal teams while stealing cars is very much routine already, and has been for some time. The speculation that police will begin to use the jamming activity to assist with arrests is, in fact, historical fact at this point, and will likely continue to generate interest. This is based mainly on GPS use in auto-theft devices. As UAVs, GPS-dependant devices, are more widely adopted by law enforcement, GPS jammers will become even more attractive. And that will change the use-case slightly from 200-300m jammers to higher powered jammers, with a range measured in a couple of miles. 

     

    We do not need to be the target, given the frequency of use, radius, and broadcast nature of these attacks. Just food for thought. Thank you for taking the time to read this musing. 

  • Moderator

    It's definitely something to keep in mind.

    One interesting vulnerabilty applies to all software which stores or caches values:

    The NetRS attempted to resolve the error by rebooting. Unfortunately, the NetRS appears to cache ephemeris data. Caching is quite common and is the reason a warm-boot of a GPS receiver takes less time to acquire lock. Since the ephemeris was cached, the receiver made the same faulty calculation, again erred, and the system entered an infinite reboot cycle. The receiver only recovered after a full hardware reset was manually performed.

    Also of interest is the fact that three of the tested units ran full-fleged OSes, and that rooting them seemed pretty straight-forward (especially on the linux-based unit :-/)

This reply was deleted.