[00:06.920 --> 00:15.320] Kia ora koutou katoa. Welcome everyone. I'm David Robinson, go on the internet as the name carrot. [00:15.440 --> 00:21.200] I'm a pen tester at ZX Security in Aotearoa New Zealand. For those who don't know where [00:21.860 --> 00:24.130] Aotearoa is, we're at the top of the map there. [00:26.560 --> 00:33.240] I enjoy, a little bit about me, I enjoy aviation and hacking. Queensland and Australia has a couple [00:33.240 --> 00:39.260] of great conferences with great hacker content, but they're also on their approach path for their [00:39.260 --> 00:45.000] local airport so you can sit on the riverbank or on the beach and watch planes come and go. [00:45.000 --> 00:47.380] So that's a great combination there. [00:48.940 --> 00:54.320] Today we're going to be looking at electronic flight bags in the general aviation cockpit. [00:54.860 --> 01:00.220] We're going to go through some example issues, some vulnerabilities, some security type things, [01:00.220 --> 01:04.880] and also going to discuss how we can mitigate the issues in each case. [01:04.880 --> 01:08.560] I'm going to go through these in more detail as we go through the talk. [01:11.300 --> 01:15.700] With the issues I'm going to present, we're at quite a high level for vulnerabilities. [01:15.740 --> 01:20.540] Discuss more sort of classes and types of issues, opposed to diving down into [01:20.540 --> 01:25.620] individual vulnerabilities. We're not going to be naming vendors or product names here. [01:25.620 --> 01:30.200] We're going to try and keep it general so it's helpful for everyone. We're not just sort of [01:30.200 --> 01:34.640] giving specific examples. Hopefully there's something that everyone can take away. [01:36.120 --> 01:41.660] Sort of for a bit of a framing of the talks of the issues I'm going to present, [01:41.660 --> 01:45.740] while I've been thinking about discussing putting this presentation together, [01:45.740 --> 01:51.240] I've sort of gone back to the CIA triad and been focusing on their integrity and availability [01:51.240 --> 01:55.980] sort of of the systems and how these issues sort of affect those. [01:57.200 --> 02:03.900] I will note that a lot of these EFBs and the receivers that are used by EFBs will say, [02:03.900 --> 02:11.120] you know, do not use for navigation or safety etc purposes. We know people are actually going [02:11.120 --> 02:15.640] to use them. People are going to put too much trust in them. So where possible, [02:15.640 --> 02:21.820] we should try and still make them safe if there are people using them in these situations. [02:24.270 --> 02:30.770] So what I'd like people to take out of this talk today is some ideas about how to make more robust [02:30.770 --> 02:36.830] and secure systems for their customers, for the pilots using their systems. There's going to be [02:36.950 --> 02:43.510] a particular focus on general aviation EFBs, but hopefully some of these ideas can apply for [02:43.510 --> 02:49.410] other EFB manufacturers and other parts of the aerospace industry. [02:51.090 --> 02:58.590] To an IT security professional, most of these issues and problems are going to discuss will not be new issues. [02:58.590 --> 03:06.970] I will be trying to put an aerospace spin and examples to them to help tie them to the aerospace industry. [03:07.390 --> 03:13.750] But a lot of these issues, as we've seen industries move into a more digital, more connected world, [03:13.750 --> 03:17.610] we've seen a lot of these types of issues, categories, classes of issues [03:17.610 --> 03:23.030] come up as they've made this transition into this new digital world. So aerospace is not going to be [03:23.030 --> 03:29.790] the first industry to go through all these growing pains, nor is it the last industry that is going to [03:29.790 --> 03:35.490] go through this growth of product scope and have to deal with these issues. [03:37.050 --> 03:43.330] So what is an EFB in the general aviation context? It's often going to be on a tablet. [03:44.770 --> 03:50.250] It's going to provide the pilot with some combination of flight charts for navigation, [03:50.250 --> 03:56.250] airport charts. It might provide some altitude and heading reference systems. [03:56.250 --> 04:01.330] So your artificial horizon, altitude, speed, direction. [04:02.330 --> 04:08.690] It may also provide some situational awareness through ADSV or FLAMIN. [04:08.690 --> 04:15.330] It will be able to show the pilot what other planes and aircraft are around the plane that [04:15.330 --> 04:24.490] they're flying. So this is how a tablet and a receiver and the sensors sort of fit together. [04:24.890 --> 04:31.930] So in the middle we have some sort of receiver unit. These are commonly, you know, and then we'll [04:31.930 --> 04:38.390] have the tablet with the EFB. And this communication between the receiver and the tablet slash EFB is [04:38.690 --> 04:42.530] quite often going to be Wi-Fi. In some cases it's Bluetooth. [04:43.910 --> 04:49.650] And between the receiver and the tablet, the most common protocol used is GDL-90. [04:51.010 --> 04:55.130] And then some things will also use HTTP or WebSockets. [04:56.730 --> 05:05.290] The receiver can take inputs from a variety of different sensors and inputs. So we could have [05:05.290 --> 05:10.230] GPS satellites as one with ADSV in to help the situational awareness. [05:10.230 --> 05:20.170] We may have a gyro and an accelerometer that will help with pitch, yaw, roll, [05:20.170 --> 05:28.070] acceleration, deceleration. In addition to the receiver sending information to the EFB or tablet, [05:28.070 --> 05:33.030] there may also be a web interface to the receiver where sort of configuration of the receiver can be [05:33.030 --> 05:42.150] done. And this normally happens over HTTP. So for my testing, I sort of only used my own [05:42.150 --> 05:50.950] tablets, my own receiver, and my own hardware. Where radio was involved, sort of, I did, [05:50.950 --> 05:56.990] you know, I made sure that my signals did stay contained to my test environment. So I used a [05:56.990 --> 06:02.610] Faraday cage. Where possible, I turned the transmit power down. I tried to use non-aviation [06:02.610 --> 06:09.390] frequencies. So if I could change the frequency used by the transmitter and the receiver unit, [06:09.390 --> 06:14.390] I would use non-aviation frequencies. Where possible, I'd directly connect the transmitter [06:14.390 --> 06:22.090] to the receiver with a cable and some attenuators to drop. So the receiver wouldn't get burnt out [06:22.090 --> 06:26.390] by the additional power. So I was really trying to make sure my system stayed contained [06:27.330 --> 06:36.240] to just my test setup. So there's a variety of examples and issues I'm going to go through, [06:36.240 --> 06:39.320] and I'm going to go through each one of these in more detail. [06:43.070 --> 06:46.130] So first up, we're going to look at heartbeat messages. [06:47.030 --> 06:53.610] So what this will do is the receiver will send a heartbeat message on a regular basis. The EFB [06:53.610 --> 06:57.990] will receive the heartbeat message and use that as an indication the receiver is up [06:57.990 --> 07:05.230] and working as expected. And it can be used to inform the pilot that the receiver is not [07:05.230 --> 07:11.020] functioning correctly or the connection between the EFB and the receiver is not working. [07:12.070 --> 07:19.170] So as an example, if we start an EFB and the receiver is off, we'll often get some type of [07:19.170 --> 07:28.550] red X, some type of no connection, no heartbeat, no connection established, [07:28.550 --> 07:32.070] some sort of error message that's quite prominent and displayed. Most of them [07:32.070 --> 07:36.830] involved a red X. I was quite clear that the system was not ready for use. [07:38.250 --> 07:43.070] So when we did start the receiver and the EFB connected to the receiver, [07:43.070 --> 07:51.010] the red X went away and it started to display data. So headings, speeds, altitude, in this case. [07:53.070 --> 07:58.570] So what happens when the heartbeat stops? This can be because we turn the receiver off. [07:58.570 --> 08:03.350] It could also be because a malicious individual is tampering with the data in some way. [08:03.690 --> 08:06.130] So what do people expect is going to happen? [08:07.030 --> 08:12.890] Do they expect the EFB to inform the pilot, bring back the red cross? [08:12.990 --> 08:16.970] Or do they think everything's just going to continue on hunky-dory? [08:17.150 --> 08:20.870] Everything's going to be fine like nothing has happened. It's all OK. [08:22.650 --> 08:28.550] So who picked just continue? Well, that is what happened in some cases. [08:28.970 --> 08:32.470] When the system is an integrated state, it should tell the pilot that [08:32.470 --> 08:37.210] the heartbeat message has gone away, that I can't trust the receiver anymore. [08:39.430 --> 08:44.950] So when we are, you know, for these heartbeat messages, we need to make sure the EFB is [08:44.950 --> 08:49.770] using it as an ongoing check. It's not just a check to be used to start up, [08:49.770 --> 08:52.810] have all the components started up. It needs to be an ongoing check [08:52.810 --> 08:58.070] to ensure that the receiver is still up and running. Because in some of these cases, [08:58.070 --> 09:04.490] if you stop the receiver, the EFB will keep displaying the same altitude, [09:04.490 --> 09:10.290] the same speed, or same location, rather than actually showing that there's an error. [09:10.570 --> 09:15.590] So it needs to inform the pilot that, you know, the heartbeat has stopped being received. [09:15.590 --> 09:19.910] And you could extend this now to start looking at other data. If you had been continuously [09:20.490 --> 09:25.130] receiving the altitude and every message that included the altitude, then suddenly [09:25.610 --> 09:31.310] the altitude field was no longer there. That's an indication that, again, that something's wrong, [09:31.310 --> 09:38.290] and a piece of data that the EFB was expecting or had become used to expecting has disappeared. [09:38.290 --> 09:42.190] Maybe it should inform the pilot that just because the altitude has disappeared, [09:42.190 --> 09:48.270] other data may not be as of the high quality as it was before. [09:54.190 --> 09:57.530] So the validity of data. [09:57.850 --> 10:04.710] The data that EFBs receive from the receivers may not always be valid. Likewise, the data the [10:04.710 --> 10:11.610] receivers receive from the sensors or other inputs may also not be correct. Receivers' [10:11.610 --> 10:17.470] sensors have faults which could result in bad data being sent. There may be corruption happening [10:17.470 --> 10:24.410] on the wire. A malicious individual could be injecting or intentionally manipulating the data [10:24.410 --> 10:34.280] to make it malicious. So one example is headings. This is a test I did. [10:34.600 --> 10:42.520] Normally a heading in aviation was between 0 and 359 degrees, or 1 and 360 degrees, [10:42.520 --> 10:47.400] depending on the particular implementation. But whatever happens, the heading should not be more [10:47.400 --> 10:58.920] than 360 degrees. So in one case, with a dummy receiver, I sent an EFB a message where the heading [10:58.920 --> 11:07.780] was 450 degrees. It was actually remapped and displayed as 90 degrees, which if you take a [11:07.780 --> 11:15.140] step back and you think about the underlying math libraries which EFB may be using, when you talk [11:15.140 --> 11:22.180] about degrees and degree maths, 90 degrees makes sense because you've got 450 degrees. [11:22.180 --> 11:29.940] So you go 360 for a whole circle, then another 90 degrees, 450. In the math domain, [11:29.940 --> 11:36.240] when you're dealing with angles, that makes sense. But in the aviation domain, yes, [11:36.240 --> 11:44.860] headings are measured as degrees, but we're dealing with headings, not degrees. So in this case, [11:51.140 --> 11:57.320] in aviation, it's 360 degrees. So if it's more than that, we know it's actually an error. [11:59.620 --> 12:06.560] So if we take a quick step away from EFBs and we think about another system where [12:06.560 --> 12:14.000] there can be pilots presented with information in their user interface, which informs the pilot [12:14.000 --> 12:19.940] that there is a disagreement, there is an issue with a sensor. A recent case has been with the [12:19.940 --> 12:26.520] 737 MAX and the MCAS. One of the things have come out that the angle of attack [12:27.040 --> 12:33.540] indicator, the AOA, there's a disagree warning. This was an optional extra that airlines could select. [12:34.520 --> 12:38.440] And I understand in the MCAS changes, this warning is now [12:39.260 --> 12:45.300] going to be implemented on all 737 MAX aircraft. And what this warning does was [12:45.300 --> 12:52.920] displaying that when the sensors no longer, seen as multiple AOA sensors on an aircraft, [12:52.920 --> 12:57.200] when the values differed, it was going to warn the pilot there was a disagreement. [12:57.420 --> 13:02.900] So the pilots knew that this piece of data could not be no longer valid and maybe they [13:02.900 --> 13:08.140] need to use other sources to cross reference and understand what the issue was. [13:09.380 --> 13:16.460] So it would be good if AFBs, when they start to detect the data may no longer be valid, [13:16.460 --> 13:22.060] it's gone out of bounds, it's not what they expect, there's a disagreement. It'd be good to see if [13:22.060 --> 13:28.820] there was a type of warning, you know, if an AFB could provide some sort of warning as the 737 MAX [13:28.820 --> 13:36.280] does with AOA disagreement as one sort of recent example. So this can be, you know, [13:36.280 --> 13:41.440] when they start to disagree or they go out of bounds, like the headings of the 450 degrees, [13:41.440 --> 13:44.940] it's out of bounds, it's an indication there should be an error. [13:47.220 --> 13:53.620] So what AFBs and receivers should do is they should know what the data should look like [13:53.620 --> 14:00.800] under normal operation. You know, they should be checking that their expected data, [14:00.800 --> 14:08.920] is it in the correct range? And when it's out of range, inform the pilots somehow or stop the [14:08.920 --> 14:14.120] information being sent so people cannot make the wrong decisions about it. Or you know that [14:14.120 --> 14:20.640] you shouldn't be relying on a sensor that is having a fault. Additionally, you can look at the trends [14:20.640 --> 14:27.600] in the data. You know, if the vertical speed results in an altitude change that's [14:27.600 --> 14:32.820] completely out of bounds, maybe you should stop displaying altitude or vertical speed. [14:32.820 --> 14:39.080] So for instance, if your altitude suddenly changes 10,000 feet in a few seconds, either [14:39.840 --> 14:44.200] there's a fault with the plane and the pilot already knows about it because the plane is [14:44.200 --> 14:52.100] dropping out of the sky, or there is a fault with the receiver or the altitude system somehow. [14:52.100 --> 14:57.500] In that case, you should inform the pilot, don't trust this altitude, [14:57.500 --> 15:03.100] go trust one of the other instruments that is giving you altitude and rely on that. [15:03.100 --> 15:09.080] And it may indicate that other sensors involved, which the EFB users, may also be [15:09.080 --> 15:20.470] invalid and the pilot should not rely on them. So with the situational awareness that pilots [15:20.470 --> 15:24.950] can have of the aircraft around them, there are some sort of denial of service scenarios. [15:25.710 --> 15:32.600] So what some EFBs do is they have a movie map, which is normally for navigation, [15:33.030 --> 15:36.710] showing you where the navigational aids are, showing you your route. [15:38.150 --> 15:44.030] But additionally, if the system is capable of ADS-B, it can start showing the other aircraft [15:44.550 --> 15:52.170] around and where they are. And with software defined radio, it's easy to transmit ADS-B out. [15:52.170 --> 15:56.770] RenderMan and others have discussed this previously at many other conferences, [15:56.770 --> 16:01.570] and I believe there's some other talks at Aerospace Village on ADS-B spoofing as well. [16:04.070 --> 16:08.690] So this is sort of roughly what it looks like. We've got a movie map, [16:08.690 --> 16:12.150] we've got the aircraft, we've got its route, and we've got some other planes around it. [16:14.890 --> 16:18.190] So what I did was I did a situation where we had this plane and I [16:18.190 --> 16:24.210] injected a large number of planes around it. So it's going to be really congested, [16:24.210 --> 16:31.290] super congested airspace. Lots of conflicts, lots of potential path crossings, a lot of potential [16:31.290 --> 16:38.750] hazards. So when I broadcasted this, I was expecting the EFB to show all the planes that [16:38.750 --> 16:45.870] I broadcasted. But in some cases, you know, on the right there in the diagram I've just popped up, [16:46.690 --> 16:51.810] it doesn't actually necessarily display all the planes. Some of the planes were being dropped off [16:52.810 --> 16:59.290] and missing. It wasn't always the furthest ones away that disappeared, so it wasn't [16:59.290 --> 17:06.050] some sort of range thing of there's too many planes. I only showed the closest X number of planes. [17:07.190 --> 17:12.490] I couldn't really determine a pattern that resulted that [17:13.450 --> 17:19.990] of what planes were missing. And also, if I replayed the same input data into the system, [17:19.990 --> 17:26.150] I wouldn't necessarily get the same output. So without sort of further research and diving into [17:26.150 --> 17:32.910] the code, my current hypothesis is it's something to do with the way that the timing of the message [17:32.910 --> 17:40.690] received and how it packages up X number of planes to send down every half a second or every 10 [17:40.690 --> 17:47.330] milliseconds, depending on how often it sent the current list of planes, and there was some [17:47.330 --> 17:52.350] cut off in buffers. That's my hypothesis. I'm not entirely sure. It's just saw this pattern [17:52.350 --> 18:01.570] of indiscriminate planes being dropped off. And this ABSV spoofing that can be combined [18:01.570 --> 18:08.610] with TCAS issues. I think Pentest partners, Ken, talked about this back in May. I believe [18:08.610 --> 18:14.950] there's also a talk going on during this aerospace village about this in more depth. [18:14.950 --> 18:24.350] But what I'll say on this is with ADSV and TCAS, TCAS is the traffic collision avoidance system, [18:24.350 --> 18:30.590] that you can actually help. You can start putting in malicious ADSV targets to help [18:31.170 --> 18:36.590] reinforce the pilot. There is actually a real TCAS issue. It's not a malicious one, [18:36.590 --> 18:40.130] because you can make the two sources correlate with each other. So you could have a malicious [18:40.130 --> 18:48.030] plane come in and then you'd start to get TCAS messages maliciously, which will come in and [18:48.810 --> 18:57.490] reinforce that as well. So whilst discussing some TCASes, TCAS in some instances from what I understand [18:57.490 --> 19:03.410] has directional antennas, so it can tell where the TCAS message is coming from, whether it's to the [19:03.410 --> 19:10.170] left or whether it's to the right or up or down and so on. We could do the same with ADSV antennas, [19:10.170 --> 19:16.650] so we know where the aircraft should be based on its location in the ADSV message, [19:16.650 --> 19:22.470] but we could also look at the direction the signal is coming from to ascertain if [19:23.190 --> 19:28.110] I believe the plane's over there and the signal is coming from over there, so that they most [19:28.110 --> 19:33.690] probably correspond. But if the plane's over there and the signal is coming from another direction, [19:33.690 --> 19:40.350] we know that possibly this is a malicious ADSV message. So if we've got that, we can rule them out. [19:42.050 --> 19:48.750] And the ADSV receivers, when they are not going to pass down a full set of aircraft as [19:48.750 --> 19:55.750] they're somehow dropping aircraft, it needs to inform the downstream systems, in this case the EFB, [19:55.750 --> 19:59.610] that there is an issue and it is operating in a degraded state. [20:01.930 --> 20:07.830] Additionally, if the EFB is dropping planes because of some limitation it has, [20:07.830 --> 20:12.170] it should also display some indication that planes are missing from the display and [20:12.170 --> 20:18.090] do not use this as a situational awareness tool at the moment. [20:24.960 --> 20:31.020] So GPS spoofing. From what my testing and from what I've seen, [20:31.020 --> 20:36.160] GPS jamming, GPS signal loss are sort of handled quite well in the EFBs. [20:36.220 --> 20:41.180] There's normally indicators that there is a GPS fix, [20:41.180 --> 20:46.980] and there is also an example when there is no GPS fix, there's an indication. [20:48.240 --> 20:52.980] But when we send malicious GPS signals, this is not the case. [20:52.980 --> 21:00.580] So when we send a malicious GPS signal, what I'm thinking of is sending a valid GPS signal [21:00.580 --> 21:07.700] replicating a set of satellites, which result in the aircraft determining the wrong position. [21:10.740 --> 21:16.320] So at last year's Aviation Village, there was a talk on ILS spoofing, [21:16.320 --> 21:24.600] which involved in the result of aircraft potentially having the wrong horizontal offsets [21:24.600 --> 21:32.480] or the wrong glide slope, and resulting the planes landing in the wrong location. [21:32.480 --> 21:40.520] One of the cases here was, oh, GPS and GNSS, RNAV, can be used to cross reference, [21:40.520 --> 21:45.400] you know, the glide slope and stuff, so they should be lining up, and if they don't line up, [21:45.400 --> 21:48.800] they can alert the pilot, and they can make further decisions about going round [21:48.800 --> 21:54.040] and ascertaining what their navigation systems are. But we could also use GPS spoofing [21:55.880 --> 22:00.560] to match up with the ILS spoofing, so they're actually going to correspond. This cross check [22:00.560 --> 22:05.280] no longer becomes a cross check because they're both incorrect. [22:05.500 --> 22:08.840] But they're both incorrect, but they're both showing the same values, so [22:08.840 --> 22:12.920] there is no cross check, and there's no indication that one of them is wrong. [22:15.020 --> 22:20.760] So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research [22:20.760 --> 22:25.540] that was mainly based around time and manipulation of time servers. [22:25.900 --> 22:32.440] But what I did during that thing, during that research, was I looked at how we could go about [22:32.440 --> 22:37.640] detecting GPS spoofing. And in that case, I came up with a bit of a proof of concept tool [22:37.640 --> 22:43.460] called GPS Snitch. It's not production ready, but what it was is looking at some of the GPS [22:43.460 --> 22:50.100] parameters, signal parameters, and so it was possible to actually detect when GPS spoofing [22:50.100 --> 23:00.300] was happening. So for a start, the maths is all based around the GPS satellites broadcasting [23:02.340 --> 23:08.300] a very accurate time, and then based on the time offsets between the different satellites, [23:08.300 --> 23:10.960] math happens and you get a location. [23:12.420 --> 23:19.900] So if we've got a clock on the receiver that is being synced up with the GPS when we first [23:19.900 --> 23:27.680] turned it on, the time should stay in sync together. But if we suddenly start GPS spoofing [23:27.680 --> 23:34.760] and the GPS receiver locks onto this spoof set of signals from a range of spoof satellites, [23:35.540 --> 23:41.600] we'll notice the time will jump, and it might be 10 milliseconds ahead of time, [23:41.600 --> 23:48.320] 5 milliseconds slow. But if we get sudden change in time, that's an indication that a spoofing [23:48.320 --> 23:54.660] has happened. Because trying to start up and have a spoofing attack start with a time with [23:54.660 --> 23:59.300] sub millisecond accuracy is quite a difficult task. [24:01.260 --> 24:03.920] And that's one parameter. There's other parameters, and I found [24:03.920 --> 24:08.240] that actually when you looked at more parameters, it was actually you get a much more stable [24:09.420 --> 24:13.140] system, particularly if you're leaving it running. You know, during my test I left it [24:13.140 --> 24:18.860] running for a day just to see what the natural variations were, and I found that sort of one [24:19.340 --> 24:23.320] look at one attribute wasn't really enough. You need to look at a range of attributes. [24:24.680 --> 24:31.380] So if you're in a case in an aircraft, if the location changes more than what the current [24:31.380 --> 24:38.460] speed allows, that's an indication that, you know, it could be GPS spoofing. Because you know your [24:38.460 --> 24:45.920] velocity, and if it changes, if you're outside of that, you've got a sort of a circle of uncertainty [24:45.920 --> 24:52.820] which may be valid, and if you're outside that, that's a potential issue. Also looking at the [24:52.820 --> 25:00.960] GPS signal strength. GPS satellites are 20,000-ish kilometers away, give or take a bit, [25:00.960 --> 25:05.800] so the overall strength of the GPS signal when it gets down to ground level is very low. [25:08.880 --> 25:14.720] So suddenly if we get a GPS signal suddenly raising strength a lot, that's possibly an [25:14.720 --> 25:19.300] indication that a GPS spoofing attack is happening, because the transmitter of the [25:19.300 --> 25:26.100] fake GPS satellites is going to be much closer. So matching the signal strength is hard. Additionally, [25:26.100 --> 25:30.820] we should have a range of signal strengths, because the satellites directly overhead seem [25:31.660 --> 25:38.020] they are closer than the ones way out at the horizon. They're going to have different [25:38.020 --> 25:42.680] signal strengths because the distance traveled and the amount of atmosphere they have to travel through. [25:42.680 --> 25:49.000] But suddenly if the range of different signal strengths decreases, that's another indication [25:49.000 --> 25:55.740] that a malicious GPS transmission is happening, because when you're doing the malicious [25:55.740 --> 26:00.400] transmission chances are it's all coming from one transmitter and it's going to have a very [26:00.400 --> 26:08.750] similar signal strength. Additionally, like we said back with the TCAS and the GPS was [26:08.750 --> 26:15.370] again looking at the signal direction. We know where the GPS satellites should be at any given [26:15.370 --> 26:23.070] time. We know the plane's current location. So we know in what direction the GPS signal [26:23.070 --> 26:28.810] should be coming from for each of the satellites. So if they don't come from the expected direction, [26:28.810 --> 26:34.350] it's an indication that there might be GPS spoofing or a GPS attack happening. [26:35.930 --> 26:41.750] So what we need to do to help mitigate some of this risk in the EFBs is they need [26:41.750 --> 26:46.290] in the receivers, they need to start monitoring GPS for abnormalities. [26:47.370 --> 26:50.890] So like with some of the topics I talked about with the GPS snitch. [26:51.430 --> 26:56.370] Show an indicator that when you have no GPS fix, when you detect the spoofing, [26:56.370 --> 27:04.530] display GPS no GPS fix because you can no longer trust that as an input. Mark it as no GPS fix [27:04.530 --> 27:10.050] or degraded GPS fix or something whatever meets the relevant terminology and [27:11.130 --> 27:26.020] accuracy standards. So integrity of the data. The data sort of in the overall system of receivers [27:26.020 --> 27:32.660] and EFBs and sensors, it's nearly always happening in clear text. There is an encrypted version of [27:32.660 --> 27:40.060] GDL 90, but from what I saw that was not in very common use. My guess is it's a bit of a chicken [27:40.060 --> 27:46.400] egg problem. The receiver manufacturers don't see the point in implementing it because none of the [27:46.400 --> 27:52.940] receivers, sorry, none of the EFBs are implementing it. EFB manufacturers don't [27:52.940 --> 27:57.940] implement it because none of the receiver manufacturers have implemented it. [27:59.280 --> 28:06.100] Additionally, the Wi-Fi is often open and in clear text, so anyone within range can connect to it [28:06.100 --> 28:09.920] with no authentication required. [28:13.420 --> 28:20.520] And also there is when you first sort of pair an EFB and a receiver, there's no key material [28:20.520 --> 28:27.320] changed. So you can switch out the receiver and the EFB will still keep talking to it. If it's the same [28:28.940 --> 28:34.400] SSID for the Wi-Fi, the same Wi-Fi password, it will just connect fine. [28:34.400 --> 28:39.460] It won't inform the pilot. So, you know, think back to your headphones and your phone. [28:39.480 --> 28:44.420] When you get a new set of Bluetooth headphones, you need to pair your headphones and your phone [28:45.400 --> 28:48.480] and they're connected and they're only going to talk to each other. [28:48.880 --> 28:53.800] You know, if you didn't pair them and you didn't have the sort of checking that they're talking [28:53.800 --> 28:57.540] to each other, as you're walking down the street listening to music, you'd start hearing the music [28:57.540 --> 29:04.360] of everyone walking past you. You know, and we don't want that to happen with our EFB. [29:04.360 --> 29:09.040] We want to make sure we're getting the data from our own plane, not our friend's plane. [29:09.040 --> 29:13.020] So, you know, if you have a friend who you're doing some formational flying with [29:13.560 --> 29:17.100] and because you're friends, you've discussed receivers and you've [29:17.100 --> 29:21.000] settled on the same sort of receivers and EFBs because you both like them. [29:21.720 --> 29:26.560] You don't want the situation that if everyone's left it with the default Wi-Fis [29:26.560 --> 29:32.840] and the default SSIDs because it just starts working, you don't want the EFB in one aircraft [29:32.840 --> 29:36.620] connecting to the Wi-Fi in another aircraft around it. [29:37.460 --> 29:41.440] Because that's going to be bad if you're receiving data for a different aircraft. [29:44.380 --> 29:50.480] So what we should look at here is, where possible, start making the migration to GDL 90. [29:50.760 --> 29:55.880] Have receivers start to say, you know, on this date, we're going to implement it. On this date, [29:55.880 --> 30:01.480] further down the track, we're only going to have GDL 90. Likewise, on the EFB front, make sure [30:01.960 --> 30:05.160] you know your systems are set up to actually accept it. [30:05.660 --> 30:12.040] When you first pair an EFB and a receiver, make sure there is some exchange of key material. [30:12.040 --> 30:19.320] Make sure there is a pairing process to couple them together so you can't introduce a [30:19.320 --> 30:25.540] malicious receiver and have the EFB connect with no error messages. [30:25.540 --> 30:31.460] Make sure you sign every message so the EFB can trust that it is coming from a receiver. [30:31.480 --> 30:36.940] That it trusts. If the message is not signed, disregard it. [30:36.940 --> 30:40.360] And additionally, ensure there's some protection against replay attacks. So [30:40.980 --> 30:45.600] make sure that a malicious event that you can't capture a packet or a series of packets [30:46.400 --> 30:50.380] and just replay those over and over and over again. [30:50.680 --> 30:55.100] Make sure there is some protection that they need to actually keep changing it as it is rolling. [31:01.040 --> 31:09.420] So device hardening is part of my job. I look at devices, systems, hardware and to make sure they [31:09.420 --> 31:13.960] are robust. You know, there's testing to make sure they've got vulnerabilities, but also checking that [31:13.960 --> 31:18.260] they're robust. So even if they're vulnerabilities, I don't know about their attack footprint is as [31:18.260 --> 31:24.900] small as possible. And when I was looking at some of those of the receiver devices, I was [31:25.540 --> 31:31.380] put this hat on. I was thinking, you know, have they made the attack footprint as small as possible? [31:32.780 --> 31:38.440] In some cases, you know, they had made the attack footprint bigger than it could have been. [31:39.180 --> 31:44.220] For instance, you know, there was a receiver that had an internal fan and based on the [31:44.220 --> 31:51.340] receiver's temperature, it would put the fan speed up and down to keep the system at [31:51.340 --> 31:57.100] the optimal temperature. But instead of setting it up so the fan controller only listened to [31:57.100 --> 32:01.880] commands coming from inside the device, they configured it so it would accept commands [32:01.880 --> 32:09.140] from anywhere in the Wi-Fi network. You know, and that's wrong because in case the only thing [32:09.140 --> 32:15.700] the fan controller should be receiving commands from is the temperature sensor inside the receiver. [32:15.700 --> 32:20.380] So when the temperature sensor noticed the temperature raising, it needed to tell the fan to [32:20.380 --> 32:29.100] go faster and vice versa. Additionally, they're all weak. Wi-Fi configs, as mentioned before, [32:29.240 --> 32:35.300] a lot of them are open. They don't have pre-shared keys. They don't use WPA2, WPA3. [32:37.080 --> 32:39.660] You know, using pre-shared keys, they will [32:41.300 --> 32:46.300] put protection on it. So A, it will encrypt most of the data. B, it will mean that only [32:46.300 --> 32:50.300] authorized people can connect to that Wi-Fi network. So you won't have [32:50.300 --> 32:54.540] malicious and rogue things connecting to the Wi-Fi network. [32:55.700 --> 33:02.520] Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do [33:02.520 --> 33:09.780] against it which can have downsides. For instance, there's management frames which [33:09.780 --> 33:15.500] are sort of below the data and control the Wi-Fi connection. And there's a particular [33:15.500 --> 33:19.840] message called a deauthentication packet. And what that does, it's sent from the access point [33:19.840 --> 33:26.420] to the receiver. So the access point, in this case, would be the receiver device and the [33:26.420 --> 33:33.320] wireless client would be the tablet slash EFB. And what the access point says is say, normally you'll [33:33.320 --> 33:38.980] say, hey, please disconnect, re-establish, because I want you to re-authenticate. [33:38.980 --> 33:44.060] So provide me with the password and whatever again. [33:44.900 --> 33:48.780] My problem is, is these messages aren't signed normally. So anyone [33:49.280 --> 33:55.620] could come along and send deauthentication packets. And this results in two possible [33:55.620 --> 34:01.940] cases that you get a denial of service because the EFB or tablet will no longer be able to connect. [34:01.940 --> 34:06.940] It just keeps being told to re-authenticate. So I'll go, I'll connect, get a packet, say [34:06.940 --> 34:12.240] re-authenticate, so disconnect, deauthenticate and re-authenticate again. [34:12.800 --> 34:18.940] Additionally, it can also be used to steer the device instead of talking to a legitimate receiver. [34:18.940 --> 34:24.680] There might be a malicious receiver. So what you do is when it's connected to the legitimate [34:24.680 --> 34:30.300] receiver, you send deauthentication packets. When it's connected to the malicious receiver, [34:30.300 --> 34:35.180] you don't send deauthentication packets. So it stays connected to that. So the EFB is receiving [34:35.180 --> 34:42.560] data from the malicious receiver rather than the receiver that the pilot put there. [34:43.940 --> 34:51.480] There's also additional services running. SSH is a common tool used for remote access to a device [34:51.480 --> 34:59.700] for configuration. So in essence, production devices don't need SSH enabled at all because [34:59.700 --> 35:07.000] they should be in a sort of secure, hardened format. When it's not an active development [35:07.000 --> 35:14.660] or active debug, you don't need the sort of access to the device. And even digging into further, [35:14.660 --> 35:18.920] its configuration is not in line with sort of best practices for the use case. [35:18.920 --> 35:24.120] Sort of in following hardening guides, they sort of had basic things like port 14 turned on, [35:24.120 --> 35:28.620] route logons turned on, a lot of things that you wouldn't normally see in something. You'd [35:28.620 --> 35:33.760] see it in the default sort of installs just to make it work, but it hasn't shown the additional [35:33.760 --> 35:42.140] hardening steps that have gone through. Also, the web config user interface had no password on first [35:42.140 --> 35:48.400] use, no password change on first use, no password at all. So even if the Wi-Fi network had a [35:48.400 --> 35:53.500] pre-shared key and password, as I mentioned on the previous slide, you should also have [35:53.500 --> 35:58.040] a password on the web UI to control the configuration of the receiver. This is so [35:58.040 --> 36:03.240] we have security in there, so it's got multiple layers of security control. So if one fails, [36:03.240 --> 36:09.180] it's still a safety net to stop it stopping the malicious individual getting further [36:09.180 --> 36:16.140] into the system. Make sure you have the safety nets just to make sure things don't happen. [36:17.980 --> 36:25.280] So with this is make sure that you seek advice on how to harden the configuration. [36:25.280 --> 36:31.140] Make sure their attack footprint is as small as possible. If components have hardening guides, [36:31.140 --> 36:37.650] make sure those are read and followed through and used to make the device as secure as possible. [36:43.230 --> 36:50.330] So password management. So as I just said, web UIs often didn't have passwords on them or didn't [36:50.330 --> 36:53.670] prompt for a password change on first use. [36:54.450 --> 37:01.650] Going back to the Wi-Fi case I've used a few times now. There is sometimes options to enable [37:02.670 --> 37:09.070] Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys. [37:09.830 --> 37:18.410] One when it did this said, came off a message saying we've securely set up your Wi-Fi. You're [37:18.410 --> 37:24.110] only going to show you this password the once. If you forget it, you'll need to do a factory reset. [37:25.550 --> 37:28.850] So I went through, I factory reset it again. [37:29.470 --> 37:32.990] Try setting up the Wi-Fi. Comes up the same password. [37:34.290 --> 37:42.030] Go across to a different instance of the same device. [37:42.550 --> 37:47.450] Gives me the same password. So instead of being randomly generated, this password was hardcoded. [37:47.450 --> 37:51.970] It always gave you the same password to be used for the Wi-Fi. [37:53.010 --> 37:56.310] And hardcoded passwords, that is a bad thing. [37:56.530 --> 38:05.090] Additionally, in this case, I found it a little bit worse was because the text and the messaging around the password setup [38:06.510 --> 38:11.850] gave the user their experience that this was actually going to be a unique password. [38:11.850 --> 38:14.710] It was sort of randomly generated. [38:14.710 --> 38:20.170] It was secure, when in actual fact it wasn't. And that's sort of a double... [38:20.170 --> 38:26.950] makes it sort of doubly bad because the pilot or the user is not actually being provided with the correct information. [38:26.950 --> 38:31.670] So they can't make the correct decisions if they've been provided with incorrect [38:33.170 --> 38:35.610] input information or documentation. [38:36.750 --> 38:42.670] So if there is a hardcoded password that you're going to use, say it's a hardcoded password and recommend that [38:42.670 --> 38:51.890] the users actually set their own password. Or better yet, just randomly set a random password. [38:51.890 --> 38:58.870] Give them a QR code that you can scan, because most tablets and phones these days can read a QR code with [38:59.730 --> 39:04.330] a Wi-Fi password in and set the Wi-Fi up without actually having to type in a long password. [39:04.330 --> 39:06.110] You can just scan a QR code. [39:08.650 --> 39:13.150] Some of the EFB applications had companion websites. [39:14.330 --> 39:19.510] You had to sign up some of the times because the EFBs would not work without them, [39:19.510 --> 39:27.590] because they had some sort of subscription functionality that free users... [39:27.590 --> 39:33.450] you only saw so much paid users use this, or you had to be a paid user depending on the thing. [39:33.450 --> 39:38.470] This allowed for flight plans or additional up-to-date weather information, [39:38.470 --> 39:46.850] sort of other non-free services that it gave you. I did not test any of these companion websites. [39:47.430 --> 39:53.650] I only went as far as registering an account on these websites. [39:55.390 --> 40:01.990] I noticed there were some issues. In one case I got emailed a password in clear text, [40:01.990 --> 40:08.010] which to me as a pen tester often means that passwords are not being correctly stored [40:08.010 --> 40:14.470] in the database. The fact that a clear text password can be sent via email, so that's a sign [40:14.470 --> 40:19.730] that incorrect password storage has been used. Additionally, you also saw some that allowed for [40:19.730 --> 40:25.590] weak passwords, so passwords that don't meet the standards of what people think is a strong [40:25.590 --> 40:31.210] password these days. Additionally, had some that said, well, don't use any special characters. [40:31.210 --> 40:37.270] So putting my pen tester hat on, if I see a password field or some other user input field [40:37.270 --> 40:43.730] that says, oh, don't use quote marks, don't use dashes, and don't use these sort of other symbols, [40:43.730 --> 40:49.190] to me that's a red flag that SQL injection might be available. They're trying to protect SQL [40:49.190 --> 40:55.910] injection by just not allowing users to use these characters. So, you know, if I was testing this [40:55.910 --> 41:01.470] for a job at work, if I saw text like don't use the quote mark, first thing I'm going to do is [41:01.470 --> 41:10.740] test SQL injection on it because chances are that's why that message is there. So password [41:10.740 --> 41:18.400] management. OWASP, the Open Web Application Security Project Foundation, has a range of [41:18.400 --> 41:24.960] great check sheets and these uncover password storage, password management, authentication, [41:25.520 --> 41:31.000] along with a range of other really helpful documentations. They've got stuff around [41:31.000 --> 41:36.140] building more secure web apps. Additionally, they've also got stuff on building secure mobile [41:36.140 --> 41:41.740] apps, which most AFBs are. So that's a great resource for information. [41:43.660 --> 41:50.380] So hopefully these example issues and solutions have helped you. And you've gone away, you've [41:50.380 --> 41:55.960] got some ideas that you want to look into in your own products some more. And I hope that [41:55.960 --> 42:02.700] as you do future development, as you add features, as you test functionality, that you think, oh, [42:02.700 --> 42:07.180] what could a malicious individual do with this? You know, is there a way that they could affect [42:07.180 --> 42:13.280] their integrity or their availability of the system with what they could do? Sort of having [42:13.280 --> 42:18.100] the sort of what-if hacker mindset and hopefully you can bring some of that into your testing [42:18.100 --> 42:26.060] and your development. Also, what can the security industry do to help the aerospace industry in this [42:26.060 --> 42:32.000] regard? What help would you like from us? You know, would some example test cases of this [42:32.000 --> 42:38.000] malicious thinking be useful? So as an FB or receiver manufacturer, you can take these [42:38.000 --> 42:44.560] test cases on board and start working them into your systems. Would a test harness that [42:44.560 --> 42:52.200] was, say, a dummy receiver which talked GDL-90, but instead of just sending sort of valid, [42:52.200 --> 43:00.080] helpful GDL-90, also sent malicious payloads and started pushing the boundaries a bit more. [43:00.080 --> 43:05.560] Would that be something that was helpful? That you could set up this test harness for this [43:05.560 --> 43:10.500] receiver, connect your FB to it and have it send all this malicious information to help you if [43:10.500 --> 43:15.400] the automation of the testing. Would that be something that's helped? So really good to hear [43:15.400 --> 43:23.740] some feedback from the industry about what you need from us as well. So, thank you. Hopefully [43:23.740 --> 43:30.700] it's been useful for everyone. I'd really love to hear feedback, chat to some people, because [43:30.700 --> 43:34.580] if I'm passionate about it, I'm sure there are other people here out there who are interested [43:34.580 --> 43:40.080] about it. Or that's why you came along and listened to this talk. Thank you very much. [43:40.220 --> 43:41.480] See you all later.