Sinking a ship and hiding the evidence

Our earlier work on Voyage Data Recorder manipulation got us thinking about how a malicious individual or organisation might bring about the demise of a ship and hide the evidence.

There are plenty of ways to get malware on to a ship. Whether it’s via satcoms, phishing, USB, crew Wi-Fi, dodgy DVDs etc.

Now the hacker has a foothold on the ship, what would they do?

If one was suitably motivated, perhaps by a nation state or a crime syndicate, one could bring about the sinking of a ship. Maybe one wanted to delay an LNG shipment in winter to a country running out of gas, affecting spot prices. Maybe one wanted to affect shipping of critical components, or just influence the stability of a country dependent on maritime cargo?

How would you do it?

Many of the critical ships control systems communicate and are controlled using NMEA 0183 messaging. It’s a superset of the same messaging format that GPS devices use to communicate.

The messages are usually exchanged using RS485 serial datacomms, either directly or encapsulated over IP networks. In some cases, CAN is used as a bridge between IP and serial. Any point where serial meets IP is a point where the hacker can potentially access the messaging system. IP to serial convertors, GPS receivers, the VDR etc are all devices that can provide a link on to these critical systems.

What uses NMEA?

• Autopilots
• GPS
• VDRs
• Propulsion control
• Dynamic positioning
• Engine control
• Ballast control
• Digital compasses

Probably the easiest way to capsize a ship would be for a hacker to mimic the Hoegh Osaka incident.

The ship is a car carrier, loaded at Southampton docks. Vessel trim and metacentric height are critical to its stability. In this case, ballast tanks weren’t properly filled and the load hadn’t been correctly assessed, resulting in the metacentric height being dangerously high, hence the ship developed a heavy list during a tight turn out of the port. Fortunately, the prevailing wind pushed the vessel on to the shallows of the Bramble Bank, avoiding a capsize. Had this happened, the shipping lane in to the busy dock would also have been blocked, causing huge problems for shipping.

For a hacker to achieve this, they would need to do the following:

Access the vessel network, either through the satcom terminal, an infected crew or company laptop, or maybe through a physical implant directly on to the serial network.

Locate a serial to IP convertor, or any other serial endpoint on the network, such as a GPS.

Compromise the convertor, bearing in mind that few have their admin passwords changed. Those that do will likely have such out of date firmware that they’re easily exploited anyway.

For example, many Moxa device servers were vulnerable to a firmware downgrade attack that allowed trivial compromise.

Modern ballast control systems provide remote monitoring and operation from the bridge, usually running on a PC.

So, the attacker would simply send the appropriate serial data to the ballast pump controllers, causing them all to pump from port to starboard ballast tanks.

That change in trim alone could cause a capsize.

If the change in ballast wasn’t enough to sink the vessel by itself, when a list had started to develop, send a NMEA message to the autopilot, commanding a turn to starboard.

Or, send a helm message commanding the same turn direction

The list, combined with the change in stability when turning, is likely to cause a capsize

Sound far-fetched? Read up on the MV Cougar Ace car carrier incident if you’re not convinced what ballast changes can do to ships:

https://en.wikipedia.org/wiki/MV_Cougar_Ace – $117M of vehicles had to be crushed as a result, even though the ship wasn’t lost.

Hiding the evidence

Vulnerabilities in a Voyage Data Recorder and Remote Storage Module mean that any data stored on them is subject to tampering.

During a post-incident investigation, the VDR may be queried to determine what went wrong. Forensic techniques may be employed in order to recover data. However, if the attacker can gain privilege on the device, there can be no trust in the integrity of that data.

If the VDR data is suspect, then in a traditional forensic investigation one would move on to other data sources. The problem here is that many on-ship devices are old and their software is likely to be out of date.

Conclusion

Consider that some ECDIS devices still run Windows XP, and to a lesser degree Windows NT, released in 1993 don’t forget.

Any half-decent attacker can happily abuse these operating systems all day long and still cover their tracks effectively. This means that trying to establish confidence in the data that these systems hold will be difficult at best, impossible at worst.

To compound the problem, many OT devices don’t or can’t log activity. Those that do have such poor security as to render the data wide open to tampering.

Having no data or tampered data on board from which to investigate a shipping incident will make it very difficult to establish cause. A field day for hackers.

There’s some great VDR security research from IOActive here:

https://ioactive.com/maritime-security-hacking-into-a-voyage-data-recorder-vdr/