Source-linked AI summary
Dishing Out DoS: How to Disable and Secure the Starlink User Terminal
Joshua Smailes, Edd Salkield, Sebastian Köhler, Simon Birnbach, Ivan Martinovic
TL;DR
Satellite-terminal admin interfaces may lack protections common in terrestrial routers, while attacks can affect connected hardware as well as connectivity. The authors audit Starlink’s interface with fuzzing and find a malformed command that can leave the terminal unresponsive until physically power-cycled. They discuss attack impacts and router-security measures, including password changes and guest networks.
Problem
Some satellite-router admin interfaces lack protections common in terrestrial routers, and Starlink’s default Wi-Fi and admin-panel settings leave the interface open to attackers.
Source: 1) Password authentication · p. 4Method
The authors audit Starlink’s admin interface and use a fuzzer to iterate through its unauthenticated command space.
Source: §I · p. 1Results
A malformed “kill” command crashes command handling, and after stowing the dish, service cannot return until a physical power-cycle.
Source: A. Fuzzer · p. 2, B. Exploitation · p. 2Takeaways & Limitations
The paper recommends router-design improvements and user choices such as changing admin passwords, updating TLS certificates, and using guest networks to reduce drive-by risk.
Source: §V · p. 3, §VI · p. 5
Abstract
from arXiv · showhide
Satellite user terminals are a promising target for adversaries seeking to target satellite communication networks. Despite this, many protections commonly found in terrestrial routers are not present in some user terminals. As a case study we audit the attack surface presented by the Starlink router's admin interface, using fuzzing to uncover a denial of service attack on the Starlink user terminal. We explore the attack's impact, particularly in the cases of drive-by attackers, and attackers that are able to maintain a continuous presence on the network. Finally, we discuss wider implications, looking at lessons learned in terrestrial router security, and how to properly implement them in this new context.
I. MOTIVATION
The Starlink terminal’s admin interface exposes an attack surface familiar from terrestrial routers, but its connection to a motorized dish makes changes to the interface capable of affecting physical state. The paper audits this surface with fuzzing and identifies a malformed command that can leave the terminal in denial of service until a physical power-cycle.
I. MOTIVATION
- Unlike ordinary router attacks, admin-interface attacks can change a motorized dish’s state, potentially turning it away from the sky or damaging hardware through overuse.The paper frames this physical-system connection as making admin-interface security especially important.Source: §I · p. 1
- The audit examines how requests reach the admin interface and uses a fuzzer to iterate through its unauthenticated command space.The identified exploit lies in command decoding and execution logic.Source: §I · p. 1
- A malformed command can crash command handling and leave the terminal in denial of service until physically power-cycled, with poor password practices broadening exploitability.The admin interface lacks password authentication, and the Wi-Fi network may use default passwords.Source: §I · p. 1
II. THREAT MODEL
- The threat model targets attackers who modify the router or connected hardware by sending commands, including local-network attackers and those using a victim’s browser.The paper assumes attackers can scan equivalent hardware ahead of time and send local-network requests; the figure describes malformed gRPC requests crashing the command handler.Source: §II · p. 1, Figure 1 · p. 2
III. ATTACK
The Starlink admin interface sends gRPC commands to the modem, where a proxy decodes them for a command handler. Most commands do not require authentication, and sending malformed commands can expose command-handler corner cases.
III. ATTACK
- The web interface sends gRPC commands to the modem in HTTP POST requests, which a gRPC web proxy decodes and forwards to a command handler.The commands can also be sent directly from another device or application on the local network.Source: §III · p. 2
- Most modem commands, including commands affecting the dish’s physical state, do not require authentication; an on-network attacker can stow the dish and deny service while present.The vast majority of commands are unauthenticated, although some require a password.Source: §III · p. 2
- HTTP-encapsulated gRPC payloads are usually 2–5 bytes, making it feasible to fuzz correctly formatted commands with random contents for unexpected behavior.The fuzzer can discover valid commands as well as invalid commands that expose handler corner cases.Source: §III · p. 2
A. Fuzzer
Fuzzing correctly formatted gRPC commands uncovered a “kill” command that crashes the terminal’s command handler. Stowing the dish before sending it freezes the terminal in that state, requiring a physical power-cycle to restore internet access.
A. Fuzzer
- The fuzzer uses the observed command structure—four null bytes, a length byte, then the command—to iterate through correctly formatted requests.It discards the common “invalid” and “unimplemented” responses; for three-byte commands, the search focuses on those ending in zero.Source: A. Fuzzer · p. 2
- The fuzzer found a “kill” command that crashes the command handler, stops responses to commands, and requires a physical power-cycle to restore functionality.The command is 00 00 00 00 03 EA 3E 00.Source: A. Fuzzer · p. 2
B. Exploitation
- Stowing the dish before sending “kill” freezes its state and prevents internet access from returning until the terminal is physically power-cycled.Appendices B and C provide shell scripts for sending the stow and kill commands; Figure 2 shows the attack outcome.Source: B. Exploitation · p. 2
IV. IMPACT
The attack can cause sustained service loss, and repeated dish movement can damage hardware; impact is greatest when attackers can remain on the network or reach many untrusted users. The paper also reports that Starlink implemented and deployed a fix in December 2022.
IV. IMPACT
- Stowing the dish before the kill command causes denial of service until physical power-cycling; repeated stowing and unstowing can damage hardware, and an on-network attacker can repeat outages.Figure 2 depicts the successful attack’s dish outcome, web control panel, and command response.Source: §IV · p. 2, Figure 2 · p. 3
- Large networks with many untrusted users face greater risk, especially when Starlink is the customer’s only internet source; examples include maritime and aviation traffic, internet cafés, and large organizations.Physical access is required to restore service, increasing disruption where terminal access is difficult or restricted, such as secured rooftops.Source: §IV · p. 3
- Remote attacks require causing a same-network device to send HTTP requests; ordinary JavaScript attacks are unlikely under modern browser CORS policies unless legacy browsers are used.A malicious executable or script could make the requests if a user is tricked into running it.Source: §IV · p. 3
- An attacker passing nearby can execute the attack within seconds if the Wi-Fi network is unprotected; a password or guest mode without admin-interface access can mitigate this route.The resulting outages can last minutes or hours.Source: §IV · p. 3
A. Responsible Disclosure
- Starlink’s security team reproduced the reported vulnerability, identified a gRPC server edge-case bug, and deployed a fix to user terminals in December 2022.The deployed fix was patch 8c03f1b9-de75-404b-87fd-7986892cdacb.uterm.release.Source: A. Responsible Disclosure · p. 3
V. DISCUSSION
Starlink’s administrative-interface risks resemble those of commercial routers, but its exposure depends on how browser requests are handled. The paper connects these risks to the difficulty of securing the initial browser-router connection.
V. DISCUSSION
- Attackers can issue commands locally or trick users into making requests, reflecting security challenges also faced by commercial routers and server software.The paper identifies bootstrapping a secure connection as a shared challenge.Source: §V · p. 3
1) Drive-by browser exploitation:
- CORS can prevent websites from reading router responses, but some configuration changes require only sending the request.For non-simple requests, browsers preflight-check the allowed origin before sending the initial request.Source: 1) Drive-by browser exploitation · pp. 3–4
- Starlink’s configuration POST is non-simple because it requires an application/grpc-web+proto header, leaving direct drive-by exploitation blocked on modern browsers but possible on older ones.The paper identifies the required header as the reason modern browsers do not directly allow this attack.Source: 1) Drive-by browser exploitation · p. 4
2) Local network attack:
Local-network attackers can reach the administrative interface through several routes, while the paper argues that satellite-router security should incorporate lessons from terrestrial router design.
2) Local network attack:
- An attacker maintaining a local-network presence can send administrative commands, and password authentication can significantly increase the difficulty of executing the attack.The paper also describes DNS hijacking and IP spoofing as ways to redirect requests for the Starlink interface.Source: 2) Local network attack · p. 4
- DNS hijacking can redirect my.starlink.com to an attacker-controlled server even if TLS is used, because the browser does not expect a secure connection.The authors argue that HTTP Strict Transport Security can address this issue.Source: 2) Local network attack · p. 4
B. Mitigations
- The Starlink attack applies to its user terminal, and the authors say the approach can generalize to other satellite routers.They emphasize that physical control of hardware makes security important, while known improvements from terrestrial router design have not been carried forward.Source: B. Mitigations · p. 4
1) Password authentication:
The paper recommends authentication and secure transport for router administration, while noting that convenience pressures and insecure defaults can leave interfaces exposed. It also outlines a per-router certificate approach for TLS.
1) Password authentication:
- Administrative commands should require a secure password randomized per router to prevent adversaries from reusing credentials across networks.The authors stress this protection for satellite modems because they control physical hardware.Source: 1) Password authentication · p. 4
- Unencrypted connections to a router over an unsecured network expose the password to local-network sniffing.Source: 1) Password authentication · p. 4
- Starlink routers leave the admin panel open by default because the WiFi network is neither password-protected nor encrypted.The default SSID “Stinky” may encourage a change, but no policy encourages secure passwords.Source: 1) Password authentication · p. 4
2) Transport Layer Security:
- Routers can use unique self-signed certificates that users download and install in their browsers, providing security similar to SSH’s Trust On First Use approach.The authors caution that sending the certificate over an initially insecure connection remains a risk.Source: 2) Transport Layer Security · p. 4
3) Guest mode:
Guest mode can limit untrusted users’ access to the admin interface, and the conclusion emphasizes balancing secure administration with user convenience. The paper reports that malformed administrative commands could disable the router, while recommending user choices and UX design as part of security.
3) Guest mode:
- Starlink’s guest mode separates a public-facing network from the admin interface, partially protecting the terminal from reconfiguration by untrusted users.The authors describe a dedicated admin network with no public-internet access as a more secure way to disable drive-by attacks.Source: 3) Guest mode · p. 4
VI. CONCLUSION
- Malformed commands sent through the administrative interface enabled a denial-of-service attack, and the vulnerability has since been patched.The paper links streamlined user-experience design choices to vulnerabilities exploitable by local attackers or through victims’ browsers.Source: §VI · p. 5
- The authors recommend guiding users toward changing administrative passwords, updating TLS certificates, and using guest networks to reduce drive-by risk.They argue that good UX design can support a polished experience without sacrificing security.Source: §VI · p. 5
APPENDIX A FUZZER SOURCE CODE
The fuzzer iterates through three-byte commands ending in a zero byte and logs responses other than invalid or unimplemented errors.
APPENDIX A FUZZER SOURCE CODE
- The fuzzer tests commands of length 3 with a trailing zero byte, logging responses that avoid error codes 13 and 12.The script can be modified to test other command lengths or send commands in random order.Source: Appendix A · p. 5
- Requests use the gRPC-Web content type and header, and the script records response data, status, headers, and content.Source: Appendix A · p. 5
- The generator creates two variable bytes, appends a zero byte, and uses a length header of 3.It iterates over 256^2 two-byte values.Source: Appendix A · p. 5
APPENDIX B GRPC HTTP “STOW” COMMAND
The appendix gives an HTTP POST request containing a gRPC command to stow the dish, turning it away from the sky.
APPENDIX B GRPC HTTP “STOW” COMMAND
- The command sends an HTTP POST request containing a gRPC command to stow the dish, turning it away from the sky.Source: Appendix B · p. 6
- The shell command posts the encoded payload to the device's gRPC-Web endpoint.Source: Appendix B · p. 6
- The request uses the application/grpc-web+proto content type and the x-grpc-web header.Source: Appendix B · p. 6
APPENDIX C GRPC HTTP “KILL” COMMAND
The appendix gives a malformed HTTP request that causes the dish to crash.
APPENDIX C GRPC HTTP “KILL” COMMAND
- A malformed request causes the dish to crash.Source: Appendix C · p. 6
- The shell command sends an encoded payload to the device's gRPC-Web endpoint.Source: Appendix C · p. 6
- The request uses the application/grpc-web+proto content type and the x-grpc-web header.Source: Appendix C · p. 6