Whispers Among the Stars
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Pavur, James
Space is changing. The number of satellites in orbit will increase from around 2,000 today to more than 15,000 by 2030. This briefing provides a practical look at the considerations an attacker may take when targeting satellite broadband communications networks. Using $300 of widely available home television equipment I show that it is possible to intercept deeply sensitive data transmitted on satellite links by some of the world's largest organizations. The talk follows a series of case studies looking at satellite communications affecting three domains: air, land, and sea. From home satellite broadband customers, to wind farms, to oil tankers and aircraft, I show how satellite eavesdroppers can threaten privacy and communications security. Beyond eavesdropping, I also discuss how, under certain conditions, this inexpensive hardware can be used to hijack active sessions over the satellite link. The talk concludes by presenting new open source tools we have developed to help researchers seeking to improve satellite communications security and individual satellite customers looking to encrypt their traffic. The talk assumes no background in satellite communications or cryptography but will be most interesting to researchers interested in tackling further unsolved security challenges in outer space.
 It's August 2018. A CIS admin 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 learned that this ship will be out of commission for at least a month, and I learned the name and passport number of the engineer who's flying away to fix it. 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 Pervort, 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 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 in a perspective, that means we were able to receive signals from as far away as parts of the United States and the Caribbean, China, and India, a massive coverage area for an attacker. And in all 18 of these feeds, we identified deeply sensitive internet traffic, whether it was being transmitted using those protocols that had issues we've known about since 2005, or using newer protocols that have replaced it. And it wasn't just any data, it was some pretty interesting traffic. We saw sensitive information from nine members of the Fortune Global 500 that we're able to identify, traffic belonging to passengers on six of the 10 largest airlines in the world by passenger count, traffic belonging to maritime companies who together make up 40% of the world's cargo shipping capacity by volume, and traffic belonging to government agencies ranging from the postal service of an Eastern European nation to an actual Air Force jet belonging to a North African country. We even saw traffic from regular people like you, people who like Brio's Wi-Fi in a coffee shop, or update their Instagram while they're on a cruise. Now before I delve into kind of the meat of this traffic, how we got at it and what it has inside, I want to kind of be sure we're all starting at the same point and give you a bit of a crash course in satellite communications. So I'm going to run through a very simple scenario here to kind of explain what satellite communications look like in practice. So here's our satellite. It's in geostationary orbit, which means it's 30,000 kilometers above the Earth's surface. We have a customer in the Atlantic Ocean who wants to talk to this satellite. And to do this, they want to visit a website over the satellite feed that's hosted over here in Ireland. We'll say it's google.com and they have a device on their boat that's called a VSAT terminal or a very small aperture terminal, which is what they'll use for this connection. And that device was sold to them by an internet service provider who runs a ground station here in Madrid. We'll also imagine an attacker who's quite far away from this conversation down here in a craw, but still wants to intercept the communications. So how does this play out? Well, because our satellite's in geostationary orbit, it doesn't move around. So our customer just needs to point their satellite dish to the sky and say, 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 and across head. They can't intercept this communication. Once we get to Madrid, the satellite internet service provider will convert this weird satellite protocol into normal IP traffic and route it to Google, just like if you were visiting a web page at home, terrestrially. It'll get the response over the terrestrial internet and then beam it back up into space. It's worth noting that when I say beam up into space, this isn't a fast process. The round trip time for a conversation like this can be as long as 700 milliseconds because the speed of light is only so fast and geostationary orbit, which is the kind of satellite we're looking at, is very far away. Once we finally make it out there, though, there's one last step, which is to beam 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 it hit the customers. This is the crux of satellite eavesdropping. An attacker can reliably expect to intercept a signal from very far away on these forward links, but they can't always be guaranteed to see both sides of the conversation, which is somewhat unusual for an eavesdropper. Additionally, we can kind of think about the security properties in this context because if we were 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 could 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 little bit of money. There are companies out there that sell specialized modems for intelligence collection purposes, like this one, and you hook them up to a multimillion dollar ground station, like this one, and you're off to the races just listening to whatever satellite signals you want. And it's a pretty reasonable assumption to say that national intelligence services are doing this. However, they don't really give this equipment to PhD students. So I had to find a different way to get this information, and that prior research that talked about using television signals is kind of what led our next step. So we tried to see how far we could get using simple home television equipment that's widely available. We picked up this nifty flat panel satellite dish, which costs 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 dollars. You could use a much cheaper card, 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 our 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 car 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've 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 then we'll take a look at the file and see if we have any indicators that it has internet traffic instead of television traffic. There's no trick here to differentiating between the two types. All I'm going to do is just kind of grep through that binary file for the string HTTP, which we would expect to see in an internet recording, but we wouldn't expect to see in a television feed. And sure enough, we see here what looks like the output of a SOAP API. At this point, this is the security vulnerability, right? We're seeing clear text information from someone else's internet signal using freely available tools and commercial off-the-shelf equipment, and that's pretty bad, 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 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 that 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, mirror time customers are aviation customers. But these customers also had much better equipment than we do. They would spend tens to hundreds of thousands of dollars on signal processing hardware, whereas we're using like 200 bucks of a PCIe card. And so when we were trying to receive these signals, we were often missing fragments of IP packets and had super corrupted feeds, which meant that existing tools weren't able to parse these signals for us. We didn't get much help in that regard. So what we did instead is build our own tool called GSE extract. And the goal of GSE extract is to forensically reconstruct PCAP files from corrupted recordings of GSE feeds. And it does this by taking some shortcuts. If we were designing a satellite modem, we would have to consider all of the edge cases and how a network operates or how a packet gets sent. But for GSE extract, we can say generally we would expect the start of an IP packet to appear here, or we'd expect this fragment to belong to this payload. And by making some of those assumptions, GSE extract is able to help us figure out what to do with between 50 and 70% of the frames that are hitting our dish. This is significantly better than existing tool, which we're just throwing error message because the feed is so corrected. Hopefully by the time that you're watching this recording, GSE extract will be available on my research groups GitHub. It may take a little bit longer because we're still kind of doing some responsible disclosure review process stuff, but it should eventually end up there. In the interim, if you want to delve into how it works a little bit deeper, it's described in pretty high detail in a related academic paper that we published a few months ago in the appendix of that paper. So this is kind of what you get at the end of the day by using GSE extract. This is a JPEG file that we intercepted from an engineer aboard a maritime vessel who was dealing with a maintenance issue and sending pictures to his colleagues. You'll see that we're able to get like the start of the packet. We're able to kind of figure out, you know, this is a JPEG file. We knew what port it was going to. We kind of knew the nature of the communications, but at some point we start losing fragments and then in the case of like a compressed file like this, we aren't able to get everything. That said, the first chunk of an IP Paleo often has the most interesting bits. It may be the entire packet or 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 a hundred percent recovery and allows someone to get away with $200 or $300 of home television equipment and do harm that they would otherwise need tens of thousands of dollars to play with in these networks. All right. So at this point, we're in a good spot. We have a satellite dish that we can use to talk to signals. We know that if those signals are in the digital video broadcasting for satellite format, which is very common from geostationary orbit, we can parse that using that PCIe card on our computer. Depending on the contents of those streams, we can use existing tools like DVB Snoop or Wire Shark or tools we've written ourselves like GSE Extract to get meaningful PCAP data out of it and understand the internet traffic inside. The next step is really to understand the impact of what we've found. How does this affect modern users of terrestrial satellite communications, maritime and aviation communication links? So across all three of these domains, there are a couple of general things we found that are worth highlighting. The first is that none of the ISPs we looked at appear to employ encryption by default. That is to say that like individual customers might choose to encrypt their traffic, but the satellite ISP was sending over the satellite feed traffic in essentially the same format that it was coming into the modem. What this means is that as an attacker, we had an ISP level vantage point on the traffic that was coming to a customer. We saw every website they visited, every bit torrent they downloaded, every connection they made would pass over that satellite link and we would get it. But when we looked at the enterprise customers, this got even more interesting because a lot of these enterprise networks operate basically as a LAN environment across the satellite feed. A good example is a cruise line we were looking at that had Windows machines on all of their ships and the internal like Windows LDAP traffic from that network that Windows local area environment was being broadcast across the satellite feed. Getting to see like Windows to Windows corporate LAN communications as a wireless eavesdropper is really unusual and we thought it was a particularly interesting angle because it got us behind the firewall of a lot of these big corporations networks. So the first environment I want to talk about the first domain is terrestrial customers and these were really interesting to us because they're real people. They're kind of your home internet users and they care about privacy. Now I know what you might be saying. You might say, wait a second, my browser has this lock icon on it, which says that my traffic is encrypted. What couldn't eavesdropper do to cause harm to me? And I would say to you convenient made up straw man that there's actually a lot that an attacker can do to mess with your communications in this context. So even though we can't see exactly the content of your communications, we get to see your DNS queries for example, which is essentially every website you're visiting and we can use that to piece together your browsing history. Additionally, those TLS certificates that you think are protecting your traffic or protecting the contents of that traffic, but they're fingerprinting the websites you're visiting, which allowed us to determine like which networks devices belong to or generally where users were going. Now, this is a mild privacy concern. You don't want an entire continent to hear your browsing history, but it gets worse when you slip up. One of the most illustrative examples of this comes from a lawyer whose emails we intercepted across this feed. So this lawyer in Spain was communicating with one of his clients about an upcoming court case. He was a defense attorney and we intercepted the emails that were going to his inbox because he was using pop three to download them over the satellite link. And so this is obviously bad news 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 and someone is just eavesdropping in a single connection to an insecure service. So the other thing we were curious about were kind of IoT systems because these didn't really exist when people were looking at these fields 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. I blacked out all of the sensitive information, but like clearly this is a clear text admin username and credential that could probably change some settings on that router. 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. 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. These control panels are publicly routable over the open internet. 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. Obviously, we didn't engage in any attacks on the electrical grid system, so there could be another protection when you log in on some sort of second factor control, but I think it's intuitively concerning that this stuff is getting sent in clear text. 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. We had these terabytes and terabytes of traffic from all kinds of different companies and all kinds of different ships. 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. 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, then. We used to de-anonymize 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. 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. It's operating within the same IP address space as that random fishing crew. Beyond being able to identify 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. We were able to identify from the traffic inside those PCAP files that there was a device onboard the ship running a vulnerable version of Windows Server 2003 that had all kinds of CVEs that could be deployed against it. At this point, if we wanted to attack that ship, we could potentially deploy CVEs not just against that one, but against any ship in this petroleum company's fleet and potentially cause some serious harm. Another piece of operational technology we were curious about was something called electronic chart display and information systems or ECTIS. ECTIS are essentially GPS NAV terminals for boats. They tell boats where they can go safely or legally. They have various hazard updates for mariners. 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? 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 onboard. The way that we get their chart updates is someone on land in the back office would copy the latest chart files into a folder called chart delivery on the FTP server and then it would get deployed to the ECTIS terminal. Because this FTP server is accessible over the internet, anyone with an internet connection can connect to it. The password is getting sent in clear text over the satellite fee because they didn't use SFTP. 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. Generally, there's an email address like chartupdates underscore shipname at shipcompany.org which will get updates every so often as attachments to the inbox. The captain will copy those files onto a flash drive, walk over to the ECTIS 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 loon check, but it could have been coincidental. At the very least, anything that tells you how much someone paid for a soda, what their name was and when they did it, is pretty deeply concerning that it's being broadcast across an entire continent in clear text. Another example of sensitive information from like real people on cruise ships or on vessels would be when ports have cargo vessels come in, they often require the crew to share some visa information. And this particular port authority thought that a great way to do that would be an insecure HTTP web service. And so as a result, we could see from the cargo vessels pulling into this port, all of the names and passport numbers and date of birth of the crew members aboard these ships. Obviously, this is deeply sensitive information that should have been encrypted. All right, let's head out to the skies. So the aviation use case is really interesting to me because it's the newest one. We were 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. And we had a lot of 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 Sanamarda does research in the satellite modems. He's definitely presented at Black Hat and Def Con and stuff, doing a lot of like hardware reverse engineering. And he has this blog post where he looks at 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 a information terminal like an ECTIS terminal, but for airplanes, it includes navigational information and weather updates and all kinds of stuff that the pilot needs to manage the flight. And this specific Chinese airline had made a mistake in configuring their EFB such that it wasn't logging in correctly, someone had like fat finger to password or something. And so all of the requests it was sending were getting balanced off of this redirect page from the satellite modem and reaching us. And we could use that to not only fingerprint like how this API works and what sort of data is being sent from the airplane and where the airplane was at any time, but we could also identify other vessels that were using this same device. And even though it seems to be encrypted over the air in most cases, we're able to confirm that the network that's carrying this operational technology traffic is the same one as the person 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 LT or whatever, which has some security guarantees over the air. But the back end was being rather unencrypted in these kind of SCTP wrappers that over the satellite signal. And so we're able to see 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 receive during your flight will show up in our packet captures. You're not even aware you're connected to a satellite network. And to kind of bring home the severity, here's a good example. There's this person who was on a flight, and in the middle of their flight they got their negative coronavirus test result. Now that's a huge relief for anyone who's sitting next to one airplane, right? But for the rest of us who care about health data privacy, it's a huge information breach that this is being sent in clear text across the continent. We saw all kinds of wild text messages. I remember listening to some guy who spoke Croatian in his text messages talking about a wild dream he had, whereas like friends' mom showed up in a burning house or something. Just real people's personal communications are being sent in clear text. And it's not just personal communications. If you've ever used like SMS as a second factor for account login, it's very clear how this could be deployed in 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 APT group called Turla Group, would be to use satellites for untraceable data exfiltration. And there are only two requirements for this to play out. First, you have to compromise a device that you want to steal data from. And it needs to be connected to a network that has a route to a satellite IP address. Generally, the internet is sufficient because there are a lot of satellite devices that have internet-routable IP addresses. But it could also be a device inside someone's LAN environment. Additionally, as an attacker, you need to be able to be inside that satellite signal's forward link footprint. You need to be able to eavesdrop on the traffic. And that's it. Let's see how this plays out. So an attacker who's compromised the device has a problem. They want to send the sensitive data they've stolen to their server somewhere on the internet. The problem is that if they decide to just route this along the internet, 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 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 networks out there that do, the attacker might still be able to use even just like the size of packets or the contents of packets or the existence of packets as a signal that's virtually untraceable because they are somewhere in this massive continent-sized footprint and that's all law enforcement could possibly know. Another attack that we tried to pull off is something called TCP session hijacking, which is a very classic kind of networking attack. Essentially, TCP has this three-way handshake to set up connections where you have to know these randomly selected sequence numbers to prove you are who you say you are. And what we found is that in certain satellite environments, you could actually impersonate one of these endpoints very reliably due to the physical characteristics of orbit and hijack arbitrary TCP session numbers. We did this against our own connection to one device and one specific satellite network, but we didn't test it at a very broad scale because we didn't want to mess with anything important. Let me give you a show of how this kind of works from a physical perspective. 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 in the cargo vessel with status information. So what they'll do is they'll send a TCP SIN number as a start of a TCP three-way handshake and this has a sequence number that you have to know to prove that you received the start of the handshake and that you're party to this conversation. This is like a very fundamental protection against spoofing attacks. However, our attacker can easily get the sequence number over the unencrypted satellite link and at the next step, our attacker, remember how I said they were in Accra in Ghana? So Accra happens to have some of the fastest terrestrial internet in Africa and a direct backbone link to the UK, although that doesn't necessarily matter. But because the speed of light is only so fast, the attacker 100% of the time can beat the legitimate acknowledgement message from that handshake to our maritime office in Ireland. And at this point, the maritime office will start a conversation thinking they're talking to the vessel when they're actually sending information to our attacker. Our attacker can continue to eavesdrop over the satellite link and that message with their spoofed acknowledgement will reach the ship at sea who will simply ignore it because that is incorrect sequence numbers, but our attacker at this point has free reign to send whatever information they want to the maritime office and impersonate the ship in a way that's virtually undetectable if you're not employing some sort of certificate signing scheme. So this is like a very simple example that shows that even though we can't transmit directly in the satellite network, we're fundamentally part of a broader network, which is the internet and in that environment, active attacks are definitely possible. So obviously this research has some ethical implications. It's a real world networks and real people. So we're very careful to adhere to the laws and go above and beyond that. You might be a little disappointed today that I haven't named and shamed any companies. That's a conscious choice because I don't want this to be about X airline is leaking your data. I want the focus to be on the fact that this is a systemic issue that affects a lot thousands, tens of thousands of satellite customers around the world. We've of course engaged in responsible disclosure. Many of the satellite companies have known about this as early as 2019, as well as some of their customers who have leaked particularly interesting data or particularly large. Most people are 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 we responsibly disclosed to you with the request that they keep it private and our academic peer reviewers. Yet somehow the FBI was able to cite specific information from a chart inside that paper. Now as a researcher, this is a little bit unsettling how did the FBI get my paper before I gave it to anyone, but if you're ever wondering, maybe you should join one of these threat intelligence schemes, it's clear that the FBI does a good job at getting a scoop ahead of 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 VPN, these performance enhancing proxies can't find those TCP through your handshakes and so they can't accelerate the connection. So in the short term, you might have to accept that as reality and just say, you know what, passport numbers are sensitive enough that we should send them encrypted or not send them at all. And in many cases, if you're using like a TCP layer encryption protocol or a UDP encryption protocol, it doesn't affect performance at all. You should never be using pop for your emails, although we found thousands of 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 the sequence numbers over the air from what they are on the ground, they can prevent TCP hijacking attacks. A lot of ISPs seem to do this already, although I think it's largely accidental. In the longer term, though, we're trying to work on a solution that makes it easier for individual customers to be sure their data is always encrypted regardless of what protocol mistakes they might make. We're building a tool called QPEP, which uses the quick protocol, which is a TCP replacement that is encrypted by default. And it's kind of a combination between like a tunneling VPN and a performance enhancing proxy. If you want to take a look at QPEP, there is a public GitHub repository for it. This isn't like a commercial product. The goal is to kind of build a tool for people to start playing around with securing these networks. It's designed to be much more accessible than existing PEPs, which tend to be written in this really obtuse like C libraries for networking. It's written in Python as a testbed, so you can simulate it without a satellite equipment at all, and then most of the networking 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 who were responsible disclosed to you 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 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. Something a different country or on a different continent from you can be listening to your internet communications. And yet many people act like this isn't the case. Whether it's a massive Fortune 500 company or a random person in a coffee shop somewhere, people are leaking deeply sensitive traffic over satellite feeds as if they don't know that an eavesdropper could be listening. We think this can be changed. We think the underlying reason that this is still a problem is that performance encryption is something that ISPs have to build into their satellite networks instead of something that individuals can just run for themselves when they connect to a satellite terminal. And we think that we can balance out that trade off and bring security to customers regardless of how they interface with the 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 top is unknown. When you connect to the internet, there's a whole web of different nodes and connections that's constantly changing that's routing your traffic. And any one of those nodes could be a satellite link or a wireless tower or a wire tapped internet cable. And so if we 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 they could have the best encryption in the world. But if the next hop is a satellite link, that does us no good. So having the ability to encrypt your own traffic, having the right to encrypt your own traffic and having the knowledge to make that encryption as secure and robust as possible is, I think, critical to preventing this whole class of attack, regardless of the domain we consider it in. Thank you so much for listening to my presentation. I'm happy to answer any questions via email or in a breakout session after this. And I hope you enjoyed the talk.
 It's August 2018.  A CIS admin 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 learned that this ship will be out  of commission for at least a month, and I learned the name and passport number of the  engineer who's flying away to fix it.  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 Pervort, 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 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 in a perspective, that means we were able to receive signals from as far away  as parts of the United States and the Caribbean, China, and India, a massive coverage area  for an attacker.  And in all 18 of these feeds, we identified deeply sensitive internet traffic, whether  it was being transmitted using those protocols that had issues we've known about since 2005,  or using newer protocols that have replaced it.  And it wasn't just any data, it was some pretty interesting traffic.  We saw sensitive information from nine members of the Fortune Global 500 that we're able  to identify, traffic belonging to passengers on six of the 10 largest airlines in the world  by passenger count, traffic belonging to maritime companies who together make up 40% of the  world's cargo shipping capacity by volume, and traffic belonging to government agencies  ranging from the postal service of an Eastern European nation to an actual Air Force jet  belonging to a North African country.  We even saw traffic from regular people like you, people who like Brio's Wi-Fi in a coffee  shop, or update their Instagram while they're on a cruise.  Now before I delve into kind of the meat of this traffic, how we got at it and what it  has inside, I want to kind of be sure we're all starting at the same point and give you  a bit of a crash course in satellite communications.  So I'm going to run through a very simple scenario here to kind of explain what satellite  communications look like in practice.  So here's our satellite.  It's in geostationary orbit, which means it's 30,000 kilometers above the Earth's surface.  We have a customer in the Atlantic Ocean who wants to talk to this satellite.  And to do this, they want to visit a website over the satellite feed that's hosted over  here in Ireland.  We'll say it's google.com and they have a device on their boat that's called a VSAT  terminal or a very small aperture terminal, which is what they'll use for this connection.  And that device was sold to them by an internet service provider who runs a ground station  here in Madrid.  We'll also imagine an attacker who's quite far away from this conversation down here  in a craw, but still wants to intercept the communications.  So how does this play out?  Well, because our satellite's in geostationary orbit, it doesn't move around.  So our customer just needs to point their satellite dish to the sky and say, 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 and across head.  They can't intercept this communication.  Once we get to Madrid, the satellite internet service provider will convert this weird satellite  protocol into normal IP traffic and route it to Google, just like if you were visiting  a web page at home, terrestrially.  It'll get the response over the terrestrial internet and then beam it back up into space.  It's worth noting that when I say beam up into space, this isn't a fast process.  The round trip time for a conversation like this can be as long as 700 milliseconds because  the speed of light is only so fast and geostationary orbit, which is the kind of satellite we're  looking at, is very far away.  Once we finally make it out there, though, there's one last step, which is to beam 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 it hit the customers.  This is the crux of satellite eavesdropping.  An attacker can reliably expect to intercept a signal from very far away on these forward  links, but they can't always be guaranteed to see both sides of the conversation, which  is somewhat unusual for an eavesdropper.  Additionally, we can kind of think about the security properties in this context because  if we were 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  could 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 little bit of money.  There are companies out there that sell specialized modems for intelligence collection purposes,  like this one, and you hook them up to a multimillion dollar ground station, like this one, and  you're off to the races just listening to whatever satellite signals you want.  And it's a pretty reasonable assumption to say that national intelligence services are  doing this.  However, they don't really give this equipment to PhD students.  So I had to find a different way to get this information, and that prior research that talked  about using television signals is kind of what led our next step.  So we tried to see how far we could get using simple home television equipment that's widely  available.  We picked up this nifty flat panel satellite dish, which costs 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 dollars.  You could use a much cheaper card, 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 our 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 car 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've 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 then we'll take a look  at the file and see if we have any indicators that it has internet traffic instead of television  traffic.  There's no trick here to differentiating between the two types.  All I'm going to do is just kind of grep through that binary file for the string HTTP, which  we would expect to see in an internet recording, but we wouldn't expect to see in a television  feed.  And sure enough, we see here what looks like the output of a SOAP API.  At this point, this is the security vulnerability, right?  We're seeing clear text information from someone else's internet signal using freely available  tools and commercial off-the-shelf equipment, and that's pretty bad, 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 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 that  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, mirror time  customers are aviation customers.  But these customers also had much better equipment than we do.  They would spend tens to hundreds of thousands of dollars on signal processing hardware,  whereas we're using like 200 bucks of a PCIe card.  And so when we were trying to receive these signals, we were often missing fragments of  IP packets and had super corrupted feeds, which meant that existing tools weren't able  to parse these signals for us.  We didn't get much help in that regard.  So what we did instead is build our own tool called GSE extract.  And the goal of GSE extract is to forensically reconstruct PCAP files from corrupted recordings  of GSE feeds.  And it does this by taking some shortcuts.  If we were designing a satellite modem, we would have to consider all of the edge cases  and how a network operates or how a packet gets sent.  But for GSE extract, we can say generally we would expect the start of an IP packet to  appear here, or we'd expect this fragment to belong to this payload.  And by making some of those assumptions, GSE extract is able to help us figure out what  to do with between 50 and 70% of the frames that are hitting our dish.  This is significantly better than existing tool, which we're just throwing error message  because the feed is so corrected.  Hopefully by the time that you're watching this recording, GSE extract will be available  on my research groups GitHub.  It may take a little bit longer because we're still kind of doing some responsible disclosure  review process stuff, but it should eventually end up there.  In the interim, if you want to delve into how it works a little bit deeper, it's described  in pretty high detail in a related academic paper that we published a few months ago in  the appendix of that paper.  So this is kind of what you get at the end of the day by using GSE extract.  This is a JPEG file that we intercepted from an engineer aboard a maritime vessel who was  dealing with a maintenance issue and sending pictures to his colleagues.  You'll see that we're able to get like the start of the packet.  We're able to kind of figure out, you know, this is a JPEG file.  We knew what port it was going to.  We kind of knew the nature of the communications, but at some point we start losing fragments  and then in the case of like a compressed file like this, we aren't able to get everything.  That said, the first chunk of an IP Paleo often has the most interesting bits.  It may be the entire packet or 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 a hundred percent  recovery and allows someone to get away with $200 or $300 of home television equipment  and do harm that they would otherwise need tens of thousands of dollars to play with  in these networks.  All right.  So at this point, we're in a good spot.  We have a satellite dish that we can use to talk to signals.  We know that if those signals are in the digital video broadcasting for satellite format, which  is very common from geostationary orbit, we can parse that using that PCIe card on our  computer.  Depending on the contents of those streams, we can use existing tools like DVB Snoop or  Wire Shark or tools we've written ourselves like GSE Extract to get meaningful PCAP data  out of it and understand the internet traffic inside.  The next step is really to understand the impact of what we've found.  How does this affect modern users of terrestrial satellite communications, maritime and aviation  communication links?  So across all three of these domains, there are a couple of general things we found that  are worth highlighting.  The first is that none of the ISPs we looked at appear to employ encryption by default.  That is to say that like individual customers might choose to encrypt their traffic, but  the satellite ISP was sending over the satellite feed traffic in essentially the same format  that it was coming into the modem.  What this means is that as an attacker, we had an ISP level vantage point on the traffic  that was coming to a customer.  We saw every website they visited, every bit torrent they downloaded, every connection  they made would pass over that satellite link and we would get it.  But when we looked at the enterprise customers, this got even more interesting because a lot  of these enterprise networks operate basically as a LAN environment across the satellite feed.  A good example is a cruise line we were looking at that had Windows machines on all of their  ships and the internal like Windows LDAP traffic from that network that Windows local area  environment was being broadcast across the satellite feed.  Getting to see like Windows to Windows corporate LAN communications as a wireless eavesdropper  is really unusual and we thought it was a particularly interesting angle because it  got us behind the firewall of a lot of these big corporations networks.  So the first environment I want to talk about the first domain is terrestrial customers  and these were really interesting to us because they're real people.  They're kind of your home internet users and they care about privacy.  Now I know what you might be saying.  You might say, wait a second, my browser has this lock icon on it, which says that my traffic  is encrypted.  What couldn't eavesdropper do to cause harm to me?  And I would say to you convenient made up straw man that there's actually a lot that  an attacker can do to mess with your communications in this context.  So even though we can't see exactly the content of your communications, we get to see your  DNS queries for example, which is essentially every website you're visiting and we can use  that to piece together your browsing history.  Additionally, those TLS certificates that you think are protecting your traffic or protecting  the contents of that traffic, but they're fingerprinting the websites you're visiting,  which allowed us to determine like which networks devices belong to or generally where users  were going.  Now, this is a mild privacy concern.  You don't want an entire continent to hear your browsing history, but it gets worse when  you slip up.  One of the most illustrative examples of this comes from a lawyer whose emails we intercepted  across this feed.  So this lawyer in Spain was communicating with one of his clients about an upcoming court  case.  He was a defense attorney and we intercepted the emails that were going to his inbox because  he was using pop three to download them over the satellite link.  And so this is obviously bad news 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  and someone is just eavesdropping in a single connection to an insecure service.  So the other thing we were curious about were kind of IoT systems because these didn't  really exist when people were looking at these fields 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.  I blacked out all of the sensitive information, but like clearly this is a clear text admin  username and credential that could probably change some settings on that router.  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.  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.  These control panels are publicly routable over the open internet.  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.  Obviously, we didn't engage in any attacks on the electrical grid system, so there could  be another protection when you log in on some sort of second factor control, but I think  it's intuitively concerning that this stuff is getting sent in clear text.  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.  We had these terabytes and terabytes of traffic from all kinds of different companies and  all kinds of different ships.  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.  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, then.  We used to de-anonymize 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.  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.  It's operating within the same IP address space as that random fishing crew.  Beyond being able to identify 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.  We were able to identify from the traffic inside those PCAP files that there was a device  onboard the ship running a vulnerable version of Windows Server 2003 that had all kinds of  CVEs that could be deployed against it.  At this point, if we wanted to attack that ship, we could potentially deploy CVEs not  just against that one, but against any ship in this petroleum company's fleet and potentially  cause some serious harm.  Another piece of operational technology we were curious about was something called electronic  chart display and information systems or ECTIS.  ECTIS are essentially GPS NAV terminals for boats.  They tell boats where they can go safely or legally.  They have various hazard updates for mariners.  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?  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 onboard.  The way that we get their chart updates is someone on land in the back office would copy  the latest chart files into a folder called chart delivery on the FTP server and then  it would get deployed to the ECTIS terminal.  Because this FTP server is accessible over the internet, anyone with an internet connection  can connect to it.  The password is getting sent in clear text over the satellite fee because they didn't  use SFTP.  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.  Generally, there's an email address like chartupdates underscore shipname at shipcompany.org  which will get updates every so often as attachments to the inbox.  The captain will copy those files onto a flash drive, walk over to the ECTIS 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 loon check, but it could have been coincidental.  At the very least, anything that tells you how much someone paid for a soda, what their  name was and when they did it, is pretty deeply concerning that it's being broadcast across  an entire continent in clear text.  Another example of sensitive information from like real people on cruise ships or on  vessels would be when ports have cargo vessels come in, they often require the crew to share  some visa information.  And this particular port authority thought that a great way to do that would be an insecure  HTTP web service.  And so as a result, we could see from the cargo vessels pulling into this port, all  of the names and passport numbers and date of birth of the crew members aboard these  ships.  Obviously, this is deeply sensitive information that should have been encrypted.  All right, let's head out to the skies.  So the aviation use case is really interesting to me because it's the newest one.  We were 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.  And we had a lot of 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 Sanamarda does research in the satellite modems.  He's definitely presented at Black Hat and Def Con and stuff, doing a lot of like hardware  reverse engineering.  And he has this blog post where he looks at 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 a information terminal like an ECTIS terminal, but for airplanes, it  includes navigational information and weather updates and all kinds of stuff that the pilot  needs to manage the flight.  And this specific Chinese airline had made a mistake in configuring their EFB such that  it wasn't logging in correctly, someone had like fat finger to password or something.  And so all of the requests it was sending were getting balanced off of this redirect  page from the satellite modem and reaching us.  And we could use that to not only fingerprint like how this API works and what sort of data  is being sent from the airplane and where the airplane was at any time, but we could  also identify other vessels that were using this same device.  And even though it seems to be encrypted over the air in most cases, we're able to confirm  that the network that's carrying this operational technology traffic is the same one as the  person 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 LT or whatever, which has some security guarantees over the air.  But the back end was being rather unencrypted in these kind of SCTP wrappers that over the  satellite signal.  And so we're able to see 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 receive during your flight will show up in our packet captures.  You're not even aware you're connected to a satellite network.  And to kind of bring home the severity, here's a good example.  There's this person who was on a flight, and in the middle of their flight they got their  negative coronavirus test result.  Now that's a huge relief for anyone who's sitting next to one airplane, right?  But for the rest of us who care about health data privacy, it's a huge information breach  that this is being sent in clear text across the continent.  We saw all kinds of wild text messages.  I remember listening to some guy who spoke Croatian in his text messages talking about  a wild dream he had, whereas like friends' mom showed up in a burning house or something.  Just real people's personal communications are being sent in clear text.  And it's not just personal communications.  If you've ever used like SMS as a second factor for account login, it's very clear how this  could be deployed in 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 APT group called Turla Group, would be to use satellites for untraceable  data exfiltration.  And there are only two requirements for this to play out.  First, you have to compromise a device that you want to steal data from.  And it needs to be connected to a network that has a route to a satellite IP address.  Generally, the internet is sufficient because there are a lot of satellite devices that  have internet-routable IP addresses.  But it could also be a device inside someone's LAN environment.  Additionally, as an attacker, you need to be able to be inside that satellite signal's  forward link footprint.  You need to be able to eavesdrop on the traffic.  And that's it.  Let's see how this plays out.  So an attacker who's compromised the device has a problem.  They want to send the sensitive data they've stolen to their server somewhere on the internet.  The problem is that if they decide to just route this along the internet, 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 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 networks  out there that do, the attacker might still be able to use even just like the size of  packets or the contents of packets or the existence of packets as a signal that's virtually  untraceable because they are somewhere in this massive continent-sized footprint and  that's all law enforcement could possibly know.  Another attack that we tried to pull off is something called TCP session hijacking, which  is a very classic kind of networking attack.  Essentially, TCP has this three-way handshake to set up connections where you have to know  these randomly selected sequence numbers to prove you are who you say you are.  And what we found is that in certain satellite environments, you could actually impersonate  one of these endpoints very reliably due to the physical characteristics of orbit and  hijack arbitrary TCP session numbers.  We did this against our own connection to one device and one specific satellite network,  but we didn't test it at a very broad scale because we didn't want to mess with anything  important.  Let me give you a show of how this kind of works from a physical perspective.  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 in the cargo vessel with status information.  So what they'll do is they'll send a TCP SIN number as a start of a TCP three-way handshake  and this has a sequence number that you have to know to prove that you received the start  of the handshake and that you're party to this conversation.  This is like a very fundamental protection against spoofing attacks.  However, our attacker can easily get the sequence number over the unencrypted satellite link  and at the next step, our attacker, remember how I said they were in Accra in Ghana?  So Accra happens to have some of the fastest terrestrial internet in Africa and a direct  backbone link to the UK, although that doesn't necessarily matter.  But because the speed of light is only so fast, the attacker 100% of the time can beat  the legitimate acknowledgement message from that handshake to our maritime office in Ireland.  And at this point, the maritime office will start a conversation thinking they're talking  to the vessel when they're actually sending information to our attacker.  Our attacker can continue to eavesdrop over the satellite link and that message with their  spoofed acknowledgement will reach the ship at sea who will simply ignore it because that  is incorrect sequence numbers, but our attacker at this point has free reign to send whatever  information they want to the maritime office and impersonate the ship in a way that's virtually  undetectable if you're not employing some sort of certificate signing scheme.  So this is like a very simple example that shows that even though we can't transmit directly  in the satellite network, we're fundamentally part of a broader network, which is the internet  and in that environment, active attacks are definitely possible.  So obviously this research has some ethical implications.  It's a real world networks and real people.  So we're very careful to adhere to the laws and go above and beyond that.  You might be a little disappointed today that I haven't named and shamed any companies.  That's a conscious choice because I don't want this to be about X airline is leaking  your data.  I want the focus to be on the fact that this is a systemic issue that affects a lot thousands,  tens of thousands of satellite customers around the world.  We've of course engaged in responsible disclosure.  Many of the satellite companies have known about this as early as 2019, as well as some  of their customers who have leaked particularly interesting data or particularly large.  Most people are 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 we responsibly disclosed to you  with the request that they keep it private and our academic peer reviewers.  Yet somehow the FBI was able to cite specific information from a chart inside that paper.  Now as a researcher, this is a little bit unsettling how did the FBI get my paper before  I gave it to anyone, but if you're ever wondering, maybe you should join one of these threat intelligence  schemes, it's clear that the FBI does a good job at getting a scoop ahead of 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 VPN, these performance  enhancing proxies can't find those TCP through your handshakes and so they can't accelerate  the connection.  So in the short term, you might have to accept that as reality and just say, you know what,  passport numbers are sensitive enough that we should send them encrypted or not send  them at all.  And in many cases, if you're using like a TCP layer encryption protocol or a UDP encryption  protocol, it doesn't affect performance at all.  You should never be using pop for your emails, although we found thousands of 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 the sequence numbers over the air from what they are on the ground,  they can prevent TCP hijacking attacks.  A lot of ISPs seem to do this already, although I think it's largely accidental.  In the longer term, though, we're trying to work on a solution that makes it easier for  individual customers to be sure their data is always encrypted regardless of what protocol  mistakes they might make.  We're building a tool called QPEP, which uses the quick protocol, which is a TCP replacement  that is encrypted by default.  And it's kind of a combination between like a tunneling VPN and a performance enhancing  proxy.  If you want to take a look at QPEP, there is a public GitHub repository for it.  This isn't like a commercial product.  The goal is to kind of build a tool for people to start playing around with securing these  networks.  It's designed to be much more accessible than existing PEPs, which tend to be written in  this really obtuse like C libraries for networking.  It's written in Python as a testbed, so you can simulate it without a satellite equipment  at all, and then most of the networking 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 who were responsible disclosed to you 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 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.  Something a different country or on a different continent from you can be listening to your  internet communications.  And yet many people act like this isn't the case.  Whether it's a massive Fortune 500 company or a random person in a coffee shop somewhere,  people are leaking deeply sensitive traffic over satellite feeds as if they don't know  that an eavesdropper could be listening.  We think this can be changed.  We think the underlying reason that this is still a problem is that performance encryption  is something that ISPs have to build into their satellite networks instead of something  that individuals can just run for themselves when they connect to a satellite terminal.  And we think that we can balance out that trade off and bring security to customers  regardless of how they interface with the 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 top is unknown.  When you connect to the internet, there's a whole web of different nodes and connections  that's constantly changing that's routing your traffic.  And any one of those nodes could be a satellite link or a wireless tower or a wire tapped  internet cable.  And so if we 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 they could have the best  encryption in the world.  But if the next hop is a satellite link, that does us no good.  So having the ability to encrypt your own traffic, having the right to encrypt your  own traffic and having the knowledge to make that encryption as secure and robust as possible  is, I think, critical to preventing this whole class of attack, regardless of the domain  we consider it in.  Thank you so much for listening to my presentation.  I'm happy to answer any questions via email or in a breakout session after this.  And I hope you enjoyed the talk.
DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_0_455.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_456_2123.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_2124_2819.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_2820_3815.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_3816_4199.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_4200_4991.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_4992_5435.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_5436_6299.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_6300_6431.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_6432_6479.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_6480_7763.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_7764_8603.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_8604_8771.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_8772_10799.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_10800_10979.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_10980_11987.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_11988_13199.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_13200_13247.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_13248_13379.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_13380_14555.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_14556_15251.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_15252_16067.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_16068_16895.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_16896_17255.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_17256_18971.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_18972_20351.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_20352_22127.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_22128_23447.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_23448_24563.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_24564_25127.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_25128_26351.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_26352_26675.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_26676_27239.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_27240_28079.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_28080_29651.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_29652_30143.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_30144_32063.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_32064_32663.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_32664_33191.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_33192_35147.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_35148_36479.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_36480_36551.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_36552_37463.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_37464_38387.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_38388_39191.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_39192_40091.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_40092_41591.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_41592_42215.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_42216_42791.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_42792_44135.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_44136_45311.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_45312_46691.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_46692_49103.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_49104_49631.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_49632_49799.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_49800_50459.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_50460_52835.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_52836_53771.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_53772_54239.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_54240_54743.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_54744_55907.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_55908_56147.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_56148_56315.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_56316_56783.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_56784_57383.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_57384_57695.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_57696_58679.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_58680_58787.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_58788_59279.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_59280_59843.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_59844_60803.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_60804_61391.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_61392_61595.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_61596_62243.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_62244_62423.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_62424_62567.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_62568_63755.png DEF_CON_Safe_Mode_-_James_Pavur_-_Whispers_Among_t_ku0Q_Wey4K0_63756_66735.png