On the usefulness of penetration testing on ships
In an article published yesterday, the company Pen Test Partners, known for its blog posts on maritime cybersecurity, released a new, somewhat alarming article on the topic.
Apparently, we are no longer supposed to adopt an alarming tone, so let us try to analyze it calmly.
The company, which operates in the United Kingdom and the United States, conducts penetration tests at the request of its clients on different types of ships. In their article, they explain that each time they perform such work, they manage to identify information systems that few — sometimes none — of the crew members know about, or whose purpose they do not understand. This may seem surprising. However, there can be explanations (which the article does not highlight, preferring — somewhat excessively in my view — the buzz). Here are a few possible explanations:
A ship has a crew, but that crew is not necessarily permanent. It evolves over time according to operational needs and can become a real patchwork. The article does not mention this. From my own experience working on cybersecurity issues aboard several ships, the crews I encountered were fully aware of the roles of the various machines present on the bridge and elsewhere.
A shipowner is neither the designer nor the integrator of the vessel: the ship is delivered according to defined requirements. The owner therefore does not necessarily have detailed knowledge of the vessel itself (wiring, internal functioning of information systems, etc.). This may seem surprising, but the same situation exists in many other sectors (which non-IT company fully understands the wiring of all its buildings?).
Maintenance providers regularly install equipment aboard ships to perform preventive or corrective maintenance operations, often to analyze wear or investigate malfunctions in an installation. This is not surprising: maintenance staff cannot remain permanently onboard. Hence the use of tools such as TeamViewer to allow remote access to the equipment in question.
So am I surprised or shocked? No. The real vulnerability in this case is mainly the maintenance provider, who evidently did not apply appropriate security measures to remote maintenance operations. Where the article suggests that such discoveries are “business as usual” in the maritime world, this seems somewhat exaggerated, and it also overlooks the underlying reasons. Once again, the focus is on consequences rather than causes — which means the problem will likely recur.
Let us continue with the article.
On the shipowner’s side ashore, the article notes that nobody was aware of the existence of this machine. Surprising? Not really. Depending on the size of the vessel, the shipowner often has no in-house information systems expert, and reliance on subcontractors is very common.
Installed by a third party? Yes, as mentioned above — nothing unusual. The equipment was not labeled; this is not entirely surprising either, as it might have been a temporary installation (the article does not clarify this). If, however, the system was intended to remain permanently onboard, then the lack of labeling would indeed be more problematic. But if the shipowner’s contract granted broad control to the maintenance provider, it becomes understandable.
Another factor that contributed to the crew overlooking the machine on the bridge was that the computer in question did not have a “night mode”. On the bridge, in order to allow watch officers to better see outside at night, equipment typically includes functions that reduce screen brightness. The crew therefore simply covered the screen to avoid light disturbance.
Two RJ-45 cables were connected to the PC. The pentesters decided to disconnect it (after a risk assessment) and used a TAP device (Test Access Port) to capture network traffic safely. They identified NMEA0183 traffic broadcast in UDP on the network. According to the company, this is a fairly common case in industrial networks. I somewhat agree: on modern or medium-sized ships, perhaps — but on older vessels or ships operating under stricter navigation rules, it is less certain. What is possible is that some NMEA data fields were required by the equipment or remote installation (for example speed or heading), or that commands between bridge equipment and remote installations were exchanged via NMEA (for instance autopilot commands).
The NMEA frame headers contained the prefix “$IN”, typically used by bridge navigation instruments. After verification, the company discovered that one of the four ECDIS systems on the bridge transmitted the same information via a serial port where only the TX (transmit) wire was connected.
Connected to the “mystery box” was a Moxa serial converter like this one, unlabeled, with a shielded cable exiting it. Such cables are very difficult to trace on a ship in order to determine their origin or destination. After a risk assessment, the team decided to monitor the traffic on this cable and detected Modbus communications, with a “master” device reading registers from a “slave” device. The values read showed a value of 169. As the vessel was sailing at 16.9 knots, the two values were likely related. It could therefore represent information exchanged between the bridge and, for example, the engine systems.
After returning to port, the team investigated the computer itself, which ran Windows and acted as the Modbus master, regularly polling a slave device to obtain information. The difficulty with Modbus connections is that they require both sending and receiving information on the connection; it is therefore not possible to disconnect the transmit cable alone. It is thus likely that the Windows machine on the bridge could potentially write registers using this protocol. Tests performed by the team confirmed that read/write operations could indeed be performed from the bridge computer.
At the same time, the team attempted to trace the physical connection and eventually located it eleven decks below, connected to a serial interface linked to a PLC. The system was undocumented and had no IP address, but had additional connections that potentially linked it to other PLCs in the engine room. The Windows machine, for its part, had TeamViewer installed and was not up to date.
After investigation, it turned out that the contract with the subcontractor responsible for the system had been terminated several years earlier. The system had been designed (a very fashionable approach today — creating “data lakes” everywhere) to collect operational data from the engine systems and elsewhere (including ECDIS) in order to determine whether the ship’s performance was economical and efficient, and to attempt to optimize it.