start	end	text
6920	15320	Kia ora koutou katoa. Welcome everyone. I'm David Robinson, go on the internet as the name carrot.
15440	21200	I'm a pen tester at ZX Security in Aotearoa New Zealand. For those who don't know where
21860	24130	Aotearoa is, we're at the top of the map there.
26560	33240	I enjoy, a little bit about me, I enjoy aviation and hacking. Queensland and Australia has a couple
33240	39260	of great conferences with great hacker content, but they're also on their approach path for their
39260	45000	local airport so you can sit on the riverbank or on the beach and watch planes come and go.
45000	47380	So that's a great combination there.
48940	54320	Today we're going to be looking at electronic flight bags in the general aviation cockpit.
54860	60220	We're going to go through some example issues, some vulnerabilities, some security type things,
60220	64880	and also going to discuss how we can mitigate the issues in each case.
64880	68560	I'm going to go through these in more detail as we go through the talk.
71300	75700	With the issues I'm going to present, we're at quite a high level for vulnerabilities.
75740	80540	Discuss more sort of classes and types of issues, opposed to diving down into
80540	85620	individual vulnerabilities. We're not going to be naming vendors or product names here.
85620	90200	We're going to try and keep it general so it's helpful for everyone. We're not just sort of
90200	94640	giving specific examples. Hopefully there's something that everyone can take away.
96120	101660	Sort of for a bit of a framing of the talks of the issues I'm going to present,
101660	105740	while I've been thinking about discussing putting this presentation together,
105740	111240	I've sort of gone back to the CIA triad and been focusing on their integrity and availability
111240	115980	sort of of the systems and how these issues sort of affect those.
117200	123900	I will note that a lot of these EFBs and the receivers that are used by EFBs will say,
123900	131120	you know, do not use for navigation or safety etc purposes. We know people are actually going
131120	135640	to use them. People are going to put too much trust in them. So where possible,
135640	141820	we should try and still make them safe if there are people using them in these situations.
144270	150770	So what I'd like people to take out of this talk today is some ideas about how to make more robust
150770	156830	and secure systems for their customers, for the pilots using their systems. There's going to be
156950	163510	a particular focus on general aviation EFBs, but hopefully some of these ideas can apply for
163510	169410	other EFB manufacturers and other parts of the aerospace industry.
171090	178590	To an IT security professional, most of these issues and problems are going to discuss will not be new issues.
178590	186970	I will be trying to put an aerospace spin and examples to them to help tie them to the aerospace industry.
187390	193750	But a lot of these issues, as we've seen industries move into a more digital, more connected world,
193750	197610	we've seen a lot of these types of issues, categories, classes of issues
197610	203030	come up as they've made this transition into this new digital world. So aerospace is not going to be
203030	209790	the first industry to go through all these growing pains, nor is it the last industry that is going to
209790	215490	go through this growth of product scope and have to deal with these issues.
217050	223330	So what is an EFB in the general aviation context? It's often going to be on a tablet.
224770	230250	It's going to provide the pilot with some combination of flight charts for navigation,
230250	236250	airport charts. It might provide some altitude and heading reference systems.
236250	241330	So your artificial horizon, altitude, speed, direction.
242330	248690	It may also provide some situational awareness through ADSV or FLAMIN.
248690	255330	It will be able to show the pilot what other planes and aircraft are around the plane that
255330	264490	they're flying. So this is how a tablet and a receiver and the sensors sort of fit together.
264890	271930	So in the middle we have some sort of receiver unit. These are commonly, you know, and then we'll
271930	278390	have the tablet with the EFB. And this communication between the receiver and the tablet slash EFB is
278690	282530	quite often going to be Wi-Fi. In some cases it's Bluetooth.
283910	289650	And between the receiver and the tablet, the most common protocol used is GDL-90.
291010	295130	And then some things will also use HTTP or WebSockets.
296730	305290	The receiver can take inputs from a variety of different sensors and inputs. So we could have
305290	310230	GPS satellites as one with ADSV in to help the situational awareness.
310230	320170	We may have a gyro and an accelerometer that will help with pitch, yaw, roll,
320170	328070	acceleration, deceleration. In addition to the receiver sending information to the EFB or tablet,
328070	333030	there may also be a web interface to the receiver where sort of configuration of the receiver can be
333030	342150	done. And this normally happens over HTTP. So for my testing, I sort of only used my own
342150	350950	tablets, my own receiver, and my own hardware. Where radio was involved, sort of, I did,
350950	356990	you know, I made sure that my signals did stay contained to my test environment. So I used a
356990	362610	Faraday cage. Where possible, I turned the transmit power down. I tried to use non-aviation
362610	369390	frequencies. So if I could change the frequency used by the transmitter and the receiver unit,
369390	374390	I would use non-aviation frequencies. Where possible, I'd directly connect the transmitter
374390	382090	to the receiver with a cable and some attenuators to drop. So the receiver wouldn't get burnt out
382090	386390	by the additional power. So I was really trying to make sure my system stayed contained
387330	396240	to just my test setup. So there's a variety of examples and issues I'm going to go through,
396240	399320	and I'm going to go through each one of these in more detail.
403070	406130	So first up, we're going to look at heartbeat messages.
407030	413610	So what this will do is the receiver will send a heartbeat message on a regular basis. The EFB
413610	417990	will receive the heartbeat message and use that as an indication the receiver is up
417990	425230	and working as expected. And it can be used to inform the pilot that the receiver is not
425230	431020	functioning correctly or the connection between the EFB and the receiver is not working.
432070	439170	So as an example, if we start an EFB and the receiver is off, we'll often get some type of
439170	448550	red X, some type of no connection, no heartbeat, no connection established,
448550	452070	some sort of error message that's quite prominent and displayed. Most of them
452070	456830	involved a red X. I was quite clear that the system was not ready for use.
458250	463070	So when we did start the receiver and the EFB connected to the receiver,
463070	471010	the red X went away and it started to display data. So headings, speeds, altitude, in this case.
473070	478570	So what happens when the heartbeat stops? This can be because we turn the receiver off.
478570	483350	It could also be because a malicious individual is tampering with the data in some way.
483690	486130	So what do people expect is going to happen?
487030	492890	Do they expect the EFB to inform the pilot, bring back the red cross?
492990	496970	Or do they think everything's just going to continue on hunky-dory?
497150	500870	Everything's going to be fine like nothing has happened. It's all OK.
502650	508550	So who picked just continue? Well, that is what happened in some cases.
508970	512470	When the system is an integrated state, it should tell the pilot that
512470	517210	the heartbeat message has gone away, that I can't trust the receiver anymore.
519430	524950	So when we are, you know, for these heartbeat messages, we need to make sure the EFB is
524950	529770	using it as an ongoing check. It's not just a check to be used to start up,
529770	532810	have all the components started up. It needs to be an ongoing check
532810	538070	to ensure that the receiver is still up and running. Because in some of these cases,
538070	544490	if you stop the receiver, the EFB will keep displaying the same altitude,
544490	550290	the same speed, or same location, rather than actually showing that there's an error.
550570	555590	So it needs to inform the pilot that, you know, the heartbeat has stopped being received.
555590	559910	And you could extend this now to start looking at other data. If you had been continuously
560490	565130	receiving the altitude and every message that included the altitude, then suddenly
565610	571310	the altitude field was no longer there. That's an indication that, again, that something's wrong,
571310	578290	and a piece of data that the EFB was expecting or had become used to expecting has disappeared.
578290	582190	Maybe it should inform the pilot that just because the altitude has disappeared,
582190	588270	other data may not be as of the high quality as it was before.
594190	597530	So the validity of data.
597850	604710	The data that EFBs receive from the receivers may not always be valid. Likewise, the data the
604710	611610	receivers receive from the sensors or other inputs may also not be correct. Receivers'
611610	617470	sensors have faults which could result in bad data being sent. There may be corruption happening
617470	624410	on the wire. A malicious individual could be injecting or intentionally manipulating the data
624410	634280	to make it malicious. So one example is headings. This is a test I did.
634600	642520	Normally a heading in aviation was between 0 and 359 degrees, or 1 and 360 degrees,
642520	647400	depending on the particular implementation. But whatever happens, the heading should not be more
647400	658920	than 360 degrees. So in one case, with a dummy receiver, I sent an EFB a message where the heading
658920	667780	was 450 degrees. It was actually remapped and displayed as 90 degrees, which if you take a
667780	675140	step back and you think about the underlying math libraries which EFB may be using, when you talk
675140	682180	about degrees and degree maths, 90 degrees makes sense because you've got 450 degrees.
682180	689940	So you go 360 for a whole circle, then another 90 degrees, 450. In the math domain,
689940	696240	when you're dealing with angles, that makes sense. But in the aviation domain, yes,
696240	704860	headings are measured as degrees, but we're dealing with headings, not degrees. So in this case,
711140	717320	in aviation, it's 360 degrees. So if it's more than that, we know it's actually an error.
719620	726560	So if we take a quick step away from EFBs and we think about another system where
726560	734000	there can be pilots presented with information in their user interface, which informs the pilot
734000	739940	that there is a disagreement, there is an issue with a sensor. A recent case has been with the
739940	746520	737 MAX and the MCAS. One of the things have come out that the angle of attack
747040	753540	indicator, the AOA, there's a disagree warning. This was an optional extra that airlines could select.
754520	758440	And I understand in the MCAS changes, this warning is now
759260	765300	going to be implemented on all 737 MAX aircraft. And what this warning does was
765300	772920	displaying that when the sensors no longer, seen as multiple AOA sensors on an aircraft,
772920	777200	when the values differed, it was going to warn the pilot there was a disagreement.
777420	782900	So the pilots knew that this piece of data could not be no longer valid and maybe they
782900	788140	need to use other sources to cross reference and understand what the issue was.
789380	796460	So it would be good if AFBs, when they start to detect the data may no longer be valid,
796460	802060	it's gone out of bounds, it's not what they expect, there's a disagreement. It'd be good to see if
802060	808820	there was a type of warning, you know, if an AFB could provide some sort of warning as the 737 MAX
808820	816280	does with AOA disagreement as one sort of recent example. So this can be, you know,
816280	821440	when they start to disagree or they go out of bounds, like the headings of the 450 degrees,
821440	824940	it's out of bounds, it's an indication there should be an error.
827220	833620	So what AFBs and receivers should do is they should know what the data should look like
833620	840800	under normal operation. You know, they should be checking that their expected data,
840800	848920	is it in the correct range? And when it's out of range, inform the pilots somehow or stop the
848920	854120	information being sent so people cannot make the wrong decisions about it. Or you know that
854120	860640	you shouldn't be relying on a sensor that is having a fault. Additionally, you can look at the trends
860640	867600	in the data. You know, if the vertical speed results in an altitude change that's
867600	872820	completely out of bounds, maybe you should stop displaying altitude or vertical speed.
872820	879080	So for instance, if your altitude suddenly changes 10,000 feet in a few seconds, either
879840	884200	there's a fault with the plane and the pilot already knows about it because the plane is
884200	892100	dropping out of the sky, or there is a fault with the receiver or the altitude system somehow.
892100	897500	In that case, you should inform the pilot, don't trust this altitude,
897500	903100	go trust one of the other instruments that is giving you altitude and rely on that.
903100	909080	And it may indicate that other sensors involved, which the EFB users, may also be
909080	920470	invalid and the pilot should not rely on them. So with the situational awareness that pilots
920470	924950	can have of the aircraft around them, there are some sort of denial of service scenarios.
925710	932600	So what some EFBs do is they have a movie map, which is normally for navigation,
933030	936710	showing you where the navigational aids are, showing you your route.
938150	944030	But additionally, if the system is capable of ADS-B, it can start showing the other aircraft
944550	952170	around and where they are. And with software defined radio, it's easy to transmit ADS-B out.
952170	956770	RenderMan and others have discussed this previously at many other conferences,
956770	961570	and I believe there's some other talks at Aerospace Village on ADS-B spoofing as well.
964070	968690	So this is sort of roughly what it looks like. We've got a movie map,
968690	972150	we've got the aircraft, we've got its route, and we've got some other planes around it.
974890	978190	So what I did was I did a situation where we had this plane and I
978190	984210	injected a large number of planes around it. So it's going to be really congested,
984210	991290	super congested airspace. Lots of conflicts, lots of potential path crossings, a lot of potential
991290	998750	hazards. So when I broadcasted this, I was expecting the EFB to show all the planes that
998750	1005870	I broadcasted. But in some cases, you know, on the right there in the diagram I've just popped up,
1006690	1011810	it doesn't actually necessarily display all the planes. Some of the planes were being dropped off
1012810	1019290	and missing. It wasn't always the furthest ones away that disappeared, so it wasn't
1019290	1026050	some sort of range thing of there's too many planes. I only showed the closest X number of planes.
1027190	1032490	I couldn't really determine a pattern that resulted that
1033450	1039990	of what planes were missing. And also, if I replayed the same input data into the system,
1039990	1046150	I wouldn't necessarily get the same output. So without sort of further research and diving into
1046150	1052910	the code, my current hypothesis is it's something to do with the way that the timing of the message
1052910	1060690	received and how it packages up X number of planes to send down every half a second or every 10
1060690	1067330	milliseconds, depending on how often it sent the current list of planes, and there was some
1067330	1072350	cut off in buffers. That's my hypothesis. I'm not entirely sure. It's just saw this pattern
1072350	1081570	of indiscriminate planes being dropped off. And this ABSV spoofing that can be combined
1081570	1088610	with TCAS issues. I think Pentest partners, Ken, talked about this back in May. I believe
1088610	1094950	there's also a talk going on during this aerospace village about this in more depth.
1094950	1104350	But what I'll say on this is with ADSV and TCAS, TCAS is the traffic collision avoidance system,
1104350	1110590	that you can actually help. You can start putting in malicious ADSV targets to help
1111170	1116590	reinforce the pilot. There is actually a real TCAS issue. It's not a malicious one,
1116590	1120130	because you can make the two sources correlate with each other. So you could have a malicious
1120130	1128030	plane come in and then you'd start to get TCAS messages maliciously, which will come in and
1128810	1137490	reinforce that as well. So whilst discussing some TCASes, TCAS in some instances from what I understand
1137490	1143410	has directional antennas, so it can tell where the TCAS message is coming from, whether it's to the
1143410	1150170	left or whether it's to the right or up or down and so on. We could do the same with ADSV antennas,
1150170	1156650	so we know where the aircraft should be based on its location in the ADSV message,
1156650	1162470	but we could also look at the direction the signal is coming from to ascertain if
1163190	1168110	I believe the plane's over there and the signal is coming from over there, so that they most
1168110	1173690	probably correspond. But if the plane's over there and the signal is coming from another direction,
1173690	1180350	we know that possibly this is a malicious ADSV message. So if we've got that, we can rule them out.
1182050	1188750	And the ADSV receivers, when they are not going to pass down a full set of aircraft as
1188750	1195750	they're somehow dropping aircraft, it needs to inform the downstream systems, in this case the EFB,
1195750	1199610	that there is an issue and it is operating in a degraded state.
1201930	1207830	Additionally, if the EFB is dropping planes because of some limitation it has,
1207830	1212170	it should also display some indication that planes are missing from the display and
1212170	1218090	do not use this as a situational awareness tool at the moment.
1224960	1231020	So GPS spoofing. From what my testing and from what I've seen,
1231020	1236160	GPS jamming, GPS signal loss are sort of handled quite well in the EFBs.
1236220	1241180	There's normally indicators that there is a GPS fix,
1241180	1246980	and there is also an example when there is no GPS fix, there's an indication.
1248240	1252980	But when we send malicious GPS signals, this is not the case.
1252980	1260580	So when we send a malicious GPS signal, what I'm thinking of is sending a valid GPS signal
1260580	1267700	replicating a set of satellites, which result in the aircraft determining the wrong position.
1270740	1276320	So at last year's Aviation Village, there was a talk on ILS spoofing,
1276320	1284600	which involved in the result of aircraft potentially having the wrong horizontal offsets
1284600	1292480	or the wrong glide slope, and resulting the planes landing in the wrong location.
1292480	1300520	One of the cases here was, oh, GPS and GNSS, RNAV, can be used to cross reference,
1300520	1305400	you know, the glide slope and stuff, so they should be lining up, and if they don't line up,
1305400	1308800	they can alert the pilot, and they can make further decisions about going round
1308800	1314040	and ascertaining what their navigation systems are. But we could also use GPS spoofing
1315880	1320560	to match up with the ILS spoofing, so they're actually going to correspond. This cross check
1320560	1325280	no longer becomes a cross check because they're both incorrect.
1325500	1328840	But they're both incorrect, but they're both showing the same values, so
1328840	1332920	there is no cross check, and there's no indication that one of them is wrong.
1335020	1340760	So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research
1340760	1345540	that was mainly based around time and manipulation of time servers.
1345900	1352440	But what I did during that thing, during that research, was I looked at how we could go about
1352440	1357640	detecting GPS spoofing. And in that case, I came up with a bit of a proof of concept tool
1357640	1363460	called GPS Snitch. It's not production ready, but what it was is looking at some of the GPS
1363460	1370100	parameters, signal parameters, and so it was possible to actually detect when GPS spoofing
1370100	1380300	was happening. So for a start, the maths is all based around the GPS satellites broadcasting
1382340	1388300	a very accurate time, and then based on the time offsets between the different satellites,
1388300	1390960	math happens and you get a location.
1392420	1399900	So if we've got a clock on the receiver that is being synced up with the GPS when we first
1399900	1407680	turned it on, the time should stay in sync together. But if we suddenly start GPS spoofing
1407680	1414760	and the GPS receiver locks onto this spoof set of signals from a range of spoof satellites,
1415540	1421600	we'll notice the time will jump, and it might be 10 milliseconds ahead of time,
1421600	1428320	5 milliseconds slow. But if we get sudden change in time, that's an indication that a spoofing
1428320	1434660	has happened. Because trying to start up and have a spoofing attack start with a time with
1434660	1439300	sub millisecond accuracy is quite a difficult task.
1441260	1443920	And that's one parameter. There's other parameters, and I found
1443920	1448240	that actually when you looked at more parameters, it was actually you get a much more stable
1449420	1453140	system, particularly if you're leaving it running. You know, during my test I left it
1453140	1458860	running for a day just to see what the natural variations were, and I found that sort of one
1459340	1463320	look at one attribute wasn't really enough. You need to look at a range of attributes.
1464680	1471380	So if you're in a case in an aircraft, if the location changes more than what the current
1471380	1478460	speed allows, that's an indication that, you know, it could be GPS spoofing. Because you know your
1478460	1485920	velocity, and if it changes, if you're outside of that, you've got a sort of a circle of uncertainty
1485920	1492820	which may be valid, and if you're outside that, that's a potential issue. Also looking at the
1492820	1500960	GPS signal strength. GPS satellites are 20,000-ish kilometers away, give or take a bit,
1500960	1505800	so the overall strength of the GPS signal when it gets down to ground level is very low.
1508880	1514720	So suddenly if we get a GPS signal suddenly raising strength a lot, that's possibly an
1514720	1519300	indication that a GPS spoofing attack is happening, because the transmitter of the
1519300	1526100	fake GPS satellites is going to be much closer. So matching the signal strength is hard. Additionally,
1526100	1530820	we should have a range of signal strengths, because the satellites directly overhead seem
1531660	1538020	they are closer than the ones way out at the horizon. They're going to have different
1538020	1542680	signal strengths because the distance traveled and the amount of atmosphere they have to travel through.
1542680	1549000	But suddenly if the range of different signal strengths decreases, that's another indication
1549000	1555740	that a malicious GPS transmission is happening, because when you're doing the malicious
1555740	1560400	transmission chances are it's all coming from one transmitter and it's going to have a very
1560400	1568750	similar signal strength. Additionally, like we said back with the TCAS and the GPS was
1568750	1575370	again looking at the signal direction. We know where the GPS satellites should be at any given
1575370	1583070	time. We know the plane's current location. So we know in what direction the GPS signal
1583070	1588810	should be coming from for each of the satellites. So if they don't come from the expected direction,
1588810	1594350	it's an indication that there might be GPS spoofing or a GPS attack happening.
1595930	1601750	So what we need to do to help mitigate some of this risk in the EFBs is they need
1601750	1606290	in the receivers, they need to start monitoring GPS for abnormalities.
1607370	1610890	So like with some of the topics I talked about with the GPS snitch.
1611430	1616370	Show an indicator that when you have no GPS fix, when you detect the spoofing,
1616370	1624530	display GPS no GPS fix because you can no longer trust that as an input. Mark it as no GPS fix
1624530	1630050	or degraded GPS fix or something whatever meets the relevant terminology and
1631130	1646020	accuracy standards. So integrity of the data. The data sort of in the overall system of receivers
1646020	1652660	and EFBs and sensors, it's nearly always happening in clear text. There is an encrypted version of
1652660	1660060	GDL 90, but from what I saw that was not in very common use. My guess is it's a bit of a chicken
1660060	1666400	egg problem. The receiver manufacturers don't see the point in implementing it because none of the
1666400	1672940	receivers, sorry, none of the EFBs are implementing it. EFB manufacturers don't
1672940	1677940	implement it because none of the receiver manufacturers have implemented it.
1679280	1686100	Additionally, the Wi-Fi is often open and in clear text, so anyone within range can connect to it
1686100	1689920	with no authentication required.
1693420	1700520	And also there is when you first sort of pair an EFB and a receiver, there's no key material
1700520	1707320	changed. So you can switch out the receiver and the EFB will still keep talking to it. If it's the same
1708940	1714400	SSID for the Wi-Fi, the same Wi-Fi password, it will just connect fine.
1714400	1719460	It won't inform the pilot. So, you know, think back to your headphones and your phone.
1719480	1724420	When you get a new set of Bluetooth headphones, you need to pair your headphones and your phone
1725400	1728480	and they're connected and they're only going to talk to each other.
1728880	1733800	You know, if you didn't pair them and you didn't have the sort of checking that they're talking
1733800	1737540	to each other, as you're walking down the street listening to music, you'd start hearing the music
1737540	1744360	of everyone walking past you. You know, and we don't want that to happen with our EFB.
1744360	1749040	We want to make sure we're getting the data from our own plane, not our friend's plane.
1749040	1753020	So, you know, if you have a friend who you're doing some formational flying with
1753560	1757100	and because you're friends, you've discussed receivers and you've
1757100	1761000	settled on the same sort of receivers and EFBs because you both like them.
1761720	1766560	You don't want the situation that if everyone's left it with the default Wi-Fis
1766560	1772840	and the default SSIDs because it just starts working, you don't want the EFB in one aircraft
1772840	1776620	connecting to the Wi-Fi in another aircraft around it.
1777460	1781440	Because that's going to be bad if you're receiving data for a different aircraft.
1784380	1790480	So what we should look at here is, where possible, start making the migration to GDL 90.
1790760	1795880	Have receivers start to say, you know, on this date, we're going to implement it. On this date,
1795880	1801480	further down the track, we're only going to have GDL 90. Likewise, on the EFB front, make sure
1801960	1805160	you know your systems are set up to actually accept it.
1805660	1812040	When you first pair an EFB and a receiver, make sure there is some exchange of key material.
1812040	1819320	Make sure there is a pairing process to couple them together so you can't introduce a
1819320	1825540	malicious receiver and have the EFB connect with no error messages.
1825540	1831460	Make sure you sign every message so the EFB can trust that it is coming from a receiver.
1831480	1836940	That it trusts. If the message is not signed, disregard it.
1836940	1840360	And additionally, ensure there's some protection against replay attacks. So
1840980	1845600	make sure that a malicious event that you can't capture a packet or a series of packets
1846400	1850380	and just replay those over and over and over again.
1850680	1855100	Make sure there is some protection that they need to actually keep changing it as it is rolling.
1861040	1869420	So device hardening is part of my job. I look at devices, systems, hardware and to make sure they
1869420	1873960	are robust. You know, there's testing to make sure they've got vulnerabilities, but also checking that
1873960	1878260	they're robust. So even if they're vulnerabilities, I don't know about their attack footprint is as
1878260	1884900	small as possible. And when I was looking at some of those of the receiver devices, I was
1885540	1891380	put this hat on. I was thinking, you know, have they made the attack footprint as small as possible?
1892780	1898440	In some cases, you know, they had made the attack footprint bigger than it could have been.
1899180	1904220	For instance, you know, there was a receiver that had an internal fan and based on the
1904220	1911340	receiver's temperature, it would put the fan speed up and down to keep the system at
1911340	1917100	the optimal temperature. But instead of setting it up so the fan controller only listened to
1917100	1921880	commands coming from inside the device, they configured it so it would accept commands
1921880	1929140	from anywhere in the Wi-Fi network. You know, and that's wrong because in case the only thing
1929140	1935700	the fan controller should be receiving commands from is the temperature sensor inside the receiver.
1935700	1940380	So when the temperature sensor noticed the temperature raising, it needed to tell the fan to
1940380	1949100	go faster and vice versa. Additionally, they're all weak. Wi-Fi configs, as mentioned before,
1949240	1955300	a lot of them are open. They don't have pre-shared keys. They don't use WPA2, WPA3.
1957080	1959660	You know, using pre-shared keys, they will
1961300	1966300	put protection on it. So A, it will encrypt most of the data. B, it will mean that only
1966300	1970300	authorized people can connect to that Wi-Fi network. So you won't have
1970300	1974540	malicious and rogue things connecting to the Wi-Fi network.
1975700	1982520	Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do
1982520	1989780	against it which can have downsides. For instance, there's management frames which
1989780	1995500	are sort of below the data and control the Wi-Fi connection. And there's a particular
1995500	1999840	message called a deauthentication packet. And what that does, it's sent from the access point
1999840	2006420	to the receiver. So the access point, in this case, would be the receiver device and the
2006420	2013320	wireless client would be the tablet slash EFB. And what the access point says is say, normally you'll
2013320	2018980	say, hey, please disconnect, re-establish, because I want you to re-authenticate.
2018980	2024060	So provide me with the password and whatever again.
2024900	2028780	My problem is, is these messages aren't signed normally. So anyone
2029280	2035620	could come along and send deauthentication packets. And this results in two possible
2035620	2041940	cases that you get a denial of service because the EFB or tablet will no longer be able to connect.
2041940	2046940	It just keeps being told to re-authenticate. So I'll go, I'll connect, get a packet, say
2046940	2052240	re-authenticate, so disconnect, deauthenticate and re-authenticate again.
2052800	2058940	Additionally, it can also be used to steer the device instead of talking to a legitimate receiver.
2058940	2064680	There might be a malicious receiver. So what you do is when it's connected to the legitimate
2064680	2070300	receiver, you send deauthentication packets. When it's connected to the malicious receiver,
2070300	2075180	you don't send deauthentication packets. So it stays connected to that. So the EFB is receiving
2075180	2082560	data from the malicious receiver rather than the receiver that the pilot put there.
2083940	2091480	There's also additional services running. SSH is a common tool used for remote access to a device
2091480	2099700	for configuration. So in essence, production devices don't need SSH enabled at all because
2099700	2107000	they should be in a sort of secure, hardened format. When it's not an active development
2107000	2114660	or active debug, you don't need the sort of access to the device. And even digging into further,
2114660	2118920	its configuration is not in line with sort of best practices for the use case.
2118920	2124120	Sort of in following hardening guides, they sort of had basic things like port 14 turned on,
2124120	2128620	route logons turned on, a lot of things that you wouldn't normally see in something. You'd
2128620	2133760	see it in the default sort of installs just to make it work, but it hasn't shown the additional
2133760	2142140	hardening steps that have gone through. Also, the web config user interface had no password on first
2142140	2148400	use, no password change on first use, no password at all. So even if the Wi-Fi network had a
2148400	2153500	pre-shared key and password, as I mentioned on the previous slide, you should also have
2153500	2158040	a password on the web UI to control the configuration of the receiver. This is so
2158040	2163240	we have security in there, so it's got multiple layers of security control. So if one fails,
2163240	2169180	it's still a safety net to stop it stopping the malicious individual getting further
2169180	2176140	into the system. Make sure you have the safety nets just to make sure things don't happen.
2177980	2185280	So with this is make sure that you seek advice on how to harden the configuration.
2185280	2191140	Make sure their attack footprint is as small as possible. If components have hardening guides,
2191140	2197650	make sure those are read and followed through and used to make the device as secure as possible.
2203230	2210330	So password management. So as I just said, web UIs often didn't have passwords on them or didn't
2210330	2213670	prompt for a password change on first use.
2214450	2221650	Going back to the Wi-Fi case I've used a few times now. There is sometimes options to enable
2222670	2229070	Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys.
2229830	2238410	One when it did this said, came off a message saying we've securely set up your Wi-Fi. You're
2238410	2244110	only going to show you this password the once. If you forget it, you'll need to do a factory reset.
2245550	2248850	So I went through, I factory reset it again.
2249470	2252990	Try setting up the Wi-Fi. Comes up the same password.
2254290	2262030	Go across to a different instance of the same device.
2262550	2267450	Gives me the same password. So instead of being randomly generated, this password was hardcoded.
2267450	2271970	It always gave you the same password to be used for the Wi-Fi.
2273010	2276310	And hardcoded passwords, that is a bad thing.
2276530	2285090	Additionally, in this case, I found it a little bit worse was because the text and the messaging around the password setup
2286510	2291850	gave the user their experience that this was actually going to be a unique password.
2291850	2294710	It was sort of randomly generated.
2294710	2300170	It was secure, when in actual fact it wasn't. And that's sort of a double...
2300170	2306950	makes it sort of doubly bad because the pilot or the user is not actually being provided with the correct information.
2306950	2311670	So they can't make the correct decisions if they've been provided with incorrect
2313170	2315610	input information or documentation.
2316750	2322670	So if there is a hardcoded password that you're going to use, say it's a hardcoded password and recommend that
2322670	2331890	the users actually set their own password. Or better yet, just randomly set a random password.
2331890	2338870	Give them a QR code that you can scan, because most tablets and phones these days can read a QR code with
2339730	2344330	a Wi-Fi password in and set the Wi-Fi up without actually having to type in a long password.
2344330	2346110	You can just scan a QR code.
2348650	2353150	Some of the EFB applications had companion websites.
2354330	2359510	You had to sign up some of the times because the EFBs would not work without them,
2359510	2367590	because they had some sort of subscription functionality that free users...
2367590	2373450	you only saw so much paid users use this, or you had to be a paid user depending on the thing.
2373450	2378470	This allowed for flight plans or additional up-to-date weather information,
2378470	2386850	sort of other non-free services that it gave you. I did not test any of these companion websites.
2387430	2393650	I only went as far as registering an account on these websites.
2395390	2401990	I noticed there were some issues. In one case I got emailed a password in clear text,
2401990	2408010	which to me as a pen tester often means that passwords are not being correctly stored
2408010	2414470	in the database. The fact that a clear text password can be sent via email, so that's a sign
2414470	2419730	that incorrect password storage has been used. Additionally, you also saw some that allowed for
2419730	2425590	weak passwords, so passwords that don't meet the standards of what people think is a strong
2425590	2431210	password these days. Additionally, had some that said, well, don't use any special characters.
2431210	2437270	So putting my pen tester hat on, if I see a password field or some other user input field
2437270	2443730	that says, oh, don't use quote marks, don't use dashes, and don't use these sort of other symbols,
2443730	2449190	to me that's a red flag that SQL injection might be available. They're trying to protect SQL
2449190	2455910	injection by just not allowing users to use these characters. So, you know, if I was testing this
2455910	2461470	for a job at work, if I saw text like don't use the quote mark, first thing I'm going to do is
2461470	2470740	test SQL injection on it because chances are that's why that message is there. So password
2470740	2478400	management. OWASP, the Open Web Application Security Project Foundation, has a range of
2478400	2484960	great check sheets and these uncover password storage, password management, authentication,
2485520	2491000	along with a range of other really helpful documentations. They've got stuff around
2491000	2496140	building more secure web apps. Additionally, they've also got stuff on building secure mobile
2496140	2501740	apps, which most AFBs are. So that's a great resource for information.
2503660	2510380	So hopefully these example issues and solutions have helped you. And you've gone away, you've
2510380	2515960	got some ideas that you want to look into in your own products some more. And I hope that
2515960	2522700	as you do future development, as you add features, as you test functionality, that you think, oh,
2522700	2527180	what could a malicious individual do with this? You know, is there a way that they could affect
2527180	2533280	their integrity or their availability of the system with what they could do? Sort of having
2533280	2538100	the sort of what-if hacker mindset and hopefully you can bring some of that into your testing
2538100	2546060	and your development. Also, what can the security industry do to help the aerospace industry in this
2546060	2552000	regard? What help would you like from us? You know, would some example test cases of this
2552000	2558000	malicious thinking be useful? So as an FB or receiver manufacturer, you can take these
2558000	2564560	test cases on board and start working them into your systems. Would a test harness that
2564560	2572200	was, say, a dummy receiver which talked GDL-90, but instead of just sending sort of valid,
2572200	2580080	helpful GDL-90, also sent malicious payloads and started pushing the boundaries a bit more.
2580080	2585560	Would that be something that was helpful? That you could set up this test harness for this
2585560	2590500	receiver, connect your FB to it and have it send all this malicious information to help you if
2590500	2595400	the automation of the testing. Would that be something that's helped? So really good to hear
2595400	2603740	some feedback from the industry about what you need from us as well. So, thank you. Hopefully
2603740	2610700	it's been useful for everyone. I'd really love to hear feedback, chat to some people, because
2610700	2614580	if I'm passionate about it, I'm sure there are other people here out there who are interested
2614580	2620080	about it. Or that's why you came along and listened to this talk. Thank you very much.
2620220	2621480	See you all later.