Unmasking mystery boxes on ship’s bridges

We pen test a variety of vessel and platform types across different fleets and operators. In every single test to date we have unearthed a system or device, that of the few crew that were aware, no-one could tell us what it is was for.

In other scenarios an undocumented system or device would be considered a malicious implant. In maritime cyber security it’s business as usual.

Fleet management told us that shoreside had no invoice, record, or inventory listing for it. They were blissfully unaware of its existence. Everyone thought it was a system installed by shoreside for ‘monitoring’ of some sort. It had been installed by a third-party; the box was unlabelled, the wires going into the box were unlabelled. Suspicious.

Now, the Ethernet connection to the ship’s business LAN was obvious. However, it also offered Ethernet out to a console on the bridge. This  wasn’t so obvious, because the crew had covered the console up. The console didn’t provide any useful information other than that it was running Windows.

Maybe more importantly it’s display couldn’t be dimmed down. If you’re on the bridge at night the practical solution to is simply to cover the bloody thing up.

It is vital that equipment dims on the bridge so that you don’t ruin night vision. We’ve seen several systems installed on a bridge without this consideration.

Anyway, back to the potentially toxic box. There was a second Ethernet connection. No idea what for. After a risk assessment we unplugged it and ran it through a passive tap. We weren’t particularly surprised to see NMEA 0183 data over UDP being sent to broadcast. This is a common pattern in ICS.

The format of it showed it was aggregate sensor data – the messages began ‘$IN’ – much like any other NMEA data. Some GPS sentences begin $GPGLL, for example.

After some hunting around the bridge, we worked out that one of the four ECDIS chart systems was outputting the same data over serial. Only the TX line was connected. Even if RX was connected, this wasn’t the bus that ECDIS consumed, so there would appear to be no risk.

Frustratingly, we couldn’t find where it was converted to UDP.

Serial convertors FTW?

But then there was a Moxa RS232->Serial converter connected to our mystery box. This was totally unlabelled, immediately entered a shielded cable and then through a deck penetration. Normally one would use a cable tracer to find the other end, but it’s much harder with shielded cable.

So, we carried out another risk assessment, to decide if we could “passively” sniff the bus.

Why the inverted commas? By passive, I mean “not actively put traffic onto the bus”. From an electrical perspective, there is always a risk you short the bus or add some noise.

It would be very uncommon for any ship control system to react negatively to a brief interruption to a serial bus, but not unheard of. It’s certainly not something to do when coming into port.

So, it turns out that the traffic is Modbus. One master reading registers from one slave. There are rapidly changing values, some more steady, some unchanging.

One value is 169, and we’re currently underway at 16.9kts. That’s a good sign that it’s useful data

The other data appears to be in groups of 10, all similar numbers. Time to work out what they’re for:

The main engine is a MAN B&W 10G90ME – we would expect to see data in sets of 10 units. Could it be mean pressure, possibly exhaust gas temp?

OMG. The mystery unravels

So it appears that our mystery, undocumented box has a Modbus connection to something that is connected to the main engine.

There’s no trivial way to determine which end of a serial bus is the Modbus master and which is the slave.

So what next? We can’t trace the cable – it’s shielded, and using a tracer on a live RS232 bus is a bad idea. So we wait until we are in port, and get admin on the box using a USB live distro.

It’s running Windows and acting as a Modbus master to continuously poll a slave. One of the side effects of using Modbus is that you can’t make the bus physically read-only. You can’t cut the TX, as the master needs to poll to get data from the slave. t’s up to the slave to handle the “security”.

The software that is acting as a Master is only reading values. But can we – the attacker – write values?

After another risk assessment, we try to write a different windspeed back to a register. It sends and persists for a few seconds. The slave accepts writes, but that doesn’t mean it’s acting on them. It depends on what it is and how it’s configured. We need to dig deeper to determine if tampering with this data could affect the ship negatively

It took several hours to find where it ended up – 11 decks down on the main engine middle plates, going into an auxiliary serial connection on a PLC.

The main control system bus is CAN though, so this PLC has been configured to run as a Modbus slave.

The trail went cold here. The PLC has no available documentation and just has a serial connection – no IP. It probably needs a proprietary tool to make sense of. It would be too risky to fuzz the protocol in order to reverse engineer it.

However, this PLC was immediately adjacent to another PLC dealing with the main engine safety systems – those that handle engine slowdown and shutdown. If this triggered mistakenly, the ship could lose power. If it didn’t trigger, the engine could be destroyed.

That might seem extreme, but these shutdowns are absolutely vital. There are several triggers than need acting on very quickly to prevent catastrophic events happening – such as a crankcase explosion. Back in the day when I was a ships engineer, if my pager went off with an engine alarm, a main engine shutdown was always a possibility. I’ve had to do it once, leaving us drifting in the Straits of Malacca whilst we fixed the problem and brought the engine back online.

For example, there is a device called an oil mist detector (OMD) on the side of the crankcase, continuously sampling the air inside. If a fine mist of oil is detected above a certain level, it may mean a hotspot is vapourising oil. This oil vapour can explode.

Bear in mind this engine is bigger than a house. A crankcase explosion could destroy the main engine, or kill crew.

This isn’t the engine in question, just an indication of size:

This is just one of many inputs to the shutdown. That was too much risk for us, too much risk for the customer.

But we’d found a Windows machine that was connected to main engine controls, which no one knew about.

The kicker? The Windows machine had Team Viewer running on it. The box hadn’t been patched in ages either.

The offending box

It turned out that a third-party that no one really knew about had remote access to a box connected to the main engine.

It turns out the commercial arrangement with the third-party stopped several years ago.

Let that sink in.

A vulnerable box that no-one knew about with a direct, remote connection to the main engine

How did this happen?

A lot is done to make everything as efficient as possible. The huge, slow-speed, two-stroke diesels are some of the most efficient engines in the world.

Some newer ships recover waste heat from the exhaust to generate electricity. Bulbous bows reduce drag. Propellers are specially designed to avoid cavitation. Special anti-fouling paints keep the hull clean.

Then there is the operational side:

Keeping the vessel in good ballast, choosing the correct speed for the passage, weather routing, how many generators to run, trying to take bunkers (refuelling) in a cheap location.

If you don’t have a system to monitor efficiency, you can’t tell if you are being efficient or not.

So there are now a lot of different systems that gather data from around the vessel, aggregate it, display it and send it ashore. This data has to come from high-risk systems: the ECDIS, the ICMS, main engine, fuel oil systems.

ECDIS (Electronic Chart Display and Information System) is the electronic chart system used for navigation. It takes GPS, speed, draft, radar etc. from other systems and brings them together on the bridge.

ICMS (Integrated Control and Monitoring System) is the ICS on the ship – tens of PLCs, operator stations. It does nearly everything apart from the main engine speed.

There are around 5 major players in the ECDIS space. Another 5 major players in ICMS. There are two main engine makers.

So you want a system to monitor efficiency? Cool.

It needs to interface with all these systems. How are you going to do that? Get a service engineer for the ECDIS and ICMS and main engine onboard? No.

You use what is already available. And your goal is to get it working, not get it working securely.

There’s also the issue that running new cabling on a ship is a painful process. This normally involves removing multiple duct seals which then need replacing. We once even had to make a new bulkhead penetration to install a system. This isn’t something that people want to do.

So a location will be found where all these signals can be found. Ideally, serial with only a TX line will be used. That’s a truly one-way connection. Modbus, Profibus and CAN don’t allow for this though. So people connect directly.

Another method is to connect Ethernet networks and setup SMB file shares to send and receive data. No firewall, no security, often open shares.

Every ship you get on is different, even from the same class and from the same shipyard. Each new system installed is another source of complexity, it really shows after a while.

Often, large container vessels will get a maximum of 48 hours in port. That’s not long to install a complex monitoring system.

We’ve proved in the past that we could bring entire fleets of vessels to a halt remotely through similar exposure of critical systems. A bit like the Jeep hack by Charlie Miller and Chris Valasek: a series of vulnerabilities lined up to allow remote compromise.

Except on ships it is easier.