An IOActive researcher has found SATCOM terminals ripe for exploitation. Learn which ones, what's being done to rectify the situation, and what you can do in the meantime.
Satellite communications have become a necessity. Military, aeronautical, maritime, and ground-based organizations all rely on SATellite COMmunications (SATCOM) to help vessels and aircraft operate safely, provide military and emergency services with communications, and furnish internet access in remote locations. So when Ruben Santamarta, Principal Security Consultant for IOActive, pens a white paper with the title A Wake-up Call for SATCOM Security, more than a few take notice.
Santamarta and IOActive evaluated SATCOM terminal equipment used on the Inmarsat and Iridium satellite networks. "IOActive found that malicious actors could abuse all of the devices within the scope of this study," wrote Santamarta. "The vulnerabilities included what would appear to be backdoors, hardcoded credentials, undocumented and/or insecure protocols, and weak encryption algorithms."
Santamarta also mentioned besides the design flaws, IOActive found several supposed features that introduce security risks.
Using a rather novel approach, Santamarta and fellow researchers reverse engineered publicly available firmware updates for satellite terminal equipment—specifically those manufactured by Cobham, Harris, Hughes, Iridium, JRC, and Thuraya. They found vulnerabilities in every firmware update.
Santamarta indicated why that's a problem, "These vulnerabilities have the potential to allow a malicious actor intercept, manipulate, or block communications, and in some cases, to remotely take control of the physical device." He also mentioned IOActive is working with CERT Coordination Center and the vendors to help eliminate the vulnerabilities. For now, IOActive recommends that all of the affected manufacturers remove firmware updates from their public-facing websites.
Why is this a big deal?
Considering only terminal equipment is affected, one might wonder why IOActive is so concerned about this. Santamarta explained that once adversaries remotely control a SATCOM terminal: they have the ability to disrupt satellite communications; spoof or delete distress calls, storm warnings, or other emergency messages; falsify ship, plane, or ground crew locations; and eavesdrop on confidential conversations.
It might be best to share some specific examples of how attackers could compromise the equipment. First, the Harris RF-7800B BGAN is a popular terminal providing tactical radio communications to militaries around the world.
The terminal is capable of satellite communications, streaming video, and text messaging. Santamarta said the terminal can be compromised by injecting malicious code that exploits a known vulnerability. Table 1 in Santamarta's paper lists the vulnerabilities (please note the vagueness was intentional). Malware running on an infected laptop connected to the terminal could deploy the payload.
Another example is the Hughes BGAN M2M terminal. Bad guys can subvert the terminal by sending malicious SMS messages to it, as shown in the following slide:
Aviation and Marine systems
Santamarta next catalogued vulnerabilities in SATCOM terminal equipment used in aviation and marine systems. The aviation example used by Santamarta was most telling. For obvious reasons, aircraft use highly dependable, redundant systems. The paper specifies that software security is based on a regulatory standard that divides failure conditions into five levels depending on how the failure affects an aircraft, crew, and passengers.
Santamarta said, "The research team was able to compromise a system certified for level D that interacts with devices certified for level A, potentially putting the level A devices' integrity at risk."
- Level A: Catastrophic failure may cause multiple fatalities, usually with loss of the airplane.
- Level D: Minor failure slightly reduces the safety margin or slightly increases crew workload.
IOActive is concerned about what their research team uncovered. They are working with the CERT Coordination Center and the involved companies. Unfortunately, Santamarta mentioned: "Except for Iridium, the vendors did not engage in addressing this situation. They did not respond to a series of requests sent by the CERT Coordination Center and/or its partners." That is why Santamarta was intentionally vague about the vulnerabilities.
IOActive offered the following steps owners and service providers can take to mitigate possible harm from the vulnerabilities:
- Owners and providers should evaluate the network exposure of these devices, implement secure policies, enforce network segmentation, and apply restrictive traffic flow templates when possible.
- Until patches are available, vendors should provide official workarounds in addition to recommended configurations in order to minimize the risk these vulnerabilities pose.
Santamarta ended his paper with, "The results of IOActive's research should be a wake-up call for both the vendors and users of the current generation of SATCOM technology."