At Infosecurity Europe this year, we demonstrated multiple methods to interrupt the shipping industry, several of which haven’t been demonstrated in public before, to our knowledge.

Some of these issues were simply through poor security hygiene on board, but others were linked to the protocols used and systems provided by maritime product vendors.

Tracking and hacking ships: satellite communications

Our earlier satcom work is here but we took this much further at the show:

Shodan already publishes a ship tracker. We think this only uses AIS data, publicly available. We’ve broken new ground by linking satcom terminal version details to live GPS position data.

This, we think, is the first ever VULNERABLE ship tracker. Two public data sets have been linked, so we now have a clickable map where vulnerable ships are highlighted with their real time position

It’s here http://ptp-shiptracker.herokuapp.com/ – note that we deliberately haven’t refreshed the data in use, ensuring it is out of date so that it can’t be used by hackers. We’ll refresh it in time.

Many satcom terminals on ships are available on the public internet. Many have default credentials, admin/1234 being very common. These passwords were found on a ship only two weeks ago:

So that’s an easy way to hijack the satellite communications and take admin rights on the terminal on board.

Hardware hacking the satellite terminal

We applied our expertise in IoT, automotive and SCADA hardware security to a Cobham (Thrane & Thrane) Fleet One satellite terminal. We haven’t seen much evidence in public of anyone looking hard at maritime satcom terminal hardware security before. They’re expensive, which may explain it!

Caveat: all of the vulnerabilities we cover here are resolved by setting a strong admin password, as per the manufacturers guidance. Either that, or they aren’t particularly significant. We found much more, but the more significant findings have to be disclosed privately to Cobham first!

First, we found that the admin interfaces were over telnet and HTTP. Pulling the firmware, we found a lack of firmware signing – the validation check was simply a CRC

Then, we discovered that we could edit the entire web application running on the terminal. That lends itself to attacks.

Further, there was no rollback protection for the firmware. This means that a hacker with some access could elevate privilege by installing an older more vulnerable firmware version.

Finally, we found the admin interface passwords were embedded in the configs, hashed with unsalted MD5.

Hardly ‘defence in depth’! Reminder: these are all fixed by setting a strong admin password. We found lots more, but can’t disclose these yet.

Sending a ship the wrong way: hacking the ECDIS

We often find a lack of network segregation on the vessel. Hack the satcom terminal and you’re on the vessel network.

ECDIS are the electronic chart systems that are needed to navigate. They can slave directly to the autopilot – most modern vessels are in ‘track control’ mode most of the time, where they follow the ECDIS course.

Hack the ECDIS and you may be able to crash the ship, particularly in fog. Younger crews get ‘screen fixated’ all too often, believing the electronic screens instead of looking out of the window.

We tested over 20 different ECDIS units and found all sorts of crazy security flaws. Most ran old operating systems, including one popular in the military that still runs Windows NT!

One interesting example had a poorly protected configuration interface. Using this, we could ‘jump’ the boat by spoofing the position of the GPS receiver on the ship. This is not GPS spoofing, this is telling the ECDIS that the GPS receiver is in a different position on the ship. It’s similar to introducing a GPS offset (which we can also do!) Here’s it jumping from one side to the other of Dover Harbour:

Blocking the English Channel?

Worse, we could reconfigure the ECDIS to make the ship appear to be a kilometre square:

This doesn’t sound bad, until you appreciate that the ECDIS often feeds the AIS transceiver – that’s the system that ships use to avoid colliding with each other.

So, simply spoof the ECDIS using the vulnerable config interface, ‘grow’ the ship and ‘jump’ it in to the shipping lanes.

Other ships AIS will alert the ships captain to a collision scenario. It would be a brave captain indeed to continue down a busy, narrow shipping lane whilst the collision alarms are sounding. Block the English Channel and you may start to affect our supply chain.

Going the wrong way: hacking NMEA 0183 messages

A completely different technique is to exploit the serial networks on board that control the Operation Technology (OT). The ethernet and serial networks are often ‘bridged’ at several points, including the GPS, the satcom terminal, the ECDIS and many other points

OT systems are used to control the steering gear, engines, ballast pumps and lots more. They communicate using NMEA 0183 messages. Here are several such messages including steering heading, GPS, AIS and Bridge alarm data.

There is no message authentication, encryption or validation of these messages. They’re plain text. All we need to do is man in the middle and modify the data. This isn’t GPS spoofing, which is well known and easy to detect, this is injecting small errors to slowly and insidiously force a ship off course.

If the autopilot is engaged, one could change the rudder command by modifying a GPS autopilot command like this:

Change R to L (Right to Left rudder command!) and then change the 2 byte XOR checksum at the end.

Conclusion

Ship security is in its infancy – most of these types of issues were fixed years ago in mainstream IT systems.

The advent of always-on satellite connections has exposed shipping to hacking attacks. Vessel owners and operators need to address these issues quickly, or more shipping security incidents will occur. What we’ve only seen in the movies will quickly become reality.