WEBVTT 00:06.920 --> 00:08.960 Kia ora koutou katoa. 00:08.960 --> 00:10.460 Welcome everyone. 00:10.860 --> 00:15.320 I'm David Robinson, go on the internet as the name carrot. 00:15.440 --> 00:19.980 I'm a pen tester at ZX Security in Aotearoa New Zealand. 00:19.980 --> 00:24.130 For those who don't know where Aotearoa is, we're at the top of the map there. 00:26.560 --> 00:30.940 I enjoy, a little bit about me, I enjoy aviation and hacking. 00:31.540 --> 00:45.000 Queensland and Australia has a couple of great conferences with great hacker content, but they're also on their approach path for their 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:04.880 We're going to go through some example issues, some vulnerabilities, some security type things, 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:22.240 Discuss more sort of classes and types of issues, opposed to diving down into individual vulnerabilities. 01:22.640 --> 01:25.620 We're not going to be naming vendors or product names here. 01:25.620 --> 01:29.400 We're going to try and keep it general so it's helpful for everyone. 01:29.400 --> 01:32.120 We're not just sort of giving specific examples. 01:32.120 --> 01:34.640 Hopefully there's something that everyone can take away. 01:36.120 --> 01:55.980 Sort of for a bit of a framing of the talks of the issues I'm going to present, while I've been thinking about discussing putting this presentation together, I've sort of gone back to the CIA triad and been focusing on their integrity and availability sort of of the systems and how these issues sort of affect those. 01:57.200 --> 02:08.520 I will note that a lot of these EFBs and the receivers that are used by EFBs will say, you know, do not use for navigation or safety etc purposes. 02:08.980 --> 02:11.900 We know people are actually going to use them. 02:11.900 --> 02:14.220 People are going to put too much trust in them. 02:14.220 --> 02:21.820 So where possible, we should try and still make them safe if there are people using them in these situations. 02:24.270 --> 02:35.810 So what I'd like people to take out of this talk today is some ideas about how to make more robust and secure systems for their customers, for the pilots using their systems. 02:35.950 --> 02:49.410 There's going to be a particular focus on general aviation EFBs, but hopefully some of these ideas can apply for 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:21.850 But a lot of these issues, as we've seen industries move into a more digital, more connected world, we've seen a lot of these types of issues, categories, classes of issues come up as they've made this transition into this new digital world. 03:21.850 --> 03:35.490 So aerospace is not going to be the first industry to go through all these growing pains, nor is it the last industry that is going to go through this growth of product scope and have to deal with these issues. 03:37.050 --> 03:41.070 So what is an EFB in the general aviation context? 03:41.070 --> 03:43.330 It's often going to be on a tablet. 03:44.770 --> 03:51.770 It's going to provide the pilot with some combination of flight charts for navigation, airport charts. 03:51.770 --> 03:56.250 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:16.330 It will be able to show the pilot what other planes and aircraft are around the plane that they're flying. 04:18.310 --> 04:24.490 So this is how a tablet and a receiver and the sensors sort of fit together. 04:24.890 --> 04:28.010 So in the middle we have some sort of receiver unit. 04:28.210 --> 04:33.810 These are commonly, you know, and then we'll have the tablet with the EFB. 04:33.950 --> 04:40.650 And this communication between the receiver and the tablet slash EFB is quite often going to be Wi-Fi. 04:40.650 --> 04:42.530 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:04.570 The receiver can take inputs from a variety of different sensors and inputs. 05:04.570 --> 05:10.230 So we could have GPS satellites as one with ADSV in to help the situational awareness. 05:10.230 --> 05:22.270 We may have a gyro and an accelerometer that will help with pitch, yaw, roll, acceleration, deceleration. 05:23.390 --> 05:33.830 In addition to the receiver sending information to the EFB or tablet, there may also be a web interface to the receiver where sort of configuration of the receiver can be done. 05:33.850 --> 05:36.470 And this normally happens over HTTP. 05:38.830 --> 05:47.390 So for my testing, I sort of only used my own tablets, my own receiver, and my own hardware. 05:47.390 --> 05:55.850 Where radio was involved, sort of, I did, you know, I made sure that my signals did stay contained to my test environment. 05:55.850 --> 05:58.130 So I used a Faraday cage. 05:58.130 --> 06:01.030 Where possible, I turned the transmit power down. 06:01.150 --> 06:03.670 I tried to use non-aviation frequencies. 06:03.670 --> 06:12.150 So if I could change the frequency used by the transmitter and the receiver unit, I would use non-aviation frequencies. 06:12.150 --> 06:18.810 Where possible, I'd directly connect the transmitter to the receiver with a cable and some attenuators to drop. 06:18.990 --> 06:23.410 So the receiver wouldn't get burnt out by the additional power. 06:23.410 --> 06:29.250 So I was really trying to make sure my system stayed contained to just my test setup. 06:31.740 --> 06:39.320 So there's a variety of examples and issues I'm going to go through, 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:52.930 So what this will do is the receiver will send a heartbeat message on a regular basis. 06:52.930 --> 07:00.110 The EFB will receive the heartbeat message and use that as an indication the receiver is up and working as expected. 07:00.750 --> 07:11.020 And it can be used to inform the pilot that the receiver is not functioning correctly or the connection between the EFB and the receiver is not working. 07:12.070 --> 07:31.510 So as an example, if we start an EFB and the receiver is off, we'll often get some type of red X, some type of no connection, no heartbeat, no connection established, some sort of error message that's quite prominent and displayed. 07:31.510 --> 07:33.710 Most of them involved a red X. 07:33.710 --> 07:36.830 I was quite clear that the system was not ready for use. 07:38.250 --> 07:46.430 So when we did start the receiver and the EFB connected to the receiver, the red X went away and it started to display data. 07:46.430 --> 07:51.010 So headings, speeds, altitude, in this case. 07:53.070 --> 07:55.470 So what happens when the heartbeat stops? 07:55.750 --> 07:58.570 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:19.890 Everything's going to be fine like nothing has happened. 08:19.890 --> 08:20.870 It's all OK. 08:22.650 --> 08:25.310 So who picked just continue? 08:25.650 --> 08:28.550 Well, that is what happened in some cases. 08:28.970 --> 08:37.210 When the system is an integrated state, it should tell the pilot that the heartbeat message has gone away, that I can't trust the receiver anymore. 08:39.430 --> 08:47.070 So when we are, you know, for these heartbeat messages, we need to make sure the EFB is using it as an ongoing check. 08:47.070 --> 08:51.230 It's not just a check to be used to start up, have all the components started up. 08:51.230 --> 08:56.790 It needs to be an ongoing check to ensure that the receiver is still up and running. 08:56.790 --> 09:10.290 Because in some of these cases, if you stop the receiver, the EFB will keep displaying the same altitude, 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:18.390 And you could extend this now to start looking at other data. 09:18.390 --> 09:28.750 If you had been continuously receiving the altitude and every message that included the altitude, then suddenly the altitude field was no longer there. 09:28.750 --> 09:38.290 That's an indication that, again, that something's wrong, and a piece of data that the EFB was expecting or had become used to expecting has disappeared. 09:38.290 --> 09:48.270 Maybe it should inform the pilot that just because the altitude has disappeared, 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:02.490 The data that EFBs receive from the receivers may not always be valid. 10:02.850 --> 10:10.610 Likewise, the data the receivers receive from the sensors or other inputs may also not be correct. 10:10.710 --> 10:15.690 Receivers' sensors have faults which could result in bad data being sent. 10:15.810 --> 10:18.550 There may be corruption happening on the wire. 10:18.550 --> 10:26.610 A malicious individual could be injecting or intentionally manipulating the data to make it malicious. 10:28.840 --> 10:32.760 So one example is headings. 10:32.760 --> 10:34.280 This is a test I did. 10:34.600 --> 10:44.860 Normally a heading in aviation was between 0 and 359 degrees, or 1 and 360 degrees, depending on the particular implementation. 10:44.860 --> 10:49.920 But whatever happens, the heading should not be more than 360 degrees. 10:50.460 --> 11:01.820 So in one case, with a dummy receiver, I sent an EFB a message where the heading was 450 degrees. 11:01.920 --> 11:22.180 It was actually remapped and displayed as 90 degrees, which if you take a step back and you think about the underlying math libraries which EFB may be using, when you talk about degrees and degree maths, 90 degrees makes sense because you've got 450 degrees. 11:22.180 --> 11:27.840 So you go 360 for a whole circle, then another 90 degrees, 450. 11:28.340 --> 11:32.680 In the math domain, when you're dealing with angles, that makes sense. 11:32.680 --> 11:42.740 But in the aviation domain, yes, headings are measured as degrees, but we're dealing with headings, not degrees. 11:43.240 --> 11:44.860 So in this case, 11:51.140 --> 11:54.540 in aviation, it's 360 degrees. 11:54.540 --> 11:57.320 So if it's more than that, we know it's actually an error. 11:59.620 --> 12:17.360 So if we take a quick step away from EFBs and we think about another system where there can be pilots presented with information in their user interface, which informs the pilot that there is a disagreement, there is an issue with a sensor. 12:17.600 --> 12:22.860 A recent case has been with the 737 MAX and the MCAS. 12:22.860 --> 12:30.180 One of the things have come out that the angle of attack indicator, the AOA, there's a disagree warning. 12:30.180 --> 12:33.540 This was an optional extra that airlines could select. 12:34.520 --> 12:43.900 And I understand in the MCAS changes, this warning is now going to be implemented on all 737 MAX aircraft. 12:43.900 --> 12:57.200 And what this warning does was displaying that when the sensors no longer, seen as multiple AOA sensors on an aircraft, when the values differed, it was going to warn the pilot there was a disagreement. 12:57.420 --> 13:08.140 So the pilots knew that this piece of data could not be no longer valid and maybe they need to use other sources to cross reference and understand what the issue was. 13:09.380 --> 13:21.100 So it would be good if AFBs, when they start to detect the data may no longer be valid, it's gone out of bounds, it's not what they expect, there's a disagreement. 13:21.260 --> 13:33.880 It'd be good to see if there was a type of warning, you know, if an AFB could provide some sort of warning as the 737 MAX does with AOA disagreement as one sort of recent example. 13:34.840 --> 13:44.940 So this can be, you know, when they start to disagree or they go out of bounds, like the headings of the 450 degrees, it's out of bounds, it's an indication there should be an error. 13:47.220 --> 13:55.700 So what AFBs and receivers should do is they should know what the data should look like under normal operation. 13:57.340 --> 14:02.720 You know, they should be checking that their expected data, is it in the correct range? 14:03.420 --> 14:13.220 And when it's out of range, inform the pilots somehow or stop the information being sent so people cannot make the wrong decisions about it. 14:13.220 --> 14:18.020 Or you know that you shouldn't be relying on a sensor that is having a fault. 14:19.220 --> 14:21.760 Additionally, you can look at the trends in the data. 14:22.580 --> 14:32.820 You know, if the vertical speed results in an altitude change that's completely out of bounds, maybe you should stop displaying altitude or vertical speed. 14:32.820 --> 14:52.100 So for instance, if your altitude suddenly changes 10,000 feet in a few seconds, either there's a fault with the plane and the pilot already knows about it because the plane is dropping out of the sky, or there is a fault with the receiver or the altitude system somehow. 14:52.100 --> 15:03.100 In that case, you should inform the pilot, don't trust this altitude, go trust one of the other instruments that is giving you altitude and rely on that. 15:03.100 --> 15:11.920 And it may indicate that other sensors involved, which the EFB users, may also be invalid and the pilot should not rely on them. 15:18.170 --> 15:24.950 So with the situational awareness that pilots can have of the aircraft around them, there are some sort of denial of service scenarios. 15:25.710 --> 15:36.710 So what some EFBs do is they have a movie map, which is normally for navigation, showing you where the navigational aids are, showing you your route. 15:38.150 --> 15:47.290 But additionally, if the system is capable of ADS-B, it can start showing the other aircraft around and where they are. 15:47.590 --> 15:52.170 And with software defined radio, it's easy to transmit ADS-B out. 15:52.170 --> 16:01.570 RenderMan and others have discussed this previously at many other conferences, and I believe there's some other talks at Aerospace Village on ADS-B spoofing as well. 16:04.070 --> 16:06.610 So this is sort of roughly what it looks like. 16:06.610 --> 16:12.150 We've got a movie map, we've got the aircraft, we've got its route, and we've got some other planes around it. 16:14.890 --> 16:22.470 So what I did was I did a situation where we had this plane and I injected a large number of planes around it. 16:22.470 --> 16:26.190 So it's going to be really congested, super congested airspace. 16:26.190 --> 16:32.390 Lots of conflicts, lots of potential path crossings, a lot of potential hazards. 16:33.170 --> 16:40.350 So when I broadcasted this, I was expecting the EFB to show all the planes that I broadcasted. 16:40.350 --> 16:49.290 But in some cases, you know, on the right there in the diagram I've just popped up, it doesn't actually necessarily display all the planes. 16:49.290 --> 16:54.650 Some of the planes were being dropped off and missing. 16:55.350 --> 17:01.990 It wasn't always the furthest ones away that disappeared, so it wasn't some sort of range thing of there's too many planes. 17:01.990 --> 17:06.050 I only showed the closest X number of planes. 17:07.190 --> 17:15.730 I couldn't really determine a pattern that resulted that of what planes were missing. 17:16.010 --> 17:22.370 And also, if I replayed the same input data into the system, I wouldn't necessarily get the same output. 17:22.650 --> 17:41.830 So without sort of further research and diving into the code, my current hypothesis is it's something to do with the way that the timing of the message received and how it packages up X number of planes to send down every half a second or every 10 milliseconds, 17:41.830 --> 17:49.150 depending on how often it sent the current list of planes, and there was some cut off in buffers. 17:49.150 --> 17:50.150 That's my hypothesis. 17:50.150 --> 17:51.010 I'm not entirely sure. 17:51.010 --> 17:55.450 It's just saw this pattern of indiscriminate planes being dropped off. 17:57.570 --> 18:03.610 And this ABSV spoofing that can be combined with TCAS issues. 18:03.610 --> 18:07.890 I think Pentest partners, Ken, talked about this back in May. 18:07.890 --> 18:14.950 I believe there's also a talk going on during this aerospace village about this in more depth. 18:14.950 --> 18:26.710 But what I'll say on this is with ADSV and TCAS, TCAS is the traffic collision avoidance system, that you can actually help. 18:26.710 --> 18:32.530 You can start putting in malicious ADSV targets to help reinforce the pilot. 18:32.530 --> 18:34.550 There is actually a real TCAS issue. 18:34.550 --> 18:38.890 It's not a malicious one, because you can make the two sources correlate with each other. 18:38.890 --> 18:50.730 So you could have a malicious plane come in and then you'd start to get TCAS messages maliciously, which will come in and reinforce that as well. 18:52.890 --> 19:07.930 So whilst discussing some TCASes, TCAS in some instances from what I understand has directional antennas, so it can tell where the TCAS message is coming from, whether it's to the left or whether it's to the right or up or down and so on. 19:07.990 --> 19:27.390 We could do the same with ADSV antennas, so we know where the aircraft should be based on its location in the ADSV message, but we could also look at the direction the signal is coming from to ascertain if I believe the plane's over there and the signal is coming from over there, 19:27.390 --> 19:28.950 so that they most probably correspond. 19:28.950 --> 19:37.270 But if the plane's over there and the signal is coming from another direction, we know that possibly this is a malicious ADSV message. 19:37.330 --> 19:40.350 So if we've got that, we can rule them out. 19:42.050 --> 19:59.610 And the ADSV receivers, when they are not going to pass down a full set of aircraft as they're somehow dropping aircraft, it needs to inform the downstream systems, in this case the EFB, that there is an issue and it is operating in a degraded state. 20:01.930 --> 20:18.090 Additionally, if the EFB is dropping planes because of some limitation it has, it should also display some indication that planes are missing from the display and do not use this as a situational awareness tool at the moment. 20:24.960 --> 20:27.320 So GPS spoofing. 20:27.780 --> 20:36.160 From what my testing and from what I've seen, GPS jamming, GPS signal loss are sort of handled quite well in the EFBs. 20:36.220 --> 20:46.980 There's normally indicators that there is a GPS fix, 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:07.700 So when we send a malicious GPS signal, what I'm thinking of is sending a valid GPS signal replicating a set of satellites, which result in the aircraft determining the wrong position. 21:10.740 --> 21:32.480 So at last year's Aviation Village, there was a talk on ILS spoofing, which involved in the result of aircraft potentially having the wrong horizontal offsets or the wrong glide slope, and resulting the planes landing in the wrong location. 21:32.480 --> 21:51.920 One of the cases here was, oh, GPS and GNSS, RNAV, can be used to cross reference, you know, the glide slope and stuff, so they should be lining up, and if they don't line up, they can alert the pilot, and they can make further decisions about going round and ascertaining what their navigation systems are. 21:51.920 --> 21:59.640 But we could also use GPS spoofing to match up with the ILS spoofing, so they're actually going to correspond. 21:59.640 --> 22:05.280 This cross check no longer becomes a cross check because they're both incorrect. 22:05.500 --> 22:12.920 But they're both incorrect, but they're both showing the same values, so there is no cross check, and there's no indication that one of them is wrong. 22:15.020 --> 22:25.540 So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research that was mainly based around time and manipulation of time servers. 22:25.900 --> 22:34.560 But what I did during that thing, during that research, was I looked at how we could go about detecting GPS spoofing. 22:34.560 --> 22:39.600 And in that case, I came up with a bit of a proof of concept tool called GPS Snitch. 22:39.600 --> 22:51.200 It's not production ready, but what it was is looking at some of the GPS parameters, signal parameters, and so it was possible to actually detect when GPS spoofing was happening. 22:52.800 --> 23:10.960 So for a start, the maths is all based around the GPS satellites broadcasting a very accurate time, and then based on the time offsets between the different satellites, math happens and you get a location. 23:12.420 --> 23:25.480 So if we've got a clock on the receiver that is being synced up with the GPS when we first turned it on, the time should stay in sync together. 23:25.480 --> 23:44.080 But if we suddenly start GPS spoofing and the GPS receiver locks onto this spoof set of signals from a range of spoof satellites, we'll notice the time will jump, and it might be 10 milliseconds ahead of time, 5 milliseconds slow. 23:44.080 --> 23:49.060 But if we get sudden change in time, that's an indication that a spoofing has happened. 23:49.060 --> 23:59.300 Because trying to start up and have a spoofing attack start with a time with sub millisecond accuracy is quite a difficult task. 24:01.260 --> 24:02.620 And that's one parameter. 24:02.620 --> 24:11.560 There's other parameters, and I found that actually when you looked at more parameters, it was actually you get a much more stable system, particularly if you're leaving it running. 24:11.840 --> 24:21.420 You know, during my test I left it running for a day just to see what the natural variations were, and I found that sort of one look at one attribute wasn't really enough. 24:21.420 --> 24:23.320 You need to look at a range of attributes. 24:24.680 --> 24:38.040 So if you're in a case in an aircraft, if the location changes more than what the current speed allows, that's an indication that, you know, it could be GPS spoofing. 24:38.040 --> 24:51.020 Because you know your velocity, and if it changes, if you're outside of that, you've got a sort of a circle of uncertainty which may be valid, and if you're outside that, that's a potential issue. 24:51.580 --> 24:54.620 Also looking at the GPS signal strength. 24:55.000 --> 25:05.800 GPS satellites are 20,000-ish kilometers away, give or take a bit, so the overall strength of the GPS signal when it gets down to ground level is very low. 25:08.880 --> 25:22.700 So suddenly if we get a GPS signal suddenly raising strength a lot, that's possibly an indication that a GPS spoofing attack is happening, because the transmitter of the fake GPS satellites is going to be much closer. 25:23.060 --> 25:25.560 So matching the signal strength is hard. 25:25.560 --> 25:35.760 Additionally, we should have a range of signal strengths, because the satellites directly overhead seem they are closer than the ones way out at the horizon. 25:36.900 --> 25:42.680 They're going to have different signal strengths because the distance traveled and the amount of atmosphere they have to travel through. 25:42.680 --> 26:02.220 But suddenly if the range of different signal strengths decreases, that's another indication that a malicious GPS transmission is happening, because when you're doing the malicious transmission chances are it's all coming from one transmitter and it's going to have a very similar signal strength. 26:05.530 --> 26:11.190 Additionally, like we said back with the TCAS and the GPS was again looking at the signal direction. 26:12.190 --> 26:15.750 We know where the GPS satellites should be at any given time. 26:15.750 --> 26:18.290 We know the plane's current location. 26:18.810 --> 26:25.190 So we know in what direction the GPS signal should be coming from for each of the satellites. 26:25.190 --> 26:34.350 So if they don't come from the expected direction, it's an indication that there might be GPS spoofing or a GPS attack happening. 26:35.930 --> 26:46.290 So what we need to do to help mitigate some of this risk in the EFBs is they need 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 --> 27:02.490 Show an indicator that when you have no GPS fix, when you detect the spoofing, display GPS no GPS fix because you can no longer trust that as an input. 27:02.510 --> 27:13.170 Mark it as no GPS fix or degraded GPS fix or something whatever meets the relevant terminology and accuracy standards. 27:19.600 --> 27:21.960 So integrity of the data. 27:21.960 --> 27:31.220 The data sort of in the overall system of receivers and EFBs and sensors, it's nearly always happening in clear text. 27:31.220 --> 27:37.860 There is an encrypted version of GDL 90, but from what I saw that was not in very common use. 27:37.860 --> 27:41.420 My guess is it's a bit of a chicken egg problem. 27:41.420 --> 27:51.080 The receiver manufacturers don't see the point in implementing it because none of the receivers, sorry, none of the EFBs are implementing it. 27:51.280 --> 27:57.940 EFB manufacturers don't implement it because none of the receiver manufacturers have implemented it. 27:59.280 --> 28:09.920 Additionally, the Wi-Fi is often open and in clear text, so anyone within range can connect to it with no authentication required. 28:13.420 --> 28:21.580 And also there is when you first sort of pair an EFB and a receiver, there's no key material changed. 28:21.580 --> 28:26.700 So you can switch out the receiver and the EFB will still keep talking to it. 28:26.700 --> 28:34.400 If it's the same SSID for the Wi-Fi, the same Wi-Fi password, it will just connect fine. 28:34.400 --> 28:35.860 It won't inform the pilot. 28:35.860 --> 28:39.460 So, you know, think back to your headphones and your phone. 28:39.480 --> 28:48.480 When you get a new set of Bluetooth headphones, you need to pair your headphones and your phone and they're connected and they're only going to talk to each other. 28:48.880 --> 28:59.400 You know, if you didn't pair them and you didn't have the sort of checking that they're talking to each other, as you're walking down the street listening to music, you'd start hearing the music of everyone walking past you. 29:00.500 --> 29:04.360 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:21.000 So, you know, if you have a friend who you're doing some formational flying with and because you're friends, you've discussed receivers and you've settled on the same sort of receivers and EFBs because you both like them. 29:21.720 --> 29:36.620 You don't want the situation that if everyone's left it with the default Wi-Fis and the default SSIDs because it just starts working, you don't want the EFB in one aircraft 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.160 Have receivers start to say, you know, on this date, we're going to implement it. 29:55.160 --> 29:59.400 On this date, further down the track, we're only going to have GDL 90. 29:59.400 --> 30:05.160 Likewise, on the EFB front, make sure 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:25.300 Make sure there is a pairing process to couple them together so you can't introduce a malicious receiver and have the EFB connect with no error messages. 30:25.300 --> 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:32.940 That it trusts. 30:34.140 --> 30:36.940 If the message is not signed, disregard it. 30:36.940 --> 30:40.360 And additionally, ensure there's some protection against replay attacks. 30:40.360 --> 30:50.380 So make sure that a malicious event that you can't capture a packet or a series of packets 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:04.800 So device hardening is part of my job. 31:04.800 --> 31:11.360 I look at devices, systems, hardware and to make sure they are robust. 31:11.360 --> 31:14.720 You know, there's testing to make sure they've got vulnerabilities, but also checking that they're robust. 31:14.720 --> 31:19.620 So even if they're vulnerabilities, I don't know about their attack footprint is as small as possible. 31:21.080 --> 31:26.540 And when I was looking at some of those of the receiver devices, I was put this hat on. 31:26.540 --> 31:31.380 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:53.180 For instance, you know, there was a receiver that had an internal fan and based on the receiver's temperature, it would put the fan speed up and down to keep the system at the optimal temperature. 31:53.180 --> 32:04.880 But instead of setting it up so the fan controller only listened to commands coming from inside the device, they configured it so it would accept commands from anywhere in the Wi-Fi network. 32:06.360 --> 32:15.700 You know, and that's wrong because in case the only thing the fan controller should be receiving commands from is the temperature sensor inside the receiver. 32:15.700 --> 32:22.620 So when the temperature sensor noticed the temperature raising, it needed to tell the fan to go faster and vice versa. 32:25.420 --> 32:26.820 Additionally, they're all weak. 32:26.820 --> 32:30.360 Wi-Fi configs, as mentioned before, a lot of them are open. 32:30.360 --> 32:31.840 They don't have pre-shared keys. 32:31.840 --> 32:35.300 They don't use WPA2, WPA3. 32:37.080 --> 32:42.500 You know, using pre-shared keys, they will put protection on it. 32:42.500 --> 32:45.040 So A, it will encrypt most of the data. 32:45.220 --> 32:49.500 B, it will mean that only authorized people can connect to that Wi-Fi network. 32:49.500 --> 32:54.540 So you won't have malicious and rogue things connecting to the Wi-Fi network. 32:55.700 --> 33:06.420 Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do against it which can have downsides. 33:06.420 --> 33:14.360 For instance, there's management frames which are sort of below the data and control the Wi-Fi connection. 33:14.540 --> 33:17.740 And there's a particular message called a deauthentication packet. 33:17.740 --> 33:21.160 And what that does, it's sent from the access point to the receiver. 33:21.160 --> 33:30.280 So the access point, in this case, would be the receiver device and the wireless client would be the tablet slash EFB. 33:30.880 --> 33:38.980 And what the access point says is say, normally you'll 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.100 My problem is, is these messages aren't signed normally. 33:48.100 --> 33:52.880 So anyone could come along and send deauthentication packets. 33:52.940 --> 34:01.940 And this results in two possible cases that you get a denial of service because the EFB or tablet will no longer be able to connect. 34:01.940 --> 34:04.940 It just keeps being told to re-authenticate. 34:04.940 --> 34:12.240 So I'll go, I'll connect, get a packet, say 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:21.380 There might be a malicious receiver. 34:21.380 --> 34:27.760 So what you do is when it's connected to the legitimate receiver, you send deauthentication packets. 34:27.760 --> 34:32.320 When it's connected to the malicious receiver, you don't send deauthentication packets. 34:32.320 --> 34:33.440 So it stays connected to that. 34:33.440 --> 34:42.560 So the EFB is receiving data from the malicious receiver rather than the receiver that the pilot put there. 34:43.940 --> 34:46.980 There's also additional services running. 34:46.980 --> 34:53.140 SSH is a common tool used for remote access to a device for configuration. 34:53.240 --> 35:03.840 So in essence, production devices don't need SSH enabled at all because they should be in a sort of secure, hardened format. 35:04.480 --> 35:10.440 When it's not an active development or active debug, you don't need the sort of access to the device. 35:10.660 --> 35:18.920 And even digging into further, its configuration is not in line with sort of best practices for the use case. 35:18.920 --> 35:28.500 Sort of in following hardening guides, they sort of had basic things like port 14 turned on, route logons turned on, a lot of things that you wouldn't normally see in something. 35:28.500 --> 35:36.260 You'd see it in the default sort of installs just to make it work, but it hasn't shown the additional hardening steps that have gone through. 35:38.040 --> 35:45.860 Also, the web config user interface had no password on first use, no password change on first use, no password at all. 35:45.960 --> 35:57.260 So even if the Wi-Fi network had a pre -shared key and password, as I mentioned on the previous slide, you should also have a password on the web UI to control the configuration of the receiver. 35:57.520 --> 36:01.940 This is so we have security in there, so it's got multiple layers of security control. 36:01.940 --> 36:10.620 So if one fails, it's still a safety net to stop it stopping the malicious individual getting further into the system. 36:11.400 --> 36:16.140 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:28.360 Make sure their attack footprint is as small as possible. 36:28.360 --> 36:37.650 If components have hardening guides, make sure those are read and followed through and used to make the device as secure as possible. 36:43.230 --> 36:45.410 So password management. 36:45.690 --> 36:53.670 So as I just said, web UIs often didn't have passwords on them or didn't prompt for a password change on first use. 36:54.450 --> 36:58.990 Going back to the Wi-Fi case I've used a few times now. 36:59.490 --> 37:09.070 There is sometimes options to enable Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys. 37:09.830 --> 37:15.770 One when it did this said, came off a message saying we've securely set up your Wi-Fi. 37:17.770 --> 37:20.830 You're only going to show you this password the once. 37:21.210 --> 37:24.110 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:31.270 Try setting up the Wi-Fi. 37:31.270 --> 37:32.990 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:43.970 Gives me the same password. 37:43.970 --> 37:47.450 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:11.850 Additionally, in this case, I found it a little bit worse was because the text and the messaging around the password setup 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:18.070 It was secure, when in actual fact it wasn't. 38:18.070 --> 38:20.170 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:35.610 So they can't make the correct decisions if they've been provided with incorrect input information or documentation. 38:36.750 --> 38:45.430 So if there is a hardcoded password that you're going to use, say it's a hardcoded password and recommend that the users actually set their own password. 38:45.430 --> 38:51.890 Or better yet, just randomly set a random password. 38:51.890 --> 39:04.330 Give them a QR code that you can scan, because most tablets and phones these days can read a QR code with 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:27.590 You had to sign up some of the times because the EFBs would not work without them, 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:43.290 This allowed for flight plans or additional up-to-date weather information, sort of other non-free services that it gave you. 39:43.350 --> 39:46.850 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 --> 39:58.070 I noticed there were some issues. 39:58.090 --> 40:09.450 In one case I got emailed a password in clear text, which to me as a pen tester often means that passwords are not being correctly stored in the database. 40:09.450 --> 40:17.010 The fact that a clear text password can be sent via email, so that's a sign that incorrect password storage has been used. 40:17.310 --> 40:27.090 Additionally, you also saw some that allowed for weak passwords, so passwords that don't meet the standards of what people think is a strong password these days. 40:27.090 --> 40:31.210 Additionally, had some that said, well, don't use any special characters. 40:31.210 --> 40:48.010 So putting my pen tester hat on, if I see a password field or some other user input field that says, oh, don't use quote marks, don't use dashes, and don't use these sort of other symbols, to me that's a red flag that SQL injection might be available. 40:48.010 --> 40:54.130 They're trying to protect SQL injection by just not allowing users to use these characters. 40:54.430 --> 41:06.890 So, you know, if I was testing this for a job at work, if I saw text like don't use the quote mark, first thing I'm going to do is test SQL injection on it because chances are that's why that message is there. 41:09.580 --> 41:11.920 So password management. 41:12.160 --> 41:29.580 OWASP, the Open Web Application Security Project Foundation, has a range of great check sheets and these uncover password storage, password management, authentication, along with a range of other really helpful documentations. 41:29.580 --> 41:33.100 They've got stuff around building more secure web apps. 41:33.100 --> 41:39.120 Additionally, they've also got stuff on building secure mobile apps, which most AFBs are. 41:39.240 --> 41:41.740 So that's a great resource for information. 41:43.660 --> 41:48.800 So hopefully these example issues and solutions have helped you. 41:48.940 --> 41:54.380 And you've gone away, you've got some ideas that you want to look into in your own products some more. 41:54.900 --> 42:05.260 And I hope that as you do future development, as you add features, as you test functionality, that you think, oh, what could a malicious individual do with this? 42:05.560 --> 42:12.380 You know, is there a way that they could affect their integrity or their availability of the system with what they could do? 42:12.700 --> 42:19.480 Sort of having the sort of what-if hacker mindset and hopefully you can bring some of that into your testing and your development. 42:21.080 --> 42:26.920 Also, what can the security industry do to help the aerospace industry in this regard? 42:26.920 --> 42:29.340 What help would you like from us? 42:29.700 --> 42:34.440 You know, would some example test cases of this malicious thinking be useful? 42:34.440 --> 42:42.500 So as an FB or receiver manufacturer, you can take these test cases on board and start working them into your systems. 42:42.980 --> 43:00.080 Would a test harness that was, say, a dummy receiver which talked GDL-90, but instead of just sending sort of valid, helpful GDL-90, also sent malicious payloads and started pushing the boundaries a bit more. 43:00.080 --> 43:01.940 Would that be something that was helpful? 43:01.940 --> 43:12.900 That you could set up this test harness for this receiver, connect your FB to it and have it send all this malicious information to help you if the automation of the testing. 43:12.900 --> 43:14.240 Would that be something that's helped? 43:14.240 --> 43:19.260 So really good to hear some feedback from the industry about what you need from us as well. 43:20.520 --> 43:22.500 So, thank you. 43:23.260 --> 43:25.540 Hopefully it's been useful for everyone. 43:26.220 --> 43:35.620 I'd really love to hear feedback, chat to some people, because if I'm passionate about it, I'm sure there are other people here out there who are interested about it. 43:35.900 --> 43:38.440 Or that's why you came along and listened to this talk. 43:38.720 --> 43:40.080 Thank you very much. 43:40.220 --> 43:41.480 See you all later.