Tag: Satellite communication

RESEARCH | March 16, 2022

Wideye Security Advisory and Current Concerns on SATCOM Security

By Ethan Shackelford

In accordance with our Responsible Disclosure Policy1, we are sharing this previously unpublished, original cybersecurity research, since the manufacturer of the affected products in the Wideye brand, Addvalue Technologies Ltd., has been non-responsive for more than 3-years after our initial disclosure and we have seen similar vulnerabilities exploited in the wild during the War in Ukraine.2 IOActive disclosed the results of the research back in 2019 and successfully connected with AddValue Technologies Ltd, the vulnerable vendor. Unfortunately, we have not received any feedback from the manufacturer after providing the coordinated, responsible disclosure of the report in 2019.

Depending on where in the world you live or work, you may be familiar with satellite internet. A variety of equipment and services exist in this field, ranging from large-scale static installations to smaller, portable equipment for use in the field or where larger installations are not possible. Satellite internet systems also make connectivity and communication possible under circumstances where traditional communication infrastructure is unavailable due to natural disaster, isolation, or deliberate disruption. In such situations, maintaining availability and ensuring these systems are well secured is of vital importance.

IOActive and others have done work on commercial satellite communication (SATCOM) terminals. Unfortunately, we have yet to see a significant improvement in this industry’s security posture. Back in 2014,3 Ruben Santamarta presented the findings documented in a whitepaper titled “A Wake-Up call for SATCOM Security.” In 20184 he presented another whitepaper, “Last Call for SATCOM Security,” where he shared a plethora of vulnerabilities and real-world attack scenarios against multiple SATCOM terminals across different sectors. These dense, extensively referenced whitepapers, include an introduction to SATCOM architecture and threat scenarios, as well as definitions of some key technical terms.

The iSavi5 and SABRE Ranger 50006 Satellite Terminals, produced by Wideye7, were included in IOActive’s SATCOM research. iSavi is an affordable, personal satellite terminal developed for Inmarsat’s8 IsatHub service. It is lightweight, highly portable, and quick and easy to set up with no technical expertise or training needed. iSavi is intended as a personal device and may not have a publicly accessible IP address. The SABRE Ranger 5000 is a compact machine-to-machine (M2M) satellite terminal. It is intended to be connected 24/7, provides remote access to equipment, and is used in SCADA applications.

IOActive conducted a black-box security assessment of these two devices in order to identify their attack surfaces and determine their overall security posture. This included dynamic penetration testing using both industry-standard techniques as well as tools and techniques developed by IOActive. Dynamic testing included network and physical interfaces. Additionally, we performed static analysis of device firmware, consisting of binary reverse engineering and review.

IOActive identified numerous security issues, spanning multiple domains and vulnerability classes. Several the identified vulnerabilities have the potential to lead to full or partial device and communication compromise, as well as leak information about components of the system, including GPS location coordinates, to unauthorized parties. The issues can be grouped in the following broad categories:

  1. Authentication and Credential Management
  2. Data Parsing
  3. Networking
  4. Firmware Security
  5. Information Disclosure

IOActive found the overall security posture of the Wideye iSavi and Ranger systems to be poor. In some areas, attempts were made to secure the devices, but these attempts proved inadequate. In other areas, no attempts were made at all, even in areas where specific threats are well established in the realm of device security.

IOActive provided coordinated, responsible disclosure to the manufacturer in 2019, but have not received any feedback after numerous attempts.

As it has been more than three years and there is clear, public information that vulnerabilities in SATCOM terminals are actively being exploited by nation-state threat actors,9 we believe it is in the best interests for us to disclose this information so that all stakeholders can make informed risk decisions and respond to these threats.

As of the posting of this blog entry, IOActive has confirmed that all the initially disclosed vulnerabilities are still present in the most current, publicly available firmware images from the Wideye website.

Due to these heightened risks, IOActive will be releasing the full details of the vulnerabilities in both the iSavi and Ranger 5000 satellite terminals in approximately 14-days.

We are offering the additional two-week window to allow impacted stakeholders to assess their risks and put compensating controls in place.

You can read additional details about our decision to publicly disclose this research in the blog post here.

 

1https://ioactive.com/disclosure-policy/

2https://www.reuters.com/business/aerospace-defense/satellite-firm-viasat-probes-suspected-cyberattack-ukraine-elsewhere-2022-02-28/

3https://ioactive.com/pdfs/IOActive_SATCOM_Security_WhitePaper.pdf

4IOActive whitepaper | Last Call for SATCOM Security

5https://www.wideye.com.sg/default/index.php?option=com_content&view=article&id=128&Itemid=11

6https://www.wideye.com.sg/default/index.php?option=com_content&view=article&id=141&Itemid=225

7https://www.wideye.com.sg/default/

8https://www.inmarsat.com/en/index.html

9https://www.reuters.com/business/aerospace-defense/satellite-firm-viasat-probes-suspected-cyberattack-ukraine-elsewhere-2022-02-28/

RESEARCH | August 10, 2018

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:
https://shiptracker.shodan.io/
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

 

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.

 

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:
After spending some hours reversing the different binaries, it was clear that security is not one of its main strengths of this equipment. Multiple services are prone to buffer overflows and command injection vulnerabilities. The mechanism to update firmware is flawed. Encryption is weak. Basically, almost the entire design should be considered insecure.
 

Take this function, extracted from from the Playback software, as an example of how not to perform authentication. For those who are wondering what ‘Encryptor’ is, just a word: Scytale.

 

Digging further into the binary services we can find a vulnerability that allows unauthenticated attackers with remote access to the VR-3000 to execute arbitrary commands with root privileges. This can be used to fully compromise the device. As a result, remote attackers are able to access, modify, or erase data stored on the VDR, including voice conversations, radar images, and navigation data.

VR-3000’s firmware can be updated with the help of Windows software known as ‘VDR Maintenance Viewer’ (client-side), which is proprietary Furuno software.

 

The VR-3000 firmware (server-side) contains a binary that implements part of the firmware update logic: ‘moduleserv’

 

This service listens on 10110/TCP.

 

Internally, both server (DCU) and client-side (VDR Maintenance Viewer, LivePlayer, etc.) use a proprietary session-oriented, binary protocol. Basically, each packet may contain a chain of ‘data units’, which, according to their type, will contain different kinds of data.

 

Figure: Some of the supported commands
‘moduleserv’ several control messages intended to control the firmware upgrade process. Let’s analyze how it handles a ‘SOFTWARE_BACKUP_START’ request:
An attacker-controlled string is used to build a command that will be executed without being properly sanitized. Therefore, this vulnerability allows remote unauthenticated attackers to execute arbitrary commands with root privileges.
Figure: ‘Moduleserv’ v2.54 packet processing
Figure: ‘Moduleserv’ v2.54 unsanitized system call

 

At this point, attackers could modify arbitrary data stored on the DCU in order to, for example, delete certain conversations from the bridge, delete radar images, or alter speed or position readings. Malicious actors could also use the VDR to spy on a vessel’s crew as VDRs are directly connected to microphones located, at a minimum, in the bridge.

 

However, compromising the DCU is not enough to cover an attacker’s tracks, as it only contains a backup HDD, which is not designed to survive extreme conditions. The key device in this anti-forensics scenario would be the DRU. The privileged position gained by compromising the DCU would allow attackers to modify/delete data in the DRU too, as this unit is directly connected through an IEEE1394 interface. The image below shows the structure of the DRU.
Figure: Internal structure of the DRU

Before IMO’s resolution MSC.233(90) [3], VDRs did not have to comply with security standards to prevent data tampering. Taking into account that we have demonstrated these devices can be successfully attacked, any data collected from them should be carefully evaluated and verified to detect signs of potential tampering.

 

IOActive, following our responsible disclosure policy, notified the CERT/CC about this vulnerability in October 2014. The CERT/CC, working alongside the JPCERT/CC, were in contact with Furuno and were able to reproduce and verify the vulnerability. Furuno committed to providing a patch for their customers “sometime in the year of 2015.” IOActive does not have further details on whether a patch has been made available.
 
References
————–

RESEARCH | April 17, 2014

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