Why hackers destroying one Starlink satellite could cause orbital Armageddon

A satellite entering a destructive spin cycle results in space debris: fast-moving particles then cause a cascade of destruction with devastating implications for the whole of humanity. Hackers can do that.

Russia's war in Ukraine has put commercial satellite operators in the spotlight like never before. Elon Musk's decision to supply Ukraine with SpaceX's Starlink terminals has caused a furore in the Kremlin.

Ukrainians using SpaceX's gear to resist Moscow's invasion resulted in the head of Russia's space agency threatening Musk with retaliation. At the same time, researchers from China urged their government to develop the means for taking the Starlink constellation out of operation.

While what those means could be is unclear, hacking a satellite is always an option. With more companies such as OneWeb and Amazon adding more devices in the Low Earth Orbit (LEO), the attack surface in space is increasing by the day.

According to Ang Cui, cybersecurity expert and founder of the cybersecurity firm Red Balloon Security, once attackers penetrate a spacecraft, nano satellites can cause colossal problems. During this year's CyberLEO conference, Cui's team showed that a threat actor could take over critical satellite systems.

"If you speed up the spin of first satellite fast enough for little pieces to fall off, some of the debris will hit the satellite in the back, starting a cascading effect,"

Ang Cui, cybersecurity expert and founder of the cybersecurity firm Red Balloon Security, told Cybernews.

It's no secret that hacking a satellite is possible. Could you tell me what an attack on a satellite looks like?

Most people think a satellite is like one computer with one control protocol. In actuality, these satellites are built to be extremely modular and debuggable, because it's very difficult to hit the reset button when you're in orbit. Satellites are failproof in the sense that you have redundancies of hardware. If any piece of firmware misbehaves, you should always be able to power down specific modules.

What that means is that each of the computers controls one function of the satellite. Be it a star tracker, attitude control, spin control, or propelling, they all run their own independent computer. Almost always, there are direct ways to access each of the very low-level physical computers in control of each and every single one of those things.

We've done demonstrations on this publicly and to our customers, to get people to realize this fact. Satellite operators use their command channels to control the satellite as a whole. That means that the main attitude control [orientation] system in the satellite will relay messages, figure out how to translate them, and send them down.

But if an attacker gets the ability to do firmware updates or change the code inside the embedded computer, then the satellite operator loses control of the physical attitude control. In that case, the attacker would be able to take over the device. And it's the most obvious way to ransom a satellite or even destroy it.

In our earlier conversations, you've talked about how using a satellite's reaction wheel can cause it to self-destruct. What would that look like in real life?

The reaction wheel (RW) is a part of the attitude control on most small satellites, CubeSats. It does attitude control for the satellite by interacting with the Earth's magnetic field. And our demonstration showed that a remote attacker on the ground could pivot from using the satellite terminal.

Let's say you have command and are on the command channel. You can then directly change the firmware through this computer that just controls the RW. Once you have that, you can easily lock a legitimate operator out because RW doesn't have to respond to any more commands.

While satellites are insanely strong, capable of surviving a force of 30Gs during launches, the situation changes a bit once they're in space. Once they're deployed, you have solar panels, antennas, and other things that stick out. Those are really fragile. We've shown with our demonstration that by getting code execution inside the RW controller, we can make the satellite spin so fast that it pulls itself apart.

The question is whether this is a feasible attack. Well, if we've proven this, you can absolutely do firmware updates. That means it is possible to hijack these satellites and take over their physical motion control. And that opens it up for ransomware. There are only so many ways you can talk to the satellite. If the thing running the firmware doesn't respond to commands anymore, it's pretty straightforward to prove that there are only so many things an operator can do without paying the ransom.

"When I'm talking about Kessler syndrome with people in the industry, they still generally think about it in terms of an accidental collision or an operator error. Like a micro asteroid or something else flying super-fast, that's not intentional,"

Cui said.

Let's say threat actors take over the satellite's attitude control system. What could they do with it to cause damage?

People often talk about crashing one satellite into another. As long as you have a propellant, you can probably do that. And we've actually seen these collisions, and they cause huge problems since operators have to navigate around space debris as a result. However, the key fear is the Kessler syndrome.

That is when there is enough density in an orbit or a collection of orbits. Once you reach a critical density, a single collision will cause more than one other collision, and you have exponential growth. A runaway behavior will destroy all of the satellites in that orbit and prevent humanity from reaching space.

Back in the seventies, when this idea was first floated, people were concerned about accidental collisions and collisions from space debris. If you fast forward to today, we have far more density in LEO. And you don't need to crash one satellite into another if you are clever about it.

The inspiration for the RW hack came after I looked at the Starlink constellation. Their satellites are in lower orbit and fly like a 'duckling row.' You have like 10 of them with the same parameter. When I came up with this idea, it was to show that it was possible to do this on the first satellite in that formation.

And if you speed up the spin of first satellite fast enough for little pieces to fall off, some of the debris will hit the satellite in the back, starting a cascading effect. It's another way to trigger the Kessler syndrome. You can cause damage by controlling the propelling system. But even if a satellite doesn't have it, there are other ways causing this type of collision.

While this sounds terrifying, do you think it's actually possible to do in the wild?

When I'm talking about Kessler syndrome with people in the industry, they still generally think about it in terms of an accidental collision or an operator error. Like a micro asteroid or something else flying super-fast, that's not intentional.

But the situation changes a lot when you start thinking about an adversarial framework where an attacker intentionally wants to cause Kessler syndrome by controlling one or two satellites. Then the question isn't so much whether it is possible or likely. This is one of these cases where anybody on the planet can potentially do this. If you don't secure it, it's more of an eventuality than a possibility.

Which types of cyberattacks you'd see as the most probable against satellite infrastructure? For example, early reports speculated that Russians carried out a simple DDoS attack on Viasat terminals to knock them out.

The only difference between people's ability to hack the terminal on the ground versus the actual satellite Viasat was fielding for Eastern Europe is that the satellite is just harder to reach because the command dictionary is encrypted. That terminal has the cybersecurity posture of, like, 2001. But the code that runs on the embedded controllers on the satellite itself, I guarantee you, is older than the firmware on the terminal on the ground.

That's because it takes years of flight testing all that stuff. And nobody ever changes any of these things for a complicated, massive satellite like Viasat's. You're not talking about a single attitude control and a single transmitter or receiver. Those things can take any phases of payload that can do all sorts of crazy stuff. And each one of those is not just a single computer, but their own little contained network of that in itself.

You have $500 million worth of embedded firmware ridden with the security of 1995 in mind flying around. And that's the reality of it. The Starlink satellites are much newer, but newer doesn't mean more secure. One way to think about it is that as your code's complexity increases, the number of vulnerabilities you have grows, too. Things have gotten much more complex.

However, the development cycle has gone from ten years to six to three, and now it's basically: screw it, let's do a firmware update and see what happens. Because we have more satellites than ever, it will not kill the world if you lose one. I think the number of vulnerabilities inside the firmware of today's satellite, by virtue of it being more complex, is probably much more than what we had, you know, 15 years ago.

Not to say that old satellites aren't hackable. They absolutely are. But modern satellites have more computing power, components, and buses, so the attack surface has gotten a lot wider.