It's August 2018. A sysadmin logs in to 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 learn that this ship will be out of commission for at least a month,
and I learn the name and passport number of the engineer who's flying away to fix it.
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 Pavore. 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've 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 use of these 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 100
million square kilometers. To put that into perspective, that means we were able to receive
signals from as far away as parts of the United States and the Caribbean, China, and India. 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 ten 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 might browse 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 Accra, 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 at the sky and say, get me Google.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 at Accra's 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 webpage
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 this 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's satellite dish at
the same time as they hit the customer's. This is the crux of satellite eavesdropping. An attacker
can reliably expect to intercept the signal from very far away on these forward links, but they
can't always be guaranteed to see both sides of the conversation, which is somewhat unusual for
an eavesdropper. 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 pull off this attack? 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
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 multi-million 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
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 in like the $80 price range at the cost of maybe not being able to comprehend the
more complex internet signals, but you'd still definitely find something. 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'll see the signal to noise ratio is pretty abysmal, so we're
not likely to get all of the packets in this network, but hopefully we'll find something.
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
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
clear text information from someone else's internet signal using freely available tools and
commercial off-the-shelf equipment. And that's pretty bad, right? 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 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.
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 would 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 would just throw an 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 group's 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 weren't able to get
everything. That said, the first chunk of an IP payload often has the most interesting bits. It
may be the entire packet, or it may be 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 a digital video broadcasting for satellite format,
which is very common from geostationary orbit, we can parse that using that PCIe card on our
computer. Depending on the contents of those streams, we can use existing tools like DVBSnoop
or Wireshark, or tools we've written ourselves like GSExtract, to get meaningful PCAP data out
of it and understand the internet traffic inside. The next step is really to understand the impact
of what we 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 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 Windows LDAP traffic
from that network, that Windows local area environment, was being broadcast across the
satellite feed. Getting to see Windows-to-Windows corporate LAN communications as a wireless
eavesdropper is really unusual and we thought it was a particularly interesting angle because it
got us behind the firewall of a lot of these big corporations' networks. 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 could an
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 POP3 to download them over the satellite link. And so this is obviously
bad news for that attorney's client, and for attorney-client privilege, and customer privacy
in general, and all of that. 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 who's 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 network's configuration page.
And I've blocked out all of the sensitive information, but clearly this is a clear text
admin username and credential that could probably change some settings on that router.
And if you have a keen eye, you'll see that the host IP address for this router is publicly
routable, meaning that anyone with an internet connection could use these credentials to log
into the device. 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 have 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 as 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 sea for a moment, I think one of the most interesting
things for us about the maritime case was how unique every boat in the network is. 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 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 listened
to was this fishing fleet here, which had a single fishing vessel and was using some sort of software
over the satellite feed to help it find fish. 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. A 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
files that there was a device on board the ship running a vulnerable version of Windows Server
2003 that had all kinds of CVEs that could be deployed against it. 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 illegally. 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 they would get their chart updates is someone on land in the back office
would copy the latest chart files into a folder called chart delivery on an FTP server,
and then it would get deployed to the ECTOS terminal. 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 feed 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 update is via emails. And generally there's
an email address like chartupdates underscore ship name at shipcompany.org, which will get
updates every so often as attachments to the inbox. The captain will copy those files onto
a flash drive, walk over to the ECTOS terminal, plug it in, and kind of update the information.
That's not inherently insecure, but if you're like this captain and you use an insecure email
protocol, then we get a pretty good template for a targeted social engineering operation
that might persuade you to copy malicious charts or malware onto your own vessel's
critical operational technology. 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
billionaire's mega yacht, and there were all kinds of interesting anecdotes that came up in the
traffic that really painted a picture of what was going on. 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 loan 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,
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 going to do this as our 2020 experiment.
We're going to get all kinds of great data from airplanes this year and really get a feeling for
how aviation intersects with satellite communication security. 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 Santamarta does research in satellite
modems. He's definitely presented at Black Hat and DEFCON and stuff, doing a lot of hardware
reverse engineering. And he has this blog post where he looks at in-flight entertainment systems,
including some of the systems that we were seeing traffic from. 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 going to call the loneliest EFB. So an EFB is an electronic flight bag. It's
essentially an information terminal like an ECTIS terminal, but for airplanes it includes
navigational information and weather updates and all kinds of stuff that the pilot needs to manage
the flight. 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 fingered a password or something.
And so all of the requests it was sending were getting bounced 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 a few
rows back who's browsing Instagram. Another case that we were interested in for airplanes is
something called a femtocell. There have been a couple of talks at DEFCON about it, I think.
And it's essentially a miniature cell tower that they put in airplanes that allows customers to
use their cell phones as if they were on the ground. And we saw that the front end of these
is fairly secure. It uses GSM or LTE or whatever, which has some security guarantees over the air.
But the back end was being routed unencrypted in these kind of SCTP wrappers 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 him on the 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 where his friend's 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 SMS as a second factor for account login,
it's very clear how this could be deployed in an 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
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 signals
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, 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 a satellite customer that will 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 surface 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 network out networks out there that do, the attacker might still be able to use even just
the size of packets or the content of packets or the existence of packets as a signal that's
virtually untraceable because they're somewhere in this massive continent-sized footprint and
that's all law enforcement could possibly know. 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 in one specific satellite network, but we
didn't test it at a very broad scale because we didn't want to mess with anything important.
Let me give you a show of how this kind of works from a physical perspective.
Let's take a look. So just like before, we have someone in Ireland, only this time they're a
maritime office that wants to visit a website that's hosted on the cargo vessel with status
information. So what they'll do is they'll send a TCP SYN 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 you're part of 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 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 it has 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 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 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,
you know, a little bit unsettling. How did the FBI get my paper before I gave it to anyone?
But if you're ever wondering that you should join one of these like threat intelligence
schemes, it's like clear that the FBI does a good job at getting a scoop ahead of like
the industry or even the researchers themselves thinking it's out there.
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 because 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 seem 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 a VPN, these performance-enhancing proxies can't find
those TCP 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
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 QUIC 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 want to take a look at QPEP, there is a public GitHub repository for it. This isn't
a commercial product. The goal is to 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 in these obtuse C libraries for networking. It's written in Python as a test bed
so you can simulate it without a satellite equipment at all. And most of the networking
layer is 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 web page 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 responsibly disclosed to were like
this isn't a security vulnerability 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've come to expect while adding in privacy basically invisible
in the background is I think the best way that we can bolster privacy and security in these
networks for real satellite customers. 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 performant encryption is something that ISPs have to build into their satellite networks
instead of something that individuals can just run for themselves when they connect to a satellite
terminal. 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 wiretapped ethernet cable. And so if we want to 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 email
questions via email or in a breakout session after this. And I hope you enjoyed the talk.