The recent attacks against the ViaSat satellite network in February and March of this year have gone largely unnoticed amid the din of the Russian assault on Ukraine. And this is understandable: these attacks are cold and distant and in a sense unreal, not at all like the heartbreak we see on the ground in Kharkiv and Mariupol, or the sheer brutality we see in Irpin and Bucha.
But it’s worth paying close attention to these attacks. Not only is this the first time a nation has waged cyber war side-by-side with armored columns, but it may also be the first time firmware – code that resides in non-volatile storage – has served as the primary battleground.
On 24 February 2022, a “multifaceted and deliberate cyber-attack” was waged against the land-based portion of ViaSat’s KA-SAT network. The attack resulted in a partial interruption of KA-SAT’s consumer-oriented satellite broadband service. The attack impacted several thousand customers located in Ukraine and tens of thousands of other fixed broadband customers across Europe.
According to ABC News and a ViaSat report on that first attack:
- High volumes of focused, malicious traffic were detected emanating from ViaSat SurfBeam2 and SurfBeam2+ modems and/or associated customer premise equipment physically located within Ukraine.
- As ViaSat personnel worked to force the malicious modems offline, other modems emerged on the network to continue the attack, degrading the ability of legitimate modems to enter or otherwise remain active on the network.
- Around the same time, ViaSat observed a gradual decline in the number of modems online in the same commercial-oriented partition, with large numbers of modems across much of Europe exiting the network.
- Ultimately, tens of thousands of modems that were previously online and active dropped off the network, and these modems were not observed attempting to re-enter the network.
February 24 was, of course, the same day Russia began its current military aggression in Ukraine, with missiles and airstrikes accompanying armored assault. It was also the first day of civilian deaths in the conflict.
Weeks later, several sources doing forensic analysis of the attacks have focused on firmware updates in the affected modems. One post in Reversemode was particularly clear about the likely vector of the attack:
To be clear: while this attack may not use the same techniques as those we have seen previously, network device issues have been increasingly targeted in recent months, affecting PulseSecure VPNs, Fortinet devices, Cisco gear and many others.
Defending the firmware in these land-based network and connected devices calls for us to “practice what we preach” regarding firmware security. Cybersecurity teams need to routinely identify, verify and fortify their device firmware:
- Identify: Firmware in vulnerable devices, including VPNs, remains under heavy attack right now. Unfortunately, you can’t protect what you don’t see, and visibility into the firmware in these devices is a critical blind spot. Similarly, the firmware in these modems has little/no protection. Like many other devices, this is accepted only because the firmware is invisible to users.
- Verify: Once devices become compromised, they can act as stepping stones into more and more critical parts of the network. When these devices were finally brought down, the attacker could easily have been building back doors or other malicious behaviors anywhere inside the trusted management network. Without a way to verify known-good device firmware – including its binary provenance and its current configuration – there are many unvalidated areas to continue hiding.
- Fortify: Everything from PCs and servers to VPNs and modems will have the same software-related vulnerabilities and attacks that we have seen with other software. The only way around this is to update and re-configure firmware securely if we are to have any hope of defending against attacks at this layer.
But what happens if attackers seek to move “upstream” from terrestial modems and attempt to compromise the firmware in the satellites themselves?
The Higher Question: Firmware in the Firmament
Of the roughly five thousand satellites in earth orbit, some 2,224 are communication satellites. These modern marvels are quietly and reliably responsible for much of what we take for granted in everyday life: television and radio, telephony and internet, military comms and data access. Most of these communication satellites are geostationary, orbiting above a fixed point to provide their service to a prescribed, relatively small area on the surface of the earth.
These satellites are, like all devices, comprised of thousands of unique components. Many of these components, if not most of them, have their own onboard firmware to provide instructions.
The firmware in these devices suffers from the same weakness and inconveniences that plague terrestrial firmware in their land-based modem counterparts:
- Firmware vulnerabilities: of the most-exploited vulnerabilities identified by the US Cybersecuirty and Security Infrastructure Agency (CISA) in Q4 of 2021, an astonishing 69% were in firmware code rather than in applications and operating systems.
- Lack of updates: because of the “black box” nature of firmware, and the general unease practitioners have in updating this non-standard and highly customized code, Eclypsium finds that nearly 80% of firmware goes without being updated before reaching device end-of-life.
- A recent Federal report – “Assessment of the Critical Supply Chains Supporting the U.S. Information and Communications Technology Industry” – cited firmware as the “single point of failure” in most technology supply chains.
If our adversaries have adopted a strategy of ”bricking” modems via firmware attacks to sow confusion, it doesn’t seem a far leap to transpose that objective on satellite attacks via firmware that would render them useless.
There is, however, a plan to stem this tide before it reaches firmware attacks on orbiting devices. New legislation being proposed in the US Senate – the Satellite Cybersecurity Act – will seek to address some of the current defensive shortcomings. Specifically, the proposal calls for:
- “Risk-based, cybersecurity-informed engineering, including continuous monitoring and resiliency”. Eclypsium hopes this will be defined to include firmware.
- “Planning for retention or recovery of positive control of commercial satellite systems in the event of a cybersecurity incident.” Eclypsium hopes requirements to address this will include provisions for automated cryptographically signed firmware updates.
- “Management of supply chain risks that affect cybersecurity of commercial satellite systems”. Eclypsium’s recent white paper on firmware security in supply chains outlines key steps organizations need to take to secure this invisible and increasingly complex supply chain layer.
If this legislation is developed and executed correctly, firmware security won’t be an afterthought, like the overarching “I guess we didn’t think of that” regret it has grown to become of the last twenty years.
We have seen, however, that human nature – from national chest-thumping to financially motivated cyber attacks to all-consuming autocratic greed – seems to work faster than acts of congress. Let’s hope we get ahead of this as an industry before we have another “we didn’t think of that” moment.
Sign up for Eclypsium’s upcoming webinar, Repairing Links: Firmware Security and Technology Supply Chains for more on this topic.
