[00:14.490 --> 00:22.190] It's August 2018. A sysadmin logs in to the control panel of a wind turbine in southern [00:22.190 --> 00:28.210] France to update its firmware. More than 600 kilometers away, [00:28.210 --> 00:35.230] their PHP session token appears on my screen. Eight months later, an Egyptian oil tanker [00:35.230 --> 00:40.350] pulls into the port of Sfax, Tunisia, with a malfunctioning alternator on board. [00:40.350 --> 00:44.430] From my vantage point, more than 1500 kilometers away, [00:44.430 --> 00:47.870] I learn that this ship will be out of commission for at least a month, [00:47.870 --> 00:53.570] and I learn the name and passport number of the engineer who's flying away to fix it. [00:54.410 --> 01:00.310] Just this summer, 13,000 meters above the Atlantic Ocean, the accountant of a Polish [01:00.310 --> 01:05.990] real estate group put the finishing touches on their annual financial report. The Word document [01:05.990 --> 01:11.390] she prepared reached my computer at the same time it arrived at the inboxes of her colleagues [01:11.390 --> 01:16.810] at her parent company, one of Europe's largest private commercial real estate trusts. [01:16.890 --> 01:21.090] How does this sort of thing happen? How do I get this kind of information, [01:21.090 --> 01:26.530] and how do we protect it in the future? I'm James Pavore. I'm a PhD student at [01:26.530 --> 01:32.350] Oxford University, where I research satellite cybersecurity. And today, I want to talk about [01:32.350 --> 01:38.930] the results of more than two years of experiments looking at real world use of satellite broadband. [01:39.050 --> 01:43.410] I do this work with a bunch of talented people from both the UK and Switzerland, [01:43.410 --> 01:48.750] and I'm honored to get to share what we've found. This actually started as a fairly small kind of [01:48.750 --> 01:54.630] summer project. What we wanted to do is take a look at some research from the mid to late 2000s [01:54.630 --> 01:59.950] and see if we could replicate these findings. And what was cool about this research is that [01:59.950 --> 02:05.570] these people found that there were these satellite television feeds that were encapsulating internet [02:05.570 --> 02:09.870] traffic as well, and that if you had the right equipment and the right know-how, you could [02:09.870 --> 02:15.750] actually find sensitive, unencrypted internet traffic inside those feeds. Now, a lot has changed [02:15.750 --> 02:20.670] both about the way we use satellites and the way we use the internet since 2005, right? We have like [02:20.670 --> 02:25.330] smartphones and stuff now. And so we wanted to update this research and also to make it a little [02:25.330 --> 02:30.810] bit broader and more systematic, kind of look at large-scale use of these patterns. So what we [02:30.810 --> 02:36.010] ended up doing is conducting a series of domain-focused experiments, looking at real-world [02:36.010 --> 02:42.550] users at land, at sea, and in the sky for these satellite internet connections. In total, we [02:42.550 --> 02:48.550] analyzed signals from 18 satellites in geostationary orbit with a combined coverage area of about 100 [02:48.550 --> 02:53.470] million square kilometers. To put that into perspective, that means we were able to receive [02:53.470 --> 02:59.650] signals from as far away as parts of the United States and the Caribbean, China, and India. A massive [02:59.650 --> 03:06.170] coverage area for an attacker. And in all 18 of these feeds, we identified deeply sensitive internet [03:06.170 --> 03:11.070] traffic, whether it was being transmitted using those protocols that had issues we've known about [03:11.070 --> 03:17.590] since 2005 or using newer protocols that have replaced it. And it wasn't just any data. It was [03:17.590 --> 03:23.530] some pretty interesting traffic. We saw sensitive information from nine members of the Fortune [03:23.530 --> 03:29.850] Global 500 that we're able to identify. Traffic belonging to passengers on six of the ten largest [03:29.850 --> 03:36.650] airlines in the world by passenger count. Traffic belonging to maritime companies who together make [03:36.650 --> 03:43.210] up 40% of the world's cargo shipping capacity by volume. And traffic belonging to government [03:43.210 --> 03:48.890] agencies ranging from the postal service of an Eastern European nation to an actual Air Force [03:48.890 --> 03:55.030] jet belonging to a North African country. We even saw traffic from regular people like you. People [03:55.030 --> 04:01.190] who might browse Wi-Fi in a coffee shop or update their Instagram while they're on a cruise. Now, [04:01.190 --> 04:06.030] before I delve into kind of the meat of this traffic, how we got at it, and what it has inside, [04:06.030 --> 04:10.530] I want to kind of be sure we're all starting at the same point and give you a bit of a crash course [04:10.530 --> 04:14.830] in satellite communications. So I'm going to run through a very simple scenario here [04:14.830 --> 04:21.090] to kind of explain what satellite communications look like in practice. 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:37.230] And to do this, they want to visit a website over the satellite feed that's hosted over here [04:37.230 --> 04:43.750] in Ireland. We'll say it's Google.com. And they have a device on their boat that's called a VSAT [04:43.750 --> 04:48.410] terminal, or a Very Small Aperture Terminal, which is what they'll use for this connection. [04:48.490 --> 04:53.490] And that device was sold to them by an internet service provider who runs a ground station here [04:53.490 --> 04:59.450] in Madrid. We'll also imagine an attacker who's quite far away from this conversation, down here [04:59.450 --> 05:04.590] in Accra, but still wants to intercept the communications. So how does this play out? [05:04.590 --> 05:08.790] Well, because our satellite's in geostationary orbit, it doesn't move around. So our customer [05:08.790 --> 05:13.890] just needs to point their satellite dish at the sky and say, get me Google.com, using whatever [05:13.890 --> 05:19.070] weird satellite protocol is used in this network. The satellite is more or less a dumb bent pipe. [05:19.070 --> 05:24.210] It doesn't really do any processing or networking. It just sends that signal right back down on a [05:24.210 --> 05:28.870] focused beam towards the ground station in Madrid. You'll notice this beam is very narrow, [05:28.870 --> 05:33.190] so it passes over our attacker at Accra's head. They can't intercept this communication. [05:33.190 --> 05:38.390] Once we get to Madrid, the satellite internet service provider will convert this weird satellite [05:38.390 --> 05:42.870] protocol into normal IP traffic and route it to Google, just like if you were visiting a webpage [05:42.870 --> 05:48.190] at home, terrestrially. It'll get the response over the terrestrial internet and then beam it [05:48.190 --> 05:54.970] back up into space. It's worth noting that when I say beam up into space, this isn't a fast process. [05:54.970 --> 05:59.290] The round-trip time for a conversation like this can be as long as 700 milliseconds, because the [05:59.290 --> 06:03.870] speed of light is only so fast, and geostationary orbit, which is the kind of satellite we're [06:03.870 --> 06:09.630] looking at, is very far away. Once we finally make it out there, though, there's one last step, [06:09.630 --> 06:14.650] which is to beam this signal back down to Earth. Only this time, we'll do it with a kind of critical [06:14.650 --> 06:19.230] difference, which is because satellites are expensive and we want to serve a lot of customers, [06:19.230 --> 06:23.630] we'll send it on a really broad forward link signal. You'll notice that the footprint of [06:23.630 --> 06:27.790] this signal reaches both our attacker in Ghana and our customer in the Atlantic Ocean, [06:27.790 --> 06:32.570] so those radio waves carrying that response from Google will hit our attacker's satellite dish at [06:32.570 --> 06:38.370] the same time as they hit the customer's. This is the crux of satellite eavesdropping. An attacker [06:38.370 --> 06:44.630] can reliably expect to intercept the signal from very far away on these forward links, but they [06:44.630 --> 06:48.990] can't always be guaranteed to see both sides of the conversation, which is somewhat unusual for [06:48.990 --> 06:54.870] an eavesdropper. Additionally, we can kind of think about the security properties in this context, [06:54.870 --> 07:00.490] because if we're imagining, say, a vulnerability in Wi-Fi or GSM, where the attacker has to be in [07:00.490 --> 07:05.490] your city or in your neighborhood to intercept your communications, here an attacker can be in [07:05.590 --> 07:09.730] a different country or on a different continent from their victim. So what does an attacker [07:09.730 --> 07:15.030] actually need to pull off this attack? Let's talk a little bit about our threat model. [07:15.190 --> 07:20.770] So in this case, if the attacker is a nation state, it's very simple. They simply need a [07:20.770 --> 07:25.750] bit of money. There are companies out there that sell specialized modems for intelligence [07:25.750 --> 07:30.490] collection purposes, like this one, and you hook them up to a multi-million dollar ground station, [07:30.490 --> 07:35.090] 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:46.330] However, they don't really give this equipment to PhD students. So I had to find a different way to [07:46.330 --> 07:51.510] information, and that prior research that talked about using television signals is kind of what [07:51.510 --> 07:57.690] led our next step. So we tried to see how far we could get using simple home television equipment [07:57.690 --> 08:03.430] that's widely available. We picked up this nifty flat panel satellite dish, which cost around 90 [08:03.430 --> 08:08.150] bucks, although honestly you could get something free off of Craigslist or Gumtree most of the [08:08.150 --> 08:12.330] time. 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:21.110] Now we used a professional end card, which tends to run about $200 to $300. You could use a much [08:21.110 --> 08:26.230] cheaper card in like the $80 price range at the cost of maybe not being able to comprehend the [08:26.230 --> 08:31.330] more complex internet signals, but you'd still definitely find something. Once we have this [08:31.330 --> 08:37.730] equipment, the next test is to actually use it to connect to a satellite signal. And figuring out [08:37.730 --> 08:41.630] where the satellite is is easy. It's public information, and since they're in geostationary [08:41.630 --> 08:46.490] orbit, they're not moving anywhere. But actually connecting is a little bit trickier. So let me [08:46.490 --> 08:51.870] show you what that looks like in our lab environment. So what we're going to go ahead [08:51.870 --> 08:57.570] and do is use a tool called EBS Pro, which is designed to help people find satellite television [08:57.570 --> 09:02.050] feeds to listen to if they want to watch TV on their computer. And we're going to scan to hunt [09:02.050 --> 09:07.270] for internet signals instead. Now what we're going to do is point our dish at a satellite that we [09:07.270 --> 09:12.050] think has internet service, say because of a press release. And we're going to scan the KU band of [09:12.050 --> 09:15.810] the radio spectrum, because that's what our equipment is set up for. And what we're looking [09:15.810 --> 09:20.430] for is kind of signal against all of this background noise that's indicative of channels [09:20.430 --> 09:26.050] that might have information. In this case, the signal is pretty noisy, but we do see a few distinct [09:26.050 --> 09:31.030] humps in the spectrum graph that might contain actual traffic inside them. We'll go ahead and [09:31.030 --> 09:35.170] tell our card to connect to this one and interpret it as a digital video broadcasting for satellite [09:35.170 --> 09:40.430] feed. After a few seconds, we get a lock, meaning that we found a satellite and we're listening to [09:40.430 --> 09:45.090] signals from it. Now for the demo, I'm going to connect to this weaker signal here because I know [09:45.090 --> 09:49.570] it has interesting information. You'll see the signal to noise ratio is pretty abysmal, so we're [09:49.570 --> 09:53.510] not likely to get all of the packets in this network, but hopefully we'll find something. [09:53.610 --> 09:58.070] I'll go ahead and real quick just jot down some information about the frequency, the orientation, [09:58.070 --> 10:01.890] and the symbol rate, because we're going to have to switch tools. This tool doesn't get us all the [10:01.890 --> 10:06.490] way, it's designed for television feeds, and what we really want is raw data from that digital video [10:06.490 --> 10:11.910] broadcasting signal. So to do that, I'll use a tool that's provided with our device, that PCIe card [10:11.910 --> 10:16.310] in the drivers. We'll lock to that signal we discovered, and then we'll kick off a quick [10:16.310 --> 10:21.530] recording. The amount of traffic you get in a recording like this is hugely variable. You could [10:21.530 --> 10:25.850] get a terabyte in a week, you could get a megabyte in a week, it depends on your equipment and the [10:25.850 --> 10:30.430] signal you're listening to. In this case, I'm just going to record a couple hundred kilobytes, and [10:30.430 --> 10:34.450] we'll take a look at the file and see if we have any indicators that it has internet traffic instead [10:34.450 --> 10:40.350] of television traffic. There's no trick here to differentiating between the two types. All I'm [10:40.350 --> 10:46.590] going to do is just kind of grep through that binary file for the string HTTP, which we would [10:46.590 --> 10:51.230] expect to see in an internet recording, but we wouldn't expect to see in a television feed. [10:51.450 --> 10:59.130] And sure enough, we see here what looks like the output of a SOAP API. At this point, this is a [10:59.130 --> 11:04.310] clear text information from someone else's internet signal using freely available tools and [11:04.310 --> 11:08.890] commercial off-the-shelf equipment. And that's pretty bad, right? They could have sensitive [11:08.890 --> 11:13.950] information just in this API string. But as an attacker, what we really want is to see if we [11:13.950 --> 11:18.330] can pull off something even worse. We want to understand the semantics of this connection, kind [11:18.330 --> 11:22.690] of the nature of the communications. And to do that, we have to delve a bit into the protocols [11:22.690 --> 11:28.190] that are being used. So in our research, we've looked at two protocols, although there are others [11:28.190 --> 11:34.690] out there. The first is called MPEG-TS. Now, you might be saying, MPEG, isn't that a video streaming [11:34.690 --> 11:40.470] format? And you'd be correct. MPEG is widely used across the internet for sending videos. [11:41.070 --> 11:45.730] It's used for satellite television video feeds, for example. And over the years, people have kind [11:45.730 --> 11:50.770] of added all kinds of weird additions. They've added the ability to, like, pause live satellite [11:50.770 --> 11:57.350] television or update your set-top boxes firmware over these feeds. And these functionalities have [11:57.350 --> 12:03.770] been kind of hacked together to offer interactivity and internet services. And so, inside all of these [12:03.770 --> 12:08.450] layers of weird protocols, you have a fairly standard container format that there's a lot of [12:08.450 --> 12:13.710] great tooling for working with. And so, in fact, if you're, like, really lucky and you get a high [12:13.710 --> 12:18.170] quality signal-to-noise ratio, you may just be able to open that file we saved in the desktop [12:18.170 --> 12:23.630] directly in Wireshark and start seeing real packets. This is kind of where prior research [12:23.630 --> 12:27.910] focused, because it was a pretty straightforward process to line up all the tools correctly. [12:28.050 --> 12:31.170] And then you could spend most of your time looking at the contents of the traffic, which is the [12:31.170 --> 12:36.750] interesting bit. However, MPEG-TS is still a used standard for satellite internet, but it's getting [12:36.750 --> 12:43.550] replaced by newer protocols like GSE, or generic stream encapsulation. GSE makes a lot more sense. [12:43.550 --> 12:48.550] It essentially has an IP layer, which is embedded inside of this generic stream, which is broken up [12:48.550 --> 12:52.670] into fragments and then put directly into that digital video broadcasting feed. So, you have none [12:52.670 --> 12:57.790] of the weird MPEG characteristics that are intended for video streaming and aren't relevant to internet. [12:58.270 --> 13:03.130] We found that it was particularly popular among enterprise customers. So, people who had an entire [13:03.130 --> 13:08.090] satellite transponder for their network, think like maritime customers or aviation customers. [13:08.110 --> 13:13.470] But these customers also had much better equipment than we do. They would spend tens to hundreds of [13:13.470 --> 13:19.550] thousands of dollars on signal processing hardware, whereas we're using, like, 200 bucks of a PCIe card. [13:19.550 --> 13:24.150] So, when we were trying to receive these signals, we were often missing fragments of IP packets and [13:24.150 --> 13:28.450] had super corrupted feeds, which meant that existing tools weren't able to parse these [13:28.450 --> 13:33.870] signals for us. We didn't get much help in that regard. So, what we did instead is build our own [13:33.870 --> 13:41.370] tool called GSE Extract. And the goal of GSE Extract is to forensically reconstruct PCAP files [13:41.370 --> 13:47.750] from corrupted recordings of GSE feeds. And it does this by taking some shortcuts. If we were [13:47.750 --> 13:51.850] designing a satellite modem, we would have to consider all of the edge cases and how a network [13:51.850 --> 13:57.150] operates or how a packet gets sent. But for GSE Extract, we can say, generally, we would expect the [13:57.150 --> 14:02.730] start of an IP packet to appear here. Or we would expect this fragment to belong to this payload. [14:02.910 --> 14:07.330] And by making some of those assumptions, GSE Extract is able to help us figure out what to do [14:07.330 --> 14:13.830] with between 50 and 70% of the frames that are hitting our dish. This is significantly better [14:13.830 --> 14:18.070] than an existing tool, which would just throw an error message because the feed is so corrupted. [14:19.150 --> 14:24.090] Hopefully, by the time that you're watching this recording, GSE Extract will be available on my [14:24.090 --> 14:28.610] research group's GitHub. It may take a little bit longer because we're still kind of doing [14:28.610 --> 14:34.090] some responsible disclosure review process stuff. But it should eventually end up there. In the [14:34.090 --> 14:38.610] interim, if you want to delve into how it works a little bit deeper, it's described in pretty [14:38.610 --> 14:43.270] high detail in a related academic paper that we published a few months ago in the appendix of that [14:43.270 --> 14:49.910] paper. So this is kind of what you get at the end of the day by using GSE Extract. This is a JPEG [14:49.910 --> 14:55.430] file that we intercepted from an engineer aboard a maritime vessel who was dealing with a maintenance [14:55.430 --> 14:59.690] issue and sending pictures to his colleagues. You'll see that we're able to get like the start [14:59.690 --> 15:03.430] of the packet. We're able to kind of figure out, you know, this is a JPEG file. We knew what port [15:03.430 --> 15:07.850] it was going to. We kind of knew the nature of the communications. But at some point, we start [15:07.850 --> 15:12.070] losing fragments. And then in the case of like a compressed file like this, we weren't able to get [15:12.070 --> 15:17.490] everything. That said, the first chunk of an IP payload often has the most interesting bits. It [15:17.490 --> 15:21.970] may be the entire packet, or it may be the parts that you care about from like a session login or [15:21.970 --> 15:27.210] something. And so we think this is still useful to an attacker, even if it's not 100% recovery, [15:27.210 --> 15:32.770] and allows someone to get away with $200 or $300 of home television equipment and do harm that [15:32.770 --> 15:36.690] they would otherwise need tens of thousands of dollars to play with in these networks. [15:38.090 --> 15:44.710] All right, so at this point, we're in a good spot. We have a satellite dish that we can use to talk [15:44.710 --> 15:49.870] to signals. We know that if those signals are in a digital video broadcasting for satellite format, [15:49.870 --> 15:54.770] which is very common from geostationary orbit, we can parse that using that PCIe card on our [15:54.770 --> 16:00.610] computer. Depending on the contents of those streams, we can use existing tools like DVBSnoop [16:00.610 --> 16:06.930] or Wireshark, or tools we've written ourselves like GSExtract, to get meaningful PCAP data out [16:06.930 --> 16:11.930] of it and understand the internet traffic inside. The next step is really to understand the impact [16:11.930 --> 16:17.090] of what we found. How does this affect modern users of terrestrial satellite communications, [16:17.090 --> 16:23.310] maritime, and aviation communication links? So across all three of these domains, there are a [16:23.310 --> 16:28.130] couple of general things we found that are worth highlighting. The first is that none of the ISPs [16:28.130 --> 16:33.530] we looked at appear to employ encryption by default. That is to say that individual customers [16:33.530 --> 16:38.690] might choose to encrypt their traffic, but the satellite ISP was sending over the satellite feed [16:38.690 --> 16:44.870] traffic in essentially the same format that was coming into the modem. What this means is that as [16:44.870 --> 16:50.070] an attacker, we had an ISP-level vantage point on the traffic that was coming to a customer. [16:50.070 --> 16:55.070] We saw every website they visited, every bit torrent they downloaded, every connection they made [16:55.070 --> 16:59.190] would pass over that satellite link and we would get it. But when we looked at the enterprise [16:59.190 --> 17:04.110] customers, this got even more interesting because a lot of these enterprise networks operate basically [17:04.110 --> 17:09.270] as a LAN environment across the satellite feed. A good example is a cruise line we were looking at [17:09.270 --> 17:14.350] that had Windows machines on all of their ships. And the internal Windows LDAP traffic [17:14.350 --> 17:18.590] from that network, that Windows local area environment, was being broadcast across the [17:18.590 --> 17:24.250] satellite feed. Getting to see Windows-to-Windows corporate LAN communications as a wireless [17:24.250 --> 17:28.970] eavesdropper is really unusual and we thought it was a particularly interesting angle because it [17:28.970 --> 17:35.270] got us behind the firewall of a lot of these big corporations' networks. So the first environment [17:35.270 --> 17:39.210] I want to talk about, the first domain, is terrestrial customers. And these were really [17:39.210 --> 17:43.170] interesting to us because they're real people, they're kind of your home internet users, and [17:43.170 --> 17:48.490] they care about privacy. Now, I know what you might be saying. You might say, wait a second, [17:48.490 --> 17:53.630] my browser has this lock icon on it which says that my traffic is encrypted. What could an [17:53.630 --> 17:59.850] eavesdropper do to cause harm to me? And I would say to you, convenient made-up straw man, that [17:59.850 --> 18:04.970] there's actually a lot that an attacker can do to mess with your communications in this context. [18:05.610 --> 18:11.190] So even though we can't see exactly the content of your communications, we get to see your DNS [18:11.190 --> 18:15.790] queries, for example, which is essentially every website you're visiting, and we can use that to [18:15.790 --> 18:21.130] piece together your browsing history. Additionally, those TLS certificates that you think are [18:21.130 --> 18:25.590] protecting your traffic, or protecting the contents of that traffic, but they're fingerprinting the [18:25.590 --> 18:30.270] websites you're visiting, which allowed us to determine like which networks devices belong to [18:30.270 --> 18:35.910] or generally where users were going. Now, this is a mild privacy concern. You don't want an entire [18:35.910 --> 18:41.050] continent to hear your browsing history. But it gets worse when you slip up. One of the most [18:41.050 --> 18:46.710] illustrative examples of this comes from a lawyer whose emails we intercepted across this feed. So [18:46.710 --> 18:51.110] this lawyer in Spain was communicating with one of his clients about an upcoming court case. He [18:51.110 --> 18:56.290] happened to be a defense attorney. And we intercepted the emails that were going to his inbox, [18:56.290 --> 19:02.630] because he was using POP3 to download them over the satellite link. And so this is obviously [19:02.630 --> 19:07.250] bad news for that attorney's client, and for attorney-client privilege, and customer privacy [19:07.250 --> 19:12.370] in general, and all of that. But it gets a little bit worse if we think about it in the context of [19:12.370 --> 19:17.250] everything else we know about this lawyer. Because we also know what other websites he was visiting, [19:17.250 --> 19:22.830] and so we can say, hey, this lawyer goes to PayPal.com. 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:36.270] This demonstrates how a man-in-the-middle attacker who's listening to your entire connection, [19:36.270 --> 19:40.930] who's essentially an internet service provider, can engage in attacks that are way more sophisticated [19:40.930 --> 19:44.910] than someone who's just eavesdropping in a single connection to an insecure service. [19:46.750 --> 19:51.030] So, the other thing we were curious about were kind of IoT systems, because these didn't really [19:51.030 --> 19:54.990] exist when people were looking at these feeds last time, especially in kind of the electricity [19:54.990 --> 20:00.350] and critical infrastructure domain. We found that a lot of operators seem to be using these [20:00.350 --> 20:05.030] networks under the assumption that they were secure against eavesdropping. A great example [20:05.030 --> 20:11.770] of this is a major electricity provider in Europe who had this HTTP basic authentication login that [20:11.770 --> 20:17.050] you see on the left to access the Cisco router inside their network's configuration page. [20:17.290 --> 20:21.030] And I've blocked out all of the sensitive information, but clearly this is a clear text [20:21.030 --> 20:25.430] admin username and credential that could probably change some settings on that router. [20:25.630 --> 20:29.830] And if you have a keen eye, you'll see that the host IP address for this router is publicly [20:29.830 --> 20:34.310] routable, meaning that anyone with an internet connection could use these credentials to log [20:34.310 --> 20:39.370] into the device. Very similarly, I kind of touched on this at the beginning, there are a lot of wind [20:39.370 --> 20:43.190] turbines that use satellite connections because they're in remote locations and they don't have [20:43.190 --> 20:48.350] terrestrial internet access. And what we found is that a lot of them have these control panels that [20:48.350 --> 20:53.690] were used to configure the devices that were being sent over the satellite feed. And these control [20:53.690 --> 20:59.010] panels are publicly routable over the open internet. So we could get these credentials that were being [20:59.010 --> 21:03.270] leaked in clear text over the satellite feed, whether that be a login cookie or username and [21:03.270 --> 21:08.070] password, and combine it with any internet connection to potentially start messing around [21:08.070 --> 21:12.330] with these power generation facilities. Now, obviously, we didn't engage in any attacks on [21:12.330 --> 21:16.210] an electrical grid system. So there could be another protection when you log in as some sort [21:16.210 --> 21:20.510] of second factor control. But I think it's intuitively concerning that this stuff is [21:20.510 --> 21:27.350] getting sent in clear text. So heading out to sea for a moment, I think one of the most interesting [21:27.350 --> 21:32.330] things for us about the maritime case was how unique every boat in the network is. So we had [21:32.330 --> 21:36.430] these terabytes and terabytes of traffic from all kinds of different companies and all kinds of [21:36.430 --> 21:41.770] different ships. And what we really wanted to do was figure out a way to tie an IP address in this [21:41.770 --> 21:47.870] massive PCAP file to a specific boat in the ocean to figure out what it was doing. So we picked 100 [21:47.870 --> 21:52.610] random IP addresses from the thousands that we had, and we set ourselves a little challenge. [21:52.610 --> 21:57.930] We designed a fingerprint based off of DNS queries and TLS certificates and a couple of strings from [21:57.930 --> 22:02.850] the first few kilobytes of their traffic. And we used that to see if we could de-anonymize IP [22:02.850 --> 22:08.810] addresses and identify ships. This very basic kind of manual process was sufficient to de-anonymize [22:08.810 --> 22:13.910] 10% of the vessels in that case study. So we de-anonymized 12 vessels. I've hidden their names [22:13.910 --> 22:18.330] here because I want to maintain the privacy of their owners, but you get a real sense for the [22:18.330 --> 22:23.730] breadth of the type of ships impacted by this research. So the smallest fleet that we listened [22:23.730 --> 22:28.530] to was this fishing fleet here, which had a single fishing vessel and was using some sort of software [22:28.530 --> 22:33.510] over the satellite feed to help it find fish. I'm not really sure how it works. On the flip side, we [22:33.510 --> 22:37.610] have this enormous container ship, one of the larger container ships in the world, belonging to [22:37.610 --> 22:42.250] one of the larger shipping companies in the world. And it's operating within the same kind of IP [22:42.250 --> 22:48.230] address space as that random fishing crew. Beyond being able to identify like which companies and [22:48.230 --> 22:52.670] organizations are affected, another cool thing we could do is kind of fingerprint operational [22:52.670 --> 22:58.310] technology aboard the vessel. A good example is this subsea repair ship down here, which is owned [22:58.310 --> 23:03.390] by a major petroleum company. And we were able to identify from the traffic inside those PCAP [23:03.390 --> 23:07.830] files that there was a device on board the ship running a vulnerable version of Windows Server [23:07.830 --> 23:13.490] 2003 that had all kinds of CVEs that could be deployed against it. At this point, if we wanted [23:13.490 --> 23:19.350] to attack that ship, we could potentially deploy CVEs not just against that one, but against any [23:19.350 --> 23:24.930] ship in this petroleum company's fleet and potentially cause some serious harm. [23:26.090 --> 23:30.850] So another piece of operational technology we were curious about was something called [23:30.850 --> 23:37.350] electronic chart display and information systems, or ECTIS. And ECTIS are essentially GPS nav terminals [23:37.350 --> 23:42.470] for boats. They tell boats like where they can go safely or illegally. They have like various [23:42.470 --> 23:47.230] hazard updates for mariners. And there's been a lot of great research on securing them. There are [23:47.230 --> 23:51.450] actually formats out there to stop people from tampering with these charts using various [23:51.450 --> 23:55.870] cryptographic authenticity guarantees. Unfortunately, we saw that a lot of maritime [23:55.870 --> 24:01.750] operators were using older or proprietary versions of these formats that did not have protections [24:01.750 --> 24:06.950] against tampering attacks that we could see. Now, you might be saying, why does this matter, right? [24:06.950 --> 24:10.790] You can get free nautical charts and maybe save a couple hundred bucks if you want to go on a [24:10.790 --> 24:15.670] sailing expedition. But can you really mess with this data as someone who's just passively listening [24:15.790 --> 24:21.130] to a satellite connection? 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:30.150] And the way they would get their chart updates is someone on land in the back office [24:30.150 --> 24:35.410] would copy the latest chart files into a folder called chart delivery on an FTP server, [24:35.410 --> 24:40.210] and then it would get deployed to the ECTOS terminal. Now, because this FTP server is [24:40.210 --> 24:44.170] 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:53.550] And so it would be pretty trivial to send a false chart to this folder or even deploy [24:53.550 --> 24:59.150] targeted malware. Another common way that charts get update is via emails. And generally there's [24:59.150 --> 25:05.710] an email address like chartupdates underscore ship name at shipcompany.org, which will get [25:05.710 --> 25:10.450] updates every so often as attachments to the inbox. The captain will copy those files onto [25:10.610 --> 25:15.190] a flash drive, walk over to the ECTOS terminal, plug it in, and kind of update the information. [25:15.910 --> 25:20.290] That's not inherently insecure, but if you're like this captain and you use an insecure email [25:20.290 --> 25:25.110] protocol, then we get a pretty good template for a targeted social engineering operation [25:25.110 --> 25:30.090] that might persuade you to copy malicious charts or malware onto your own vessel's [25:30.090 --> 25:36.170] critical operational technology. Beyond this kind of operational technology, I think it's [25:36.170 --> 25:41.790] important to remember that there are real people aboard these ships who have real privacy concerns, [25:41.790 --> 25:46.690] like billionaires sailing around on their super yachts. Now I know getting up at DefCon and saying [25:46.690 --> 25:51.690] think of the billionaires is not a great starting point, but this was a really fun case study that I [25:51.690 --> 25:56.170] want to kind of delve into a little bit. So we were listening to this traffic from this Greek [25:56.170 --> 26:01.330] billionaire's mega yacht, and there were all kinds of interesting anecdotes that came up in the [26:01.330 --> 26:06.130] traffic that really painted a picture of what was going on. For example, one day the captain of this [26:06.130 --> 26:12.010] yacht forgot to log in to his Microsoft account, and so the credentials for that captain's account [26:12.010 --> 26:16.630] came across the satellite feed in clear text in the format of an account reset link. [26:16.930 --> 26:20.650] Now at this point, we could hijack the account of someone who has reason to communicate [26:20.650 --> 26:25.090] with a very high net worth individual and potentially engage in some super targeted [26:25.090 --> 26:29.930] social engineering attacks. Because the captain's email address included the name of the yacht, [26:29.930 --> 26:34.310] we could also very easily identify which billionaire was affected by this traffic. [26:35.630 --> 26:40.070] Additionally, once we had kind of de-anonymized the owner of this yacht, there were other things we [26:40.070 --> 26:45.310] could piece together. For example, the yacht used software to manage, like, lunch orders and stuff [26:45.310 --> 26:49.470] for the crew members and for guests, and so we could see who this billionaire was inviting on [26:49.470 --> 26:53.850] their yacht or where they were going or even what they were eating for lunch on a particular day, [26:53.850 --> 26:57.910] which is, like, not inherently sensitive, but if you're hiding who you're meeting or you don't want [26:57.910 --> 27:01.910] an entire continent to know about your social life, it could be a little bit concerning for [27:01.910 --> 27:06.630] these individuals. Beyond the billionaires, though, there are also regular people on [27:06.630 --> 27:12.650] vessels across the sea who have privacy concerns. Another privacy thing that we encountered was what [27:12.650 --> 27:17.150] looked like point-of-sale terminal traffic coming off of cruise ships from a major European cruise [27:17.150 --> 27:21.990] operator. And I don't know if there were credit card numbers in here, so I've censored the data [27:21.990 --> 27:26.510] very heavily. A lot of the numbers did pass the loan check, but it could have been coincidental. [27:26.810 --> 27:30.810] At the very least, anything that tells you how much someone paid for a soda, what their name was, [27:30.810 --> 27:36.690] is pretty deeply concerning that it's being broadcast across an entire continent in clear text. [27:37.230 --> 27:40.850] Another example of sensitive information from, like, real people on cruise ships [27:41.370 --> 27:47.290] or on vessels would be when ports have cargo vessels come in. They often require the crew to [27:47.290 --> 27:52.250] share some visa information. And this particular port authority thought that a great way to do that [27:52.250 --> 27:57.230] would be an insecure HTTP web service. And so as a result, we could see from the cargo vessels [27:57.230 --> 28:01.950] pulling into this port, all of the names and passport numbers and date of birth of the crew [28:01.950 --> 28:06.670] members aboard these ships. Obviously, this is deeply sensitive information that should have [28:06.670 --> 28:12.570] been encrypted. All right, let's head out to the skies. So the aviation use case is really [28:12.570 --> 28:17.430] interesting to me because it's the newest one. We were going to do this as our 2020 experiment. [28:17.430 --> 28:21.470] We're going to get all kinds of great data from airplanes this year and really get a feeling for [28:21.470 --> 28:26.670] how aviation intersects with satellite communication security. And we started out great. We had some [28:26.670 --> 28:31.250] great traffic from these in-flight entertainment systems in February. We're super excited for the [28:31.250 --> 28:37.890] year. And then everyone stopped flying. The number of people in airplanes sank dramatically because [28:37.890 --> 28:42.090] of the pandemic. And so the amount of traffic we were getting also tanked. I was originally [28:42.090 --> 28:46.950] pretty salty about this, but then I realized that there's actually a silver lining here. [28:47.390 --> 28:52.210] You see, back in February, the traffic we were seeing was a lot, but it was mostly garbage. It [28:52.210 --> 28:56.030] was people checking their Facebook on a flight, which isn't that interesting from a security [28:56.030 --> 29:01.130] researcher perspective. But in April, when the airplanes were flying empty, almost all of the [29:01.130 --> 29:05.470] traffic in these networks was somehow essential to either the operation of the airline or the [29:05.470 --> 29:09.990] operation of the airplane. There were no passengers to generate noise. And even as passenger counts [29:09.990 --> 29:14.810] increased, the passengers we saw tended to be like high-value business executives as opposed to just [29:14.810 --> 29:19.470] random tourists, which made the traffic a little bit more interesting from a privacy perspective. [29:19.990 --> 29:24.990] Now, because we had this unique opportunity, there was something I wanted to test, which was a claim [29:24.990 --> 29:29.970] that was made by a researcher whose work I really admire. So Ruben Santamarta does research in satellite [29:29.970 --> 29:34.330] modems. He's definitely presented at Black Hat and DEFCON and stuff, doing a lot of hardware [29:34.330 --> 29:38.570] reverse engineering. And he has this blog post where he looks at in-flight entertainment systems, [29:38.570 --> 29:43.370] including some of the systems that we were seeing traffic from. And he posited that he suspects the [29:43.370 --> 29:47.670] satellite terminal could be a bridge between the part of the airplane that keeps people entertained [29:47.670 --> 29:52.010] and happy and the part of the airplane that keeps it in the sky and going in the right direction. [29:52.010 --> 29:56.370] And we wanted to see if there was anything in these traffic captures that crossed that red [29:56.370 --> 30:00.730] line and kind of crossed those two separate information security domains, which shouldn't [30:00.730 --> 30:06.010] be happening. We would have missed this if we had all of that Facebook traffic. We actually [30:06.010 --> 30:10.870] had traffic from this device for several months, and we didn't realize it until coronavirus hit. [30:10.870 --> 30:16.070] But we found what I'm going to call the loneliest EFB. So an EFB is an electronic flight bag. It's [30:16.070 --> 30:20.650] essentially an information terminal like an ECTIS terminal, but for airplanes it includes [30:20.650 --> 30:24.950] navigational information and weather updates and all kinds of stuff that the pilot needs to manage [30:24.950 --> 30:30.270] the flight. And this specific Chinese airline had made a mistake in configuring their EFB [30:30.790 --> 30:35.190] such that it wasn't logging in correctly. Someone had like fat fingered a password or something. [30:35.190 --> 30:38.930] And so all of the requests it was sending were getting bounced off of this redirect page from [30:38.930 --> 30:44.170] the satellite modem and reaching us. And we could use that to not only fingerprint like how this API [30:44.170 --> 30:48.350] works and what sort of data is being sent from the airplane and where the airplane was at any time, [30:48.350 --> 30:54.870] but we could also identify other vessels that were using this same device. And even though [30:54.870 --> 30:59.910] it seems to be encrypted over the air in most cases, we're able to confirm that the network [30:59.910 --> 31:04.290] that's carrying this operational technology traffic is the same one as the person a few [31:04.290 --> 31:10.610] rows back who's browsing Instagram. Another case that we were interested in for airplanes is [31:10.610 --> 31:14.510] something called a femtocell. There have been a couple of talks at DEFCON about it, I think. [31:14.510 --> 31:19.170] And it's essentially a miniature cell tower that they put in airplanes that allows customers to [31:19.170 --> 31:23.970] use their cell phones as if they were on the ground. And we saw that the front end of these [31:23.970 --> 31:29.970] is fairly secure. It uses GSM or LTE or whatever, which has some security guarantees over the air. [31:29.970 --> 31:36.370] But the back end was being routed unencrypted in these kind of SCTP wrappers over the satellite [31:36.370 --> 31:41.370] signal. And so we're able to see like the contents of people's cellular communications. [31:41.370 --> 31:45.470] What's particularly scary about this is that we don't know if these customers were aware [31:45.470 --> 31:49.090] of what they were doing. If you forgot to put your phone into airplane mode, [31:49.090 --> 31:53.190] it's very possible a text message that you received during your flight will show up in [31:53.190 --> 31:56.790] our packet captures. You're not even aware you're connected to a satellite network. [31:57.190 --> 32:02.130] And to kind of bring home the severity, here's a good example. There's this person who was on [32:02.290 --> 32:05.810] 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:14.330] But for the rest of us who care about health data privacy, it's a huge information breach that [32:14.330 --> 32:19.050] this is being sent in clear text across a continent. We saw all kinds of wild text messages. [32:19.050 --> 32:23.630] I remember listening to some guy who spoke Croatian in his text messages talking about [32:23.810 --> 32:28.350] a wild dream he had where his friend's mom showed up in a burning house or something. [32:28.350 --> 32:33.090] Just real people's personal communications are being sent in clear text. And it's not [32:33.090 --> 32:38.730] just personal communications. If you've ever used SMS as a second factor for account login, [32:38.730 --> 32:42.390] it's very clear how this could be deployed in an account hijacking attack. [32:44.050 --> 32:49.010] So fundamentally, everything we've done is passive. We haven't gotten any equipment to send signals [32:49.010 --> 32:52.970] in these networks. We don't have a license to do that. But is it possible that there are other [32:52.970 --> 32:58.350] sort of semi-active or fully active attacks we could deploy against these networks? One scenario [32:58.350 --> 33:03.430] I saw, which is based off of some malware that actually has been used in practice by a Russian [33:03.430 --> 33:10.170] group, would be to use satellites for untraceable data exfiltration. And there are only two [33:10.170 --> 33:14.630] requirements for this to play out. First, you have to compromise a device that you want to steal data [33:14.630 --> 33:19.630] from. And it needs to be connected to a network that has a route to a satellite IP address. [33:19.770 --> 33:23.210] Generally, the internet is sufficient because there are a lot of satellite devices that have [33:23.210 --> 33:27.990] internet routable IP addresses, but it could also be a device inside someone's LAN environment. [33:28.870 --> 33:32.990] Additionally, as an attacker, you need to be able to be inside that satellite signals [33:32.990 --> 33:36.910] forward link footprint. You need to be able to eavesdrop on the traffic. And that's it. [33:36.910 --> 33:41.250] Let's see how this plays out. 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 --> 33:50.890] The problem is that if they decide to just route this along the internet, just send a post request [33:50.890 --> 33:56.650] with whatever file they have to a web server they run, then law enforcement can very easily trace [33:56.650 --> 34:01.390] that post request and identify where the attacker's command and control server or data exfiltration [34:01.390 --> 34:07.930] database is. But if the attacker uses a satellite hop as an intermediary, they can really cause some [34:07.930 --> 34:13.270] trouble for law enforcement. Because you see, the compromised computer with the malware can send a [34:13.270 --> 34:18.270] signal to a satellite customer that will be routed over the satellite feed. And this customer doesn't [34:18.270 --> 34:22.350] need to be involved at all. It can just be a random ship in the ocean that happens to have an [34:22.350 --> 34:26.670] IP address. It doesn't even need a service running at that port. It could be a closed port or broken [34:26.670 --> 34:30.990] connection. And what will happen is the satellite will beam that signal down across its footprint [34:30.990 --> 34:37.030] area. And if the pilot, if a law enforcement officer tries to investigate this, they'll see it [34:37.030 --> 34:43.830] reach this like broken surface on a maritime ship and have no idea where it's gone. Meanwhile, behind [34:43.830 --> 34:49.690] the scenes, the attacker can be using a satellite dish to eavesdrop on that connection and leak [34:49.690 --> 34:54.630] information in clear text. Even if the satellite network had some degree of encryption, which there [34:54.630 --> 34:59.690] are some network out networks out there that do, the attacker might still be able to use even just [34:59.690 --> 35:05.310] the size of packets or the content of packets or the existence of packets as a signal that's [35:05.310 --> 35:10.150] virtually untraceable because they're somewhere in this massive continent-sized footprint and [35:10.150 --> 35:15.770] that's all law enforcement could possibly know. Another attack that we tried to pull off is [35:15.770 --> 35:20.450] something called TCP session hijacking, which is a very classic kind of networking attack. [35:20.470 --> 35:24.810] Essentially, TCP has this three-way handshake to set up connections where you have to know these [35:24.810 --> 35:29.170] randomly selected sequence numbers to prove you are who you say you are. And what we found is that [35:29.170 --> 35:33.650] in certain satellite environments, you could actually impersonate one of these endpoints very [35:33.650 --> 35:39.510] reliably due to the physical characteristics of orbit and hijack arbitrary TCP session numbers. [35:39.570 --> 35:43.990] We did this against our own connection to one device in one specific satellite network, but we [35:43.990 --> 35:47.230] 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:56.530] Let's take a look. So just like before, we have someone in Ireland, only this time they're a [35:56.530 --> 36:00.330] maritime office that wants to visit a website that's hosted on the cargo vessel with status [36:00.330 --> 36:06.930] information. So what they'll do is they'll send a TCP SYN number as a start of a TCP three-way [36:06.930 --> 36:11.350] handshake. And this has a sequence number that you have to know to prove that you received the start [36:11.350 --> 36:15.030] of the handshake and that you're part of this conversation. This is like a very fundamental [36:15.030 --> 36:20.270] protection against spoofing attacks. However, our attacker can easily get the sequence number over [36:20.270 --> 36:24.750] the unencrypted satellite link. And at the next step, our attacker, remember how I said they were [36:24.750 --> 36:31.190] in Ghana? So Accra happens to have some of the fastest terrestrial internet in Africa and a [36:31.190 --> 36:35.330] direct backbone link to the UK, although that doesn't necessarily matter. But because the speed [36:35.330 --> 36:41.250] of light is only so fast, the attacker 100% of the time can beat the legitimate acknowledgement [36:41.250 --> 36:46.350] message from that handshake to our maritime office in Ireland. And at this point, the maritime office [36:46.350 --> 36:50.410] will start a conversation thinking they're talking to the vessel when they're actually [36:50.410 --> 36:55.490] sending information to our attacker. Our attacker can continue to eavesdrop over the satellite link [36:55.490 --> 37:00.030] and that message with their spoofed acknowledgement will reach the ship at sea, who will simply [37:00.030 --> 37:03.530] ignore it because it has incorrect sequence numbers. But our attacker at this point has [37:03.530 --> 37:08.350] free reign to send whatever information they want to the maritime office and impersonate the ship [37:08.350 --> 37:12.050] in a way that's virtually undetectable if you're not employing some sort of certificate signing [37:12.050 --> 37:19.170] scheme. So this is like a very simple example that shows that even though we can't transmit [37:19.170 --> 37:23.030] directly in the satellite network, we're fundamentally part of a broader network, which [37:23.030 --> 37:28.310] is the internet. And in that environment, active attacks are definitely possible. So obviously, this [37:28.310 --> 37:33.010] research has some ethical implications. It's real world networks and real people. So we're very [37:33.010 --> 37:36.990] careful to adhere to the laws and go above and beyond that. You might be a little disappointed [37:36.990 --> 37:41.450] today that I haven't named and shamed any companies. That's a conscious choice, because I don't want [37:41.450 --> 37:45.670] this to be about X airline is leaking your data. I want the focus to be on the fact that this is a [37:45.670 --> 37:50.930] systemic issue that affects a lot, thousands, tens of thousands of satellite customers around the world. [37:51.690 --> 37:55.470] We've, of course, engaged in responsible disclosure. Many of the satellite companies have known about [37:55.470 --> 38:00.050] this as early as 2019, as well as some of their customers who have leaked particularly interesting [38:00.050 --> 38:04.930] data or particularly large. Most people were receptive to this. We talked to a lot of CISOs [38:04.930 --> 38:08.270] who have started changing around their networks. We don't know exactly what they're doing, but at [38:08.270 --> 38:12.290] least they're aware of the risks. And we only had one company threatened to sue us, which is really [38:12.290 --> 38:17.770] good for this kind of systemic cybersecurity research. We got a huge boost to responsible [38:17.770 --> 38:22.190] disclosure, courtesy of the Federal Bureau of Investigation, who releases threat intelligence [38:22.190 --> 38:28.050] notification to the maritime industry. And what's really interesting about this notification is that [38:28.050 --> 38:34.930] it showed up online from the FBI almost a month before our academic paper was publicly available. [38:34.930 --> 38:39.450] So the only people that accessed this PDF file were people who were responsibly disclosed to you [38:39.450 --> 38:45.430] with the request that they keep it private and our academic peer reviewers. Yet somehow the FBI [38:45.430 --> 38:51.550] was able to cite specific information from a chart inside that paper. Now, as a researcher, this is, [38:51.550 --> 38:55.390] you know, a little bit unsettling. How did the FBI get my paper before I gave it to anyone? [38:55.450 --> 38:58.450] But if you're ever wondering that you should join one of these like threat intelligence [38:58.450 --> 39:03.450] schemes, it's like clear that the FBI does a good job at getting a scoop ahead of like [39:03.450 --> 39:07.170] the industry or even the researchers themselves thinking it's out there. [39:07.810 --> 39:12.030] So how do we protect against these attacks going forward? How do we defend these networks? [39:12.170 --> 39:16.130] Well, I think we need to understand why these kinds of attacks can happen. And it's easy to say [39:16.130 --> 39:20.390] it's because satellite operators are ignorant, but the reality is more complicated. Remember when I [39:20.390 --> 39:24.970] said the speed of light is only so fast? That means that sending a signal to space is slow, [39:24.970 --> 39:29.890] which makes all of those TCP connections you get when you visit a website add up to make your [39:29.890 --> 39:35.170] internet seem really slow. So what ISPs have done is they started splitting these handshakes as a [39:35.170 --> 39:39.510] man-in-the-middle attacker, basically, who benevolently accelerates your connection via [39:39.510 --> 39:43.630] what we call a performance-enhancing proxy. The problem is that if a customer uses like [39:43.630 --> 39:47.770] end-to-end encryption over a VPN, these performance-enhancing proxies can't find [39:47.770 --> 39:54.650] those TCP handshakes, and so they can't accelerate the connection. So in the short term, you might [39:54.650 --> 39:58.810] have to accept that as reality and just say, you know what, passport numbers are sensitive enough [39:58.810 --> 40:03.190] that we should send them encrypted or not send them at all. And in many cases, if you're using [40:03.410 --> 40:08.890] a TCP layer encryption protocol or a UDP encryption protocol, it doesn't affect performance at all. [40:08.890 --> 40:12.790] You should never be using POP for your emails, although we found thousands and thousands of [40:12.790 --> 40:18.330] people still do. You should be using an encrypted email client. And since ISPs are already screwing [40:18.330 --> 40:22.950] around with TCP sequence numbers and TCP sessions, if they just change those sequence numbers over [40:22.950 --> 40:27.470] the air from what they are on the ground, they can prevent TCP hijacking attacks. A lot of ISPs [40:27.470 --> 40:32.090] seem to do this already, although I think it's largely accidental. In the longer term, though, [40:32.090 --> 40:36.810] we're trying to work on a solution that makes it easier for individual customers to be sure their [40:36.810 --> 40:41.030] data is always encrypted, regardless of what protocol mistakes they might make. We're building [40:41.210 --> 40:46.990] a tool called QPEP, which uses the QUIC protocol, which is a TCP replacement that is encrypted by [40:47.350 --> 40:51.530] default. And it's kind of a combination between like a tunneling VPN and a performance enhancing [40:51.530 --> 40:58.310] proxy. If you want to take a look at QPEP, there is a public GitHub repository for it. This isn't [40:58.510 --> 41:02.370] a commercial product. The goal is to build a tool for people to start playing around with [41:02.370 --> 41:07.050] securing these networks. It's designed to be much more accessible than existing PEPs, which tend to [41:07.050 --> 41:12.010] be written in these obtuse C libraries for networking. It's written in Python as a test bed [41:12.010 --> 41:16.090] so you can simulate it without a satellite equipment at all. And most of the networking [41:16.090 --> 41:21.750] layer is written in Go for performance reasons. And the end goal is to help individuals protect [41:21.750 --> 41:26.110] their traffic instead of trying to berate ISPs into encrypting data, which we know doesn't work [41:26.110 --> 41:32.990] because we've been doing it since 2005. So this kind of shows the difference between those two [41:32.990 --> 41:38.190] options versus using an encrypted proxy like the one that we're building and using a very good [41:38.190 --> 41:42.230] open source VPN, but one that doesn't take into account the unique aspects of satellite [41:42.230 --> 41:46.350] communications. And you can see the difference in the amount of time it takes to load just a [41:46.350 --> 41:51.570] very typical web page as an indicator of why customers aren't encrypting their data. It's [41:51.570 --> 41:55.670] not that they don't know privacy is at risk. Many of the people responsibly disclosed to were like [41:55.670 --> 42:01.430] this isn't a security vulnerability because everyone knows about it, which has its own problems. But I [42:01.430 --> 42:06.530] think fundamentally when you give someone a choice between performance and privacy, it's very likely [42:06.530 --> 42:11.490] that they will choose performance, especially in an environment like satellite where you already have [42:11.490 --> 42:16.830] kind of sluggish connections. And so finding technological solutions that enable people to [42:16.830 --> 42:21.790] have as good of a performance as they've come to expect while adding in privacy basically invisible [42:21.790 --> 42:27.350] in the background is I think the best way that we can bolster privacy and security in these [42:27.350 --> 42:34.110] networks for real satellite customers. So to sum things up, today I've kind of presented the case [42:34.110 --> 42:38.710] that satellite broadband as it's used in the status quo is vulnerable to long-range eavesdropping [42:38.710 --> 42:43.670] attacks. Someone in a different country or on a different continent from you can be listening to [42:43.670 --> 42:48.750] your internet communications and yet many people act like this isn't the case. Whether it's a [42:48.750 --> 42:53.850] massive Fortune 500 company or a random person in a coffee shop somewhere, people are leaking [42:53.850 --> 42:58.170] deeply sensitive traffic over satellite feeds as if they don't know that an eavesdropper could be [42:58.170 --> 43:03.250] listening. We think this can be changed. We think the underlying reason that this is still a problem [43:03.250 --> 43:08.670] is that performant encryption is something that ISPs have to build into their satellite networks [43:08.670 --> 43:12.650] instead of something that individuals can just run for themselves when they connect to a satellite [43:12.650 --> 43:17.090] terminal. And we think that we can balance out that trade-off and bring security to customers [43:17.090 --> 43:21.910] regardless of how they interface with a satellite connection. So if I wanted to give a broader [43:21.910 --> 43:27.450] lesson, kind of a major takeaway from this talk that has almost nothing to do with satellites, [43:27.450 --> 43:32.990] it would be very simple. And that is that the next hop is unknown. When you connect to the internet, [43:32.990 --> 43:37.210] there's a whole web of different nodes and connections that's constantly changing that's [43:37.210 --> 43:43.630] routing your traffic. And any one of those nodes could be a satellite link or a wireless tower or [43:44.130 --> 43:50.070] a wiretapped ethernet cable. And so if we want to be sure that no one is listening to our traffic [43:50.070 --> 43:54.090] wherever it might go next, right? Because we could connect to a Wi-Fi hotspot and it could have [43:54.090 --> 43:59.170] the best encryption in the world. But if the next hop is a satellite link, that does us no good. [43:59.330 --> 44:03.950] So having the ability to encrypt your own traffic, having the right to encrypt your own traffic, [44:03.950 --> 44:07.970] and having the knowledge to make that encryption as secure and robust as possible [44:07.970 --> 44:12.990] is, I think, critical to preventing this whole class of attack regardless of the domain we [44:12.990 --> 44:18.630] consider it in. Thank you so much for listening to my presentation. I'm happy to answer any email [44:18.630 --> 44:23.990] questions via email or in a breakout session after this. And I hope you enjoyed the talk.