 It's August 2018, a CIS admin logs into the control panel of a wind turbine in southern France to update its firmware. More than 600 kilometers away, their PHP session token appears on my screen. Eight months later, an Egyptian oil tanker pulls into the port of Sfax, Tunisia, with a malfunctioning alternator on board. From my vantage point, more than 1500 kilometers away, I learned that this ship will be out of commission for at least a month, and I learned the name and passport number of the engineer who's flying away to fix it. 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. 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. How does this sort of thing happen? How do I get this kind of information, and how do we protect it in the future? I'm James Pavour. I'm a PhD student at Oxford University where I research satellite cybersecurity, and today I want to talk about the results of more than two years of experiments looking at real-world use of satellite broadband. 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 found. This actually started as a fairly small kind of summer project. 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. 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, unencrypted internet traffic inside those feeds. Now a lot has changed both about the way we use satellites and the way we use the internet since 2005, right? We have like smartphones and stuff now, 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 usage patterns. 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. In total, we analyzed signals from 18 satellites in geostationary orbit with a combined coverage area of about a hundred million square kilometers. To put that in a 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, a massive coverage area for an attacker. 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. And it wasn't just any data, it was some pretty interesting traffic. We saw sensitive information from nine members of the Fortune Global 500 that we're able to identify, traffic belonging to passengers on six of the 10 largest airlines in the world by passenger count, traffic belonging to maritime companies who together make up 40% of the world's cargo shipping capacity by volume, 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. We even saw traffic from regular people like you, people who like Brio's Wi-Fi in a coffee shop, or update their Instagram while they're on a cruise. 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. So I'm going to run through a very simple scenario here to kind of explain what satellite communications look like in practice. So here's our satellite. It's in geostationary orbit, which means it's 30,000 kilometers above the Earth's surface. We have a customer in the Atlantic Ocean who wants to talk to this satellite. And to do this, they want to visit a website over the satellite feed that's hosted over here in Ireland. We'll say it's Google.com, 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. And that device was sold to them by an internet service provider who runs a ground station here in Madrid. We'll also imagine an attacker who's quite far away from this conversation down here in a craw, but still wants to intercept the communications. So how does this play out? Well, because our satellite's in geostationary orbit, it doesn't move around. So our customer just needs to point their satellite dish to the sky and say gitmegoogle.com using whatever weird satellite protocol is used in this network. The satellite is more or less a dumb bent pipe. It doesn't really do any processing or networking. It just sends that signal right back down on a focused beam towards the ground station in Madrid. You'll notice this beam is very narrow, so it passes over our attacker and across head. They can't intercept this communication. 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 web page at home, terrestrially, it'll get the response over the terrestrial internet and then beam it back up into space. It's worth noting that when I say beam up into space, this isn't a fast process. 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. Once we finally make it out there, though, there's one last step, which is to beam the signal back down to earth. 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. 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 satellite dish at the same time as they hit the customers. This is the crux of satellite eavesdropping. An attacker can reliably expect to intercept a 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 each dropper. 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. So what does an attacker actually need to do? Well, let's talk a little bit about our threat model. So in this case, if the attacker is a nation state, it's very simple. They simply need a little bit of money. There are companies out there that sell specialized modems for intelligence collection purposes like this one, and you hook them up to a multimillion dollar ground station like this one, and you're off to the races just listening to whatever satellite signals you want. And it's a pretty reasonable assumption to say that national intelligence services are doing this. However, they don't really give this equipment to PhD students. So I had to find a different way to get this information. And that prior research that talked about using television signals is kind of what led our next step. So we tried to see how far we could get using simple home television equipment that's widely available. 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. You may even have a satellite dish kind of like rusting on your roof that you could use. And then we got a card to interpret these signals in our computer. Now we used a professional end card, which tends to run about 200 to $300. You could use a much cheaper card and 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. Once we have this equipment, the next test is to actually use it to connect to a satellite signal and figuring out where the satellite is is easy. It's public information. And since they're in geostationary orbit, they're not moving anywhere, but actually connecting is a little bit trickier. So let me show you what that looks like in our lab environment. 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. And we're going to scan to hunt for internet signals instead. 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, and we're going to scan the KU band of the radio spectrum because that's what our equipment is set up for. 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. 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. We'll go ahead and tell our card to connect to this one and interpret it as a digital video broadcasting for satellite feed. After a few seconds, we get a lock, meaning that we found a satellite and we're listening to signals from it. Now, for the demo, I'm going to connect to this weaker signal here because I know it has interesting information. You 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. 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. 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. So to do that, I'll use a tool that's provided with our device, that PCIe card in the drivers. We'll lock to that signal we discovered and then we'll kick off a quick recording. The amount of traffic you get in a recording like this is hugely variable. 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. In this case, I'm just going to record a couple hundred kilobytes and then we'll take a look at the file and see if we have any indicators that it has internet traffic instead of television traffic. There's no trick here to differentiating between the two types. 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. And sure enough, we see here what looks like the output of a SOAP API. At this point, this is a security vulnerability. We're seeing clear text information from someone else's internet signal using freely available tools and commercial off-the-shelf equipment. And that's pretty bad. They could have sensitive information just in this API string. But as an attacker, what we really want is to see if we can pull off something even worse. We want to understand the semantics of this connection, kind of the nature of the communications. And to do that, we have to delve a bit into the protocols that are being used. So in our research, we've looked at two protocols, although there are others out there. The first is called MPEG TS. Now, you might be saying MPEG. Isn't that a video streaming format? And you'd be correct. MPEG is widely used across the internet for sending videos. It's used for satellite television video feeds, for example. And over the years, people have kind of added all kinds of weird additions. They've added the ability to like pause live satellite television or update your set-top firm set-top boxes firmware over these feeds. And these functionalities have been kind of hacked together to offer interactivity and internet services. 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. 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. This is kind of where prior research focused because it was a pretty straightforward process to line up all the tools correctly. And then you could spend most of your time looking at the contents of the traffic, which is the interesting bit. 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. GSE makes a lot more sense. 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. So you have none of the weird MPEG characteristics that are intended for video streaming and aren't relevant to internet. We found that it was particularly popular among enterprise customers. So people who had an entire satellite transponder for their network think like maritime customers or aviation customers. But these customers also had much better equipment than we do. 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. And 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. We didn't get much help in that regard. So what we did instead is build our own tool called GSE Extract. And the goal of GSE Extract is to forensically reconstruct PCAP files from corrupted recordings of GSE feeds. And it does this by taking some shortcuts. 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. But for GSE Extract, we can say generally we would expect the start of an IP packet to appear here, or we'd expect this fragment to belong to this payload. 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. This is significantly better than an existing tool, which we're just throwing error message because the feed is so corrupted. Hopefully by the time that you're watching this recording, GSE Extract will be available on my research groups GitHub. It may take a little bit longer because we're still kind of doing some responsible disclosure review process stuff. But it should eventually end up there. 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. So this is kind of what you get at the end of the day by using GSE Extract. 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. You'll see that we're able to get like the start of the packet. We're able to kind of figure out, you know, this is a JPEG file. We knew what port it was going to. We kind of knew the nature of the communications. But at some point we start losing fragments. And then in the case of like a compressed file like this, we aren't able to get everything. That said, the first chunk of an IP Paleo often has the most interesting bits. It may be the entire packet or maybe the parts that you care about from like a session login or something. 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. All right. So at this point we're in a good spot. We have a satellite dish that we can use to talk to signals. We know that if those signals are in the digital video broadcasting for satellite format, which is very common from geostationary orbit, we can parse that using that PCIe card on our computer. Depending on the contents of those streams, we can use existing tools like DVB Snoop or Wireshark or tools we've written ourselves like GSE extract to get meaningful PCAP data out of it and understand the internet traffic inside. The next step is really to understand the impact of what we've found. How does this affect modern users of terrestrial satellite communications, maritime and aviation communication links? So across all three of these domains, there are a couple of general things we found that are worth highlighting. The first is that none of the ISPs we looked at appear to employ encryption by default. That is to say that like 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. What this means is that as an attacker, we had an ISP level vantage point on the traffic that was coming to a customer. 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. 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. A good example is a cruise line we were looking at that had windows machines on all of their ships and the internal like windows LDAP traffic from that network that windows local area environment was being broadcast across the satellite feed. Getting to see like 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. So the first environment I want to talk about the first domain is terrestrial customers 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. Now I know what you might be saying. You might say, wait a second, my browser has this lock icon on it, which says that my traffic is encrypted. What couldn't eavesdropper do to cause harm to me? 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. 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. 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. Now this is a mild privacy concern. You don't want an entire continent to hear your browsing history, but it gets worse when you slip up. One of the most illustrative examples of this comes from a lawyer whose emails we intercepted across this feed. So this lawyer in Spain was communicating with one of his clients about an upcoming court case. He happened to be a defense attorney and we intercepted the emails that were going to his inbox because he was using pop three to download them over the satellite link. And so this is obviously bad news to that attorney's client and for attorney client privilege and customer privacy in general and all of that, but it gets a little bit worse if we think about it in the context of everything else we know about this lawyer, because we also know what other websites he was visiting. And so we can say, hey, this lawyer goes to PayPal.com. We see that from his DNS queries. We have his email address and we can read everything that goes to his inbox. We can go and hit the reset my password link on PayPal and essentially hijack his accounts. 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 is just eavesdropping in a single connection to an insecure service. 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. We found that a lot of operators seem to be using these networks under the assumption that they were secure against eavesdropping. 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 networks configuration page. And I blacked out all of the sensitive information, but like clearly this is a clear text admin username and credential that could probably change some settings on that router. 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 the internet connection could use these credentials to log into the device. 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. And what we found is that a lot of them had these control panels that were used to configure the devices that were being sent over the satellite feed. And these control panels are publicly routable over the open internet. 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. Now obviously we didn't engage in any attacks on an electrical grid system. So there could be another protection when you log in on some sort of second factor control. But I think it's intuitively concerning that this stuff is getting sent in clear text. So heading out to see 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. So we had these terabytes and terabytes of traffic from all kinds of different companies and all kinds of different ships. 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. So we picked 100 random IP addresses from the thousands that we had. And we set ourselves a little challenge. We designed a fingerprint based off of like DNS queries and TLS certificates and a couple of strings from the first few kilobytes of their traffic. And we used that to see if we could de-anonymize IP addresses and identify ships. This very basic kind of manual process was sufficient to de-anonymize 10% of the vessels in that case study. So we de-anonymized 12 vessels. 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. So the smallest fleet that we listen 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. I'm not really sure how it works. 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. And it's operating within the same kind of IP address space as that random fishing crew. 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. Good example is this subsea repair ship down here, which is owned by a major petroleum company. And we were able to identify from the traffic inside those pcap piles that there was a device onboard the ship running a vulnerable version of Windows Server 2003 that had all kinds of CVEs that could be deployed against it. 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. So another piece of operational technology we were curious about was something called Electronic Chart Display and Information Systems or ECTIS. And ECTIS are essentially GPS NAV terminals for boats. They tell boats like where they can go safely or legally. They have like various hazard updates for mariners. And there's been a lot of great research on securing them. There are actually formats out there to stop people from tampering with these charts using various cryptographic authenticity guarantees. 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. Now, you might be saying, why does this matter? Right? You can get free nautical charts and maybe save a couple hundred bucks if you want to go on a sailing expedition. But can you really mess with this data as someone who's just passively listening to a satellite connection? It turns out that you can because a lot of these are updated insecurely. A great example is this ship which had a publicly routable FTP server on board. And the way that we 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 the FTP server and then it would get deployed to the act as terminal. Now, because this FTP server is accessible over the internet, anyone with an internet connection can connect to it. And the password is getting sent in clear text over the satellite fee because they didn't use SFTP. And so it would be pretty trivial to send a false chart to this folder or even deploy targeted malware. Another common way that charts get updated is via emails. And generally there's an email address like chart updates underscore shipname at shipcompany.org which will get updates every so often as attachments to the inbox. The captain will copy those files onto a flash drive, walk over to the act as terminal, plug it in and kind of update the information. 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 vessels critical operational technology. 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. 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. So we were listening to this traffic from this Greek billionaires 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. 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. 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. 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. Additionally, once we had kind of de-anonymized the owner of this yacht there were other things we could piece together. 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 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. Beyond the billionaires though there are also regular people on vessels across the sea who have privacy concerns. 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. And I don't know if there were credit card numbers in here so I've censored the data very heavily. A lot of the numbers did pass the loon check but it could have been coincidental. At the very least anything that tells you how much someone paid for a soda what their name was and when they did it is pretty deeply concerning that it's being broadcast across an entire continent in clear text. Another example of sensitive information from like real people on cruise ships or on vessels would be when ports have cargo vessels come in they often require the crew to share some visa information. And this particular port authority thought that a great way to do that would be an insecure HTTP web service. 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. Obviously this is deeply sensitive information that should have been encrypted. All right let's head out to the skies. So the aviation use case is really interesting to me because it's the newest one. We were gonna do this as our 2020 experiment we're gonna get all kinds of great data from airplanes this year and really get a feeling for how aviation intersects with satellite communication security. And we started out great. We had some great traffic from these in-flight entertainment systems in February we're super excited for the year. And then everyone stopped flying. The number of people in airplanes sank dramatically because of the pandemic. And so the amount of traffic we were getting also tanked. I was originally pretty salty about this but then I realized that there's actually a silver lining here. You see back in February the traffic we were seeing was a lot but it was mostly garbage. It was people checking their Facebook on a flight which isn't that interesting from a security researcher perspective. 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. There were no passengers to generate noise. 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. 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. So Ruben Santa Marta does research in the satellite modems. He's definitely presented at Black Hat and Def Con and stuff doing a lot of like hardware reverse engineering. And he has this blog post where he looks at inflate entertainment systems including some of the systems that we were seeing traffic from. 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. 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. We would have missed this if we had all of that Facebook traffic. We actually had traffic from this device for several months and we didn't realize it until coronavirus hit. But we found what I'm gonna call the loneliest EFB. So EFB is an electronic flight bag. It's essentially a 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. And this specific Chinese airline had made a mistake in configuring their EFB such that it wasn't logging in correctly. Someone had like fat finger to password or something. And so all of the requests it was sending were getting balanced off of this redirect page from the satellite modem and reaching us. 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. 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 if you rose back who's browsing Instagram. Another case that we were interested in for airplanes is something called a Femto cell. There have been a couple of talks at DEF CON about it I think. And it's essentially a miniature cell tower that they put an airplane that allows customers to use their cell phones as if they were on the ground. And we saw that the front end of these is fairly secure. It uses GSM or LT or whatever which has some security guarantees over the air but the back end was being rather unencrypted in these kind of SCTP wrappers that over the satellite signal. And so we're able to see like the contents of people's cellular communications. What's particularly scary about this is that we don't know if these customers were aware of what they were doing. 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. You're not even aware you're connected to a satellite network. And to kind of bring home the severity, here's a good example. There's this person who was on a flight and in the middle of their flight they got their negative coronavirus test result. Now that's a huge relief for anyone who's sitting next to one airplane, right? 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. We saw all kinds of wild text messages. I remember listening to some guy who spoke Croatian in his text messages talking about a wild dream he had whereas like friends mom showed up in a burning house or something. Just real people's personal communications are being sent in clear text. And it's not just personal communications. If you've ever used like SMS as a second factor for account login, it's very clear how this could be deployed in account hijacking attack. So fundamentally, everything we've done is passive. We haven't gotten any equipment to send signals in these networks. We don't have a license to do that. But is it possible that there are other sort of semi-active or fully active attacks we could deploy against these networks? One scenario I saw, which is based off of some malware that actually has been used in practice by a Russian APT group called Turla Group would be to use satellites for untraceable data exfiltration. And there are only two requirements for this to play out. First, you have to compromise a device that you want to steal data from. And it needs to be connected to a network that has a route to a satellite IP address. 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. Additionally, as an attacker, you need to be able to be inside that satellite signal's forward link footprint. You need to be able to eavesdrop on the traffic. And that's it. Let's see how this plays out. So an attacker who's compromised the device has a problem. They want to send the sensitive data they've stolen to their server somewhere on the internet. The problem is that if they decide to just route this along the internet or 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. But if the attacker uses a satellite hop as an intermediary, they can really cause some trouble for law enforcement because you see the compromised computer with the malware can send a signal to the satellite customer that'll be routed over the satellite feed. And this customer doesn't need to be involved at all. It can just be a random ship in the ocean that happens to have an IP address. It doesn't even need a service running at that port. It could be a closed port or broken connection. And what will happen is the satellite will beam that signal down across its footprint area. And if the pilot, if a law enforcement officer tries to investigate this, they'll see it reach this like broken service on a maritime ship and have no idea where it's gone. Meanwhile, behind the scenes, the attacker can be using a satellite dish to eavesdrop on that connection and leak information in clear text. Even if the satellite network had some degree of encryption, which there are some networks out there that do, the attacker might still be able to use even just like the size of packets or the content of packets or the existence of packets as a signal that's virtually untraceable because they are somewhere in this massive continent-sized footprint and that's all law enforcement could possibly know. Another attack that we tried to pull off is something called TCP session hijacking, which is a very classic kind of networking attack. 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. 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. We did this against our own connection to one device and 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. Let me give you a show of how this kind of works from a physical perspective. So let's take a look. So just like before, we have someone in Ireland. Only this time, there are a maritime office that wants to visit a website that's hosted in the cargo vessel with status information. So what they'll do is they'll send a TCP SIN number as a start of a TCP three-way handshake and this has a sequence number that you have to know to prove that you received the start of the handshake and that your party's this conversation. This is like a very fundamental protection against spoofing attacks. However, our attacker can easily get the sequence number over the unencrypted satellite link. And at the next step, our attacker, remember how I said they were in Accra in Ghana? 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. 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. 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. 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 that is incorrect sequence numbers. 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. 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 and in that environment, active attacks are definitely possible. So obviously this research has some ethical implications. It's a real world networks and real people. So we're very careful to adhere to the laws and go above and beyond that. You might be a little disappointed today that I haven't named and shamed any companies. That's a conscious choice because I don't want this to be about X airline is leaking your data. 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. We've of course engaged in responsible disclosure. 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. Most people were receptive to this. We talked to a lot of CISOs who have started changing around their networks. We don't know exactly what they're doing but at least they're aware of the risks and we only had one company threatened to sue us which is really good for this kind of systemic cybersecurity research. We got a huge boost to responsible disclosure, courtesy of the Federal Bureau of Investigation who releases threat intelligence notification to the maritime industry. And what's really interesting about this notification is that it showed up online from the FBI almost a month before our academic paper came was publicly available. 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. Yet somehow the FBI was able to cite specific information from a chart inside that paper. Now as a researcher, this is a little bit unsettling how did the FBI get my paper before I gave it to anyone? But if you're ever wondering if 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. So how do we protect against these attacks going forward? How do we defend these networks? Well, I think we need to understand why these kinds of attacks can happen. And it's easy to say it's cause satellite operators are ignorant, but the reality is more complicated. Remember when I said the speed of light is only so fast? 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 scene really slow. 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. The problem is that if a customer uses like end to end encryption over VPN, these performance enhancing proxies can't find those TCP through your handshakes and so they can't accelerate the connection. 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. And in many cases, if you're using like a TCP layer encryption protocol or a UDP encryption protocol, it doesn't affect performance at all. You should never be using pop for your emails, although we found thousands and thousands of people still do. You should be using an encrypted email client. 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. A lot of ISPs seem to do this already, although I think it's largely accidental. 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. We're building a tool called QPEP, which uses the quick protocol, which is a TCP replacement that is encrypted by default. And it's kind of a combination between like a tunneling VPN and a performance enhancing proxy. If you wanna take a look at QPEP, there is a public GitHub repository for it. This isn't like a commercial product. The goal is to kind of build a tool for people to start playing around with securing these networks. It's designed to be much more accessible than existing PEPs, which tend to be written as really obtuse like C libraries for networking. It's written in Python as a testbed so you can simulate it without a satellite equipment at all. And then most of the networking layers are written in Go for performance reasons. 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. 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. And you can see the difference in the amount of time it takes to load just a very typical webpage as an indicator of why customers aren't encrypting their data. It's not that they don't know privacy is at risk. Many of the people who are responsibly disclosed to were like, this isn't a security vulnerability we want to believe because everyone knows about it, which has its own problems. 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. And so finding technological solutions that enable people to have as good of a performance as they 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. 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. 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. 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. We think this can be changed. We think the underlying reason that this is still a problem is that performance 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. 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. 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. And that is that the next hop is unknown. 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. And any one of those nodes could be a satellite link or a wireless tower or a wire tapped internet cable. And so if we wanna be sure that no one is listening to our traffic wherever it might go next, right? Because we could connect to a Wi-Fi hotspot and it could have the best encryption in the world. But if the next hop is a satellite link, that does us no good. 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. Thank you so much for listening to my presentation. I'm happy to answer any questions via email or in a breakout session after this. And I hope you enjoyed the talk.