EDITORIAL | May 13, 2022

Update on SATCOM Terminal Attacks During the War in Ukraine

By John Sheehy

In a prior post titled “Missed Calls for SATCOM Cybersecurity: SATCOM Terminal Cyberattacks Open the War in Ukraine,” I shared three hypotheses about the identity of the threat actor responsible for the SATCOM terminal attacks that opened the war.^[1] On 31 March 2022, shortly after my post went live, other posts examining forensic evidence from the attack provided some of the additional information needed to support or reject these hypotheses.

Open-Source Forensic Analysis

Ruben Santamarta published a blog post titled “VIASAT Incident: From Speculation to Technical Details” with a forensic analysis of a compromised Surfbeam2 modem.^[2] In it, he reviews the Viasat blog post covering the cyberattack^[3] and analyses the flash memory from both a compromised and working Surfbeam2 modem. His results showed that the overwrite pattern used on the firmware was identical to that used the AcidRain wiper malware.

Later the same day, a couple of analysts at SentinelOne posted their findings on the AcidRain malware titled “AcidRain | A Modem Wiper Rains Down on Europe.”^[4] They analyzed a malware sample uploaded to VirusTotal with the interesting name of ‘ukrop.’^[5] They conclude, “While we cannot definitively tie AcidRain to VPNFilter (or the larger Sandworm threat cluster), we note a medium-confidence assessment of non-trivial developmental similarities between their components and hope the research community will continue to contribute their findings in the spirit of collaboration that has permeated the threat intelligence industry over the past month.”

The VPNFilter malware^[6] has been attributed to a specific unit of the Russian General Staff Main Intelligence Directorate (GRU), the GTsST, also known as Unit 74455.^[7] This unit has developed other derivatives of the VPNFilter malware, such as Cyclops Blink.^[8] This group is also known by the name Sandworm among others.^[9] The GTsST has on occasion operated jointly with GRU Unit 26165, which is also referred to as APT28.^[10] Additional information about Russian-linked cyberoperations elements can be found in the detailed April 2022 Joint Cybersecurity Advisory Alert (AA22-110A) from CISA.^[11]

This additional open-source forensic and analytical information supports two of the initial hypotheses about the identity of the threat actor responsible for the Viasat cyberattack: an element of Russian military intelligence (GRU unit) or a collaboration between elements of Russian special services. Without any secret intelligence, a favored hypothesis emerged, which is one or more elements of the GRU. The hypothesis of the Russian FSB-linked Turla group should be disfavored based on this additional evidence.

It would be interesting to see a comparative analysis of the AcidRain and Cyclops Blink malware variants. While they have different target devices and platforms, any similarities could provide additional insights.

Intelligence Agency Public Attributions

On 10 May 2022, numerous governments made public attributions on the identity of this threat actor.^[12] Australia,^[13] Canada,^[14] Estonia,^[15] the EU,^[16],[17] the UK,^[18] and the US^[19] varyingly attributed the 24 Feb 2022 Viasat SATCOM cyberattack to Russia and specific Russian cyber operation elements. Concurrently, New Zealand^[20] issued a more broadly worded communique referencing Russian cyberattacks in Ukraine without specifically mentioning the Viasat SATCOM attack.

Many of the statements mentioned spillover, however, I will share some thoughts in a future blog post on how this was much more likely a case of ‘pour-over’ (intentional, plausibly deniable spillover) rather than true spillover.

Conclusions

The weight of open-source forensics evidence and the public attributions made by numerous national intelligence services suggests that the threat actor responsible for the Viasat SATCOM terminal attack on 24 February 2022 was almost certainly the Russian General Staff Main Intelligence Directorate (GRU). Moreover, the open-source forensic analysis indicates it was likely the GTsST (Unit 74455) operating alone or jointly with another GRU element.

^[1] https://ioactive.com/missed-calls-for-satcom-cybersecurity/

^[2] https://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html

^[3] https://www.viasat.com/about/newsroom/blog/ka-sat-network-cyber-attack-overview/

^[4] https://www.sentinelone.com/labs/acidrain-a-modem-wiper-rains-down-on-europe/

^[5] https://www.virustotal.com/gui/file/9b4dfaca873961174ba935fddaf696145afe7bbf5734509f95feb54f3584fd9a/details

^[6] https://www.cisa.gov/uscert/ncas/alerts/TA18-145A

^[7] https://www.ncsc.gov.uk/news/uk-and-partners-condemn-gru-cyber-attacks-against-olympic-an-paralympic-games

^[8] https://www.cisa.gov/uscert/ncas/alerts/aa22-054a

^[9] https://attack.mitre.org/groups/G0034/

^[10] https://www.justice.gov/opa/page/file/1098481/download

^[11] https://www.cisa.gov/uscert/ncas/alerts/aa22-110a

^[12] https://www.reuters.com/world/europe/russia-behind-cyberattack-against-satellite-internet-modems-ukraine-eu-2022-05-10/

^[13] https://www.foreignminister.gov.au/minister/marise-payne/media-release/attribution-russia-malicious-cyber-activity-against-european-networks

^[14] https://www.canada.ca/en/global-affairs/news/2022/05/statement-on-russias-malicious-cyber-activity-affecting-europe-and-ukraine.html

^[15] https://vm.ee/en/news/estonia-joins-statement-attribution-cyberattacks-against-ukraine

^[16] https://www.consilium.europa.eu/en/press/press-releases/2022/05/10/russian-cyber-operations-against-ukraine-declaration-by-the-high-representative-on-behalf-of-the-european-union/

^[17] https://news.err.ee/1608593500/estonia-high-certainty-russia-behind-cyberattacks-on-ukraine-viasat

^[18] https://www.gov.uk/government/news/russia-behind-cyber-attack-with-europe-wide-impact-an-hour-before-ukraine-invasion

^[19] https://www.state.gov/attribution-of-russias-malicious-cyber-activity-against-ukraine/

^[20] https://www.beehive.govt.nz/release/new-sanctions-target-disinformation-and-malicious-cyber-actors

WHITEPAPER | April 5, 2022

Cyberattacks on SATCOM: Understanding the Threat

By Ethan Shackelford

In 2014, Ruben Santamarta, Principal Security Consultant with IOActive, published a whitepaper titled “A Wake-up Call for SATCOM Security.” It detailed the discovery of an exceptionally weak security posture across a number of SATCOM terminals from a range of manufacturers. Four years later in 2018, Ruben published a follow up titled “Last Call for SATCOM Security” which detailed a thorough investigation into the security of SATCOM equipment across the Aviation, Maritime, and Military industries. In light of the cyberattacks at the start of the war in Ukraine, once again, the security posture was found to be overwhelmingly poor and in need of immediate and thorough corrective action by manufacturers.

Get the Whitepaper

WHITEPAPER | August 10, 2018

Last Call for SATCOM Security

By Ruben Santamarta

Revisiting the original research by Ruben Santamarta ‘Wake Up Call for SATCOM Security‘ – this research update comprehensively details three real-world scenarios involving serious vulnerabilities that affect the aviation, maritime, and military industries. The vulnerabilities include backdoors, insecure protocols, and network misconfigurations.

This white paper elaborates the approach and technical details of these vulnerabilities, which could allow remote attackers, originated from the Internet, to take control of:

Airborne SATCOM equipment on in-flight commercial aircrafts
Earth Stations on Vessels, including Antennas
Earth Stations used by the US Military in conflict zones

Get the Whitepaper

RESEARCH |

Breaking Extreme Networks WingOS: How to Own Millions of Devices Running on Aircrafts, Government, Smart Cities and More

By Josep Pi Rodriguez

On Sunday, August 12th at 11am PT, I will give a talk at DEF CON 26 explaining how several critical vulnerabilities were found in the embedded operating system WingOS. The talk is entitled, “BreakingExtreme Networks WingOS: How to Own Millions of Devices Running on Aircrafts,Government, Smart Cities and More.” The Wing operating system was originally created by Motorola and nowadays Extreme Networks maintains it. WingOS is running in Motorola, Zebra and Extreme Networks access points and controllers. It is mainly used for WLAN networks.

This research started focusing in one access point widely used by many airlines around the world, which provides Wi-Fi and Internet access to their aircraft’s passengers. After starting to reverse engineer the firmware, I realized that this access point uses the WingOS and this OS is not only used in the aircraft industry, but also in many other industries.

Based on public information, we can see how it is actively used not only by many airlines but also in public places such as the New York City subway, hospitals, hotels, casinos, resorts, mines, smart cities, sea ports, and more. I will share some real-world examples of places where these devices are being used during my talk.

During my talk, besides the introduction of this OS, scenarios and attack surfaces, I will show some examples of critical vulnerabilities that attackers could exploit to completely compromise these devices. Some of these vulnerabilities do not require any kind of authentication, meaning that an attacker — just through the Ethernet connection or Wi-Fi connection — could exploit these issues. Once the devices are compromised, obviously the attacker can compromise the communications from the clients connected to this access point or controller and also launch more effective attacks against those clients. Basically, it is the same idea when an attacker has full control of a router where dozens or hundreds of clients are connected, which can be really dangerous and the possibilities of successful attacks to the clients connected and their communications are really high.

In the case of a controller, we had the same impact but it was even greater. Controllers can control dozens or even hundreds of access points. Some of the vulnerabilities affects the controllers as well, so the attacker could get remote code execution at one controller and then compromise all the access points connected to this controller.

Another interesting and obvious fact from the attacker’s perspective is the following example:

Let’s put us in the New York City subway or in the aircraft scenario. We know that normally these vulnerable devices running WingOS are connected to other assets of the internal network that are not normally reachable from the Internet. Let’s say that an attacker is able to exploit one of the vulnerabilities through the Wi-Fi or Ethernet network. Since the attacker now has code execution at the WingOS device, now the attacker can pivot and try to attack these other assets inside the internal network of the New York City subway or at the aircraft scenario. Obviously, we don’t know for sure what is beyond that, but what is clearly obvious is that this is technically possible and clearly this is also a really juicy entry point for attackers that might want to attack other assets in the internal network of that particular scenario.

During the talk, I will show one exploit that chains several vulnerabilities to get code execution using the Wi-Fi connection that a vulnerable access point provides. After that, we will discuss some conclusions about this research. Hopefully, after this, there will be some lessons learned about security of the WingOS so that it security can improve in the future and millions of devices installed out there will be less exposed to attackers that could do some serious damage to several industries/companies.

RESEARCH | October 26, 2017

AmosConnect: Maritime Communications Security Has Its Flaws

By Mario Ballano

Satellite communications security has been a target of our research for some time: in 2014 IOActive released a document detailing many vulnerabilities in popular SATCOM systems. Since then we’ve had the opportunity to dive deeper in this area, and learned a lot more about some of the environments in which these systems are in place.

Recently, we saw that Shodan released a new tool that tracks the location of VSAT systems exposed to the Internet. These systems are typically installed in vessels to provide them with internet connectivity while at open sea.

The maritime sector makes use of some of these systems to track and monitor ships’ IT and navigation systems as well as to aid crew members in some of their daily duties, providing them with e-mail or the ability to browse the Internet. Modern vessels don’t differ that much from your typical office these days, aside from the fact that they might be floating in a remote location.

Satellite connectivity is an expensive resource. In order to minimize its cost, several products exist to perform optimizations around the compression of data while in transit. One of the products that caught our eye was AmosConnect.

AmosConnect 8 is a platform designed to work in a maritime environment in conjunction with satellite equipment, providing services such as:

E-mail
Instant messaging
Position reporting
Crew Internet
Automatic file transfer
Application integration

We have identified two critical vulnerabilities in this software that allow pre-authenticated attackers to fully compromise an AmosConnect server. We have reported these vulnerabilities but there is no fix for them, as Inmarsat has discontinued AmosConnect 8, announcing its end-of-life in June 2017. The original advisory is available here, and this blog post will also discuss some of the technical details.

Blind SQL Injection in Login Form
A Blind SQL Injection vulnerability is present in the login form, allowing unauthenticated attackers to gain access to credentials stored in its internal database. The server stores usernames and passwords in plaintext, making this vulnerability trivial to exploit.

The following POST request is sent when a user tries to log into AmosConnect

The parameter data[MailUser][emailAddress] is vulnerable to Blind SQL Injection, enabling data retrieval from the backend SQLite database using time-based attacks.

Attackers that successfully exploit this vulnerability can retrieve credentials to log into the service by executing the following queries:

SELECT key, value from MOBILE_PROPS WHERE key LIKE ‘USER.%.password’;

SELECT key, value from MOBILE_PROPS WHERE key LIKE

‘USER.%.email_address’;

The authentication method is implemented in mail_user.php:

The call to findByEmail() instantiates a COM object that is implemented in native C++ code.

The following C++ native methods are invoked upon execution of the call:

Neptune::UserManager::User::findByEmai(…)

Neptune::ConfigManager::Property::findBy( … )

Neptune::ConfigManager::Property::findAllBy( … )

The vulnerable code is implemented in Neptune::ConfigManager::Property::findAllBy() as seen below:

Strings are concatenated in an insecure manner, building a SQL query that in this case would look like:

“[…] deleted = 0 AND key like ‘USER.%.email_address’ AND upper(value) like ‘{email}'”

Privileged Backdoor Account

The AmosConnect server features a built-in backdoor account with full system privileges. Among other things, this vulnerability allows attackers to execute commands with SYSTEM privileges on the remote system by abusing AmosConnect Task Manager.

Users accessing the AmosConnect server see the following login screen:

The login website reveals the Post Office ID, this ID identifies the AmosConnect server and is tied to the software license.

The following code belongs to the authentication method implemented in mail_user.php. Note the call to authenticateBackdoorUser():

authenticateBackdoorUser() is implemented as follows:

The following code snippet shows how an attacker can obtain the SysAdmin password for a given Post Office ID:

Conclusions and thoughts

Vessel networks are typically segmented and isolated from each other, in part for security reasons. A typical vessel network configuration might feature some of the following subnets:

· Navigation systems network. Some of the most recent vessels feature “sail-by-wire” technologies; the systems in charge of providing this technology are located in this network.

· Industrial Control Systems (ICS) network. Vessels contain a lot of industrial machinery that can be remotely monitored and operated. Some vessels feature a dedicated network for these systems; in some configuration, the ICS and Navigation networks may actually be the same.

· IT systems network. Vessels typically feature a separate network to support office applications. IT servers and crew members’ work computers are connected to this network; it’s within this network that AmosConnect is typically deployed.

· Bring-Your-Own-Device networks. Vessels may feature a separate network to provide internet connectivity to guests or crew members’ personal devices.

· SATCOM. While this may change from vessel to vessel, some use a separate subnet to host satellite communications equipment.

While the vulnerabilities discussed in this blog post may only be exploited by an attacker with access to the IT systems network, it’s important to note that within certain vessel configurations some networks might not be segmented, or AmosConnect might be exposed to one or more of these networks. A typical scenario would make AmosConnect available to both the BYOD “guest” and IT networks; one can easily see how these vulnerabilities could be exploited by a local attacker to pivot from the guest network to the IT network. Also, some the vulnerabilities uncovered during our SATCOM research might enable attackers to access these systems via the satellite link.

All in all, these vulnerabilities pose a serious security risk. Attackers might be able to obtain corporate data, take over the server to mount further attacks or pivot within the vessel networks.

References:

http://www.kb.cert.org/vuls/id/586501

https://thenextweb.com/insider/2017/07/18/welp-even-ships-are-hackable-now/#.tnw_Y0uqUj76

https://shiptracker.shodan.io/

https://ioactive.com/alerts/satellite-satcom-security-assurance.html

/a-wake-up-call-for-satcom-security/

http://www.stratosglobal.com/products/the%20stratos%20advantage/amosconnect.aspx

RESEARCH | December 9, 2015

Maritime Security: Hacking into a Voyage Data Recorder (VDR)

By Ruben Santamarta

In 2014, IOActive disclosed a series of attacks that affect multiple SATCOM devices, some of which are commonly deployed on vessels. Although there is no doubt that maritime assets are valuable targets, we cannot limit the attack surface to those communication devices that vessels, or even large cruise ships, are usually equipped with. In response to this situation, IOActive provides services to evaluate the security posture of the systems and devices that make up the modern integrated bridges and engine rooms found on cargo vessels and cruise ships. [1]

There are multiple facilities, devices, and systems located on ports and vessels and in the maritime domain in general, which are crucial to maintaining safe and secure operations across multiple sectors and nations.

Port security refers to protecting all of these assets from acts of piracy, terrorism, and other unlawful activities, such as smuggling. Recent activity appears to demonstrate that cyberattacks against this sector may have been underestimated. As threats evolve, procedures and policies must improve to take these new attack scenarios into account. For example,https://www.federalregister.gov/articles/2014/12/18/2014-29658/guidance-on-maritime-cybersecurity-standards

/wp-content/uploads/2015/12/663784.pdf

This blog post describes IOActive’s research related to one type of equipment usually present in vessels, Voyage Data Recorders (VDRs). In order to understand a little bit more about these devices, I’ll detail some of the internals and vulnerabilities found in one of these devices, the Furuno VR-3000.

What is a Voyage Data Recorder?

(http://www.imo.org/en/OurWork/Safety/Navigation/Pages/VDR.aspx ) A VDR is equivalent to an aircraft’s ‘BlackBox’. These devices record crucial data, such as radar images, position, speed, audio in the bridge, etc. This data can be used to understand the root cause of an accident.

Real Incidents

Several years ago, piracy acts were on the rise. Multiple cases were reported almost every day. As a result, nation-states along with fishing and shipping companies decided to protect their fleet, either by sending in the military or hiring private physical security companies.

On February 15, 2012, two Indian fishermen were shot by Italian marines onboard the Enrica merchant vessel, who supposedly opened fire thinking they were being attacked by pirates. This incident caused a serious diplomatic conflict between Italy and India, which continues to the present. https://en.wikipedia.org/wiki/Enrica_Lexie_case

‘Mysteriously’, the data collected from the sensors and voice recordings stored in the VDR during the hours of the incident was corrupted, making it totally unusable for authorities to use during their investigation. As this story, from Indian Times, mentions the VDR could have provided authorities with crucial clues to figure out what really happened.

http://timesofindia.indiatimes.com/city/chennai/Lost-voice-data-recorder-may-cost-India-Italian-marines-case/articleshow/18942389.cms

Curiously, Furuno was the manufacturer of the VDR that was corrupted in this incident. This Kerala High Court’s document covers this fact: http://indiankanoon.org/doc/187144571/ However, we cannot say whether the model Enrica Lexie was equipped with was the VR-3000. Just as a side note, the vessel was built in 2008 and the Furuno VR-3000 was apparently released in 2007.

Just a few weeks later, on March 1, 2012, the Singapore-flagged cargo ship MV. Prabhu Daya was involved in a hit-and-run incident off the Kerala Coast. As a result, three fishermen were killed and one more disappeared and was eventually rescued by a fishing vessel in the area. Indian authorities initiated an investigation of the accident that led to the arrest of the MV. Prabhu Daya’s captain.

During that process, an interesting detail was reported in several Indian newspapers.

http://www.thehindu.com/news/national/tamil-nadu/voyage-data-recorder-of-prabhu-daya-may-have-been-tampered-with/article2982183.ece

So, What’s Going on Here?

From a security perspective, it seems clear VDRs pose a really interesting target. If you either want to spy on a vessel’s activities or destroy sensitive data that may put your crew in a difficult position, VDRs are the key.

Understanding a VDR’s internals can provide authorities, or third-parties, with valuable information when performing forensics investigations. However, the ability to precisely alter data can also enable anti-forensics attacks, as described in the real incident previously mentioned.

As usual, I didn’t have access to the hardware; but fortunately, I played some tricks and found both firmware and software for the target VDR. The details presented below are exclusively based on static analysis and user-mode QEMU emulation (already explained in a previous blog post). [2]

Figure: Typical architecture of a VR-3000

Basically, inside the Data Collecting Unit (DCU) is a Linux machine with multiple communication interfaces, such as USB, IEEE1394, and LAN. Also inside the DCU, is a backup HDD that partially replicates the data stored on the Data Recording Unit (DRU). The DRU is protected against aggressions in order to survive in the case of an accident. It also contains a Flash disk to store data for a 12 hour period. This unit stores all essential navigation and status data such bridge conversations, VHF communications, and radar images.

The International Maritime Organization (IMO) recommends that all VDR and S-VDR systems installed on or after 1 July 2006 be supplied with an accessible means for extracting the stored data from the VDR or S-VDR to a laptop computer. Manufacturers are required to provide software for extracting data, instructions for extracting data, and cables for connecting between a recording device and computer.

The following documents provide more detailed information:

Furuno Vr3000 LivePlayer Version 4 Operator’s Manual for Version 2.xx.

A Wake-up Call for SATCOM Security

By Ruben Santamarta

During the last few months we have witnessed a series of events that will probably be seen as a tipping point in the public’s opinion about the importance of, and need for, security. The revelations of Edward Snowden have served to confirm some theories and shed light on surveillance technologies that were long restricted.

We live in a world where an ever-increasing stream of digital data is flowing between continents. It is clear that those who control communications traffic have an upper-hand.

Satellite Communications (SATCOM) plays a vital role in the global telecommunications system. Sectors that commonly rely on satellite networks include:

Aerospace
Maritime
Military and governments
Emergency services
Industrial (oil rigs, gas, electricity)
Media

It is important to mention that certain international safety regulations for ships such as GMDSS or aircraft’s ACARS rely on satellite communication links. In fact, we recently read how, thanks to the SATCOM equipment on board Malaysian Airlines MH370, Inmarsat engineers were able to determine the approximate position of where the plane crashed.

IOActive is committed to improving overall security. The only way to do so is to analyze the security posture of the entire supply chain, from the silicon level to the upper layers of software.

Thus, in the last quarter of 2013 I decided to research into a series of devices that, although widely deployed, had not received the attention they actually deserve. The goal was to provide an initial evaluation of the security posture of the most widely deployed Inmarsat and Iridium SATCOM terminals.

In previous blog posts I’ve explained the common approach when researching complex devices that are not physically accessible. In these terms, this research is not much different than the previous research: in most cases the analysis was performed by reverse engineering the firmware statically.

What about the results?

Insecure and undocumented protocols, backdoors, hard-coded credentials…mainly design flaws that allow remote attackers to fully compromise the affected devices using multiple attack vectors.

Ships, aircraft, military personnel, emergency services, media services, and industrial facilities (oil rigs, gas pipelines, water treatment plants, wind turbines, substations, etc.) could all be affected by these vulnerabilities.

I hope this research is seen as a wake-up call for both the vendors and users of the current generation of SATCOM technology. We will be releasing full technical details in several months, at Las Vegas, so stay tuned.

The following white paper comprehensively explains all the aspects of this research IOActive_SATCOM_Security_WhitePaper