 I'm Dave Carrot. I'm a security consultant pentester from Wellington in New Zealand. For those who don't know where Wellington is, we're up the top of the map there. I enjoy the radio-hacking and also the physical stuff for flocksport and stuff like that. So today we're going to be looking at GPS, GPS spoofing, how we can change time and what we can do with that. Attacking some NTP servers and whether we can actually detect some of the spoofing. So just going back to the start, GPS can tell us where the time is, tells us and tells us where we are and it uses the time to actually do the calculations to figure out where you are and it's the constellations of satellites orbiting about 20,000 kilometres above us. So we have to trust GPS, right? So does anyone currently not trust GPS locations? Anyone not trust GPS time currently? Does anyone feel they may change their opinion by the end of this talk? Sort of we have to trust GPS, right? It's too important to life, it's got to be robust, the military uses it, important services like Uber and Tinder and stuff require it and also some other less important things like NTP time, planes and ships navigating, keeping an eye on armadvans. We've just changed our taxi law in New Zealand and they removed the knowledge requirement for the drivers because the Minister of Transport came out and basically said, what was the last time you ever saw a taxi driver without a GPS in their car? And from my experience actually since taxi drivers have got GPS they've actually become worse at actually getting to where you need to go. So moving forward, look at some of the tax. There's sort of been GPS jamming for a while now in this particular instance, you know, a truck driver, their manager, a pot GPS trackers and all their trucks. So he didn't like being tracked. He also liked having an afternoon nap. Hapana's particular nap spot was next to Newark Airport and when you mess with planes, people do sort of notice and they'll come out and actually track you down. And also on the GPS jamming front apparently some of the black cabs in London they don't like Uber and Lyft so they are running GPS jammers to mess with Uber and Lyft so people will use the black cabs rather than actually Uber and Lyft. But jammers are rather boring. You can just buy them off your favourite Chinese online store. They're not particularly graceful. They just sort of jam GPS. You realise that, hey, I don't have a GPS location. Something's amiss. Moving forward to sort of 2011, supposedly the Iranian stole, crashed the US drone by doing some GPS spoofing to try and get it to land or crash land in Iran though this was nation state level of cash in research. Moving forward to 2013, a professor with some students and $2,000 worth of sort of equipment managed to steer a ship, of course. This wasn't GPS spoofing per se. It was the fact that they delayed the GPS time signals ever so slightly that the boat thought it was somewhere where it wasn't, so a ship altered course trying to correct itself. In May last year Unicorn Team talked about using wireless time signals and attacking NTP with this. They looked at GPS. They also looked at some of the other terrestrial time sources that are sent out over radio, though from what I could see when they didn't actually release any code. Then I found this on GitHub. Someone had written a software-defined GPS signal simulator. So I took that, added it in, sort of in addition to that, you need a computer to run it on. You need a software-defined radio with transmit. I could personally use the BladeRF because that's what we had sitting around in the office at the time. Also the HackRF or the USRP will also work. So for less than $500 in hardware, you can start your GPS spoofing. And as far as software-defined radio things go, this is one, this code, you just downloaded it, you ran it and it just worked fine straight out of the box, sort of one of the best experiences I've had with software-defined radio code, which is really nice. So yeah, I also had it running off a Raspberry Pi 3 and that case with a battery, that case the BladeRF was about the biggest thing involved in the setup. People, the regulators generally don't like you trying to broadcast GPS signals, so best wrap it up in a Faraday cage with some aluminium foil. You know, yeah, not a lawyer. That's not open spectrum. You've got to keep your GPS goodness to yourself, unfortunately. And when you are doing this, your software-defined radio transmitter is going to be a lot closer than the satellite. Satellites are about 20,000 kilometres away. You're going to be a lot less than that. From what I've seen of other people using this tool, the range is still only hallway length, it doesn't go particularly well through walls. And GPS signals on the whole are actually quite weak. So on the left there, we've got a normal radio signal. In the red there we've got the noise floor, so that's just the background static. And then in the green we've got the signal. So grossly simplifying radio stuff. In this case we can basically figure out what the noise floor is, delete it and you're left with just a signal. But on the right-hand side there we've got the GPS and it's the other way around. In red we've got the noise floor and we've actually got the GPS signal. So that's why GPS processing uses so much battery power because it's actually even to process all the noise hoping to actually find a GPS signal. That's basically got a mask and it goes, is that a GPS signal? Or is that a GPS signal? And when it does detect one it goes, oh yep, I do have it and it can start actually processing it. So we've got the simulator software. I've got a Blade RF. What could we do? You know, first simple thing, we can just change your location. My phone was under my desk in the office in Wellington. Here I've got my phone figures actually in Bletchley Park. So how does the tool work? It had two methods of working. The first one was a two-step process where it would generate the data and then it would broadcast it. It works out about a gigabyte of data in a minute and it can be a standard location or it can be a path so you can actually have the GPS location moving around. It also takes in the ALMAC of where all the satellites are going to be at a given time so it's not generating just one GPS satellite it's not generating the entire constellation. It will go at this place on Earth it should be seeing this set of satellites at this particular time. Yet in the other method it does both the generate and the broadcast in one step in real time. Though this does have the downside it needs much more CPU to actually do this. So a little limitation to the tool by default it will only generate five minutes of data at a time. With that you can just go into the C header file, change it and you can do longer. I suspect the reason for this was didn't want bug requests and complaints saying this thing filled up my disk when I was trying to generate two days worth of data. It means that hopefully the person who knows how to change a C file also realises about file sizes and stuff. The Raspberry Pi 3 can't do the generation in real time it takes if I was trying to generate five minutes of data or Raspberry Pi 3 it would take about 15 minutes of actual CPU time to generate that five minutes of data and also generating a path is quite simple. You add sort of 0.1 second intervals you give it a set of locations. Unfortunately you can't just use latitude, longitude and altitude. You have to use Earth Centered Earth Fix or NEMA data rows at this but there are tools to do the conversion online for you so it becomes quite simple and you can start drawing little paths in the middle of Wellington Harbour using the tool. What can we do with the locations? Armadvan, you want to take it back to your underground lair, broadcast the path that it should be travelling around all the banks but you're actually driving it off to your underground lair. Uber has a time in a distance component. If you never left your actual destination it's only ever going to have time component and given experience with Uber drivers they're never going to, they always blame me and say oh the map's really bad or it's giving me bad routes today, they're just going to assume the app's having a bad day they're never going to assume someone's actually attacking them to scan money out of them. Planes can also use GPS for landing particularly when it's not a straight landing and you can't use the normal tiduristial based radio stuff. This is Queenstown Airport in New Zealand, it's got a nice hairpin and a little chicane onto landing through some tight valleys and stuff so you want the planes never going to be fairly accurately through that or they'll make a big mess on the side of a hill. Also we can change time, seeing one of the core things that GPS is actually spinning out through all the calculations for locations as it's time. So we have NTPD which is the common NTP daemon on Linux and Unix servers If you have the GPS receiver just putting serial into the computer NTPD knows how to do the rest and actually uses a time source with no really additional config required other than adding a new server in the config file. Also looking at some of the commercial NTP servers available on the market that do have NTP in, sorry GPS in they will appear to run NTPD under the hood because NTPD has its own custom license and then if you're in the documentation they mention they've got stuff licensed under the NTPD license. Vis-a-vis they have NTPDs running under the hood. So a little bit of tacking NTP, if you try to move time in big amounts particularly over 5 minutes NTPD will shut down though there's actually no log messages saying why it shut down and when you restart NTPD it just says the time has been changed. Which is really common because the local motherboard clock and NTP very rarely actually correspond with each other because motherboard clocks are notoriously inaccurate and always trust the GPS time or the NTP network time over the motherboard clock. If you do turn the NTPD logging up to sort of debug level but no one actually runs this in production like this, there is some logging which I could kind of interpret what was going on because I was actually attacking it at the time and knew what I was doing but if someone saw this and actually in real life they wouldn't think much of it and if NTPD crashes and it restarts through a watch dog or the sys admin has to get up at 2am in the morning and it just restarts normally and it continues on and actually going to log any deeper or check the time is correct a lot of the time. I just want to go back to sleep. But we want to somehow move this time without actually crashing NTPD because if we are actually attacking it and so instead of doing the big steps we have to do lots of little steps back in time to sort of wind the clock back. So I wrote a tool called Tajips. It's a python script that sort of method two of the GPS signal simulator. The code is up on github currently and this is sort of designed mostly for air gap networks. So a network where you've got the NTP time servers it's getting the time from GPS and there's no other network connection out to the rest of the world to get a time source from anywhere else. Or people who have sort of configured badly with maybe only GPS and one other server and then in that case it will most probably trust the GPS time more than the other one because it will have a lower stratum coming from the GPS satellite. So sort of my little test setup I had was little hacker on his laptop broadcasting out the GPS signal and then down the bottom there I've got an NTP server receiving the GPS signal. So I've got a little sort of video of this so the local machine up on the top left that's the attacker, the target machine that was the NTP server on the top right and then the bottom there we're actually going to have the script running. So the script's running away so it takes a little while and as the script's running it will sort of move time backwards and then sort of give it time as the GPS receiver to sync back up let it run forward a little bit and then it will move the time back again, you know, wait for the GPS receiver to sync up again and then play for a little bit then move the time backwards again. So it stayed rather stable, you could move the time back a lot through this method and it's just running like this. So moving on, so what can we sort of do with these sort of touch time? What sort of attacks can we do? Most of you have most of come across time-based one-time passwords like you'll see in Google Earth every 30 seconds you'll get a new token to use with your login. So in this case if we can move time backwards what can happen here? So I've got a little video here it's a plant, yep. I'm doing the current date there. And here I've set up SSH to require the verification code in addition to the passwords. So there we've logged in. So now sort of going to fast forward, just copy in the time just so we can reference back to it later and now the video is going to fast forward a little bit so we've got the time to move forward a little bit. So we'll just wait for that to happen. Going forward, going forward. So I'm checking the date again now and we'll see that the time's moved forward. So we'll log in again and the first time I log in I'm going to use the code we used before and we'll see that we get prompted again for the password because it's the incorrect time password for this particular time. So it's prompted for the password again but if I type in the password and then use the current verification code I can log in. So I'll log out again and I'll fast forward it again but this time during the while it's fast forwarding I'm actually going to be moving time backwards again so the video's fast forwarding time is going to be start winding itself backwards after a little bit. So yeah so we see time's moved back a little bit and just waiting for it to now tick forward to where we logged in last time or the very first time sorry. So the time's insane so we can SSH in again, type in the password and use the same code as before and we've logged in. So this was the default LibPam Google Earth sort of time-based one-time password library. Thing was is when you're setting it up it didn't have a default for reuse so this is the question had for reuse if you just hit enter it would just prompt you again with this or no it doesn't actually say yes you do want reuse protection on because it stops you know they may be assuming that time only ever moves forward you won't be able to reuse it if time moves backwards. So that was the case I've also looked at some other implementations I've got some add-ons to websites and things and then some of them do have it by default some have no default and then on the right I've got some common libraries available and in this case only one of them actually had the reuse verification in it and they didn't even have that function available they just obviously assumed time moved forward. So when you are looking at implementing time-based one-time passwords make sure there is a setting for disabling reuse and make sure it's set not to allow reuse or you can look at other two-factor auth alternatives. There's HOTP which takes account of plus the seed to give you the number and there's U2F which is currently what I prefer if it's available and also friends don't let friends use SMS for 2FA. So I was also looking at what are some of the other things in Linux that uses time. So subacosts across Tudu which allows you to escalate and run something as root and that will prompt you for a password and then if you try it again in the next 5 or 15 minutes if you again for the password. So I thought hey can I sudo, let time run forward, roll time backwards and then can I still log in. In this case sudo didn't realise what would happen and stopped it and this is because instead of using the wall clock time like LibPam was using sudo is looking at the number of OS ticks coming from the CPU so it's actually known so many ticks have passed therefore I need to re-authenticate the user. It works in a similar way so I can use uptime as an example here. So I've got a date initially on the 7th of November, the service has been up for about 4 minutes, I roll the server forward in time a week and it realises hey it's only now it's all been up for 7 minutes, only 3 minutes have passed between me doing those 2 snippets. Forensics could get rather interesting if you had a log consolidator that allowed you to sort all your logs by time. The logs might have the earliest log entry saying the hacker logging out then the hacker doing the elite hack and the most recent entries the hacker logging in and I know a person may initially start from when they're logged in then start looking forward to see what happened they might not necessarily actually look backwards to see what happened in the past before their initial login. Also if there's not centralized logging you could just with a cron job move the date backwards and forwards at random and this may actually cause the log rolling and log purging to happen on the server that oh a weeks past I better go and purge and delete all the logs. A couple of weekends ago someone saw on Twitter someone had mentioned that they've seen in a Stingray release, one of the Stingray device release notes that sometimes when an external GPS device gives erroneous GPS ticks the license for the Stingray may fail. So maybe if you're in a jurisdiction that allows GPS broadcast and you want to disable Stingray device maybe that's a method to try. So what sort of the NDP servers and actually how do they work? On data center you may often see a GPS aerial that often looks like that and sort of these work in two ways. At the top you either have the GPS antenna and it's radio down the cable down to your data rack and into the computer and then actually inside the server you've got the GPS receiver and that's directly sold on to the motherboard and the other option is you have the GPS antenna and that's also got the GPS receiver up on the roof and then it will send serial down through the building down to the rack and into the GPS server and to use that you just tell NDPD that you've got a new server 127.0.20.0 and then that no NDPD goes oh that's a GPS source I'll look at DEV, GPSO and DEV PPS0 and start doing the import for time. So the serial data is the NEMA data arrows. The GPS ones start with dollar GP those are the two most common ones used by NDPD for time and you'll see they've got a time component and one of them also has a date component in it and the other says are additional wire quite often involved and that's a pulse per second signal and what that means for the 0.1 of a second at the start of a second will go high for 0.1 of a second there'll be low for 0.9 of a second and pulse per second doesn't contain a time value it only gives a very accurate indicator where the second starts and the way this GPS receivers are built and designed the pulse per second takes a much shorter path through the processing and has less processing so it's a much more accurate time sort of indicator and gives you sort of micro or nanosecond accuracy opposed to the NEMA data sentences which are maybe only millisecond accuracy. So in the setup I had I initially just had NDPD running on Raspberry Pi by the GPS receiver coming in through serial onto the GPO pins along with the pulse per second so initially I started looking at can I just spoof the pulse per second it's nice and simple it's just highs and lows don't have to think too much so I connected the pulse per second wire to another GPO pin on the Raspberry Pi and I just had a little script that set the pin high and low as applicable what I found out was happening was if you run the pulse per second faster or slower than the NEMA data it would sort of keep correcting itself as it would get the actual second number from the NEMA data rows but just the start of that second might be a little bit messed up so never deviated more than a second if you're in finance or telecoms or energy where fractions of the second count it would be an important thing in other industries where seconds aren't the actual fractions of second aren't so important it's most probably less of an issue so I thought oh can I just remove the serial data and will it just rely solely on pulse per second pulling the wire it didn't it just stopped and it even started just regarding the pulse per second in that case so I did have to actually start working on getting a full solution that did the NEMA data and the pulse per second so I've got another Python script that will do that and it will move time slowly and in steps so you can adjust the time I found this simpler to use than TarGyps because I wasn't having to deal with the GPS signals I was only worried about serial data and it's a lot simpler to write serial than it is to try and integrate with other tools and involve radio and the timing involved in that so basically worked by writing some NEMA serial to standard out, have a pulse per second pin going high or low loop through that at whatever rate you wanted a second to be you soak at to move the standard out to the relevant virtual console then simply link the virtual console to devgps0 and ntbd top the time from there so behave just like TarGyps simpler because it didn't have to involve the radio though does require physical access to the data centre's roof to actually splice into the wires rather than attacking it remotely so I went and got an NTP server this is a cheap one that the boss paid for that this company delivers NTP solutions for things like airports and nuclear power plants so this should be good right nuclear power plants got to keep those safe so with TarGyps and NEMA desync if I moved time forward and just one big jump it just continued on merrily if I moved time backwards and a big jump it crashed like we saw in NTPD before but TarGyps and NEMA desync worked fine and it could move time backwards on it so I had no protections in that regard and then I also had a look at the web UI found some bugs they're so simple and dumb I'm almost afraid to actually mention them here but basically found that it's using get for everything so even when you log in with the password it then just pots the password up in the URL bar yeah and basically because it's not using cookies at all so I could just later just navigate directly to the relevant pages yeah and you notice when you want to change the part the first one was changing the network settings when you go to change the password you're actually in a different password form this case yeah password form and when you reset the password again the new passwords just in the get I don't find any posts in it having this URL is really handy when you do change the password then come back to the thing a month or two later if you got what you set the password to you just pull out the URL and reset the password with no more from now needing to actually know the current passwords so yeah just by not having any auth I suppose so sort of we've been looking at some attacking how about we can look at maybe some detecting of GPS spoofing have a little talk called GPS snitch and how that works is it looks at the time offsets from and in this case if you do have external time source other than just GPS you could look at whether the time you're getting from GPS differs from the time you're getting from the NTP network you can also look at say the signal strengths because when a satellite's directly over here it's going to be stronger than when it's down at the horizon because the distance is greater and also the range of the signal strengths because you know different strengths of the satellites you should see a different range and the signal and the signal strengths also if it's an NTP server the location should be stationary most people don't have data centres that move much and also one that I haven't actually looked at is maybe looking at actually the directional of the signal because if you're doing GPS spoofing chance are the signal's all going to be one direction when you are using GPS in the real world the satellites are all around you little video of the tool running so what you see it sticking through and initially it's only going to do warnings this is because we want to remove any false positives because sometimes if a cloud goes past or other little things like that the GPS signal will change slowly and we don't want to alert every time a cloud goes past so we'll wait for a particular number of failures and also more than just one type of failure so by the end of it it's actually saying critical and it's detecting the error now well the spoofing now that's particularly helpful maybe if you're running a GPS server if you just stop looking at the GPS location bit you can also use a GPS receiver so how can we detect the NEMA serial spoofing so this is a new tool I wrote just for the DEF CON hopefully it's on GitHub if my colleagues have woken up at 9am on a Saturday morning they should have made this repository public so if not it should be public soon but it is there waiting to go what this tool does it records as all the NEMA sentences coming in it looks at the time stamps them all and it looks at the ratios between the different NEMA sentence types and also how many sentences per second it gets so just a little table there most of the sentences are coming in once per second there's one there that sort of only comes in every 0.6 of a second so if you start to see the sentence rate deviating from one and sort of the ratio changing you know that something's amiss in this case and when it sees those it will alert for you so we've got those tools to detect and maybe stop the GPS spoofing some other methods are making sure you have more than three upstream NTP servers the number of servers I've reviewed in my day job that only have one NTP server even better when they have one NTP server configured and that server is no longer actually working yeah if you've got three you can detect the bad ticker and you know which one's actually ticking bad because you still have two corresponding and also make sure you've got multiple types of upstream don't rely just on GPS there's also atomic clocks the NTP poll and also don't pick one upstream provider for your time outside of your network because you might have the rogue admin problem at the upstream where they could change all the times on the internet facing NTP servers and then all your time goes awry that's a particular common case if you're a customer of a managed service provider and they just provide their own time servers into your own network you maybe like to say hey can we all set some time from outside so we're not reliant solely on you for time if you're on an air gap network and you're still relying on GPS well you're still receiving some signals over the air so are you still really an air gap network maybe in that case splash out get some atomic clocks or some cesium or a radium and yeah do it like the national labs run some of the central time servers around yeah if you're actually devine some NTPD or something maybe look at a plameni something like GPS snitch and NEMA desync make the logging a little bit more explicit when it is shutting down because the time is so different and yeah so that's my talk thank you very much and thank you again