IOActive has long been interested in the security of satellite communications. In 2014, it published a report on “multiple high risk vulnerabilities” in all the satellite systems it studied.
More recently, it was prompted to examine the security of ship-based satellite communications following the release of a Shodan tool that tracks the location of VSAT systems (typically employed by vessels to provide Internet connectivity at sea). In particular, it examined an Inmarsat product, AmosConnect 8 (AC8), used by ships at sea to optimize and compress data in transit to reduce satellite costs.
“We have identified two critical vulnerabilities in this software,” blogged IOActive principal security consultant Mario Ballano on Thursday, “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.”
The two vulnerabilities are a blind SQL injection in the login form; and a privileged backdoor account. The former, writes Ballano, allows “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.”
For the latter, he writes: “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.”
These vulnerabilities can only be exploited by an attacker with access to the vessel’s IT systems network. In theory, this could be separated from its operational network (ICS), its navigation network, its ‘guest’ BYOD network, and its ‘SATCOM’ network hosting the satellite communications equipment. Or there might be no segmentation — there is unlikely to be complete segmentation.
“All in all,” writes Ballano, “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.”
CERT agrees. Its Vulnerability Note VU#586501 comments, “Attackers having network access to an AmosConnect server can log into it using a backdoor account that has 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.”
The NIST National Vulnerability Database classifies the vulnerability (CVE-2017-3222) as critical, with a severity score of 9.8.
Ballano adds, “some of the vulnerabilities uncovered during our SATCOM research might enable attackers to access these systems via the satellite link.”
However, CERT also adds, “As of July 2017, support for the Inmarsat AmosConnect8 service has been decommissioned and clients will no longer be able to download the software from the software distribution website.”
This has been confirmed in an Inmarsat statement emailed to SecurityWeek:
“Inmarsat had begun a process to retire AmosConnect 8 from our portfolio prior to IOActive’s report and, in 2016, we communicated to our customers that the service would be terminated in July 2017.
“When IOActive brought the potential vulnerability to our attention, early in 2017, and despite the product reaching end of life, Inmarsat issued a security patch that was applied to AC8 to greatly reduce the risk potentially posed. We also removed the ability for users to download and activate AC8 from our public website.
“Inmarsat’s central server no longer accepts connections from AmosConnect 8 email clients, so customers cannot use this software even if they wished too.”
The problem with this statement is that it differs from the disclosure timeline provided to SecurityWeek by Ballano. IOActive discovered the vulnerabilities in September 2016, and sent a vulnerability report to Inmarsat in October 2016. Inmarsat says it was told “early in 2017”. In reality, in November 2016, Inmarsat acknowledged the vulnerabilities, claimed they were only exploitable locally, and said they would be fixed.
At the end of January, Inmarsat told IOActive that a fix would be available on March 1, 2017; and later pushed this back to March 31. At the end of April, with no fix, IOActive warned that it would imminently disclose the vulnerabilities, and gave a week’s notice on disclosure. IOActive received no further communication from Inmarsat, but did not publicly disclose the vulnerabilities until this week. Noticeably, Inmarsat never told IOActive that a fix had been produced.
Meanwhile, Inmarsat, has retired the product and advises customers to ‘revert’ to the earlier AC7. It says there is no problem because “customers cannot use this software [AC8] even if they wished too.”
But there may still be a problem. Ballano told SecurityWeek, “Bear in mind that [AC8] might be still vulnerable and open to attacks even if the Inmarsat infrastructure no longer accepts these clients. Customers would need to uninstall it and move to an alternative solution.”
Since writing this report, Inmarsat has provided a copy of the communication it sent to customers. Dated May 4, 2016 it confirms the intention to retire AC8 on June 30, 2017. The long term intention is to migrate customers to its newer high speed broadband Fleet Xpress product, while continuing to support AC7 during the transition.
However, this doesn’t explain the poor communication between Inmarsat and IOActive. The bottom line is that Inmarsat AC8 customers were potentially using a product that Inmarsat knew to have vulnerabilities between October 2016 and July 2017. It is still important that all customers that have used AC8 should physically remove the software from their systems. It remains vulnerable even if not used.
Related: Critical Vulnerabilities Found in Nuke Plant Radiation Monitors
Related: Critical Vulnerability Found in Diebold ATM Machine
