Nadia: *39C3 opening music*
I'm Nadia Heninger, and yes, my ancestors are from
Germany, but we spell and pronounce the name wrong.
And this is...
Annie: Annie Dai, I'm actually from Maryland, not Missouri.
Nadia: And we're going to be telling you today about our joint work with our excellent
co -authors on looking at unencrypted data from geosynchronous satellites.
So our co -authors are Morty Zhang, Keegan Ryan, Dave Levin, and Aaron Schulman.
And Keegan is right here.
So you have three of us here to talk to about this research if you love it.
The rest of our co -authors have families and stuff and didn't want to fly out here.
So the short summary of the talk, in case you want to see it in 30 seconds and
then go to sleep or something, is we bought a consumer -grade satellite dish and we
installed it on the roof of our building at UC San Diego in San Diego, California.
And after years of trying to get everything to work, we
eventually aimed our dish at every satellite we could see
from San Diego and we found a lot of unencrypted network data.
We have an academic paper, we have some source code,
and we have other information which we put online here.
So in case you're really bored of the talk, you can just go check
this out and, you know, go sit in somewhere to have more fun.
All right.
Annie: Okay.
I'm here to give you a primer in geostationary satellites because
most people don't learn about this in computer science classes.
Geostationary satellites occupy a fixed position above the equator relative to the Earth.
There are about 590 active geostationary satellites in orbit right now.
Each satellite has dozens of transponders and these are transmitters/ responders
that re -broadcast signals that are transmitted to them from the Earth.
They operate in different frequency bands along the electromagnetic spectrum.
So there's Ku band, Ka band, and C band. We're interested in KU band.
A transponder's footprint is the geographical area on the
ground where you can receive signal from that transponder.
At this orbit and in this frequency, we see footprints that are continental in scale.
In this case, we have an image here where the
footprint is basically the entirety of North America.
And this is why, in our data, we can see information from the other side of the country.
We don't study low Earth orbit or medium Earth orbit in this work
because we don't want to track the satellites because they're moving.
And geostationary orbit, in particular, is used for a lot of
critical applications because of the reliability it provides.
Unlike low Earth orbit and medium Earth orbit, there aren't any gaps in coverage.
Because of this, it's used in a lot of really important legacy infrastructure.
And oftentimes these infrastructure, oftentimes these technologies are decades old.
The satellites themselves are expected to operate for up to 15 years.
And this is just a particularly unique opportunity for passive adversaries.
In fact, we've had some previous work show that it's
possible to observe unencrypted data in this domain.
Some more background information on how satellite networks operate.
The satellites themselves are basically dumb repeaters.
They're, in industry terms, a bent pipe.
No encryption or decryption occurs at the satellite.
They only rebroadcast what is transmitted to them from the ground terminal.
The encryption happens before the signal ever reaches the satellite.
So it can happen at the link layer, which is at the terminal itself, or
at the network layer, which is the router equipment before it reaches
the terminal, or at the end user, which is the application layer.
Nadia: All right.
So with that introduction, our extremely naive research plan was to
buy a satellite dish, install it on a roof, look at the data that is
just falling at us from the sky, see what we find, and then profit.
Well, not profit because we're academic researchers
and we're really bad at monetising our research.
So instead we published a paper. And that was at CCS 2025, a couple of months ago.
And unfortunately, some of our disclosures were
still in progress when our paper was published.
So here we are today with some new information that we were not able to disclose before.
*Applause*
That's exciting. Is this going to load? Okay. Maybe this is not going to load.
We're missing a slide. All right.
So step number one of our research project is to buy some hardware.
If we had an actual budget for this hardware, we would have, I don't know,
bought a 10 -meter dish and installed it somewhere in the middle of Australia
with a nice radome and, you know, have arbitrarily like steerable configurations.
That's definitely out of our budget and a 10 -meter dish
doesn't fit through the door to the roof of our building.
Option number two is we could have gone shopping
for a modern system that does these kinds of things.
There are nice phased array that can do sort of arbitrarily aim at satellites.
There are also self -calibrating steerable dishes.
Those were also beyond our budget for this unfunded
research project that we started on a lark.
So instead what we did, since this was basically coming out of my
little discretionary budget as a professor for funds these projects,
and also we didn't really know what we were doing, so we went with
the smallest, cheapest, off -the -shelf kind of thing that we could buy.
So most satellite TV is Ku band, which is the easiest band
to pick up with a small dish, so that's what we bought.
It's totally off -the -shelf consumer equipment.
And as proof that we totally didn't know what we were doing when we started,
I don't know how many of you, like, have ever installed a satellite dish.
We totally hadn't before.
This is our dish that we initially put on the mount backwards, because who knew?
We fixed it.
Annie: So our goal is to create a ground station for satellite
data that doesn't cost tens of thousands of dollars.
So first, we bought a motor that can point the dish at satellites.
Then we bought a dish that can receive the signal from the satellites,
an LNB that we can focus the signal into, and it'll filter out the noise.
And then finally, we bought a tuner card, which will process
the signal and produce a raw byte stream for us to analyse.
Now, one of the things that we should know about this tuner
card is that it is commercial off -the -shelf equipment.
It's used to watch satellite TV.
And after we published our paper, we found that the hardware has
gone out of stock everywhere, and it is also no longer produced.
*Laughter*
So one of the really big challenges for this setup is that even though we can
achieve pretty good signal -to -noise ratio, we have to get really precise alignment.
And getting alignment is actually pretty
challenging because none of us are SATCOM engineers.
So the first thing that we want to do is we look
at a couple different tools for getting alignment.
First off, we have an AR tool, and it'll do an
overlay of all the satellites that are in orbit.
Here, we just see the portion that's visible to us from San Diego.
And then we have a SDR, which lets us observe
the signal strength for a given frequency band.
We want to first find a satellite, kind of any satellite, along that band.
And the image in the middle is an example of us pointing towards
a satellite that is actively transmitting data towards us.
We don't know what the data is, but we can see that there's energy levels there.
After we align to that particular satellite, we want to keep
in mind that our motor only sweeps in one degree of freedom.
So we want to align the sweep of the motor to the arc of the satellite.
So we basically center on the one satellite that
we've already discovered and get the rest to align.
The next problem after you've aligned your satellite dish to the
geostationary arc is actually figuring out which satellite you're looking at.
And this is a non -trivial problem if you're not a SATCOM engineer.
So in some instances, this was a little bit easier because
if you look at the downlink and then you just run strings on
it, it turns out some satellites just broadcast their names.
They also broadcast their orbital parameters in case you're interested in astrodynamics.
We've listed one of them here. And the name of the satellite is AMC3.
You can Google it.
Another thing that we can use to identify the satellites that
are in orbit is the TV channels that they're broadcasting.
Because we're looking at Ku band, it's commonly used for television.
And we can cross compare the channel listings that we observe
with public source data and then identify satellites that way.
And once we have at least one or a couple satellites identified, we can
start counting degrees to the other satellites along that arc because the
spacing between the geostationary satellites is also public knowledge.
Okay.
So once we have a byte stream, we've got to do something with the byte stream.
Our first setup worked pretty well for TV channels.
We were able to view live feeds of the White House or of
random airfields when the reporters were off eating sandwiches.
And during this phase, we found out that this setup
actually performed really poorly on internet data.
And it was kind of as if someone was chopping out all of the things that
didn't look like television formats, and they were just throwing them away.
So eventually someone found, Keegan actually, found a setting
hidden deep within the menus of this software where you uncheck
the option or you check the option to enable or disable the filter.
And after we did this, we got much more reasonable -looking data.
*Laughter* *Applause* Okay.
So we have data streams that are no longer being
filtered, and we want to know what is happening in them.
Some of you may have already noticed that the first
thing we tried was running strings on the raw capture.
And it turns out that this is a pretty reasonable way
to analyse the non -binary content of a network capture.
So in this case, we found *Applause* a very funny configuration file.
This is a somewhat real one where we replaced the password hashes.
But it basically gave you some information about
the device, and it's just broadcast in plain text.
It's in ASCII. You can do it on any data that you find. Okay.
Strings is not always the right answer, though, because
sometimes you'll get stuff that looks like this.
And this is not as intuitive to puzzle out, but it does look very much like text.
And it turns out that if you actually look at it a bit longer...
Oh, it didn't render.
Why are we missing half of our slides? Okay. We're missing half of our slides.
How do you want to do this?
Go back to the previous one? Mm -hmm. I'll point it out.
If you swap every other character and every neighboring
character, this actually reads 'military true'.
*Laughter*
And if you apply the same transposition to the binary data, you'll
actually recover some binary headers for IP, and then you'll see
the source and destination addresses for that particular packet.
So our goal here is to create a parser that's able to transform a
raw capture into a packet capture that we can analyse with Wireshark.
This turns out to not be that simple in practice.
You have to learn and implement some proprietary or not -so -proprietary protocols.
Some of them are open source, and they're public, such as DVB -S2 and GSE.
But then it turns out that people don't always implement these
protocols correctly, or maybe they do it on purpose just to vex me.
And it turns out that if you apply a lot of graduate student labor
and reverse engineering, you will figure out what they're doing.
And you will get PCAPs at the end of it. This is a monument to my suffering.
I am not going to explain everything on here, but there are multiple variants
of known protocols where they do something a little bit off the implementation.
And I'm told they do it on purpose. *Applause*
So we wrote up all this code, and then we posted it on the Internet.
It's on GitHub. Some people have already found it. You can find it.
These YouTubers have also already found it, and they
have published their proofs of concept to YouTube.
The parser itself consists of multiple protocols, and all of those are also implemented.
You can test them in any order and figure out which one works best for you.
Here is an example that works on a previous packet capture that we demonstrated.
All right. So now we have all the tools in place to collect a bunch of data.
And we've done all of this work to reconstruct PCAP files that we can open in Wireshark.
And so if you do this and you open them in Wireshark, what do you find?
You find plain text. A lot of plain text.
And I want to point out sort of before we go into the details
of the plain text that we're finding, is that the people whose
networks these are had multiple options to encrypt their data.
So going back to sort of the introduction that we saw, this traffic
could have been encrypted in multiple different network layers.
So at the link layer, so the satellite protocols, satellite encryption has
been around for 40 years to encrypt PayTV and force people to pay for it.
So we know that it is possible to scramble satellite signals in a reasonable way.
It is also possible to encrypt at the network layer.
So we saw about 6 % of the transponders that we observed
do sort of ubiquitous encryption using IPsec tunnels.
6%. It is also possible to encrypt at the application layer.
So TLS is ubiquitous for end user traffic.
We'll mention multiple times that HTTPS Everywhere has actually been successful.
But critical infrastructure is not encrypted in this way.
And I also want to note that we're only seeing half of the communication.
So we only see the downlink side for the traffic.
This is because if you think about the satellite, it's broadcasting to
some footprint that could be airplanes or power plants or something.
And if our dish happens to be in the footprint for
that transponder, then we will see that traffic.
But we are not seeing the uplink side that is going
to be aimed at a specific provider's stations.
Okay. Case number one. Who flew here? I'm not flight shaming here.
Who paid for online or who paid for in -flight Wi -Fi on their way here?
Some of you. Did you know that your data is being broadcast to the ground?
Because I totally didn't before doing this.
And so it turns out that we saw traffic from two of the major in -flight Wi
-Fi vendors who you probably see if you connect to Wi -Fi on your flights.
So there's Intelsat and Panasonic. And they have...
Intelsat's been acquired in various ways. So...
And essentially, both of them, we just see the raw data from passenger Wi -Fi.
So we can see the user traffic.
And thanks to HTTPS Everywhere, it is mostly encrypted. But DNS is not encrypted.
So we can see all the host names that they're doing DNS lookups on.
We can also see endpoints aimed at crew software among the exposed host names.
So it's not just the passenger Wi -Fi.
We also see the seat -back entertainment system. So the video is scrambled.
The audio is in the clear for some reason.
And there is a fun little CTF problem in our paper
where there were partial RSA keys being transmitted.
And Keegan has a fun little algorithm for partial key recovery.
In case you want a brain teaser. So that's in our paper.
So this has been known for years. So this was documented in a paper in 2022.
And we saw exactly the same thing that they did.
We reached out to the vendors because it wasn't clear if disclosure happened before.
And the vendor response to our disclosure was basically, it's, like, a network.
It's like cafe Wi -Fi. We're not going to fix it.
It's fine that users, like if users want things to
be encrypted, they should encrypt their traffic.
So, I mean, the good news over this is that really
HTTPS Everywhere is there for end -user traffic.
But the cafe Wi -Fi analogy is a little bit interesting.
I mean, your cafe is essentially continent -sized, which is a
little bit beyond the threat model that I'd sort of imagined there.
And another good news is that a lot of this infrastructure is
actually being upgraded to low -Earth orbit satellites like Starlink.
And this will actually improve security because these links are using LTE encryption.
Uh -oh. We're missing another slide. Oh, we're missing the... Okay. I will do this.
I will do this without any notes.
We are missing the slide on cell network backhaul.
So one of the most surprising things, at least to me,
that we saw in our data was cell network backhaul.
So the picture to have in your head here is if you have a very remote
cell tower that's in the middle of the desert or in the middle of a
mountainous region, and it is not possible to get network connectivity
there by running a fiber optic cable or by running even microwave, those
networks can be connected to the rest of the cell network via satellite.
So the traffic will go from the tower through the satellite back
to the rest of the cell network and then in the reverse direction.
And we saw unencrypted traffic from several of those towers in our data. One of...
So the types of traffic that we see is the traffic that
is running over the cell providers' networks themselves.
So what we can see is control plane data.
So things like the session keys for the user's connection to the network.
And we can also see metadata around cell handoffs. And we can also...
And then there's also the user plain data, which is things like call setup
using SIP, and then the raw audio of calls, which would be in RTP packets.
A couple of the providers whose data that we observed, we saw
some data from a few towers belonging to T -Mobile in the US.
These were in remote mountainous regions.
And we actually recovered full phone call audio and raw text messages.
T -Mobile was extremely responsive to our disclosure. They were very on the ball.
Their security team is awesome. We talked to them a bunch.
And they fixed it very quickly.
I think they did not realise that their traffic was unencrypted.
Their traffic was actually inside of an IPsec tunnel.
But the tunnel had a null cipher. *Laughter* *Applause*
Another provider whose data we saw was AT &T Mexico.
In that case, we didn't see raw contents.
We saw the control plain data, which included some of the session keys.
We disclosed this to AT &T Mexico.
The response was a little bit more mixed, but we don't see those transponders anymore.
So perhaps they got it. So that was really surprising to us.
A third telecom -related application that we saw was VoIP traffic from Telmex.
Telmex owns about 80 % of the phone lines in Mexico.
We saw a bunch of unencrypted calls from Telmex's VoIP service.
This included the SIP setup for phone calls and
then the unencrypted packets with actual voice data.
We attempted to contact Telmex multiple times via numerous different methods.
We never were able to get a response.
This unencrypted data is still being broadcast by the same transponders.
To back up a little bit, this was super surprising to us because cell phone
data is encrypted very carefully between the cell phone and the tower.
There's been a lot of security analysis of the ciphers that are used for this,
but academic researchers have no way of looking at the cell networks themselves.
So this seems to be sort of uncharted territory.
Users have no way themselves of knowing if the
tower that they connect to uses satellite backhaul.
You have no way of knowing if your traffic is being broadcast to the continent.
This is different from the rollout of things like
low -earth orbit satellite support for cell phones.
That is essentially your phone connecting to the satellite using LTE, and
so those connections are encrypted between the satellite and the phone.
In terms of updating threat models, when we as sort of the security
community talk about threat models for telecom, we talk about
things like compelled legal access or MZ catchers or undersea
cable tapping or intelligence organisations compromising networks.
It never occurred to me to think that a broadcaster would accidentally
broadcast clear text call contents to an entire continent.
So perhaps we can update our threat model. So, alright, that's telecom.
We also saw military traffic.
We saw a large amount of traffic coming out of the Mexican government.
I'll focus just on one application.
So there is a set of military data systems from the Mexican government that
send unencrypted asset location updates via this convenient text Redis format.
This includes GPS coordinates of things like ships and helicopters.
We attempted multiple times to reach out to the
Mexican government and never received a response.
However, this did eventually get some local press attention in Mexico.
The Secretary of Defense was asked about it on TV,
and the Navy reached out to us after this attention.
And this transponder is gone now, but there is still a lot of unencrypted traffic
from different systems, including things from the National Guard in Mexico.
We also saw US government traffic.
So this is a new one that we haven't been able to talk about before.
So this, we saw a particular transponder whose traffic included IPsec
tunnels between US Defense Information Systems Agency IP addresses,
unencrypted VoIP traffic to a city with a large Navy base,
some satellite terminal configuration files that mentioned Raven
satellites with what appear to be US military codes for global regions.
And after seeing all of this traffic, there was a single IP address that allowed
us to trace this traffic back to a satellite provider in Inmarsat government.
And this tracing was validated during disclosure.
Viasat had acquired them in the meantime, and they said
that it would take a few months to replace this traffic.
I think it takes a few months, perhaps, for boats to
come back into port and have their equipment upgraded.
And there's public information about upgrading satellite
service for the US Navy military sea lift command ships.
These transponders are no longer active, which is why we are disclosing this now.
Okay, we are missing PG &E. We are missing PG. Yes, we are missing PG &E.
All right, we are doing this blind.
I don't know why these slides are not appearing.
So, PG, Pacific Gas and Electric is one of the largest utilities in the United States.
It provides utilities for Northern California. It has about 16 million customers.
We observed transponders transmitting unencrypted information for PG &E's internal networks,
which included a lot of SCADA commands to their infrastructure, among other things.
We disclosed this. They were very responsive.
We worked with them, and they were able to encrypt the data,
so we no longer see unencrypted data being sent to their networks.
The traffic that we saw, it included SNMP traffic,
which included things like community strings,
which are essentially passwords for network configuration. And we also saw DMP3.
Annie: DMP3.
Yes. Okay. All right.
So, it is surprising to see this kind of unencrypted traffic
being sent from military and critical infrastructure.
To sort of reiterate what I've said before,
HTTPS Everywhere was successful for end -user browser traffic,
but not for this kind of critical infrastructure.
And the US government really knows what they're doing.
They carefully encrypt their own traffic.
We saw these IPsec tunnels between military IP spaces.
But even though they really know what they're doing and are very careful about it,
there's complicated layers of commercial contracts that obscure the security issues,
even for these highly resourced governments and highly regulated industries.
They had no ability to audit their own network communications.
Which is kind of incredible.
So, we had to validate that they had actually secured their networks for them.
The final new case study that I want to mention is SageNet.
So, they are a service provider that provides, among other things, payment systems.
So, they have a large number of endpoints and they operate their own satellite network.
And we saw a lot of unencrypted credit card transactions, which included full numbers.
We also saw transactions from public food assistance in the United States.
So, the EBT system, which included both partial and full card numbers and balances.
And transaction failures.
So, they were very responsive to our disclosure and have encrypted their traffic.
So, why are we seeing all these things? There are...
It turns out there's multiple sort of systemic issues here that make it difficult to deploy
encryption for satellites. One is that there's overhead to deploying encryption.
So, first, if you have encrypted data, it can't be compressed.
And second, if you use something like an IPsec tunnel, then you can add additional headers.
And adding those additional headers can actually introduce more overhead.
One of the service providers that we talked to said that
this overhead can be up to 30 % of real -life traffic.
Another issue is that there are apparently historical
pricing wars that caused the satellite providers
to pull out all their different services as special add -on charges.
And so, encryption was one of those services that was pulled out as a special add -on charge.
So, there is, in fact, an economic disincentive to encrypt data.
And as we know that there's no actual economic incentive
for providers to protect their customers' privacy.
And a third effect is that, essentially, a lot of these organisations
had no visibility into their own network configurations.
So, some of the organisations that we talked to
thought that they were encrypting their satellite data,
and there was some accidental configuration somewhere in a long chain
of network equipment that resulted in plain text being transmitted.
And they had no ability to audit their transmissions,
and so we were the first ones to see it.
So, what we see is, essentially, this provides a new look
into the internal networks in a lot of these organisations
that is not easy to get for responsible -looking researchers like us.
And we can see that these organisations are treating their satellite
backhaul just as another transparent part of their internal network.
And so, their internal networks are not encrypted.
And so, if you just add a satellite link as another link in the chain,
we see the same plain text that is presumably everywhere else in the network.
So, this, you know, proper defense in depth would mean that
you would encrypt everything on your private internal networks.
But that's a huge pain to deploy.
And we essentially need a lot of future work and more
transparency in order to secure this part of our infrastructure
that has been, until now, neglected.
So, our final slide is, let's see, do we have something else there? I don't know.
Here's our final slide.
We have some time for Q &A, and you can find our paper and our software at this URL.
Thank you. *Applause*
Thank you very much. We can go to the questions and answers.
Are there any questions and answers? Here on the first microphone first, I guess.
Hi. This is obviously huge and has probably been a problem for, like, decades.
And yet, all it took for you, like, hardware -wise, was like a satellite TV dish.
Why do you think has nobody else seen this before?
Nadia: There's been some previous work.
As far as we can tell, some of the previous work
that was coming out of European researchers,
they were worried about the legality of looking at this data,
which is why they restricted themselves to particular
domains like maritime and aviation applications
where it was sort of clearly legal in, say, the UK to examine this data.
So, that's one effect. Another, that's one reason.
Another reason is it actually was a giant pain.
We're kind of hiding how much of a giant pain it was to parse all this stuff.
I don't know if you want to add anything.
Annie: So, the organisations, and I have a couple of friends
who I found out work for these ground stations.
They do it on purpose. I told them that it didn't stop me and they were surprised.
They were like, that's supposed to stop people from actually analysing it.
I was like, you have made me suffer, but you have not stopped me. Okay. *Applause*
Thank you. I see three more questions.
Next, I guess, five, then three, and two, and one
additional in the end maybe from the internet.
So.
Audience: Thank you very much for the talk.
So, you talked a lot about confidentiality, but also if it's plain text,
is it also an authenticity issue where you could just send data to a satellite,
and have you seen data that, if spoofed, could cause a lot of issues?
Oh, yes. That's a very, very good point.
I should have mentioned, particularly for the, say, power grid infrastructure,
having unauthenticated SCADA commands, I'm not an expert on these protocols,
but I don't see, it seems plausible that a malicious
attacker who could broadcast to a satellite
may be able to inject commands into the internal networks of these organisations.
And we only gave the example of PG &E in our slides,
but there were multiple other utility providers
and gas pipelines and other things that we saw in our data.
Okay, thanks. Next one, microphone of three.
Audience: Okay, thank you again for the slide.
You have speak about Wireshark dissector before.
Have you tried to do PR on Wireshark and see what the misleading part of the dissector was?
Annie: So, I have taken a look at Wireshark dissectors.
I'm just going to admit here that I don't know Lua as well as I do Python.
So, we wrote Python dissectors, and they're not very fast, but they do work,
so they are posted onto our GitHub.
Audience: Okay, thank you.
Herald: Okay, and microphone two, please.
If somebody had a spy satellite up there, wouldn't
he see all the traffic from the other side?
I mean, how accurate are these uplinks?
So, you would imagine... This is speculation.
I don't actually know anything about spy satellites, and I feel like I should say that.
But you would imagine that spy satellites are actually within the control of the government.
So, rather than contracting this out, they have more direct
control over whether or not the signal gets encrypted or not.
Audience: No, I mean somebody else's.
Annie: Someone else's spy satellites?
There was a news story recently about some unidentified
downlinks that were coming from targets that nobody knew of,
and there was speculation that it was someone's satellites.
Audience: No, I mean the uplinks are also unencrypted, I guess.
Annie: The uplinks, we don't know anything about the
uplinks, but the uplinks tend to be much narrower.
So, it's possible you can eavesdrop on them if you
navigate a drone between the terminal and the satellite,
but we haven't done that.
Thank you. The internet, I think that's the last question. And...
Hello. Yeah, this is the question from the internet.
If the data is encrypted between the phone and the cell phone tower,
why, how is it then unencrypted for transmission via satellite?
Nadia: I guess the picture to think here is that, so, the tower, so, the
negotiation, the key negotiation is between the tower and the phone.
They strip off, the tower is going to strip off the radio encryption
and then send the data that is relevant to the rest of the network.
So, much like any other part of the internet, protocols and data can be stripped off,
and the payloads are re -encapsulated into other
protocols and then sent over the rest of the network.
So, the cell providers are handling their own internal networks and
I guess they didn't see any reason to apply separate encryption.
But the radio link itself ends at the cell tower and then
the cell tower needs to communicate that data to the rest
of the network in order to get it to the actual recipient.
Thank you. I guess we are at the end. A warm applause. *Applause*