Ask HN: How is Starlink kept secure? | Hacker News Reader

Ask HN: How is Starlink kept secure?

20 pointsjonplackett17 comments

I just saw the map of spacex’s thousands of satellites in orbit and it got me wondering how they can keep them from being hacked.

If you have a web server you can do lots of things to help - blocking or whitelisting IPs. Rate limiting password attempts. 2FA etc, but also you can have physical access if things really go wrong.

How are these remote systems kept secure? How do you prevent someone just constantly brute forcing the password? Or doing a denial of service attack on them?

Presumably someone (Russia) has tried this given the use of Starlink in Ukraine.

Just very curious how this task is approached.

View on HN

I think you may be interested in: https://hackasat.com/

Hack-A-Sat is a Capture the Flag (CTF) competition designed to inspire the world’s top cybersecurity talent to develop the skills necessary to help reduce vulnerabilities and build more secure space systems.

In Hack-A-Sat 1, 2 and 3, the best of the best have been learning more about all the skills required to hack in space through physical flatsat hardware and digital twin simulation. But, this year, PRACTICE IS OVER, as Hack-A-Sat 4 presents the world’s first CTF competition IN SPACE. Five Finalist Teams will compete on Moonlighter, an on-orbit satellite. Moonlighter is the world’s first and only hacking sandbox in space, designed specifically to advance the cyber security community and secure space for us all.

Before delving into this topic, it's important to differentiate between Starlink and Starshield[0]. Both offer end-to-end encryption. The latter serves national security purposes and thus demands more robust security measures.

When considering targeting a single satellite, note that Starlink's Ku-Band beam spans approximately 3 degrees[1]. Given their low-altitude orbits, individual satellites will move out of coverage within minutes, to be replaced by the next in line. Analogous to aiming at a static target is easy, but when the target is rapidly moving, it becomes much more difficult to target, not to imagine the hardware required. The challenge becomes almost insurmountable at certain cost scales when dealing with multiple, swiftly changing targets.

In addition, SpaceX is establishing LISLs[2] (Laser Inter-Satellite Links), where instead of communicating with a ground-station, the satellites can communicate amongst themselves which yields higher data rates, less interference, lower latency, and mostly importantly provides a higher security by eliminating the need for a ground-based intermediary. I was fortunate enough to tour Starlink's assembly factory and witness the development of LISLs firsthand - their work is truly impressive.

In terms of updating and patching the satellites, of course there's the traditional software patches applies. As for hardware updates, it's worth noting that Starlink satellites have about a 5-year lifespan. New satellites are frequently launched to join the constellation, presumably with the latest hardware patches, while older or malfunctioning satellites can be de-orbited.

[0]: https://www.spacex.com/starshield/

[1]: https://fcc.report/IBFS/SAT-MOD-20181108-00083/1569860

[2]: https://arxiv.org/ftp/arxiv/papers/2103/2103.00056.pdf

You're aware that a good password is completely immune to brute force, right?

As for denial of service, are we talking about data level or physical level? On a data level, you'd have to get your flood through the starlink-controlled uplink station. Or maybe you'd simplify to flooding the uplink station itself. On a physical level you can deny access pretty easily, but only to the specific cell you're in. It would take a lot of power to block communication in completely different directions.

Even a bad password can be immune to brute force if the attacker never gets their hands on the password hash.

People always forget that there are two steps to a password brute force attack. First the attacker needs to somehow get their hands on the password hashes (usually from a database hack or leak) and then they can brute force it offline.

The only thing a high-quality password does is make the second step harder.

Getting the hash makes brute force faster, but it's not in general necessary. How important it is depends on the password quality and how often you can try to login.

If a system let you try one password per minute, and the password is in the dictionary, you could break it in a day or two with no hashes.

And if the system isn't configured to limit login attempts, you could try orders of magnitude more passwords.

Even if the target system doesn't have explicit login attempt limiting, you still run into the natural limitation of target CPU time. It's common to have login attempt limiting just to avoid letting remote targets waste all your CPU time with bogus attempts.

The amount of passwords you can try against a single target with an online attack is extremely limited, not even enough for a decent sized dictionary attack. You would have to be using an absolute horrid password for the attacker to get a hit.

Online password attacks are only really viable when you don't care about the target. Just use tiny dictionary of a few thousand common username/passwords pairs and hit every single ip address on the internet.

If you think the natural limitation of target CPU time is enough to stop a brute force and the best description is "extremely limited", you are massively overestimating the average password.

Keep in mind there is one-ish account in this scenario.

https://web.archive.org/web/20150327031521/http://research.m...

Going by this, a huge fraction of passwords are in the 30 bit range. And lots of basic web servers can do tens of thousands up to a hundred thousand requests per second per core. Which translates to 2^35 - 2^38 attempts per month per core you saturate, if the login implementation is lazy. Let alone the very many passwords in the 20 bit tier. And I think this paper didn't even consider dictionary words in their analysis of password strength, in which case it's giving much too high ratings to lots of passwords.

just don't use passwords :)

using decent cryptography correctly, you've just made the problem nearly untractable compared to brute force passwords (which also should be doing things like delays etc.)

While I agree that other methods are better than passwords, a decent password can be equally untractable.

> How do you prevent someone just constantly brute forcing the password?

Unless they are morons, they will use some sort of key derivation step, probably on the client side, that is relatively expensive to compute and produces a key of a size that is completely impossible to brute force. That key is the actual "password" verified during authentication. If done on the client side as I suspect, the parameters for this step could be chosen to take up to multiple seconds of compute time, thus making even simple passwords effectively immune to being brute forced in turn.

I doubt you'll get much hard evidence as to which measures are being used, but the above is pretty much guaranteed.

It's probably easier to coordinate a denial of service attack against operations that aren't splintered, into thousands of pieces, and each piece catapulting through space at thousands of km/h. A webserver, by comparison is usually sitting neat in a datacenter with cables to it.

The nature of Starlink should make it more immune to attack not less. Similarly it'd be really difficult to DoS something like youtube, due to the hugely fragmented nature of the deployment. And that's without the added complication of being an entirely wireless system in space.

While the addition of being in orbit, and so truly inaccessible if you lose comms, adds a slight wrinkle these are in most other ways just another piece of infrastructure connected to the internet, and so securing them is probably done in much the same way.

I guess the closest equivalent here is a remote point of presence for an ISP, which is also unlikely to be staffed on a regular basis. The first step is physical security, ensuring no one can get their hands on the hardware itself… that one’s pretty much in the bag here.

With that out of the way, we then look at the communications channel. This is probably the greatest vulnerability Starlink has, since if you can target the satellite with a powerful enough transmitter you can hypothetically block anyone else communicating with it. I’d be curious to hear if there are any specific defences against that built into Starlink. As another poster mentioned though, you’re only going to be able to do that to a given satellite for a short period before it crosses the horizon, so this is mostly a case of being able to deny service in a specific region of the world.

Next up is remote access. Again, curious to hear otherwise, but there’s probably a couple of control channels here. The satellites are probably running an SSH server, but I’d be surprised if that’s exposed to the public internet, so you’d need to breach whatever VPN or equivalent SpaceX use to communicate with the satellites. In this regard they’re just another computer, apply whatever methods you’d usually apply.

They also likely have a channel via which they’re listening for instructions to update their configuration. In that regard, these are IoT devices, it’s just that instead of receiving instructions to turn on a light bulb, they get instructions to fire rockets and change their orbit. My hunch here is that the primary comms channel for this is going to be the same as the SSH server, but there may well be a direct radio link they can use to recover if IP connectivity is lost. That’s probably the weak point if you want to hack a satellite, but it’ll be encrypted in some manner, and need authentication. Just finding out how that works will be a needle in a haystack because you’d have to intercept the traffic to start analysis.

Or get physical access. Maybe you could contract SpaceX to give you a lift up?

They're just computers like anything else and have to try to establish security best practices, both on hardware and software level.

It would be interesting to find out how effective patching methods are in place with satellites considering their somewhat unique location.

I can imagine that updating security patches in challenging network conditions could be difficult. Or do satellites actually have better network accessibility than I might think?

It is a bit more challenging in general for satellites but they always have remote access available regularly.

And in particular for Starlink, a constellation providing internet access, network capability is absolutely not an issue from an operator perspective. Even without the laser intersatellite link, the satellites can be contacted a fair portion of their time and have more than enough bandwidth to deal with software upgrades. Once they have laser comms, they will have 24/7 access to them, bar the odd failures.

> How are these remote systems kept secure? How do you prevent someone just constantly brute forcing the password?

I would be somewhat surprised if any proactively secured tech used a password. Key pair encryption is the way. A password over 20 random characters is virtually un-brute-forceable if there was one.

DDOS would involve either a botnet or a nation-state. Both could be solved by the US government if needed. It would be a bad target because you would almost certainly gain fed attention and that isn't attention you want. A satellite could probably be signal jammed with the only possible way to stop it being to blow up the jamming device.

I think your model of a satellite being more special than a web server is probably not all that correct. It's probably not significantly different than your home router in an abstract sense, just with a humongous antennae.

Most serious networking devices separate the control of the device from the operation of the device, so it's possible that there are specific configuration antenna or specific configuration frequencies, or sequences of frequencies that are used for configuration. There is probably some wireless equivalent of "using a different cable."

ACL's are probably standard, rate limiting is probably standard. I would be surprised if there were not 2fac. I would be surprised if there was not an incredibly monitored machine that is the only machine with credentials for those satellites, maybe even air-gapped from the internet at large.

I would potentially be worried about my hardware supply chain, for example if components came from China, they would probably inspect them quite carefully.

Your model of attacking the satellite itself is probably also wrong. Exploiting a companies networking devices, particularly from the outside is probably quite hard, what people go after is employee devices. There are probably a number of starlink employees with access and compromising their laptops might compromise all satellites. This means attacking the satellite system is probably like any other corporate hacking job, phish some employees or compromise a supply chain, use that to move around a company's network, hopefully undetected, etc.

If I wanted to compromise Starlink, and I was a nation-state, I would keep a list of all starlink employees or attempt to get that list via technical means and then try to compromise an employee. Compromises can be done technically, with bribery, extortion, and then violence.

The first stage of hacking is figuring out information. Who are the employees, who are the suppliers, what is the security architecture, etc. That informs the approach. Maybe there is a piece of software that would be easier to find a zero day for. Maybe it would be easier to compromise a supply chain. Maybe it's easiest to honeypot the employee with a beautiful person.

Setting up a coffee shop next to a starlink office and putting some great cameras and microphones in it for example, would probably be fruitful.

Exactly this ^^^^

Reply on news.ycombinator.com