Ships can’t be hacked. Wrong

I get a lot of objections from ships captains when discussing security flaws in ships, so I felt it worthwhile looking at these in some detail.

The usual response is ‘ships can’t be hacked.’ When I dig further, what they usually seem to mean is that ‘processes aboard the bridge mean that the captain or officers will spot the issue and take manual control’

This implies several important issues:

• That the hack is detectable by a ships crew.
• That the crew are actively comparing digital navigation aids with manual navigation techniques (e.g. looking out of the bridge windows!)
• That the manual controls are actually usable and haven’t been hacked themselves
• That there are offline backup systems in the event that primary aids aren’t available (e.g. paper charts)
• That anyone actually checked the digital systems are reporting correctly

I’ve been working in IT security for over 20 years. I see the same pattern when security flaws are discovered in an industry for the first time. Back the early 2000’s, few industries outside financial services and government took security seriously. ‘Why would hackers be interested in us’ was the usual objection.

Over time, as FS and gov improved their security, other industries became easier targets for hackers looking to monetise their gains. I remember charities objecting ‘We’re a charity working for good causes, why would hackers attack us’ – yet soon they were being used for validating stolen credit card data through small test charges.

Hackers will come to every industry, starting with those with the weakest security. Why develop hugely costly nation-state grade malware to hack a bank when you can exploit Windows XP systems in shipping and generate similar returns?

So why don’t ships captains believe that hacking is possible?

They’ve spent years training and working up the ships hierarchy, gaining significant expertise. They are experts in their field and have doubtless dealt with some very difficult situations at sea. They have precise navigation skills that aren’t that far removed from those first used in the 1600s. Only in the last few years have digital controls and navigation systems entered shipping.

It’s not unreasonable for a captain to assume that, if digital systems started failing, they could fall back to paper charts and manual control. The problem is; hacking doesn’t work like that.

Hacking and security are not binary. One can’t state that a system is/isn’t secure, only that the risk and threat profiles are different. To explicitly state that a ship can’t be hacked therefore implies that the captain doesn’t understand the threat and risk profile.

Knowing you’ve been hacked

A Ponemon data breach report in 2017 showed that it took US organisations an average of 206 days to detect a data breach. That’s a statistic from shore-based organisations, where IT and IT security personnel and expertise are usually available.

So how does a ships crew, where perhaps one person on the crew has a small amount of basic IT skill, detect a breach of a vessel?

If you don’t know, you can’t take action. At what point do you decide that the navigation systems are no longer trustworthy? Who makes that decision? The inexperienced third officer? Do they wake the captain?

Who decides to take the vessel out of track control mode? Remember, security isn’t binary – something is a bit odd, but all the digital systems seem to agree with each other. A security incident doesn’t have to involve alarming ransomware taking control of an ECDIS, it can be much more subtle than that.

Even with years of forensics experience, sometimes investigators struggle to determine the cause of an incident. I remember one case where a human hair in a switch port was causing public IP addresses to be spoofed on the internal network. We didn’t believe it either, until we removed the hair and replaced it several times, at which point the spoofing stopped and started consistently!

So you take action, you assess the incident and decide you need help. You pick up the satphone to HQ. The satphone isn’t working as it uses the same, vulnerable satellite terminal that the hacker exploited. What next?

Looking out of the window

Experienced captains understand the importance of looking out of the window. This is critical in order to compare the real world with what the digital systems are reporting.

Three problems here: First, younger crews with less experience of manual navigation are too willing to trust the digital screens. Screen fixation is a common problem in shipping incidents

Second: officers of the watch get complacent and even fall asleep. That’s why we have Bridge Navigational Watch and Alarm Systems (BNWAS) to keep tabs on them. However, the alarm and escalation procedure usually takes several minutes to trigger. That’s often enough to effect a hack.

Finally, one needs external references to navigate manually. That’s easy when in sight of shore, but at sea on an overcast day or night it becomes much harder. You’ve also got to unpick any navigational errors that could have already occurred, prior to an incident being detected.

The myth of manual control

Vessels are required to practice manual steering control. It’s one of the very last systems on board that has a genuine manual control, but it is still painful to operate manually. Steering instructions are by VHF or telephone from bridge to steering room; this all ties up busy engineering resource that is likely to be required elsewhere on the vessel whilst arriving in port. It is a royal pain and lends itself to incidents. We have ships engineers on our team who have been there during manual control exercises.

There is also potential to interfere prior to manual control being implemented. Steering control from the bridge can be either automatic (e.g. ECDIS in track control mode), heading – where the rudder maintains a heading, or manual bridge control where an OOW turns a small wheel.

This helm information is transmitted electrically using a telemotor. Full manual control involves disconnecting the telemotor and turning a wheel in the steering room that physically moves valves to control hydraulic rams that operate the rudder.

Call a tug if you are anywhere near land or a busy separation scheme and having steering issues.

Maybe not an issue for the captain, but the vessel operator won’t be impressed with the towage charges or for lateness to port.

Manual engine control is really quite difficult, particularly when manoeuvring:

Control is usually direct from the bridge – the engine control levers directly control the engine control systems. These communicate using serial data networks that can be manipulated.

Control can also be managed from the engine control room, through PLCs and HMIs. Again, serial data communications that can be tampered with.

Manual control of a ships engine usually involves three sticks: one for the fuel pump, one for start air and one for engine direction. Fuel pump rate does not directly correlate with engine speed – there are many variables that affect this, even air humidity will change how the engine performs for a given lever setting.

Shifting the engine to stop or reverse involves using start air to restart each time. Air tanks usually contain enough air for 10 starts under automatic control, requiring 45 minutes or so to recharge. Under manual control, even a skilled operator will probably only get 5 engine starts. That’s 45 minutes and potentially 5 changes of propeller direction.

Imagine a junior officer trying to deal with failing navigation systems, all bridge sensors offline, steering gear not responding and engine levers inoperative. Manual control is an option but, as a pilot, I know very well how quickly one can become overloaded with information and become incapable of dealing with a situation. Fixation on a single error quickly leads to loss of the wider picture.

Further, any number of minor incidents or technical dependencies can leave a vessel dead in the water. My colleague remembers a simple overlooked microswitch leading to start air not recharging and the vessel quickly becoming immobile.

Those serial control devices are usually connected to serial networks. As we showed at Infosecurity Europe this year, hacking of serial networks is not difficult. Similar problems have been known about for years in utilities industrial control systems (ICS). The same serial to IP convertors that we’ve compromised in utilities are used on vessels. Compromise any point on the serial network and that ‘manual control’ doesn’t work any more

Offline backup systems

Most vessels will have two ECDIS, or electronic chart systems, for redundancy. Few vessels now carry backup paper charts, as they are expensive and hard to keep updated. A colleague remembers collecting chart updates from the ships agent at each port, which he had to cut out and paste on to the chart.

Having two redundant systems sounds like a good idea. However, most of the ECDIS units we’ve tested have been running old operating systems or were missing critical patches and were trivial to compromise. Two easily hacked ECDIS units on board. Great!

Both ECDIS are often updated at the same time, removing the benefit of redundancy. This often has to be done, as otherwise there would be inconsistencies in the charts on each ECDIS

Checking digital systems

There are huge assumptions made that only one digital system on the bridge will be affected. Therefore it will be obvious to the officers that something is awry. But security isn’t binary…

ECDIS and other digital aids take feeds from multiple sources. These include GPS, log, gyro, echo sounder, AIS etc. Exploiting the serial networks that these devices use to communicate can result in rogue position data being sent to all navigation systems.

The digital systems on the bridge all agree with each other. It’s just outside that’s wrong.

It doesn’t even have to be the data feeds that can be made to misreport; we’ve shown how to inject offsets in to both ECDIS and synthetic radar, so the primary digital cross-check of position has been tampered with.

Here’s an offset injected in to a synthetic radar:

And here’s an offset being injected in to an ECDIS. Note the vessel has ‘moved’ from one side of a breakwater to the other:

Denial

To paraphrase Arthur Schopenhauer, experts in their field will often attack those who question their expertise. One doesn’t need to be an expert navigator or ships officer in order to find issues in shipping systems.

Change has been fast on board vessels; digitalisation has come faster than many may have expected.

Talk of autonomous shipping no doubt concerns many mariners – will they be replaced by computers?

Personally, I hope not. It is those experienced seafarers that have the best chance of spotting security issues when at sea.

Perhaps we have the same vested interests? We believe that experienced captains and officers are the best people to be in control of a vessel, not computers. We believe that autonomous shipping is potentially a bad thing, as it makes hacking easier to effect.

Conclusion

What should ships captains do? First, accept that it is possible to hack a ship. We’ve proved it enough times on different shipping systems.

Then, acknowledging that, start to build ways to detect and defend the vessel. Traditional seafaring skills aren’t enough to defend against cyber incidents, so actively learn what to look for. Ensure you have ready access to shore based support who can help you diagnose and respond.

Human eyes aren’t always capable of detecting hacking incidents. Some are insidious – minor changes that confuse the crew. Others are instant and critical, such as a ballast pump suddenly starting, uncommanded.

We can learn from aviation incidents – often the initial cause is something as simple as a blown bulb or frozen pitot that consumes the crew’s attention, whilst something else worse is developing elsewhere.