Want to pwn a satellite? Turns out it's surprisingly easy | Hacker News Reader

Want to pwn a satellite? Turns out it's surprisingly easy

theregister.com

124 pointsDamonHD52 comments

I post this on every satellite related thread, but if you're interested in this stuff, you can easily listen to amateur radio satellites with an RTL-SDR dongle and a simple antenna.

There's even a repeater on the ISS, and sometimes you can hear the astronauts making contact with people on the ground in their spare time.

https://www.amsat.org/fm-satellite-frequency-summary/

From what I read in the PDF, the analysis is very debatable (with The Register putting forward mostly the nonsensical allegations).

Disclosure: I work on satellite design and in the recent years on a program that is part of the NewSpace. I have an intimate knowledge of how what I help design works but a limited knowledge of what others may be doing.

A couple of insights:

* I started working on satellites in a large industrial group where, while not being handled by world class cybersecurity experts, secure communications with the satellites rely on a sane use of proven encryption protocols

* I am not sure when this level of security became standard and what was done to secure the satellites before hardware-level encryption with modern algorithms became available

* I was astounded when I discovered the level of casualness for everything related to security on scientific satellite projects, with even recent projects led by major agencies considering that always encrypting command and monitoring is overkill

And my main grip is that the study relies on asking universities that have the lowest bar in terms of caring about security (they already struggle enough to build a working thing) and then extrapolating from a specious argument that it must be worse on commercial spacecrafts.

> One surprising result was that the larger the satellite, the more vulnerable it was. Larger machinery typically used more commercial off-the-shelf components and was thus more vulnerable since the code base was public, whereas smaller CubeSats tended to use custom code.

Also

> a satellite should be designed so that TCs do not compromise the satellite’s stability without further validation

Says who ? What validation ? If an operator had the right to have a telecommand sent to the satellite, who or what aboard the satellite should decide if this telecommand was legitimate.

From experience, there is a myriad of things that you think are usually not a good idea to make your satellite do and then, when you need it as a workaround or mitigation for an unexpected condition, you are happy you have not implemented a list of authorized actions that is too constrained.

PS: It reminds me of the guy that was able to capture the GPS coordinates of an airplane broadcasted to the In-Flight Entertainment systems and got a lot of press coverage by extrapolating that it meant he could also take control of the aircraft from his seat in the cabin.

The remote satellite/robot shouldn't decide what is a valid command (beyond verifying it comes from a valid authority), because we have multiple situations where NASA has recovered a space probe/robot by sending commands never dreamed of when the vessel was launched.

It really depends on the definition of a "valid command". What do you do when you receive a command that you don't recognize or the parameters are in the wrong format? You would just ignore it and increment the invalid command counter. You wouldn't want to just block a command that would be valid at any other time just because the receiver isn't expecting it. Although you may want to block a command that could cause harm to the system in it's current state (don't allow the command to blow the fairing bolts while the rocket is still on the ground). I don't think I'd want to allow accepting commands that don't conform to the correct format because even though you could potentially solve some problem with something like a register overflow, you'd be leaving yourself vulnerable to that same exploit causing harm, accidentally or maliciously.

If you have a command called SET_MODE and it only has the options 1, 2, or 3, it would be ridiculous for the system to accept mode 4 since it doesn't exist. The system should refuse the command. If the SET_MODE command actually just sets a bunch of toggles for you in the background, it would be a good idea to retain control of those toggles so you can customize the configuration and effectively make your own "mode 4" for any emergencies.

As someone who has worked on private in-flight entertainment systems I haven't heard of the story you mentioned about the GPS coordinates but I can confirm that controlling the plane would take a lot more than just getting on the RS-232 or RS-485 read-only busses the FMS sends data on.

> I haven't heard of the story you mentioned

I think it was this one [1]. The story is older than I remember (2015) but at the time I was working on aircraft system design and knew people well-versed in ARINC 664 and everything related to aircraft data network segregation between domains.

And a lot of the noise was coming from Boeing requesting Special Conditions [2] for the certification of recent airliners where segregation is less absolute than when systems had a floppy reader to install updates.

> Hacker Chris Roberts claimed he was able to break into the in-flight entertainment system up to 20 times on separate flights and that on one flight he was able to make the plane “climb” and “move sideways” by accessing flight control systems from a laptop in his seat.

[1] https://www.theguardian.com/technology/2015/may/19/hacker-ch...

[2] https://www.federalregister.gov/documents/2007/12/28/E7-2507...

Thank you for all of the great information!

Agreed. Generalizing the security of modern spacecraft by what university CubeSat teams get up to is like generalizing all of modern cybersecurity based on an anecdote about a one man company that left an SSH server open with the root password set to "12345."

Don't get me wrong, I have the utmost respect for what academic CubeSat teams can pull off with miniscule budgets and resources, but this doesn't reflect what actually happens outside the university context. Modern commercial spacecraft are well-secured, particularly on telecommand. For a look at what the professionals actually do, I suggest people take a look at the CCSDS 350.x series Green Book publications: https://public.ccsds.org/publications/GreenBooks.aspx

>"They have planned these systems for every milliwatt of power that is used to run the satellite, so there is not the power budget on existing systems to run encryption or authentication. It's not practical."

I doubt this. If they were concerned with power usage at the milliwatt level, they would most likely be using custom real time kernels. Encryption is ridiculously cheap in terms of power usage and performance on any modern processor because of intrinsics. I doubt they'd see even a blip in power usage with ChaCha20 unless all their code is hand optimised assembly.

I was under the impression that many of these systems do run RTOS, and that they don't use 'modern' processors, they use rad-hardened processors. Is this not the case?

Nice username.

Maybe someone else can chime in because I wasn't aware that ordinary satellites required radiation hardened hardware. At most I thought they'd just put it all into a metal box.

When selecting components there's a certain range of "quality grades" to choose from ranging from commercial/automotive to space grade and radiation hardened parts. Often times a lower grade component can work with some precautions, for example, with a reset circuit in case of latch up. Many cubesats use non-space grade components because of their high price and are only expected to work for a limited time, e.g., a few years.

Exactly, there is a big difference between multi-million dollar communications/observation satellites and cubesats, which can now be built and flown for under $100k. There is no reason or budget to use radhard chips with that sort of budget, when the thing will probably fail or re-enter the atmosphere before radiation damage matters.

The satellite I'm working on will be LEO, but fairly large, to do earth observation (SAR). The subsystem I'm working on uses a radiation hardened SPARC chip from Gaisler (Leon4). It's a fairly popular choice nowadays. We do use an RTOS, although I've largely been writing bare-metal boot loader code and drivers so it's not my area of expertise. Pretty much all of our buses/interconnects/CPUs/FPGAs are space-grade, with ECC/EDAC memory and nonvolatile storage.

The Gaisler drivers are hideous if you're doing anything more serious than basic interface testing. Good that you are rolling your own. Consider the -mflat compiler option which can improve timing jitter and reduce memory pressure by avoiding spilling of unused registers :D

My god, they really are something. Had quite the time with their SpaceWire driver. Thankfully that’s behind us now… hopefully.

Can you elaborate a bit regarding the -mflat compiler option? Why does it improve timing jitter etc? I am not sure I understand the description from the GCC docs. Is it disabling the register windows? Isn't that one of the big selling points of the SPARC architecture?

There is a finite number of register windows, usually 8 but only 7 can be used because the 8th serves as "sentinel" to detect over- and underflow.

Once register windows are full (a function call wants to activate the next register window but there is no unused window left) window overflow occurs and a trap handler is activated.

The trap handler "unwinds" the register windows and stores all the contents in memory (stack). Now the next function can continue with an empty set of register windows. Once you return from the function, the contents of the windows have to be restored (window underflow trap).

Problem is that the trap handlers can't know which of the registers in each window were in use. Therefore all have to be saved/restored. This ratio will worsen when you write smaller functions that use less register and nest deeper.

So there are two issues: 1. You can't really know at which point in your program that underflow/overflow occurs because it changes depending on the exact path of execution through the program. 2. Unnecessary memory write/read operations. While ca. 120 x 32-bit words is not that much, with an 8-bit wide SRAM, some waitstates and EDAC this might be noticeable. (Consider that the LEON processors have a data cache for read access but for writing only a "store buffer" that queues few memory writes)

Using -mflat every register is saved by the caller/callee (as ABI demands) on the stack. This means that the memory accesses are predictable and spread out over each function call.

So, my personal conclusion is that register windows are an intriguing idea on the surface but become useless when you aren't writing 80s spaghetti code. There were many similar ideas at that time, e.g., Am29000.

We’d considered using mflat, but we’re not that performance constrained (and prefer the slightly smaller binary size with register windows enabled). I may do some profiling of the under flow/overflow interrupts though since you’ve now got me second guessing myself.

Registers asr22/23 contain a cycle counter that you can use to time stuff. If it's not present, there's a register in the DSU that counts cycles but that requires an access via the AHB bus. You can measure a lot of things with those cycle counters, like context switch and interrupt handling times, memcpy vs naive for-loop, linear vs. binary search on small arrays...

I'd expect a few microseconds per overflow at most but it depends a lot on the characteristics of the system. Of course, if the application is not sensitive to a few microseconds here and a few microseconds there that optimization might not be worth it.

Yes. Though sometimes LEO satellites use standard hardware. Otherwise, rad hard electronics are quite behind the state of the art. A ~100 MHz 32-bit machine with a few dozen megabytes of RAM is typical of recent low-end rad hard space hardware. Still, even that is quite capable of modern public key encryption.

You don't normally use public key encryption in satellites, it is some sort of block crypto. CCSDS (a bunch of standards for space applications that is quite popular in the industry) recommends AES-HMAC for authentication and AES-GCM for both authentication and encryption.

My experience with a LEON processor ~100 MHz is that it is hard to get much throughput out of an AES implementation.

You don't need asymmetric crypto for satellites because you can set up a pre-shared symmetric key on the ground before it launches.

Satellites larger than cubesats usually use rad-hardened processors, e.g. in Europe the LEON processors are quite common. These are basically rad-hardened SPARC v8 processors. They are also clocked quite low since they are often implemented using a FPGA.

So, a rather old RISC architecture, lacking any cryptography extensions/intrinsics, running at a rather low clock frequency means that it is not that easy to fit authentication and cryptography in software (at least at the necessary rates).

To get authentication/encryption in these systems you need a separate crypto unit or implement AES-GCM/AES-HMAC in FPGA (if you have room).

Aren't they using hardened CPUs on those? Those are more than a few generations behind anything in common use on the ground.

It depends. Cubesats and other small LEO satellites commonly use consumer grade hardware. They're going to deorbit and burn up before the radiation becomes a major problem, and they're often deployed in fleets so it's fine to lose a portion anyway.

Certainly something that applies more to cubesats and similar projects. "Normal" satellites typically carry at least an authentication unit that performs some kind of HMAC checking. You can find some of that stuff here: https://public.ccsds.org/Pubs/352x0b2.pdf

Here's an example of an AU: https://www.esa.int/Enabling_Support/Space_Engineering_Techn...

> The prevailing wisdom is that hacking this kit would be prohibitively expensive due to the high cost of ground stations that communicate with the orbital birds, and that such hardware benefited from security by obscurity

I can really relate to this a lot. I've recently purchased a Flipper Zero and oh my god, so much tech is exposed based on NFC and Sub-GHz protocols. Many devices simply were not developed with security in mind because no one ever came up with such a tool to mess with. I wouldn't want people to mess with something floating on top of my house.

Stupid question that I've always been curious about, driving around.

Can an old C-band (large) satellite dish be used for transmitting as well as receiving?

If so, would there be any benefit to doing so, versus smaller/K* dish dimensions?

Know this is a basic question, but RF isn't my field.

yes.

no advantage over the smaller more modern dishes, as the more modern dishes are made with better shape tolerances, so they can be smaller and still get the same amount of signal to the satellite.

> I wouldn't want people to mess with something floating on top of my house.

I understand the sentiment but it sounds like you may have a misunderstanding of how orbits work here. Even if a geosync satellite were positioned exactly above your house, nothing could ever make it "fall down" onto you. Anything that brought it closer to Earth would make it not a geosync satellite anymore, and I strongly doubt any geosync satellites have enough fuel left to de-orbit entirely (geosync is far away!)

For low-orbit satellites, sure, they can (and are designed to, eventually) de-orbit, but nobody can hit you with it. The debris breaks up in atmosphere and tiny pieces (with a few larger, actually dangerous ones) are scattered randomly over hundreds of square miles of what is most likely the Pacific Ocean.

while they don't have the fuel to deorbit themselves, they will eventually deorbit due to orbital decay.

Still, as you said, they won't fall straight down, and would probably burn up in the atmosphere regardless.

In the case of satellites in GEO that "eventually" is on the order of millions of years. For LEO it's a lot shorter obviously.

that's actually a good point, I didn't know orbital decay was so slow

I don't know that I'd extrapolate much from the insecurity of cubesats being run by university research teams to commercial satellites. There is already another person here claiming they worked on these and they have better security. I worked for the NRO for a long time and there is no way in hell anybody was ever going to hack any of the US spy satellites or GPS satellites. You'd have to go past the heat death of the universe to crack the encryption. It's theoretically possible to take over a ground station, but they're air-gapped, so you're not doing it remotely, and they're located in SCIFs on US military installations, which, putting aside what you may have seen on the X-Files or a Mission Impossible movie, aren't actually that easy to infiltrate. I recall my wife working on experimental aerial surveillance radar for the US Navy years back, and one of the testing sites had some AT&T contractors (probably accidentally) dig a little too close to the network fiber backbone and an unmarked black SUV showed up to take them to God knows where within two minutes.

Back during the Iraq war the video feeds from drones and such were not encrypted, and people published some as a result. IIRC it was because there was not enough capacity on military sats, and the commercial sats used for this didn't have the necessary functionality. That's not to say that command and control functions were unauthenticated and unencrypted. But I suspect that older satellites -both American as well as not-American- are vulnerable, especially commercial ones predating modern cryptography, and since it takes a long time for modernity to filter through to specialized kit like satellites, I suspect that commercial satellites from before 2010 are generally vulnerable. American military satellites, I suspect, have been fairly secure for longer, though I have no specific knowledge, only an expectation that the NSA would have done their part to protect American assets in space.

Semi related is the Max Headroom incident.

https://youtu.be/aTuonpTAIOw

https://youtu.be/8rRo5CHFxAI

I thought that was due to terrestrial overpowering.

Yeah it was, but the problem is the same.

The assumption that inability to get the transmitter or knowledge of how to do it is enough to protect your reciever.

As far as I know, relay satellites also did not use authentication in the past.

That was in the days of analog TV. No good way to authenticate uplinks there, I think.

Subscriber satillite would have existed by the time of the incident.

I don't think it was a technical limitation and it's likely encrypted uplinks would have been possible long before consumers got encrypted downlinks (subscriber satillite).

There were actually 3 broadcasts, and if you find the third, on youtube, you will quickly realize exactly how it was done. Take note of the type of the network on all 3.

I asked this before - but do we know if Voyagers have any protection outside of needing a big transmitter to send commands to them?

These guys[1] hacked a NASA space probe and refired its motors. I read the entire blog once but I can't remember if there was any sort of encryption on the communication, although I know that was brought up. Modern probes do use cryptography, but I doubt Voyager does. I suspect if you fired commands at it you could control it. For the lulz or whatever.

[1] https://en.wikipedia.org/wiki/International_Cometary_Explore...

Fwiw, Russia pwned Viasat's satellites during invasion last year.

https://www.reuters.com/world/europe/russia-behind-cyberatta...

They attacked the firmware of customer terminals on the ground via a management network, not the satellites themselves.

See, among others:

https://www.viasat.com/about/newsroom/blog/ka-sat-network-cy...

https://www.reversemode.com/2022/03/viasat-incident-from-spe...

The terminal firmware had a bunch of security vulnerabilities allowing injection of arbitrary executables and commands without adequate signature verification.

The attack bricked the terminals requiring a hardware swap to restore service.

They didn't hack the satellites, they hacked the modems:

> "After those modems were knocked offline it wasn't like you unplug them and plug them back in and reboot and they come back,"

Would it be possible to return the favour and hack Russian satellites?

People have been hacking satellites for decades, it's kind of common knowledge in the hacker community. I think up until recently there just weren't a ton of private sector satellite to hack, and nobody wanted to go to federal prison for fucking with the military or clear community.

Related: hobbyists taking control of ISEE-3:

https://blog.xkcd.com/2014/05/30/isee-3/

https://xkcd.com/1337/

I was fortunate to visit this team while they were talking to ISEE.

They had some true wizards on the team and it was amazing to see them communicate with this vintage satellite using modern SDR stuff. Too bad about the bum propellant valve!

I've always been surprised that the contracted black hats attack websites, when, instead they could ransom a $50M satellite.

I mean if regular infra & businesses are still easy enough after 20 years of knowledge of evolving risks, satellites have to be easy pickings.

Trading Microwave Towers.

I went to watch the latest Mission Impossible today and was chuckling to myself at how trivially easy it was for Ving Rhames to "hack into the satellite" multiple times. Maybe it wasn't so far off the mark after all!

Reply on news.ycombinator.com