[00:00.000 --> 00:25.360]  Oh my gosh. Talking. Come on, stream. Come on. All right. And we're live. All right.
[00:25.770 --> 00:32.560]  We're here today with another speaker, talking about sniffing satellite traffic, whispers
[00:32.560 --> 00:36.840]  among the stars, with James Pavor. Pavor? I didn't actually...
[00:36.840 --> 00:37.880]  Yeah, Pavor.
[00:37.880 --> 00:41.160]  Pavor. Got it right. Yeah. All right.
[00:41.160 --> 00:46.560]  We'll be taking questions in the track one live QA. Do you want to give a quick summary
[00:46.560 --> 00:52.960]  of your talk for anybody that might not have gotten a chance to see your talk right off the bat?
[00:53.640 --> 00:58.920]  Yeah, sure. So the quick recap of the talk is that if you use kind of simple home television
[00:58.920 --> 01:03.780]  equipment, you can intercept these radio waves coming off of satellites in geostationary orbit
[01:03.780 --> 01:07.980]  that are providing internet service. And what we found is that these internet services are often
[01:07.980 --> 01:11.600]  unencrypted at the internet service provider level, which means you get to see all kinds
[01:11.600 --> 01:15.240]  of nifty traffic. We looked at it from a bunch of different perspectives. We saw traffic going
[01:15.240 --> 01:20.340]  to like cargo ships and oil rigs in the ocean or to airplanes in the sky or to like wind turbines
[01:20.340 --> 01:24.920]  on the ground. And across all of these domains, the talk kind of delves a little deeper into what
[01:24.920 --> 01:28.820]  an attacker might do with that information or how they might abuse these signals to cause harm.
[01:28.820 --> 01:32.480]  And then it concludes by talking about ways we can fix it by coming up with alternatives to
[01:33.000 --> 01:35.760]  VPNs, which tend to be very slow on a satellite connection.
[01:35.760 --> 01:45.220]  Awesome. So we do have our first question with RPTK2015, MVP question asker.
[01:46.060 --> 01:50.800]  In your talk, you made an active attack by impersonating a ship response. I assume this
[01:50.800 --> 01:54.640]  requires you to spoof your source address, but ingress filtering ISPs is supposed to prevent
[01:54.640 --> 01:58.740]  IP spoofing. Can you please explain how you still did it?
[01:59.060 --> 02:04.120]  Yeah, it's a great question. I'm not actually sure how that happened from an ingress filtering
[02:04.120 --> 02:07.440]  perspective. I guess the answer would be that it looks like they weren't filtering correctly
[02:07.900 --> 02:12.180]  because we were able to spoof in one specific network. It's worth noting, though, that the
[02:12.180 --> 02:17.140]  vast majority of satellite networks we looked at were not trivially vulnerable to TCP session
[02:17.140 --> 02:20.900]  hijacking because of the way that the sequence numbers were changed by those performance
[02:20.900 --> 02:25.700]  enhancing proxies I talk about in my presentation. So there are only a handful of networks that were
[02:25.700 --> 02:30.080]  directly vulnerable, and they seemed almost designed so that each operator's IP address
[02:30.080 --> 02:35.120]  was a direct gateway to the internet, which might be why the individual customers
[02:35.120 --> 02:37.820]  weren't checking IP addresses for spoofing.
[02:38.620 --> 02:42.740]  Fair enough. So if they were peering directly into the backbone of the internet, they might just
[02:43.520 --> 02:47.460]  trust that it's coming from a legitimate source already or already been filtered?
[02:47.740 --> 02:48.320]  Yeah.
[02:49.340 --> 02:50.300]  Cool.
[02:50.740 --> 02:56.980]  I think Hawkeye asked one that would really fall in line with this. Why do you believe that
[02:56.980 --> 03:02.100]  these high-profile enterprise SATCOM customers haven't adopted and implemented a simple
[03:02.100 --> 03:05.520]  encryption-in-transit policy to stop this kind of spoofing?
[03:06.480 --> 03:10.580]  So there are a couple of reasons. I think one is that, like I mentioned in the talk,
[03:10.580 --> 03:14.540]  VPNs are really slow, and that's what a lot of people think an encryption-in-transit policy
[03:14.540 --> 03:18.380]  would look like. And because of the way that VPNs interact with the internet service provider
[03:18.380 --> 03:24.920]  offerings, they often end up seeing this kind of false tradeoff between privacy and performance.
[03:24.920 --> 03:28.680]  That said, there are a lot of these enterprise customers. And when we reached out to them with
[03:28.680 --> 03:33.540]  responsible disclosure, the answer would be that they kind of tried to implement a TLS everywhere
[03:33.540 --> 03:38.460]  policy. But you're talking about kind of massive networks, like hundreds of ships at sea. And so
[03:38.460 --> 03:42.780]  there are a lot of systems that are just forgotten, like legacy FTP services or services that they
[03:42.780 --> 03:46.920]  think are behind some sort of firewall. And so they're willing to accept the risk without realizing
[03:46.920 --> 03:49.560]  that that risk includes a wireless eavesdropping threat.
[03:50.120 --> 03:56.600]  Yeah. And some of those ships have a lot of systems that are just unknown. Like a contractor
[03:56.600 --> 04:01.260]  installed them at some point, they just got lost or forgotten and still plugged into a network in
[04:01.260 --> 04:03.720]  there somewhere. Yeah, definitely.
[04:05.440 --> 04:10.320]  So in your talk, you mentioned the performance-improving proxies. And
[04:11.500 --> 04:15.440]  what I didn't understand was that that was something that would be run by the actual
[04:15.440 --> 04:16.860]  operator. Is that right?
[04:17.900 --> 04:22.820]  Yeah. So almost always that's the case. There's no like technical reason a customer couldn't
[04:22.820 --> 04:28.080]  bring their own performance-enhancing proxy. But generally, satellite internet service providers
[04:28.080 --> 04:33.280]  are acting as kind of benevolent eavesdroppers on your TCP sessions. And they're kind of messing
[04:33.280 --> 04:37.160]  with your TCP three-way handshake to make your traffic faster. And that's just kind of part of
[04:37.160 --> 04:42.020]  how they see providing customers with sufficiently performance satellite internet services.
[04:42.020 --> 04:50.270]  Got it. You want to throw a question out there, Elle?
[04:50.270 --> 04:55.630]  You know, I was... sorry. You had a lot of feedback on YouTube. And a lot of what I'm
[04:55.630 --> 04:59.190]  seeing now is people going, could you do it with this? Could you do it with that?
[04:59.190 --> 05:03.270]  And I know you gave a bit of an outline at the beginning of your talk on how you did it.
[05:03.270 --> 05:07.430]  If somebody wanted to replicate this, play along with it, could you kind of give an outline,
[05:07.430 --> 05:11.430]  you know, from beginning down to software, what they would need to just start out with?
[05:11.850 --> 05:17.410]  Yeah, definitely. So I think the core bits that you need are some sort of satellite dish that's
[05:17.410 --> 05:22.250]  capable of receiving satellite television. We researched the KU band, but there's no reason
[05:22.250 --> 05:27.130]  you couldn't do it in the KA or C frequency bands as well. And then you need some kind
[05:27.130 --> 05:31.170]  of way to interpret what that dish is saying on your computer. We use this specific kind
[05:31.170 --> 05:35.470]  of professional grade PCIe card, which I think the model number is on the slide deck.
[05:35.570 --> 05:39.690]  But you could actually get away with a bunch of like much less expensive cards.
[05:39.810 --> 05:43.030]  The problem with that is that you won't be able to listen to some of the more interesting signals,
[05:43.030 --> 05:49.050]  which use like 32 APSK modulation and seem to do really poorly. There are also some USB cards.
[05:49.230 --> 05:53.070]  So you could do this with a laptop. You don't have to like build out a satellite spying computer
[05:53.530 --> 05:58.570]  to be able to play with this stuff. From a software perspective, the tool that I show in
[05:58.570 --> 06:03.430]  the actual like little demo video is I think what I would recommend first. It's called EBS Pro,
[06:03.430 --> 06:07.630]  and it's designed for feed hunting. And it's really intuitive and has an interface that's
[06:07.630 --> 06:12.130]  easy to use. If you're on the Linux side, the tooling is, I think, significantly worse.
[06:12.690 --> 06:17.150]  So it might be worth spinning up a Windows VM to do this stuff. The other big tool in the space
[06:17.150 --> 06:22.130]  is something called Crazy Scan, which is around on some of these like satellite television feed
[06:22.130 --> 06:27.350]  hunting forums. And then once you have all of that lined up, if you're listening to older protocols,
[06:27.350 --> 06:32.150]  so the MPEG-TS standard, Wireshark can actually just interpret those feeds directly.
[06:32.230 --> 06:36.490]  If you're listening to newer protocols, you have to kind of parse the traffic dumps.
[06:36.550 --> 06:40.570]  Unfortunately, the tool I talk about in my presentation is still awaiting our chance to
[06:40.570 --> 06:44.170]  publish it as we're trying to be careful not to release an attack tool into the wild before
[06:44.170 --> 06:50.030]  systems are patched. But we were able to build it using the Python library called KyTy, which is
[06:50.030 --> 06:54.530]  used for like parsing various protocol formats. And so it wouldn't be that hard to kind of put
[06:54.530 --> 07:03.970]  together your own GSE parser. Do you know what the signal width is on these? What grade of software
[07:03.970 --> 07:09.770]  defined radio would you need to be able to receive these signals? That's a great question. I actually
[07:09.770 --> 07:15.470]  have no idea. I know that on the DVBS side of the software defined radio community, I kind of
[07:15.470 --> 07:19.670]  delved into this a tiny bit. And it looks like being able to keep up with these more complicated
[07:19.670 --> 07:26.050]  modulation schemes is not something that your kind of standard SDR software is able to do.
[07:26.710 --> 07:31.250]  Whereas these kind of like PCIe cards, I think they often use like specialized FPGAs for the
[07:31.250 --> 07:38.510]  signal processing and are just better at it. I had two follow-ups on the previous question.
[07:38.510 --> 07:42.150]  Somebody was asking, which I find funny, is if you're using kind of like the old dish network
[07:42.150 --> 07:45.850]  up on your ceiling, do you need to go up there and kind of reorient the dish?
[07:46.490 --> 07:50.590]  Yeah, so that was actually a big frustration for us because it turns out that I don't have any fine
[07:50.590 --> 07:55.170]  motor skills. So there were like several hours between each satellite of me like swearing at
[07:55.170 --> 07:59.750]  various bits of hardware on the roof. So what we ended up doing is purchasing this thing called the
[07:59.750 --> 08:05.210]  DISEC motor, which allows you to steer a satellite dish across the horizon. And you can actually just
[08:05.210 --> 08:09.930]  put in the specific location in geostationary orbit you want and direct it that way. It increased
[08:09.930 --> 08:14.490]  the cost of the attack a little bit, but because we were looking at I think 18 satellites in total,
[08:14.490 --> 08:18.450]  being able to hop between them without crawling onto the roof every time was a big benefit.
[08:18.450 --> 08:25.010]  I can imagine. So the parts that you had listed in your talk were between like 300 and 400. What
[08:25.010 --> 08:29.910]  was the like extra cost of that automated rotor? I don't remember off the top of my head. I want
[08:29.910 --> 08:34.690]  to say it's around $100. You need to be careful that you get one that correctly mounts to the
[08:34.690 --> 08:38.190]  dish you have, because different ones have different ways of attaching. So it's a little bit
[08:38.690 --> 08:42.350]  less easy to just buy one off the shelf, but it's definitely doable.
[08:42.550 --> 08:48.450]  Yeah, I've done some ham radio stuff with with aiming antennas, and it's always kind of
[08:48.450 --> 08:50.850]  up in the air whether it's going to work or not.
[08:53.050 --> 08:58.870]  Have you documented any of this like in a blog, you know, a GitHub, whatever it is that you're using?
[08:59.170 --> 09:04.230]  Yeah, so there are two academic papers that I can put into the chat afterwards that talk about
[09:04.230 --> 09:09.930]  our domain studies onto terrestrial users and maritime users. And those go into a lot more
[09:09.930 --> 09:16.150]  detail. In particular, if you were interested in replicating the GSE extract tool, the appendix of
[09:16.150 --> 09:21.250]  the maritime paper goes into a lot of depth on like how we actually parse the GSE packets and
[09:21.250 --> 09:24.190]  how we deal with the corruption in the signals that we were getting.
[09:24.590 --> 09:29.350]  Did you have a paper associated with the avionics stuff as well? Or is that just...
[09:29.350 --> 09:35.090]  No, that's new for the Hacker Summer Camp. So that was new stuff. We're still... I think once
[09:35.090 --> 09:39.170]  aviation picks up a little bit more, we can get consistent data, we may try to publish something
[09:39.170 --> 09:43.050]  that's a little bit more robust. But because it was kind of a toss in the air as to whether or
[09:43.050 --> 09:46.750]  not there would be a plane out that day, we didn't have as much data as we wanted.
[09:46.910 --> 09:51.410]  Yeah, I mean, one of my next questions was going to be like, what are the future research look like
[09:51.410 --> 09:55.350]  for you? Sounds like that's that's one of them. You got anything else like coming down the pipe
[09:55.350 --> 09:56.730]  that you want to do with this kind of thing?
[09:56.730 --> 10:01.770]  Yeah, so I mean, we're still looking at that proxy that I mentioned at the end of the paper.
[10:01.770 --> 10:05.250]  So that's kind of going through peer review right now. It's always hard to kind of convince
[10:05.250 --> 10:09.590]  academic peer reviewers that something can be both simple and novel. So who knows how that's
[10:09.590 --> 10:13.230]  going to turn out in the end, but it's on GitHub. And we're kind of working to make that something
[10:13.230 --> 10:18.310]  that people can hack on and use. And then I'm also interested in satellite security in general.
[10:18.310 --> 10:22.830]  I'll be talking at the Aerospace Village tomorrow for a little bit on other threat models to
[10:22.830 --> 10:29.530]  around like space debris tracking. And so just generally hacking satellites is kind of my focus
[10:29.530 --> 10:36.830]  area. Sounds like a whole lot of fun. I think we were. Yeah. Is there a satellite hacking village
[10:36.830 --> 10:41.790]  going on right now? Yeah. So the Aerospace Village is doing both aviation like last year,
[10:41.790 --> 10:45.630]  and then they've got all kinds of new talks on satellites this year. Yeah, I knew there
[10:45.630 --> 10:51.390]  was supposed to be a special event this year, but we went virtual. So maybe next year.
[10:53.150 --> 10:58.250]  Hawkeye is asking, is there any reason you didn't go with a parabolic antenna in your research?
[10:58.250 --> 11:03.690]  It seems that the gain might increase with one. Yeah, I think the gain would definitely increase
[11:03.690 --> 11:08.850]  with one. The reason we use that self-sat flat panel is just literally because of the shape
[11:08.850 --> 11:12.630]  of the area we were trying to fit it in with a bunch of other things up there. And it was just
[11:12.630 --> 11:18.250]  the one that we ordered fastest. But I think that a curved dish would do better and would be cheaper.
[11:18.950 --> 11:26.810]  Cool. I think it might be being addressed in the village, but one of the questions on YouTube was,
[11:26.810 --> 11:30.910]  you know, you've talked about how you pull down information. What is the likelihood that you could
[11:30.910 --> 11:35.730]  push up commands as well? And you know, started kind of attacking, well not even attacking, but
[11:35.730 --> 11:41.710]  just impacting what you're seeing. So I haven't looked a ton at transmitting on these internet
[11:41.710 --> 11:46.650]  feeds, and if there's any authentication there, in part because it's just harder to get a license
[11:46.650 --> 11:52.470]  to transmit than a license to listen. But that said, if you wanted to engage in like attacks
[11:52.470 --> 11:56.070]  against the telemetry link for the satellite, so actually steer the satellite and stuff,
[11:56.290 --> 12:01.130]  a lot of those communications happen in different frequency bands. In particular, S-band is kind of
[12:01.130 --> 12:05.310]  the dominant satellite telemetry band, and that would require completely different hardware and
[12:05.310 --> 12:10.130]  use different protocols. That said, the general threat model of like being within kind of this
[12:10.130 --> 12:14.630]  massive footprint areas, I think would still be relevant to think about in that context.
[12:17.170 --> 12:22.310]  Cool. We've actually got a fair number of questions that we've backed up. I'm sorry,
[12:22.310 --> 12:32.610]  guys, I'm not trying to ignore your questions. Let's see here. Since this is just a dbb-s
[12:32.610 --> 12:37.710]  or dbb-s2, why not use one of the bazillion conditional access system solutions used for
[12:37.710 --> 12:44.210]  video broadcast? That's a great question. I didn't even... oh, so you're talking about the like
[12:44.210 --> 12:49.730]  streamwise encryption. That's something that I talk about a little bit in one of the papers. I
[12:49.730 --> 12:54.550]  think these protocols are not well designed from a cryptographic perspective at all. There have
[12:54.550 --> 12:58.050]  been a lot of vulnerabilities found in them, especially the proprietary ones, which seem
[12:58.050 --> 13:02.250]  popular probably because they have a good marketing link behind them. But also kind of
[13:02.250 --> 13:06.050]  doing a stream level encapsulation like these protocols do works great for television where
[13:06.050 --> 13:10.350]  you don't want everyone watching a proprietary video feed, but it doesn't work well because
[13:10.350 --> 13:14.050]  anyone who has the keys can listen to their neighbor's traffic. And you'll often have one
[13:14.050 --> 13:19.570]  satellite transponder that's carrying the traffic of 20, 30, 50 users. And so it decreases the threat
[13:19.570 --> 13:24.870]  model a lot and it's a big improvement, but it doesn't fix the underlying issues. And you mentioned
[13:24.870 --> 13:31.030]  another solution that was sort of a replacement for the MPEG, which had been
[13:31.030 --> 13:37.370]  jury-rigged to sort of take IP traffic. Does that have like the same level of like research
[13:37.370 --> 13:40.730]  involved in it? Is the same level of like vulnerabilities or something like that? I know
[13:40.730 --> 13:48.310]  that you're doing like probabilistic extraction of data from it, but... Yeah, so the MPEG standards
[13:48.310 --> 13:51.870]  that are used for sending internet these days, there's something called multi-protocol encapsulation
[13:51.870 --> 13:58.290]  or MPE and ultra lightweight encapsulation, I think, or ULE. And we looked at both of those.
[13:58.290 --> 14:02.550]  Wireshark has built-in support for them. So the threat model is fairly trivial there if you can
[14:02.550 --> 14:07.150]  get a good recording. What's interesting about the MPEG context though is that building your
[14:07.150 --> 14:11.730]  own parser is a real pain because it's not a format that was designed for sending data,
[14:11.730 --> 14:16.690]  much less secure data. And so it's an incredibly complicated and convoluted way of getting IP
[14:16.690 --> 14:23.750]  packets from one place to another. I believe it. All those old things that are just like,
[14:23.750 --> 14:28.110]  oh yeah, I'm sure we could fit this data in here somewhere. It'll work, right?
[14:29.950 --> 14:36.170]  One of the questions I saw on YouTube is, you know, you talked in your talk about how a lot
[14:36.170 --> 14:42.530]  of these are using, you know, old devices, obviously, old operating systems. And I don't
[14:42.530 --> 14:45.810]  know how much you went into the past, but what they were wanting to know is have you seen any
[14:45.810 --> 14:50.250]  progression in what they're trying to do to actually protect this data? Or is it just been
[14:50.250 --> 14:56.430]  the same historically? Yeah. So there are companies out there that offer encrypted satellite internet
[14:56.430 --> 15:01.370]  services. It's often something a customer has to pay extra for or accept like significant
[15:01.370 --> 15:06.950]  performance degradation in the form of the VPN. One big product in this area is made by NewTek.
[15:06.950 --> 15:12.770]  It's called Enhanced TCP or ETCP. There was a WikiLeaks document a few years ago that talked
[15:12.770 --> 15:16.390]  about how there were built-in backdoors for law enforcement and intelligence agencies,
[15:16.390 --> 15:21.070]  which is always the risk with using kind of these proprietary standards. But there definitely is an
[15:21.070 --> 15:24.690]  initiative in parts of the industry to encrypt traffic. I think it's just one of those things
[15:24.690 --> 15:27.850]  where the commercial incentives don't align with the need for customers.
[15:29.210 --> 15:34.810]  So I just want to like, we previously talked about your performance improving proxy, which
[15:34.810 --> 15:42.150]  you mentioned uses QUIC. There is, is there any potential benefits of just like using WireGuard
[15:42.450 --> 15:48.030]  instead of like, it's another VPN. It's like you directly compare OpenVPN. WireGuard is supposed
[15:48.030 --> 15:55.110]  to like, it's simpler. It's using UDP sessions, should be faster round trip. Is there, did you
[15:55.110 --> 15:59.350]  look at that in comparison before you started working on your own QUIC proxy?
[15:59.430 --> 16:03.930]  That's a great question. So we didn't test WireGuard specifically, although I would point
[16:03.930 --> 16:08.890]  out so that GitHub repository that's linked at the end of the talk for QPAP is actually a generic
[16:08.890 --> 16:12.930]  purpose like Docker test bed, where you could easily install whatever VPN you want and simulate
[16:12.930 --> 16:19.610]  the satellite link. That said, I think that a UDP-based VPN like WireGuard will still hide the
[16:19.610 --> 16:24.290]  TCP three-way handshake. So also send those ACK messages across the satellite link. And so it
[16:24.290 --> 16:29.170]  might be a little bit faster, like starting the VPN session, but the encapsulated traffic is still
[16:29.170 --> 16:33.670]  going to be hidden from the ISP. And so they can't optimize it correctly. So you really need to split
[16:33.670 --> 16:39.010]  out the TCP sessions on the ground first, which most VPNs don't do because it'd be a little silly.
[16:39.150 --> 16:43.770]  Right. Fair. Yeah. And WireGuard is designed so that they specifically can't see those TCP sessions
[16:43.770 --> 16:55.310]  or what's inside. Right. So kind of changing pace, sorry, talking and reading at the same time.
[16:56.130 --> 17:01.470]  Have you looked into Starlink? I know it's a pretty hot topic that's going on right now.
[17:01.470 --> 17:06.810]  See if they are actively using any kind of encryption or anything else like that.
[17:07.830 --> 17:12.110]  So I haven't tested anything related to Starlink yet, although that's definitely... you talked
[17:12.110 --> 17:15.710]  about like areas I'd be interested in the future. That's definitely an exciting topic.
[17:16.250 --> 17:20.690]  Starlink is in low Earth orbit, which does change the dynamics a lot because the satellites are
[17:20.690 --> 17:25.410]  closer. You don't have the same problems with TCP through a handshakes, which means that using a VPN
[17:25.950 --> 17:30.890]  is generally viable because the latency is much lower. Although certain conditions can change that
[17:30.890 --> 17:34.990]  if you have to make a lot of hops across the constellation. So I think that it would be easier
[17:34.990 --> 17:39.770]  for SpaceX to implement an encrypted service than it would be for some of these geostationary
[17:39.770 --> 17:47.010]  providers. Whether or not they do that remains to be seen. Fair enough. And like the receiving
[17:47.010 --> 17:50.310]  traffic, it's like because they're in lower Earth orbit, they're going to have a much smaller
[17:50.310 --> 17:55.470]  footprint. Yeah, that's a great point. Like the Iridium low Earth orbit constellation, each of
[17:55.470 --> 18:00.750]  the satellites passes across the horizon in like seven minutes. So the area that an attacker could
[18:00.750 --> 18:05.350]  be is still too large, right? It's dozens of miles, hundreds of miles, but it's nowhere near
[18:05.350 --> 18:10.710]  comparable to a different continent. Yeah. Were you looking at like Iridium satellites as like
[18:10.710 --> 18:16.330]  your testbed? Like you didn't mention actually which satellites were involved. Yeah, so we
[18:16.330 --> 18:20.350]  didn't look at Iridium because it's a low Earth orbiting constellation. We made the decision not
[18:20.350 --> 18:25.950]  to name specific satellite operators for like legal reasons, but they were geostationary
[18:25.950 --> 18:31.290]  providers that were Europe. Yeah. I've always found the Iridium satellites, like the story
[18:31.290 --> 18:37.230]  behind the Iridium satellite, super interesting. Like it's just like a fascinating evolution out
[18:37.230 --> 18:46.930]  of Motorola. Yeah. Yeah. I was wondering, like as the, you know, I guess end result, if I'm up on
[18:46.930 --> 18:50.710]  the airplane on a cruise ship and I decide to pay for internet and I'm getting things like text
[18:50.710 --> 18:57.350]  messages, what can I do to protect the status? Something like a VPN enough to impact my protection?
[18:57.350 --> 19:02.530]  So the text message case, I think you're kind of, you're kind of in a bad spot, whatever you do,
[19:02.530 --> 19:06.510]  because that's over the femtocells and you don't have a ton of control over what their
[19:06.510 --> 19:12.330]  backend looks like. But for emails and stuff, so many people, more people than ever should be,
[19:12.330 --> 19:18.490]  were using just unsecure POP email inboxes and leaking deeply sensitive stuff over the feeds.
[19:18.490 --> 19:24.170]  And I think just generally using like TLS for visiting websites or POP3 with TLS for
[19:24.170 --> 19:29.050]  checking your inbox is a huge step up for protection. And then if you're willing to
[19:29.050 --> 19:33.810]  take it a bit slower and have that latency problem, any VPN will be better than having
[19:33.810 --> 19:38.050]  someone spy on your traffic, in my opinion. I think this is going to be the first year
[19:38.990 --> 19:44.110]  in DEF CON's history since the wall of sheep started that they did not get plain text POP
[19:44.110 --> 19:47.810]  or IMAP credentials. And that's only because they're not capturing traffic.
[19:51.390 --> 19:54.770]  People attending these conferences should know at least that much.
[19:55.330 --> 19:59.890]  Yeah. We're making a lot of assumptions here.
[20:00.310 --> 20:05.230]  Yeah. I don't know. I feel like if you're going to a security convention, you could at least
[20:05.930 --> 20:09.950]  not use POP. It's a good start.
[20:09.950 --> 20:16.690]  Yeah. Is there anything else that we haven't brought up like that you might want to
[20:17.350 --> 20:20.130]  talk about specifically? Anything that you might have left out of your
[20:20.870 --> 20:25.990]  talk because it got cut by time that you're interested in? Anything like that?
[20:26.630 --> 20:33.210]  There's not too much left. I think that one thing that I kind of highlighted in the talk
[20:33.210 --> 20:37.730]  but ended up not happening is that GSE Extract is not in our GitHub repository yet.
[20:37.890 --> 20:41.170]  But it's still something I'm aware of and trying to get out there for people who are
[20:41.170 --> 20:46.090]  interested in checking it out. And so that's definitely something that I hope will be out
[20:46.090 --> 20:52.010]  soon. Other than that, though, I think that the general idea of the talk is pretty straightforward,
[20:52.010 --> 20:56.910]  right? It's that unencrypted traffic, wherever you put it, should be encrypted instead. And
[20:56.910 --> 21:00.650]  satellites are especially frightening these days because of the way that their signal properties
[21:00.650 --> 21:05.290]  are. But really, it's wherever you're using the internet, you don't know who's listening.
[21:05.290 --> 21:09.150]  And so encrypting end-to-end and being sure that you understand kind of how that works
[21:09.150 --> 21:12.490]  under the hood can go a really long way towards helping with privacy.
[21:13.430 --> 21:22.450]  That's great. I know you mentioned one of the attack of using the downlink of the satellites
[21:22.450 --> 21:29.090]  as a way to, like, exfiltrate data. And I know that there was one particular attack
[21:29.590 --> 21:33.930]  in history that made use of this. And it was, like, somewhere in Africa. And they figured out
[21:33.930 --> 21:38.690]  that someone was just driving a truck around collecting that data. Do you know anything
[21:38.690 --> 21:41.590]  about the attack? It's been a year since I remember anything about that.
[21:41.590 --> 21:45.830]  Yeah, so I think it was by Turla Group, which is a Russian state-affiliated, well,
[21:45.830 --> 21:50.570]  depending on who you ask, state-affiliated advanced persistent threat group. And yeah,
[21:50.570 --> 21:55.790]  they seem to have been using these satellite hops to make traffic just disappear over the internet.
[21:55.790 --> 21:59.650]  And I think that's a really intuitive threat model, because all you have to do is be able
[21:59.650 --> 22:02.790]  to send a packet to the right IP address. And you don't have to have any software
[22:02.790 --> 22:07.330]  on the place that you're sending it. Really, really sneaky.
[22:08.090 --> 22:14.810]  Uh-huh. So I can't think of any more questions. If anyone is out there watching the stream
[22:14.810 --> 22:18.230]  is interested in asking more questions, we're still here for a couple more minutes.
[22:20.130 --> 22:24.290]  Yep. My email is also at the end of the slide deck. Happy to answer any questions there,
[22:24.290 --> 22:29.010]  too, or on Discord or wherever. Yeah. Do you have any additional, like,
[22:29.010 --> 22:34.370]  resources you can share with us that we can just drop into track one? Anything that people might
[22:34.370 --> 22:37.190]  be interested in further research? Yeah, definitely. I'll share links to those
[22:37.190 --> 22:43.310]  academic papers. There's also a preprint paper talking about the proxy that hasn't been published
[22:43.310 --> 22:48.970]  yet, but is generally the idea of what we're trying to get published. And so if anyone has
[22:48.970 --> 22:52.670]  ideas to contribute to that GitHub repository, or has noticed mistakes that I've made because
[22:52.670 --> 22:56.610]  I'm not a network programmer, feel free to pop up an issue on GitHub.
[22:56.930 --> 23:03.950]  That's great. RPTK2015 says, how did you get to this project? Like,
[23:03.950 --> 23:09.370]  what was your path to get here? Yeah, so it was all those earlier talks from...
[23:09.370 --> 23:13.910]  so there was the researchers in 2005, which was kind of academic. And then there were two talks
[23:13.910 --> 23:20.910]  at Black Hat DC in 2009 and 2010. And I was just fascinated by that as something that could be done.
[23:20.910 --> 23:25.570]  And seeing what's changed was really the starting off point. And then it started out as literally
[23:25.570 --> 23:29.630]  just a summer mini project. It was supposed to be six weeks, but we found so much information
[23:29.630 --> 23:34.890]  in those six weeks, that I've sort of pivoted my PhD research around this satellite communications.
[23:34.890 --> 23:39.470]  And everywhere we look, it just gets more and more fascinating, and honestly, worse and worse.
[23:40.850 --> 23:46.710]  Fair enough. So here between us, just between friends, can you tell us what was the most
[23:46.710 --> 23:50.070]  interesting piece of traffic that you kind of stumbled across?
[23:50.430 --> 23:54.690]  Oh, that's so hard. I mean, it's really a different definition of interesting, right?
[23:54.690 --> 23:59.310]  Like, I forget if I mentioned this in my briefing or not. But for example, there were two friends,
[23:59.310 --> 24:03.590]  one guy was on a plane, one guy was on the ground, just chatting about some wild dream they had,
[24:03.590 --> 24:07.830]  where this guy's mom popped up in a burning building and started trying to feed him.
[24:07.850 --> 24:11.230]  And so you get all this real, you know, it's real people who are affected. And then,
[24:11.230 --> 24:16.070]  I mentioned being able to track this billionaire's yacht, right? And that's kind of a different world
[24:16.070 --> 24:21.570]  to know what the people in the yacht are eating for lunch that day, based off of the web APIs
[24:21.570 --> 24:27.290]  that they're using to manage their food system. And so it's just a different world of security
[24:27.290 --> 24:30.990]  problems. I don't think being able to listen to the internet is something a hacker expects
[24:30.990 --> 24:36.750]  to get from any perspective. And the fact that it's so inexpensive and easy in a satellite world
[24:36.750 --> 24:44.310]  is, I think, especially concerning. Yeah, but definitely, like, yeah, not great.
[24:46.770 --> 24:50.910]  We do have someone calling out that this is one of the coolest talks that they've gotten
[24:50.910 --> 24:57.810]  to see. Oh, I'm flattered. Yeah, it was a really good talk. And I'm definitely glad that I got to
[24:57.810 --> 25:04.850]  do this QA session with you. It was fun research to do, so I enjoyed it. Have you talked to any of
[25:04.850 --> 25:12.110]  the... I know there's some projects for, like, reviving old satellites and talking with them.
[25:12.110 --> 25:16.670]  Have you talked with those guys at all? And it's like, they might have, like, additional knowledge
[25:16.670 --> 25:21.690]  about, like, talking to satellites or different research projects that you might be interested in
[25:21.690 --> 25:27.330]  doing. No, I haven't done that. But it is a very, very related field, right? Because to some extent,
[25:27.330 --> 25:32.550]  reverse engineering a satellite that you can't touch is the same as exploiting one. A lot of
[25:32.550 --> 25:36.950]  the cases, it's really understanding the systems as the entirety of the security properties.
[25:37.330 --> 25:40.190]  And so, yeah, that's definitely a fascinating area I'd want to explore.
[25:40.190 --> 25:45.910]  Yeah, I do know that they've also gotten special permission to do a bunch of transmissions to
[25:45.910 --> 25:52.650]  satellites. That's part of it. That's part of the revival stuff. So, yeah, that was... they did a talk,
[25:52.650 --> 25:57.450]  I want to say, two years ago about MicMoon, which was their headquarters for satellite communications.
[25:58.090 --> 25:59.050]  That's awesome.
[25:59.050 --> 26:11.420]  Yeah. Some people are making references to DOCSIS work from earlier DEF CONs. I don't
[26:11.420 --> 26:16.100]  know how... if that's necessarily related, because DOCSIS is a cable protocol.
[26:17.180 --> 26:21.520]  Yeah, I don't know anything about it. So if it is related, I completely missed it.
[26:22.140 --> 26:24.640]  Definitely something for someone else to contribute.
[26:26.760 --> 26:32.340]  And The Geek is asking about new radio and SDR again, which we did briefly cover.
[26:33.740 --> 26:34.640]  But so...
[26:34.640 --> 26:37.980]  Yeah, I think it's possible. I think it's just a little bit harder.
[26:37.980 --> 26:41.600]  These things are pre-made and just easier to use and so widely available,
[26:41.600 --> 26:44.340]  but it's easier to just pick up a satellite tuner yourself.
[26:44.340 --> 26:47.780]  Yeah. Makes sense.
[26:50.420 --> 26:54.540]  I think you're getting high compliments from Mav there, talking about how this feels
[26:54.540 --> 27:00.100]  very much like, you know, the old Alexa Park content. So, wow, people are loving this.
[27:01.040 --> 27:05.280]  I'm really flattered. Yeah, it was cool stuff to do. It was a little frightening at times, but
[27:05.800 --> 27:11.020]  really enjoyable research. And I think space is a place people haven't done a lot of exploring. I
[27:11.020 --> 27:15.120]  mean, there obviously are other people before me, but I think there's a lot of low-hanging
[27:15.120 --> 27:20.040]  fruit for people who are interested in kind of living the days when hacking was maybe not easy,
[27:20.040 --> 27:23.920]  but terrifying. Well done.
[27:27.880 --> 27:33.140]  All right. Well, we're approaching the end of the session. Any final shout outs or anything
[27:33.140 --> 27:38.060]  you want to do before we sign off? One other thing I might hit on,
[27:38.060 --> 27:42.800]  as I mentioned, electronic flight bags in the talk as kind of an interesting component of the
[27:42.800 --> 27:46.380]  aviation stuff. I didn't know it at the time when I was recording the talk, but there were actually
[27:46.380 --> 27:53.920]  two village talks on electronic flight bags. One happened yesterday by Matt Gaffney,
[27:53.920 --> 27:58.160]  and I thought it was really cool. And then there's one tonight by David Robinson. So if you're
[27:58.160 --> 28:02.200]  interested in kind of the aviation side and what it might mean to hack an EFB, I definitely recommend
[28:02.200 --> 28:08.120]  checking those out. I know I will be. That's awesome. And I think that at least the vast
[28:08.120 --> 28:12.220]  majority of our village talks are also being recorded and put on YouTube. I don't know
[28:12.220 --> 28:17.600]  if that village is. It's an opt-in, opt-out kind of thing. So it's up to everyone.
[28:18.240 --> 28:22.620]  But it may already be available on YouTube. The one yesterday may already be available on YouTube
[28:22.620 --> 28:30.760]  for people if they want to go watch it as well. Okay. Well, thank you very much for joining us
[28:30.760 --> 28:36.820]  for this QA session. Thank you for making such great content for DEF CON. Thank you for being
[28:36.820 --> 28:42.200]  part of our virtual experience. Thanks. It was great. Great talking to you all.
[28:42.200 --> 28:43.840]  All right.