I've investigated network equipment before, my findings were that you shouldn't trust any of it and use a standard Linux box whenever possible. The worst was consumer-grade modems/routers with low-hanging fruits such as backdoors, "forgotten" telnet servers left enabled, shell command injection in the web UI, etc but even enterprise stuff had its problems (thankfully, at least on enterprise stuff you can disable the web UI and any services you don't use, considerably shrinking the attack surface to pretty much just the kernel). And don't get me started on mobile network equipment where untrusted data is parsed at the kernel level and the motto is still security by obscurity (and the impossibility to obtain said equipment for the average Joe).<p>What I think happened is that they breached the control infrastructure which gives them access to an "internal" VLAN that the satellite terminals use to communicate with the mothership for firmware updates, configuration changes, etc, and from there were able to attack these as if they were locally connected (or worse - since that network segment is presumed "internal" and may expose services not normally available - think whatever is the TR-069 equivalent for BGAN terminals), either just pushing an incorrect configuration that prevents the terminal from connecting (essentially bricking it until you can get out-of-band access and reconfigure it properly) or obtaining root (via exploit or pushing a specially-crafted firmware update) and overwriting /dev/mtd* to completely kill the terminal.<p>"Cyberattack on satellite network" sounds so serious but I very much doubt it's got anything to do with the satellite part of it. They've done the equivalent of breaching into the management network at a terrestrial, wired ISP and sent garbage configuration over TR-069 to brick the modems. Attacking the satellite layer would require much more effort for essentially the same gain (and if your objective was to get into the satellite layer, why waste that access on breaking everything in a highly-visible way when you're better off silently sitting there and using the access to eavesdrop on everything, especially when it's used for SCADA traffic of critical systems that's itself unencrypted and vulnerable to tampering?).
Simultaneously, Russian ground forces have had a hell of a time using their encrypted radios, resulting in the logistical and tactical omnishambles observed by many, and fallback transmitting in the clear using civilian ham radios or cell phones.<p>Some have attributed this to difficulty in distributing encryption keys to forward units or just general incompetence, but one fun theory I saw on twitter is that Russia uses SDRs somewhere in their radio net and a similar poison packet bricked them all.
Seems entirely plausible to me that someone pushed a firmware update which corrupted the firmware (even maybe at the fpga/bootcode level) and effectively bricked the devices. Not horribly complicated to do and once you've done it it would require physical access to recover each device individually.<p>Is there a plausible explanation for who would do this, besides Russia?<p>Is Viasat/Eutelsat a particularly good target for this for some reason (seems more like Iridium is used in these scenarios).
I have personally seen that a lot of "cheap" point to multipoint contended access VSAT modems have very little security on them.<p>Would not be surprised in the slightest if something like a new firmware load or configuration push coming from the hub of the network was not properly validated by the modems using a secure crypto key/signature method.<p>Keep in mind that what we're talking about here is the European equivalent of the viasat/hughesnet/wildblue low cost, highly contended access geostationary vsat modem service. It's about the cheapest possible thing you can buy that is two way IP data via geostationary at 64:1 oversubscription ratio or more. There are very demanding economics factors in play that require the company to make the end user terminal hardware as absolutely cheap as possible, for all of the sub components (physical dish/mounting, LNB, Tx/BUC/SSPA, cabling, and modem).
It's not clear how any of the suggested attacks constitute 'permanent' damage:
disabling the transmitter, corrupting the antenna pointing logic, demod, power params can all be solved by reflashing the firmware and FPGAs. Not always simple but possible at least by the manufacturer.<p>One way to really destroy a transmitter is to transmit at full power without an antenna attached. Another is to burn the receiver front end by directing the full transmitter output to the receiver input. If the RF path is configured with software controlled RF switches a hack could burn out the front end circuitry for good. All depends on how permanent we're talking.
Well, if my paytv CPE experience means anything here…<p>One brand of electronic countermeasure would cause a firmware write that wouldn’t allow the receiver to boot because you’re a lazy hacker that didn’t lock the flash chip at the hardware WE pin level.<p>There were a couple of strategies to resolve:<p>1) remove chip and re-program (not fun on TSOPs)<p>2) JTAG reprogram (easy and cheap when computers had parallel ports: just some wires and a DB25 connector and the port can bit bang everything)<p>3) the device does a Power on self test. If it detects a corrupted flash file, it will grab a fresh and clean one from the satellite stream and overwrite your nasty one. You can trigger this by shorting/grounding the right address lines on the flash chip at the right time in the self-test. It won’t pass checksum validation and will think a corrupted update occurred and rewrite it.<p>That was all for the parallel flash chip (a 28 or 29f series I think).<p>If it was a serial flash chip like a 24 series, that would be even easier to deal with.
Can confirm that this kind of software is terrible. I've worked in SATCOM for years, we've deployed modems to military that have hardcoded passwords for web UI and SSH that you can google on the internet... Obviously some effort goes into firewalling all that off very carefully, and then often separate VPN over the top (hardware crypto, etc.), but the modems themselves are appalling. The SSH host keys also change when you do a firmware upgrade which makes me think that might be hardcoded and just changed in each version, not generated for each device... I haven't checked though.<p>Unfortunately that was the modem that the satellite operator <i>required</i> us to use, there was no other option!
If someone have access to bricked modem and can ship it for analysis we can try to collect evidence what happen and how modem was bricked - who knows, may be log partition wasn't overwritten or other artefacts are left (significant events like update are permanently logged).
As side effect, recovery instruction can be created.<p>Best contact point is via <a href="https://www.satsig.net/cgi-bin/yabb/YaBB.pl?num=1646161484" rel="nofollow">https://www.satsig.net/cgi-bin/yabb/YaBB.pl?num=1646161484</a>
Elon Musk mentioned this attack in one of his tweets a few days ago:<p><a href="https://twitter.com/elonmusk/status/1499585449450344451" rel="nofollow">https://twitter.com/elonmusk/status/1499585449450344451</a>
Can someone versed in military doctrine / strategy talk about dealing with the uncertainty of a false-flag attack?<p>Does the best-known approach just boil down to weighing the cost/benefit of (acting | not acting) x P(most likely aggressor | some other cause)? Or has someone figured out a better approach?