An equipment room containing PLCs and control gear for critical systems was located some distance from the main engine control room but required frequent adjustments via a local HMI.
To avoid leaving the control room, a PC was installed in the equipment room. Teamviewer was used to enable remote access from the control room.
The remote PC bridged between the corporate network and the OT network. The Teamviewer password was on a label above a monitor in the control room, allowing access to the remote PC from the wider Internet.
A vulnerability discovered in the network switches of the OT equipment allowed a shared password to be recovered. With this, it was possible to wipe the configuration of PLCs and switches, stopping all OT systems from functioning.
Scenario 2: Third-party mistakenly allows access to critical serial networks
The load computer was located on the bridge of the vessel. This required network connectivity between two PCs, and to several remote Serial->IP convertors used to read information from ballast tanks.
The third-party vendor used the available network sockets on the bridge to interface to these. The network design of the vessel meant that any unrecognised or unregistered devices were placed in an isolated VLAN.
This allowed the PCs to interact with the Serial->IP convertors. However, network sockets in the passenger space used the same mechanism.
A laptop connected to a network port in the passenger space could therefore inject traffic onto the serial network used for ballast tank readings. Random data injected here prevented the bridge systems reading ballast tank levels, causing multiple alarms and the requirement to take manual dippings until the problem was resolved.
Scenario 3: Remote firmware update causes operational issues
The NOx scrubber system was installed by a third party and contained significant control gear and remote monitoring.
The ship owner provided a dedicated VLAN for the system to communicate over VSAT. It was found that the HMI providing remote connectivity was also attempting to download a firmware and configuration from a remote server using unsecured HTTP.
It was possible to update the firmware of the HMI to a malicious one, and remotely interact with the control gear of the scrubber. The configuration of the PLCs in the scrubber was wiped, preventing control and monitoring of the scrubber. The engines needed to be operated at reduced power to avoid damage to the scrubber system.
Scenario 4: Accessible HMI leaks high-value passwords
An HMI in a HVAC room on the vessel had access to a limited number of screens, only concerning control of the HVAC equipment and monitoring of power systems on the vessel.
By using the “Print” menu, it was possible to break out of the HMI software and access the underlying operating system.
All HMIs used a shared Windows network, including SMB shares. One of the HMIs in the main control room had a file called “passwords.txt” left on this share.
This contained operator and administrator passwords for all the HMIs and PLCs, left from when the vessel was commissioned. These passwords were found to be common across all vessels using that ICMS (Integrated Control and Monitoring System) vendor.
Conclusion
Getting the basics dealt with is a good start. Issues with passwords, patches and people are widespread on vessels. Checklists work when dealing with these basics.
A checklist is not the way to address all security issues; to borrow a phrase from aviation – tyres need to be kicked and fires need to be lit. Hard evidence is needed that policies are actually adhered to when at sea.
Finally, vessel security needs to be tested thoroughly, as cyber criminals don’t use checklists.
SHIP IP LTD – Remote internal/external Vulnerability &
Penetration Testing
TRUST OUR NETWORK – WE GUARANTEE BEST PRICES!
READ MORE
Source: pentestpartners
