WEBVTT 00:14.490 --> 00:17.150 It's August 2018. 00:17.710 --> 00:24.890 A sysadmin logs in to the control panel of a wind turbine in southern France to update its firmware. 00:25.410 --> 00:31.770 More than 600 kilometers away, their PHP session token appears on my screen. 00:32.430 --> 00:40.350 Eight months later, an Egyptian oil tanker pulls into the port of Sfax, Tunisia, with a malfunctioning alternator on board. 00:40.350 --> 00:53.570 From my vantage point, more than 1500 kilometers away, I learn that this ship will be out of commission for at least a month, and I learn the name and passport number of the engineer who's flying away to fix it. 00:54.410 --> 01:04.790 Just this summer, 13,000 meters above the Atlantic Ocean, the accountant of a Polish real estate group put the finishing touches on their annual financial report. 01:04.850 --> 01:16.810 The Word document she prepared reached my computer at the same time it arrived at the inboxes of her colleagues at her parent company, one of Europe's largest private commercial real estate trusts. 01:16.890 --> 01:19.110 How does this sort of thing happen? 01:19.110 --> 01:23.710 How do I get this kind of information, and how do we protect it in the future? 01:23.790 --> 01:25.190 I'm James Pavore. 01:25.190 --> 01:30.290 I'm a PhD student at Oxford University, where I research satellite cybersecurity. 01:30.570 --> 01:38.930 And today, I want to talk about the results of more than two years of experiments looking at real world use of satellite broadband. 01:39.050 --> 01:45.630 I do this work with a bunch of talented people from both the UK and Switzerland, and I'm honored to get to share what we've found. 01:46.010 --> 01:50.030 This actually started as a fairly small kind of summer project. 01:50.090 --> 01:57.630 What we wanted to do is take a look at some research from the mid to late 2000s and see if we could replicate these findings. 01:57.810 --> 02:11.370 And what was cool about this research is that these people found that there were these satellite television feeds that were encapsulating internet traffic as well, and that if you had the right equipment and the right know-how, you could actually find sensitive, 02:11.370 --> 02:14.210 unencrypted internet traffic inside those feeds. 02:14.330 --> 02:20.310 Now, a lot has changed both about the way we use satellites and the way we use the internet since 2005, right? 02:20.310 --> 02:22.370 We have like smartphones and stuff now. 02:22.390 --> 02:30.130 And so we wanted to update this research and also to make it a little bit broader and more systematic, kind of look at large-scale use of these patterns. 02:30.330 --> 02:41.110 So what we ended up doing is conducting a series of domain-focused experiments, looking at real-world users at land, at sea, and in the sky for these satellite internet connections. 02:41.630 --> 02:50.410 In total, we analyzed signals from 18 satellites in geostationary orbit with a combined coverage area of about 100 million square kilometers. 02:50.410 --> 02:58.930 To put that into perspective, that means we were able to receive signals from as far away as parts of the United States and the Caribbean, China, and India. 02:58.930 --> 03:01.610 A massive coverage area for an attacker. 03:01.750 --> 03:15.630 And in all 18 of these feeds, we identified deeply sensitive internet traffic, whether it was being transmitted using those protocols that had issues we've known about since 2005 or using newer protocols that have replaced it. 03:15.630 --> 03:17.330 And it wasn't just any data. 03:17.330 --> 03:19.490 It was some pretty interesting traffic. 03:19.490 --> 03:26.510 We saw sensitive information from nine members of the Fortune Global 500 that we're able to identify. 03:26.550 --> 03:32.610 Traffic belonging to passengers on six of the ten largest airlines in the world by passenger count. 03:33.110 --> 03:40.990 Traffic belonging to maritime companies who together make up 40% of the world's cargo shipping capacity by volume. 03:41.250 --> 03:51.350 And traffic belonging to government agencies ranging from the postal service of an Eastern European nation to an actual Air Force jet belonging to a North African country. 03:51.470 --> 03:54.690 We even saw traffic from regular people like you. 03:54.750 --> 04:00.390 People who might browse Wi-Fi in a coffee shop or update their Instagram while they're on a cruise. 04:00.990 --> 04:12.410 Now, before I delve into kind of the meat of this traffic, how we got at it, and what it has inside, I want to kind of be sure we're all starting at the same point and give you a bit of a crash course in satellite communications. 04:12.470 --> 04:18.910 So I'm going to run through a very simple scenario here to kind of explain what satellite communications look like in practice. 04:19.330 --> 04:21.090 So here's our satellite. 04:21.090 --> 04:26.630 It's in geostationary orbit, which means it's 30,000 kilometers above the Earth's surface. 04:26.650 --> 04:30.870 We have a customer in the Atlantic Ocean who wants to talk to this satellite. 04:31.730 --> 04:38.270 And to do this, they want to visit a website over the satellite feed that's hosted over here in Ireland. 04:38.270 --> 04:40.050 We'll say it's Google.com. 04:40.450 --> 04:48.410 And they have a device on their boat that's called a VSAT terminal, or a Very Small Aperture Terminal, which is what they'll use for this connection. 04:48.490 --> 04:54.410 And that device was sold to them by an internet service provider who runs a ground station here in Madrid. 04:55.170 --> 05:02.310 We'll also imagine an attacker who's quite far away from this conversation, down here in Accra, but still wants to intercept the communications. 05:02.750 --> 05:04.590 So how does this play out? 05:04.590 --> 05:08.190 Well, because our satellite's in geostationary orbit, it doesn't move around. 05:08.190 --> 05:16.610 So our customer just needs to point their satellite dish at the sky and say, get me Google.com, using whatever weird satellite protocol is used in this network. 05:16.770 --> 05:19.070 The satellite is more or less a dumb bent pipe. 05:19.070 --> 05:21.450 It doesn't really do any processing or networking. 05:21.450 --> 05:26.730 It just sends that signal right back down on a focused beam towards the ground station in Madrid. 05:26.850 --> 05:31.230 You'll notice this beam is very narrow, so it passes over our attacker at Accra's head. 05:31.230 --> 05:33.190 They can't intercept this communication. 05:33.190 --> 05:44.770 Once we get to Madrid, the satellite internet service provider will convert this weird satellite protocol into normal IP traffic and route it to Google, just like if you were visiting a webpage at home, terrestrially. 05:44.810 --> 05:49.670 It'll get the response over the terrestrial internet and then beam it back up into space. 05:50.470 --> 05:54.970 It's worth noting that when I say beam up into space, this isn't a fast process. 05:54.970 --> 06:06.110 The round-trip time for a conversation like this can be as long as 700 milliseconds, because the speed of light is only so fast, and geostationary orbit, which is the kind of satellite we're looking at, is very far away. 06:06.450 --> 06:12.170 Once we finally make it out there, though, there's one last step, which is to beam this signal back down to Earth. 06:12.330 --> 06:22.170 Only this time, we'll do it with a kind of critical difference, which is because satellites are expensive and we want to serve a lot of customers, we'll send it on a really broad forward link signal. 06:22.310 --> 06:34.990 You'll notice that the footprint of this signal reaches both our attacker in Ghana and our customer in the Atlantic Ocean, so those radio waves carrying that response from Google will hit our attacker's satellite dish at the same time as they hit the customer's. 06:34.990 --> 06:37.790 This is the crux of satellite eavesdropping. 06:37.890 --> 06:50.150 An attacker can reliably expect to intercept the signal from very far away on these forward links, but they can't always be guaranteed to see both sides of the conversation, which is somewhat unusual for an eavesdropper. 06:51.510 --> 07:08.470 Additionally, we can kind of think about the security properties in this context, because if we're imagining, say, a vulnerability in Wi-Fi or GSM, where the attacker has to be in your city or in your neighborhood to intercept your communications, here an attacker can be in a different country or on a different continent from their victim. 07:08.730 --> 07:12.390 So what does an attacker actually need to pull off this attack? 07:12.390 --> 07:15.030 Let's talk a little bit about our threat model. 07:15.190 --> 07:19.710 So in this case, if the attacker is a nation state, it's very simple. 07:19.710 --> 07:21.790 They simply need a bit of money. 07:21.870 --> 07:35.090 There are companies out there that sell specialized modems for intelligence collection purposes, like this one, and you hook them up to a multi-million dollar ground station, like this one, and you're off to the races just listening to whatever satellite signals you want. 07:35.090 --> 07:39.870 And it's a pretty reasonable assumption to say that national intelligence services are doing this. 07:40.510 --> 07:44.630 However, they don't really give this equipment to PhD students. 07:44.630 --> 07:53.070 So I had to find a different way to information, and that prior research that talked about using television signals is kind of what led our next step. 07:53.330 --> 07:59.370 So we tried to see how far we could get using simple home television equipment that's widely available. 07:59.370 --> 08:08.450 We picked up this nifty flat panel satellite dish, which cost around 90 bucks, although honestly you could get something free off of Craigslist or Gumtree most of the time. 08:08.450 --> 08:12.330 You may even have a satellite dish kind of like rusting on your roof that you could use. 08:12.470 --> 08:15.450 And then we got a card to interpret these signals in our computer. 08:15.450 --> 08:19.890 Now we used a professional end card, which tends to run about $200 to $300. 08:20.130 --> 08:30.050 You could use a much cheaper card in like the $80 price range at the cost of maybe not being able to comprehend the more complex internet signals, but you'd still definitely find something. 08:30.430 --> 08:36.510 Once we have this equipment, the next test is to actually use it to connect to a satellite signal. 08:36.830 --> 08:39.050 And figuring out where the satellite is is easy. 08:39.050 --> 08:43.510 It's public information, and since they're in geostationary orbit, they're not moving anywhere. 08:43.590 --> 08:46.050 But actually connecting is a little bit trickier. 08:46.050 --> 08:49.510 So let me show you what that looks like in our lab environment. 08:50.670 --> 09:00.670 So what we're going to go ahead and do is use a tool called EBS Pro, which is designed to help people find satellite television feeds to listen to if they want to watch TV on their computer. 09:00.710 --> 09:03.810 And we're going to scan to hunt for internet signals instead. 09:04.390 --> 09:10.110 Now what we're going to do is point our dish at a satellite that we think has internet service, say because of a press release. 09:10.130 --> 09:14.930 And we're going to scan the KU band of the radio spectrum, because that's what our equipment is set up for. 09:15.230 --> 09:21.990 And what we're looking for is kind of signal against all of this background noise that's indicative of channels that might have information. 09:22.650 --> 09:30.330 In this case, the signal is pretty noisy, but we do see a few distinct humps in the spectrum graph that might contain actual traffic inside them. 09:30.350 --> 09:35.890 We'll go ahead and tell our card to connect to this one and interpret it as a digital video broadcasting for satellite feed. 09:36.210 --> 09:41.490 After a few seconds, we get a lock, meaning that we found a satellite and we're listening to signals from it. 09:41.630 --> 09:46.550 Now for the demo, I'm going to connect to this weaker signal here because I know it has interesting information. 09:46.670 --> 09:53.510 You'll see the signal to noise ratio is pretty abysmal, so we're not likely to get all of the packets in this network, but hopefully we'll find something. 09:53.610 --> 10:00.530 I'll go ahead and real quick just jot down some information about the frequency, the orientation, and the symbol rate, because we're going to have to switch tools. 10:00.530 --> 10:07.850 This tool doesn't get us all the way, it's designed for television feeds, and what we really want is raw data from that digital video broadcasting signal. 10:08.150 --> 10:12.890 So to do that, I'll use a tool that's provided with our device, that PCIe card in the drivers. 10:13.050 --> 10:17.150 We'll lock to that signal we discovered, and then we'll kick off a quick recording. 10:17.770 --> 10:21.270 The amount of traffic you get in a recording like this is hugely variable. 10:21.270 --> 10:27.130 You could get a terabyte in a week, you could get a megabyte in a week, it depends on your equipment and the signal you're listening to. 10:27.230 --> 10:35.850 In this case, I'm just going to record a couple hundred kilobytes, and we'll take a look at the file and see if we have any indicators that it has internet traffic instead of television traffic. 10:36.310 --> 10:40.130 There's no trick here to differentiating between the two types. 10:40.130 --> 10:51.230 All I'm going to do is just kind of grep through that binary file for the string HTTP, which we would expect to see in an internet recording, but we wouldn't expect to see in a television feed. 10:51.450 --> 10:55.390 And sure enough, we see here what looks like the output of a SOAP API. 10:55.770 --> 11:06.310 At this point, this is a clear text information from someone else's internet signal using freely available tools and commercial off-the-shelf equipment. 11:06.770 --> 11:08.090 And that's pretty bad, right? 11:08.090 --> 11:11.310 They could have sensitive information just in this API string. 11:11.450 --> 11:15.810 But as an attacker, what we really want is to see if we can pull off something even worse. 11:15.810 --> 11:20.510 We want to understand the semantics of this connection, kind of the nature of the communications. 11:20.670 --> 11:24.010 And to do that, we have to delve a bit into the protocols that are being used. 11:24.750 --> 11:29.170 So in our research, we've looked at two protocols, although there are others out there. 11:29.310 --> 11:32.130 The first is called MPEG-TS. 11:32.130 --> 11:35.550 Now, you might be saying, MPEG, isn't that a video streaming format? 11:35.770 --> 11:36.730 And you'd be correct. 11:36.730 --> 11:40.470 MPEG is widely used across the internet for sending videos. 11:41.070 --> 11:44.250 It's used for satellite television video feeds, for example. 11:44.250 --> 11:47.650 And over the years, people have kind of added all kinds of weird additions. 11:47.650 --> 11:55.930 They've added the ability to, like, pause live satellite television or update your set-top boxes firmware over these feeds. 11:56.010 --> 12:01.750 And these functionalities have been kind of hacked together to offer interactivity and internet services. 12:02.130 --> 12:10.250 And so, inside all of these layers of weird protocols, you have a fairly standard container format that there's a lot of great tooling for working with. 12:10.630 --> 12:21.430 And so, in fact, if you're, like, really lucky and you get a high quality signal-to-noise ratio, you may just be able to open that file we saved in the desktop directly in Wireshark and start seeing real packets. 12:21.630 --> 12:27.910 This is kind of where prior research focused, because it was a pretty straightforward process to line up all the tools correctly. 12:28.050 --> 12:32.290 And then you could spend most of your time looking at the contents of the traffic, which is the interesting bit. 12:32.490 --> 12:40.950 However, MPEG-TS is still a used standard for satellite internet, but it's getting replaced by newer protocols like GSE, or generic stream encapsulation. 12:41.210 --> 12:43.550 GSE makes a lot more sense. 12:43.550 --> 12:52.290 It essentially has an IP layer, which is embedded inside of this generic stream, which is broken up into fragments and then put directly into that digital video broadcasting feed. 12:52.290 --> 12:57.790 So, you have none of the weird MPEG characteristics that are intended for video streaming and aren't relevant to internet. 12:58.270 --> 13:02.070 We found that it was particularly popular among enterprise customers. 13:02.070 --> 13:08.090 So, people who had an entire satellite transponder for their network, think like maritime customers or aviation customers. 13:08.110 --> 13:11.650 But these customers also had much better equipment than we do. 13:11.650 --> 13:19.550 They would spend tens to hundreds of thousands of dollars on signal processing hardware, whereas we're using, like, 200 bucks of a PCIe card. 13:19.550 --> 13:29.230 So, when we were trying to receive these signals, we were often missing fragments of IP packets and had super corrupted feeds, which meant that existing tools weren't able to parse these signals for us. 13:29.230 --> 13:31.550 We didn't get much help in that regard. 13:31.850 --> 13:36.050 So, what we did instead is build our own tool called GSE Extract. 13:36.110 --> 13:44.450 And the goal of GSE Extract is to forensically reconstruct PCAP files from corrupted recordings of GSE feeds. 13:44.610 --> 13:47.070 And it does this by taking some shortcuts. 13:47.290 --> 13:53.850 If we were designing a satellite modem, we would have to consider all of the edge cases and how a network operates or how a packet gets sent. 13:53.850 --> 13:59.190 But for GSE Extract, we can say, generally, we would expect the start of an IP packet to appear here. 13:59.190 --> 14:02.730 Or we would expect this fragment to belong to this payload. 14:02.910 --> 14:11.930 And by making some of those assumptions, GSE Extract is able to help us figure out what to do with between 50 and 70% of the frames that are hitting our dish. 14:11.950 --> 14:18.070 This is significantly better than an existing tool, which would just throw an error message because the feed is so corrupted. 14:19.150 --> 14:25.430 Hopefully, by the time that you're watching this recording, GSE Extract will be available on my research group's GitHub. 14:25.710 --> 14:31.570 It may take a little bit longer because we're still kind of doing some responsible disclosure review process stuff. 14:31.690 --> 14:33.770 But it should eventually end up there. 14:33.790 --> 14:43.890 In the interim, if you want to delve into how it works a little bit deeper, it's described in pretty high detail in a related academic paper that we published a few months ago in the appendix of that paper. 14:45.450 --> 14:49.110 So this is kind of what you get at the end of the day by using GSE Extract. 14:49.110 --> 14:57.690 This is a JPEG file that we intercepted from an engineer aboard a maritime vessel who was dealing with a maintenance issue and sending pictures to his colleagues. 14:57.930 --> 15:00.350 You'll see that we're able to get like the start of the packet. 15:00.350 --> 15:02.850 We're able to kind of figure out, you know, this is a JPEG file. 15:02.850 --> 15:04.430 We knew what port it was going to. 15:04.430 --> 15:06.450 We kind of knew the nature of the communications. 15:06.610 --> 15:08.750 But at some point, we start losing fragments. 15:08.750 --> 15:12.990 And then in the case of like a compressed file like this, we weren't able to get everything. 15:13.190 --> 15:17.450 That said, the first chunk of an IP payload often has the most interesting bits. 15:17.450 --> 15:22.730 It may be the entire packet, or it may be the parts that you care about from like a session login or something. 15:22.910 --> 15:36.690 And so we think this is still useful to an attacker, even if it's not 100% recovery, and allows someone to get away with $200 or $300 of home television equipment and do harm that they would otherwise need tens of thousands of dollars to play with in these networks. 15:38.090 --> 15:41.630 All right, so at this point, we're in a good spot. 15:41.630 --> 15:45.710 We have a satellite dish that we can use to talk to signals. 15:45.950 --> 15:55.550 We know that if those signals are in a digital video broadcasting for satellite format, which is very common from geostationary orbit, we can parse that using that PCIe card on our computer. 15:56.270 --> 16:09.650 Depending on the contents of those streams, we can use existing tools like DVBSnoop or Wireshark, or tools we've written ourselves like GSExtract, to get meaningful PCAP data out of it and understand the internet traffic inside. 16:09.650 --> 16:13.150 The next step is really to understand the impact of what we found. 16:13.150 --> 16:20.030 How does this affect modern users of terrestrial satellite communications, maritime, and aviation communication links? 16:20.430 --> 16:25.910 So across all three of these domains, there are a couple of general things we found that are worth highlighting. 16:25.950 --> 16:31.310 The first is that none of the ISPs we looked at appear to employ encryption by default. 16:31.430 --> 16:42.570 That is to say that individual customers might choose to encrypt their traffic, but the satellite ISP was sending over the satellite feed traffic in essentially the same format that was coming into the modem. 16:43.270 --> 16:50.070 What this means is that as an attacker, we had an ISP-level vantage point on the traffic that was coming to a customer. 16:50.070 --> 16:57.810 We saw every website they visited, every bit torrent they downloaded, every connection they made would pass over that satellite link and we would get it. 16:57.910 --> 17:06.910 But when we looked at the enterprise customers, this got even more interesting because a lot of these enterprise networks operate basically as a LAN environment across the satellite feed. 17:06.910 --> 17:12.090 A good example is a cruise line we were looking at that had Windows machines on all of their ships. 17:12.210 --> 17:19.670 And the internal Windows LDAP traffic from that network, that Windows local area environment, was being broadcast across the satellite feed. 17:19.770 --> 17:32.770 Getting to see Windows-to-Windows corporate LAN communications as a wireless eavesdropper is really unusual and we thought it was a particularly interesting angle because it got us behind the firewall of a lot of these big corporations' networks. 17:34.010 --> 17:38.650 So the first environment I want to talk about, the first domain, is terrestrial customers. 17:38.650 --> 17:44.510 And these were really interesting to us because they're real people, they're kind of your home internet users, and they care about privacy. 17:44.650 --> 17:46.650 Now, I know what you might be saying. 17:46.650 --> 17:52.810 You might say, wait a second, my browser has this lock icon on it which says that my traffic is encrypted. 17:52.910 --> 17:56.210 What could an eavesdropper do to cause harm to me? 17:56.230 --> 18:04.970 And I would say to you, convenient made-up straw man, that there's actually a lot that an attacker can do to mess with your communications in this context. 18:05.610 --> 18:18.050 So even though we can't see exactly the content of your communications, we get to see your DNS queries, for example, which is essentially every website you're visiting, and we can use that to piece together your browsing history. 18:18.270 --> 18:33.130 Additionally, those TLS certificates that you think are protecting your traffic, or protecting the contents of that traffic, but they're fingerprinting the websites you're visiting, which allowed us to determine like which networks devices belong to or generally where users were going. 18:33.130 --> 18:35.110 Now, this is a mild privacy concern. 18:35.110 --> 18:38.190 You don't want an entire continent to hear your browsing history. 18:38.190 --> 18:40.470 But it gets worse when you slip up. 18:40.470 --> 18:46.590 One of the most illustrative examples of this comes from a lawyer whose emails we intercepted across this feed. 18:46.590 --> 18:51.010 So this lawyer in Spain was communicating with one of his clients about an upcoming court case. 18:51.010 --> 18:52.790 He happened to be a defense attorney. 18:53.130 --> 19:01.190 And we intercepted the emails that were going to his inbox, because he was using POP3 to download them over the satellite link. 19:01.510 --> 19:08.710 And so this is obviously bad news for that attorney's client, and for attorney-client privilege, and customer privacy in general, and all of that. 19:08.710 --> 19:14.330 But it gets a little bit worse if we think about it in the context of everything else we know about this lawyer. 19:14.390 --> 19:20.690 Because we also know what other websites he was visiting, and so we can say, hey, this lawyer goes to PayPal.com. 19:20.690 --> 19:22.830 We see that from his DNS queries. 19:22.830 --> 19:26.590 We have his email address, and we can read everything that goes to his inbox. 19:26.590 --> 19:32.170 We can go and hit the reset my password link on PayPal, and essentially hijack his accounts. 19:32.250 --> 19:44.910 This demonstrates how a man-in-the-middle attacker who's listening to your entire connection, who's essentially an internet service provider, can engage in attacks that are way more sophisticated than someone who's just eavesdropping in a single connection to an insecure service. 19:46.750 --> 19:56.990 So, the other thing we were curious about were kind of IoT systems, because these didn't really exist when people were looking at these feeds last time, especially in kind of the electricity and critical infrastructure domain. 19:57.370 --> 20:03.850 We found that a lot of operators seem to be using these networks under the assumption that they were secure against eavesdropping. 20:04.030 --> 20:17.050 A great example of this is a major electricity provider in Europe who had this HTTP basic authentication login that you see on the left to access the Cisco router inside their network's configuration page. 20:17.290 --> 20:25.430 And I've blocked out all of the sensitive information, but clearly this is a clear text admin username and credential that could probably change some settings on that router. 20:25.630 --> 20:35.450 And if you have a keen eye, you'll see that the host IP address for this router is publicly routable, meaning that anyone with an internet connection could use these credentials to log into the device. 20:35.750 --> 20:45.110 Very similarly, I kind of touched on this at the beginning, there are a lot of wind turbines that use satellite connections because they're in remote locations and they don't have terrestrial internet access. 20:45.330 --> 20:52.890 And what we found is that a lot of them have these control panels that were used to configure the devices that were being sent over the satellite feed. 20:52.890 --> 20:56.490 And these control panels are publicly routable over the open internet. 20:56.610 --> 21:10.110 So we could get these credentials that were being leaked in clear text over the satellite feed, whether that be a login cookie or username and password, and combine it with any internet connection to potentially start messing around with these power generation facilities. 21:10.290 --> 21:13.770 Now, obviously, we didn't engage in any attacks on an electrical grid system. 21:13.770 --> 21:17.710 So there could be another protection when you log in as some sort of second factor control. 21:17.710 --> 21:22.130 But I think it's intuitively concerning that this stuff is getting sent in clear text. 21:23.330 --> 21:31.870 So heading out to sea for a moment, I think one of the most interesting things for us about the maritime case was how unique every boat in the network is. 21:31.870 --> 21:37.450 So we had these terabytes and terabytes of traffic from all kinds of different companies and all kinds of different ships. 21:37.650 --> 21:46.450 And what we really wanted to do was figure out a way to tie an IP address in this massive PCAP file to a specific boat in the ocean to figure out what it was doing. 21:46.730 --> 21:52.610 So we picked 100 random IP addresses from the thousands that we had, and we set ourselves a little challenge. 21:52.610 --> 21:59.850 We designed a fingerprint based off of DNS queries and TLS certificates and a couple of strings from the first few kilobytes of their traffic. 21:59.910 --> 22:04.710 And we used that to see if we could de-anonymize IP addresses and identify ships. 22:04.710 --> 22:10.890 This very basic kind of manual process was sufficient to de-anonymize 10% of the vessels in that case study. 22:10.890 --> 22:12.710 So we de-anonymized 12 vessels. 22:12.710 --> 22:21.770 I've hidden their names here because I want to maintain the privacy of their owners, but you get a real sense for the breadth of the type of ships impacted by this research. 22:21.910 --> 22:30.690 So the smallest fleet that we listened to was this fishing fleet here, which had a single fishing vessel and was using some sort of software over the satellite feed to help it find fish. 22:30.690 --> 22:32.510 I'm not really sure how it works. 22:32.790 --> 22:39.950 On the flip side, we have this enormous container ship, one of the larger container ships in the world, belonging to one of the larger shipping companies in the world. 22:40.030 --> 22:45.130 And it's operating within the same kind of IP address space as that random fishing crew. 22:46.050 --> 22:54.510 Beyond being able to identify like which companies and organizations are affected, another cool thing we could do is kind of fingerprint operational technology aboard the vessel. 22:54.730 --> 23:00.250 A good example is this subsea repair ship down here, which is owned by a major petroleum company. 23:00.610 --> 23:12.090 And we were able to identify from the traffic inside those PCAP files that there was a device on board the ship running a vulnerable version of Windows Server 2003 that had all kinds of CVEs that could be deployed against it. 23:12.090 --> 23:24.930 At this point, if we wanted to attack that ship, we could potentially deploy CVEs not just against that one, but against any ship in this petroleum company's fleet and potentially cause some serious harm. 23:26.090 --> 23:34.950 So another piece of operational technology we were curious about was something called electronic chart display and information systems, or ECTIS. 23:34.950 --> 23:38.670 And ECTIS are essentially GPS nav terminals for boats. 23:38.830 --> 23:41.710 They tell boats like where they can go safely or illegally. 23:41.710 --> 23:44.610 They have like various hazard updates for mariners. 23:44.610 --> 23:47.110 And there's been a lot of great research on securing them. 23:47.110 --> 23:53.630 There are actually formats out there to stop people from tampering with these charts using various cryptographic authenticity guarantees. 23:54.010 --> 24:04.270 Unfortunately, we saw that a lot of maritime operators were using older or proprietary versions of these formats that did not have protections against tampering attacks that we could see. 24:04.630 --> 24:06.950 Now, you might be saying, why does this matter, right? 24:06.950 --> 24:11.650 You can get free nautical charts and maybe save a couple hundred bucks if you want to go on a sailing expedition. 24:11.650 --> 24:16.890 But can you really mess with this data as someone who's just passively listening to a satellite connection? 24:16.970 --> 24:21.130 It turns out that you can, because a lot of these are updated insecurely. 24:21.130 --> 24:26.850 A great example is this ship, which had a publicly routable FTP server on board. 24:27.010 --> 24:37.730 And the way they would get their chart updates is someone on land in the back office would copy the latest chart files into a folder called chart delivery on an FTP server, and then it would get deployed to the ECTOS terminal. 24:38.730 --> 24:44.170 Now, because this FTP server is accessible over the internet, anyone with an internet connection can connect to it. 24:44.170 --> 24:49.050 And the password is getting sent in clear text over the satellite feed because they didn't use SFTP. 24:49.050 --> 24:54.770 And so it would be pretty trivial to send a false chart to this folder or even deploy targeted malware. 24:55.170 --> 24:58.570 Another common way that charts get update is via emails. 24:58.570 --> 25:08.850 And generally there's an email address like chartupdates underscore ship name at shipcompany.org, which will get updates every so often as attachments to the inbox. 25:08.850 --> 25:15.190 The captain will copy those files onto a flash drive, walk over to the ECTOS terminal, plug it in, and kind of update the information. 25:15.910 --> 25:32.210 That's not inherently insecure, but if you're like this captain and you use an insecure email protocol, then we get a pretty good template for a targeted social engineering operation that might persuade you to copy malicious charts or malware onto your own vessel's critical operational technology. 25:33.090 --> 25:45.090 Beyond this kind of operational technology, I think it's important to remember that there are real people aboard these ships who have real privacy concerns, like billionaires sailing around on their super yachts. 25:45.090 --> 25:53.690 Now I know getting up at DefCon and saying think of the billionaires is not a great starting point, but this was a really fun case study that I want to kind of delve into a little bit. 25:53.790 --> 26:03.890 So we were listening to this traffic from this Greek billionaire's mega yacht, and there were all kinds of interesting anecdotes that came up in the traffic that really painted a picture of what was going on. 26:03.950 --> 26:16.630 For example, one day the captain of this yacht forgot to log in to his Microsoft account, and so the credentials for that captain's account came across the satellite feed in clear text in the format of an account reset link. 26:16.930 --> 26:26.850 Now at this point, we could hijack the account of someone who has reason to communicate with a very high net worth individual and potentially engage in some super targeted social engineering attacks. 26:26.870 --> 26:34.310 Because the captain's email address included the name of the yacht, we could also very easily identify which billionaire was affected by this traffic. 26:35.630 --> 26:40.990 Additionally, once we had kind of de-anonymized the owner of this yacht, there were other things we could piece together. 26:40.990 --> 26:53.850 For example, the yacht used software to manage, like, lunch orders and stuff for the crew members and for guests, and so we could see who this billionaire was inviting on their yacht or where they were going or even what they were eating for lunch on a particular day, 26:53.850 --> 27:02.970 which is, like, not inherently sensitive, but if you're hiding who you're meeting or you don't want an entire continent to know about your social life, it could be a little bit concerning for these individuals. 27:03.410 --> 27:10.170 Beyond the billionaires, though, there are also regular people on vessels across the sea who have privacy concerns. 27:10.490 --> 27:17.950 Another privacy thing that we encountered was what looked like point-of-sale terminal traffic coming off of cruise ships from a major European cruise operator. 27:18.250 --> 27:23.050 And I don't know if there were credit card numbers in here, so I've censored the data very heavily. 27:23.130 --> 27:26.510 A lot of the numbers did pass the loan check, but it could have been coincidental. 27:26.810 --> 27:36.690 At the very least, anything that tells you how much someone paid for a soda, what their name was, is pretty deeply concerning that it's being broadcast across an entire continent in clear text. 27:37.230 --> 27:45.890 Another example of sensitive information from, like, real people on cruise ships or on vessels would be when ports have cargo vessels come in. 27:45.890 --> 27:49.510 They often require the crew to share some visa information. 27:49.610 --> 27:54.930 And this particular port authority thought that a great way to do that would be an insecure HTTP web service. 27:55.070 --> 28:03.570 And so as a result, we could see from the cargo vessels pulling into this port, all of the names and passport numbers and date of birth of the crew members aboard these ships. 28:03.810 --> 28:07.610 Obviously, this is deeply sensitive information that should have been encrypted. 28:08.290 --> 28:10.350 All right, let's head out to the skies. 28:10.590 --> 28:14.950 So the aviation use case is really interesting to me because it's the newest one. 28:14.950 --> 28:17.430 We were going to do this as our 2020 experiment. 28:17.430 --> 28:24.650 We're going to get all kinds of great data from airplanes this year and really get a feeling for how aviation intersects with satellite communication security. 28:25.130 --> 28:26.330 And we started out great. 28:26.330 --> 28:30.030 We had some great traffic from these in-flight entertainment systems in February. 28:30.030 --> 28:31.950 We're super excited for the year. 28:32.010 --> 28:34.730 And then everyone stopped flying. 28:34.730 --> 28:38.670 The number of people in airplanes sank dramatically because of the pandemic. 28:38.670 --> 28:41.370 And so the amount of traffic we were getting also tanked. 28:41.370 --> 28:46.950 I was originally pretty salty about this, but then I realized that there's actually a silver lining here. 28:47.390 --> 28:52.130 You see, back in February, the traffic we were seeing was a lot, but it was mostly garbage. 28:52.130 --> 28:57.350 It was people checking their Facebook on a flight, which isn't that interesting from a security researcher perspective. 28:57.670 --> 29:06.450 But in April, when the airplanes were flying empty, almost all of the traffic in these networks was somehow essential to either the operation of the airline or the operation of the airplane. 29:06.450 --> 29:08.650 There were no passengers to generate noise. 29:08.870 --> 29:19.470 And even as passenger counts increased, the passengers we saw tended to be like high-value business executives as opposed to just random tourists, which made the traffic a little bit more interesting from a privacy perspective. 29:19.990 --> 29:27.670 Now, because we had this unique opportunity, there was something I wanted to test, which was a claim that was made by a researcher whose work I really admire. 29:27.690 --> 29:30.490 So Ruben Santamarta does research in satellite modems. 29:30.490 --> 29:35.490 He's definitely presented at Black Hat and DEFCON and stuff, doing a lot of hardware reverse engineering. 29:35.630 --> 29:41.230 And he has this blog post where he looks at in-flight entertainment systems, including some of the systems that we were seeing traffic from. 29:41.430 --> 29:52.010 And he posited that he suspects the satellite terminal could be a bridge between the part of the airplane that keeps people entertained and happy and the part of the airplane that keeps it in the sky and going in the right direction. 29:52.010 --> 30:01.710 And we wanted to see if there was anything in these traffic captures that crossed that red line and kind of crossed those two separate information security domains, which shouldn't be happening. 30:02.290 --> 30:05.690 We would have missed this if we had all of that Facebook traffic. 30:05.690 --> 30:10.870 We actually had traffic from this device for several months, and we didn't realize it until coronavirus hit. 30:10.870 --> 30:13.910 But we found what I'm going to call the loneliest EFB. 30:13.910 --> 30:15.910 So an EFB is an electronic flight bag. 30:15.910 --> 30:25.750 It's essentially an information terminal like an ECTIS terminal, but for airplanes it includes navigational information and weather updates and all kinds of stuff that the pilot needs to manage the flight. 30:26.070 --> 30:32.870 And this specific Chinese airline had made a mistake in configuring their EFB such that it wasn't logging in correctly. 30:32.870 --> 30:35.190 Someone had like fat fingered a password or something. 30:35.190 --> 30:41.290 And so all of the requests it was sending were getting bounced off of this redirect page from the satellite modem and reaching us. 30:41.290 --> 30:54.450 And we could use that to not only fingerprint like how this API works and what sort of data is being sent from the airplane and where the airplane was at any time, but we could also identify other vessels that were using this same device. 30:54.450 --> 31:06.290 And even though it seems to be encrypted over the air in most cases, we're able to confirm that the network that's carrying this operational technology traffic is the same one as the person a few rows back who's browsing Instagram. 31:07.850 --> 31:11.890 Another case that we were interested in for airplanes is something called a femtocell. 31:11.890 --> 31:14.510 There have been a couple of talks at DEFCON about it, I think. 31:14.510 --> 31:21.570 And it's essentially a miniature cell tower that they put in airplanes that allows customers to use their cell phones as if they were on the ground. 31:22.090 --> 31:25.390 And we saw that the front end of these is fairly secure. 31:25.390 --> 31:29.970 It uses GSM or LTE or whatever, which has some security guarantees over the air. 31:29.970 --> 31:36.930 But the back end was being routed unencrypted in these kind of SCTP wrappers over the satellite signal. 31:36.930 --> 31:41.370 And so we're able to see like the contents of people's cellular communications. 31:41.370 --> 31:46.570 What's particularly scary about this is that we don't know if these customers were aware of what they were doing. 31:46.670 --> 31:54.210 If you forgot to put your phone into airplane mode, it's very possible a text message that you received during your flight will show up in our packet captures. 31:54.210 --> 31:56.790 You're not even aware you're connected to a satellite network. 31:57.190 --> 32:00.230 And to kind of bring home the severity, here's a good example. 32:00.570 --> 32:05.810 There's this person who was on a flight and in the middle of their flight, they got their negative coronavirus test result. 32:05.930 --> 32:09.690 Now that's a huge relief for anyone who's sitting next to him on the airplane, right? 32:09.690 --> 32:16.970 But for the rest of us who care about health data privacy, it's a huge information breach that this is being sent in clear text across a continent. 32:16.970 --> 32:19.050 We saw all kinds of wild text messages. 32:19.050 --> 32:28.350 I remember listening to some guy who spoke Croatian in his text messages talking about a wild dream he had where his friend's mom showed up in a burning house or something. 32:28.350 --> 32:32.670 Just real people's personal communications are being sent in clear text. 32:32.690 --> 32:34.410 And it's not just personal communications. 32:34.410 --> 32:42.390 If you've ever used SMS as a second factor for account login, it's very clear how this could be deployed in an account hijacking attack. 32:44.050 --> 32:46.570 So fundamentally, everything we've done is passive. 32:46.570 --> 32:49.870 We haven't gotten any equipment to send signals in these networks. 32:49.870 --> 32:51.470 We don't have a license to do that. 32:51.470 --> 32:57.430 But is it possible that there are other sort of semi-active or fully active attacks we could deploy against these networks? 32:57.630 --> 33:09.130 One scenario I saw, which is based off of some malware that actually has been used in practice by a Russian group, would be to use satellites for untraceable data exfiltration. 33:09.430 --> 33:11.970 And there are only two requirements for this to play out. 33:11.970 --> 33:15.350 First, you have to compromise a device that you want to steal data from. 33:15.350 --> 33:19.630 And it needs to be connected to a network that has a route to a satellite IP address. 33:19.770 --> 33:27.990 Generally, the internet is sufficient because there are a lot of satellite devices that have internet routable IP addresses, but it could also be a device inside someone's LAN environment. 33:28.870 --> 33:33.890 Additionally, as an attacker, you need to be able to be inside that satellite signals forward link footprint. 33:33.890 --> 33:35.850 You need to be able to eavesdrop on the traffic. 33:35.890 --> 33:36.910 And that's it. 33:36.910 --> 33:38.510 Let's see how this plays out. 33:38.570 --> 33:41.250 So an attacker who's compromised the device has a problem. 33:41.250 --> 33:45.630 They want to send the sensitive data they've stolen to their server somewhere on the internet. 33:45.630 --> 34:02.730 The problem is that if they decide to just route this along the internet, just send a post request with whatever file they have to a web server they run, then law enforcement can very easily trace that post request and identify where the attacker's command and control server or data exfiltration database is. 34:03.330 --> 34:09.350 But if the attacker uses a satellite hop as an intermediary, they can really cause some trouble for law enforcement. 34:09.550 --> 34:17.010 Because you see, the compromised computer with the malware can send a signal to a satellite customer that will be routed over the satellite feed. 34:17.010 --> 34:19.290 And this customer doesn't need to be involved at all. 34:19.290 --> 34:22.730 It can just be a random ship in the ocean that happens to have an IP address. 34:22.730 --> 34:24.610 It doesn't even need a service running at that port. 34:24.610 --> 34:27.110 It could be a closed port or broken connection . 34:27.350 --> 34:31.810 And what will happen is the satellite will beam that signal down across its footprint area. 34:32.330 --> 34:42.650 And if the pilot, if a law enforcement officer tries to investigate this, they'll see it reach this like broken surface on a maritime ship and have no idea where it's gone. 34:42.750 --> 34:51.730 Meanwhile, behind the scenes, the attacker can be using a satellite dish to eavesdrop on that connection and leak information in clear text. 34:51.730 --> 35:12.630 Even if the satellite network had some degree of encryption, which there are some network out networks out there that do, the attacker might still be able to use even just the size of packets or the content of packets or the existence of packets as a signal that's virtually untraceable because they're somewhere in this massive continent-sized footprint and that's all law enforcement could possibly know. 35:13.830 --> 35:20.450 Another attack that we tried to pull off is something called TCP session hijacking, which is a very classic kind of networking attack. 35:20.470 --> 35:28.310 Essentially, TCP has this three-way handshake to set up connections where you have to know these randomly selected sequence numbers to prove you are who you say you are. 35:28.310 --> 35:39.510 And what we found is that in certain satellite environments, you could actually impersonate one of these endpoints very reliably due to the physical characteristics of orbit and hijack arbitrary TCP session numbers. 35:39.570 --> 35:47.230 We did this against our own connection to one device in one specific satellite network, but we didn't test it at a very broad scale because we didn't want to mess with anything important. 35:47.570 --> 35:51.210 Let me give you a show of how this kind of works from a physical perspective. 35:51.330 --> 35:52.450 Let's take a look. 35:53.050 --> 36:01.310 So just like before, we have someone in Ireland, only this time they're a maritime office that wants to visit a website that's hosted on the cargo vessel with status information. 36:01.790 --> 36:07.430 So what they'll do is they'll send a TCP SYN number as a start of a TCP three-way handshake. 36:07.430 --> 36:13.770 And this has a sequence number that you have to know to prove that you received the start of the handshake and that you're part of this conversation. 36:13.790 --> 36:16.950 This is like a very fundamental protection against spoofing attacks. 36:17.610 --> 36:22.090 However, our attacker can easily get the sequence number over the unencrypted satellite link. 36:22.330 --> 36:26.070 And at the next step, our attacker, remember how I said they were in Ghana? 36:26.290 --> 36:34.330 So Accra happens to have some of the fastest terrestrial internet in Africa and a direct backbone link to the UK, although that doesn't necessarily matter. 36:34.350 --> 36:44.510 But because the speed of light is only so fast, the attacker 100% of the time can beat the legitimate acknowledgement message from that handshake to our maritime office in Ireland. 36:44.510 --> 36:52.470 And at this point, the maritime office will start a conversation thinking they're talking to the vessel when they're actually sending information to our attacker. 36:52.690 --> 37:02.350 Our attacker can continue to eavesdrop over the satellite link and that message with their spoofed acknowledgement will reach the ship at sea, who will simply ignore it because it has incorrect sequence numbers. 37:02.370 --> 37:12.910 But our attacker at this point has free reign to send whatever information they want to the maritime office and impersonate the ship in a way that's virtually undetectable if you're not employing some sort of certificate signing scheme. 37:14.330 --> 37:23.970 So this is like a very simple example that shows that even though we can't transmit directly in the satellite network, we're fundamentally part of a broader network, which is the internet. 37:23.970 --> 37:27.070 And in that environment, active attacks are definitely possible. 37:27.430 --> 37:30.270 So obviously, this research has some ethical implications. 37:30.350 --> 37:32.470 It's real world networks and real people. 37:32.470 --> 37:35.710 So we're very careful to adhere to the laws and go above and beyond that. 37:35.710 --> 37:39.530 You might be a little disappointed today that I haven't named and shamed any companies. 37:39.530 --> 37:43.910 That's a conscious choice, because I don't want this to be about X airline is leaking your data. 37:43.910 --> 37:50.930 I want the focus to be on the fact that this is a systemic issue that affects a lot, thousands, tens of thousands of satellite customers around the world. 37:51.690 --> 37:53.950 We've, of course, engaged in responsible disclosure. 37:53.950 --> 38:01.690 Many of the satellite companies have known about this as early as 2019, as well as some of their customers who have leaked particularly interesting data or particularly large. 38:02.390 --> 38:03.970 Most people were receptive to this. 38:03.970 --> 38:06.910 We talked to a lot of CISOs who have started changing around their networks. 38:06.910 --> 38:09.430 We don't know exactly what they're doing, but at least they're aware of the risks. 38:09.430 --> 38:15.910 And we only had one company threatened to sue us, which is really good for this kind of systemic cybersecurity research. 38:16.050 --> 38:24.730 We got a huge boost to responsible disclosure, courtesy of the Federal Bureau of Investigation, who releases threat intelligence notification to the maritime industry. 38:25.170 --> 38:34.930 And what's really interesting about this notification is that it showed up online from the FBI almost a month before our academic paper was publicly available. 38:34.930 --> 38:44.150 So the only people that accessed this PDF file were people who were responsibly disclosed to you with the request that they keep it private and our academic peer reviewers. 38:44.150 --> 38:49.970 Yet somehow the FBI was able to cite specific information from a chart inside that paper. 38:50.070 --> 38:52.710 Now, as a researcher, this is, you know, a little bit unsettling. 38:52.710 --> 38:55.390 How did the FBI get my paper before I gave it to anyone? 38:55.450 --> 39:07.170 But if you're ever wondering that you should join one of these like threat intelligence schemes, it's like clear that the FBI does a good job at getting a scoop ahead of like the industry or even the researchers themselves thinking it's out there. 39:07.810 --> 39:10.250 So how do we protect against these attacks going forward? 39:10.250 --> 39:12.030 How do we defend these networks? 39:12.170 --> 39:15.310 Well, I think we need to understand why these kinds of attacks can happen. 39:15.310 --> 39:19.830 And it's easy to say it's because satellite operators are ignorant, but the reality is more complicated. 39:19.890 --> 39:22.230 Remember when I said the speed of light is only so fast? 39:22.230 --> 39:31.570 That means that sending a signal to space is slow, which makes all of those TCP connections you get when you visit a website add up to make your internet seem really slow. 39:31.650 --> 39:41.610 So what ISPs have done is they started splitting these handshakes as a man-in-the-middle attacker, basically, who benevolently accelerates your connection via what we call a performance-enhancing proxy. 39:41.610 --> 39:51.490 The problem is that if a customer uses like end-to-end encryption over a VPN, these performance-enhancing proxies can't find those TCP handshakes, and so they can't accelerate the connection. 39:52.010 --> 40:01.510 So in the short term, you might have to accept that as reality and just say, you know what, passport numbers are sensitive enough that we should send them encrypted or not send them at all. 40:01.650 --> 40:08.890 And in many cases, if you're using a TCP layer encryption protocol or a UDP encryption protocol, it doesn't affect performance at all. 40:08.890 --> 40:13.970 You should never be using POP for your emails, although we found thousands and thousands of people still do. 40:13.970 --> 40:16.090 You should be using an encrypted email client. 40:16.830 --> 40:26.750 And since ISPs are already screwing around with TCP sequence numbers and TCP sessions, if they just change those sequence numbers over the air from what they are on the ground, they can prevent TCP hijacking attacks. 40:26.750 --> 40:30.590 A lot of ISPs seem to do this already, although I think it's largely accidental. 40:31.010 --> 40:40.550 In the longer term, though, we're trying to work on a solution that makes it easier for individual customers to be sure their data is always encrypted, regardless of what protocol mistakes they might make. 40:40.550 --> 40:47.530 We're building a tool called QPEP, which uses the QUIC protocol, which is a TCP replacement that is encrypted by default. 40:47.530 --> 40:52.410 And it's kind of a combination between like a tunneling VPN and a performance enhancing proxy. 40:52.970 --> 40:58.030 If you want to take a look at QPEP, there is a public GitHub repository for it. 40:58.030 --> 40:59.370 This isn't a commercial product. 40:59.370 --> 41:03.830 The goal is to build a tool for people to start playing around with securing these networks. 41:03.990 --> 41:10.370 It's designed to be much more accessible than existing PEPs, which tend to be written in these obtuse C libraries for networking. 41:10.450 --> 41:15.110 It's written in Python as a test bed so you can simulate it without a satellite equipment at all. 41:15.110 --> 41:18.350 And most of the networking layer is written in Go for performance reasons. 41:18.850 --> 41:28.430 And the end goal is to help individuals protect their traffic instead of trying to berate ISPs into encrypting data, which we know doesn't work because we've been doing it since 2005. 41:29.910 --> 41:43.270 So this kind of shows the difference between those two options versus using an encrypted proxy like the one that we're building and using a very good open source VPN, but one that doesn't take into account the unique aspects of satellite communications. 41:43.390 --> 41:51.070 And you can see the difference in the amount of time it takes to load just a very typical web page as an indicator of why customers aren't encrypting their data. 41:51.070 --> 41:53.450 It's not that they don't know privacy is at risk. 41:53.450 --> 42:00.970 Many of the people responsibly disclosed to were like this isn't a security vulnerability because everyone knows about it, which has its own problems. 42:00.970 --> 42:13.670 But I think fundamentally when you give someone a choice between performance and privacy, it's very likely that they will choose performance, especially in an environment like satellite where you already have kind of sluggish connections. 42:13.830 --> 42:29.470 And so finding technological solutions that enable people to have as good of a performance as they've come to expect while adding in privacy basically invisible in the background is I think the best way that we can bolster privacy and security in these networks for real satellite customers. 42:30.370 --> 42:39.630 So to sum things up, today I've kind of presented the case that satellite broadband as it's used in the status quo is vulnerable to long-range eavesdropping attacks. 42:39.670 --> 42:48.070 Someone in a different country or on a different continent from you can be listening to your internet communications and yet many people act like this isn't the case. 42:48.070 --> 42:58.950 Whether it's a massive Fortune 500 company or a random person in a coffee shop somewhere, people are leaking deeply sensitive traffic over satellite feeds as if they don't know that an eavesdropper could be listening. 42:59.010 --> 43:00.750 We think this can be changed. 43:00.750 --> 43:13.470 We think the underlying reason that this is still a problem is that performant encryption is something that ISPs have to build into their satellite networks instead of something that individuals can just run for themselves when they connect to a satellite terminal. 43:13.550 --> 43:19.990 And we think that we can balance out that trade-off and bring security to customers regardless of how they interface with a satellite connection. 43:20.510 --> 43:28.730 So if I wanted to give a broader lesson, kind of a major takeaway from this talk that has almost nothing to do with satellites, it would be very simple. 43:28.730 --> 43:31.590 And that is that the next hop is unknown. 43:31.590 --> 43:38.470 When you connect to the internet, there's a whole web of different nodes and connections that's constantly changing that's routing your traffic. 43:38.530 --> 43:45.650 And any one of those nodes could be a satellite link or a wireless tower or a wiretapped ethernet cable. 43:46.690 --> 43:51.850 And so if we want to be sure that no one is listening to our traffic wherever it might go next, right? 43:51.850 --> 43:55.870 Because we could connect to a Wi-Fi hotspot and it could have the best encryption in the world. 43:55.870 --> 43:59.170 But if the next hop is a satellite link, that does us no good. 43:59.330 --> 44:14.190 So having the ability to encrypt your own traffic, having the right to encrypt your own traffic, and having the knowledge to make that encryption as secure and robust as possible is, I think, critical to preventing this whole class of attack regardless of the domain we consider it in. 44:14.250 --> 44:17.050 Thank you so much for listening to my presentation. 44:17.050 --> 44:22.370 I'm happy to answer any email questions via email or in a breakout session after this. 44:22.370 --> 44:23.990 And I hope you enjoyed the talk.