Speed 2 – The Poseidon Adventure – Part One

This post is a companion to the DEF CON 28 video available here https://www.youtube.com/watch?v=0yoMhWURaCI

This is a tale of how we tested a brand new cruise ship over the course of a week.

TL;DR

• How fire zone safety design affects security
• When ballasting control goes wrong
• Where maritime tech providers let security down, badly
• Are IMO & BIMCO cyber security requirements fit for purpose?

There were two of us on this six engine vessel. The weather got quite rough with a seven meter swell and I found out my colleague gets really seasick.

There were 500 Wi-Fi access points distributed across the ship, 500 CCTV cameras, 1,200 crew and over 2,000 passengers. Security is undoubtedly better in newer ships, but what about a ship that’s fresh out of the yard, reflecting the latest security requirements set out by IMO, BIMCO and others?

Well, there were of course a pile of vulnerabilities, some of which we can talk about in general terms. Broadly, we took from it that the coming regulation isn’t really fit for purpose without significant additions, that ship owners are doing the right thing and driving security, but they are being let down by their technology suppliers and installers.

So what is on a brand new cruise ship? It’s not only a ship but also a hotel and retail outlet, including payments

We can break it down further and look at off-board communication, so VSAT Iridium and Fleet Broadband, plus further comms such as the ship’s radio. What about physical security: how do we stop people getting onto the bridge, into the machine rooms, into the engine room etc?

The navigation systems have to be kept up-to-date and secure so the ship can navigate safely. There’s vast quantities of networking equipment spread across the vessel, dealing with both passenger needs and industrial controls. There’s a load computer and the load monitoring system to make sure the stability of the vessel is good, plus all the industrial controls to enable that. It’s also going to have a crew and passenger network, so people can browse the internet on their laptops and phones.

Does Safety trump Security?

divided up into vertical fire zones; these are barriers for fire and water so that it can’t spread quickly from one compartment to another. This is relevant as dictates how the network is designed and divided up. In each fire zone there is an ‘RDP’ or Remote Distribution Point: essentially a very large rack of Cisco gear. There are multiples of these per fire zone.

Each fire zone network is split into sub networks called ‘Cabin Switches’ or ‘CS’, so there are multiple loops of cabin switches on each RDP. They are connected via wired ethernet, the RDPs are connected via fibre, so there are big loops of cabin switches, with maybe 10 or 20 cabins each, and each RDP will have multiple loops on it. To provide redundancy there are port and starboard RDPs, connected via a fibre network.

This is what it looks like divided up into fire zones with a massive loop of RDPs connected via fibre:

This is a photo of one half of one RDP so you can see the sheer scale:

Each pair of ethernet cables coming out of there is going through a loop of cabins. The scale is huge.

This diagram shows what each switch is providing to each cabin. There’s IPTV, some of which is streamed from servers. There are live broadcasts of the stage shows on the ship over IP on a VLAN connected to the cabin. There’s a VOIP phone, but the really interesting system to me was the cabin control system. It controls the lighting, HVAC, door access and hot water. With hot water it’s really important that you heat the water up beyond a certain point periodically to prevent Legionnaires disease outbreaks.

The reason for this level of control is to reduce energy consumption in unoccupied cabins. Each cabin switch here actually worked on a pair of cabins; A and B. They were almost identical in almost all situations, but some cabin switches also had other networks hanging off them. They also had Wi-Fi access points: In fact there were 500 Wi-Fi access points distributed across the vessel. As ships are made of metal you need a lot of access points to ensure good coverage. We also had all of the CCTV cameras in this trunk flowing through the cabin switches, as well as the TV, the VoIP, and the cabin control, so it’s quite an important trunk network.

Threat Model

I called this talk Speed 2 because in the movie a rogue engineer takes control of the ship and programs it to crash into another ship. The important thing here is the attacker was already on board. I’m not talking about remote attacks as when you regularly invite 2,000 people onto your ship there’s a chance that some of them might be malicious, or inadvertently introduce malicious .

The film highlighted the importance of control of the vessel. If you’ve got physical access you can nearly always take control, but the crew should be able to stop that. Despite all the fancy connectivity and control systems you can nearly always take manual control. For an attacker to take control it requires a strong motivation and they’ve got to have a screw loose. Although the impact of this is huge, the likelihood is quite low.

What’s far more likely is loss of service. If everybody is suddenly locked out of their cabin and has to visit Guest Services, that’s 2,000 people queuing up to get new access cards.

We also ‘followed the money’ – what would result in financial loss for the cruise operator and/or passengers?

If the ship can’t sail from the port or the ship can’t dock, passengers will have to be compensated. If people can’t pay for things in the shop or order in the restaurant it costs the cruise company money. This was our objective: what impact could be caused by affecting the passengers?

Issue 1: V.SATisfying Wi-Fi

Unsurprisingly, guest Wi-Fi was offered on this ship and access points were spread about the vessel. Those APs gave access to the corporate network, the passenger management system and of course the guest Wi-Fi. We could connect to that and then start exploring the network.

One of the first things we do when we connect to a guest network on a vessel is a traceroute. It’s immediately obvious at what point our traffic leaves the vessel, given the ping times on the hops:

The first few ping times of 25 milliseconds mean we’re on the vessel. The ones after that jump up to 700+ milliseconds. That means we’ve now gone over that VSAT link, and VSAT links are latent.

We know the first three steps are on the vessel so we decided to explore them. What we found was that the second to last hop allowed us access to equipment in the VSAT rack.

So from the guest Wi-Fi we can connect through to the VSAT rack. We’ve worked on a lot of VSAT equipment, so we know all the default passwords for VSAT terminals and related kit. No surprise here: the installer had left the credentials default.

The modem tunnels all the traffic on and off the vessel. We examined the device and found a vulnerability that gave him root access. With root access we could intercept everything going on and off the vessel over the VSAT link. That meant that credentials in plain text were ours to see. This is a serious problem especially as we could access it from anywhere on the guest Wi-Fi.

So, the passenger Wi-Fi had access to the VSAT equipment with default passwords, the device was vulnerable, and it allowed us to intercept all off-board traffic.

This could all be solved at various stages. The network could be altered so that the passenger Wi-Fi couldn’t access all of these management interfaces on those devices. The VSAT installer (a third party) could have changed the passwords so that we couldn’t just trivially guess them. Maritime technology suppliers should not be providing easily rooted vulnerable devices.

All of the VSAT equipment was installed by a third party, not the cruise company. We’ll be coming back to this issue again… and again… and again.

Issue 2: Just Another Hole In The Wall

One of the most important things for the safety of a ship is stability. You’ve got to make sure that the fluid levels in all of your tanks keep the vessel stable. If you ride too high in the water you could be unstable. If you ride too low in the water the ship is inefficient. If you put too much stress on the hull the ship could become unsafe.

Ships are hugely complex and you can’t do these  calculations on paper so you use a Load Computer. This will take readings from all the tanks around the vessel. It will take things like the passenger manifest and the stores telling you how much food/beer/wine is on board, it will calculate if the vessel is stable or not and tell you what to do to make it stable.

The Load Computer is vital for any modern ship, yet we managed to compromise it. Along the way we also found a way to cause a denial of service to bridge systems that are essential for day-to-day operations. Most cruise ships have an Integrated Control and Monitoring System or ICMS running all the screens on the bridge plus the HMIs and the PLCs down in the engine room. It glues all of the industrial equipment on the ship together – the power, the generators, the propulsion, the rudder, everything is held together by this complex system.

It’s a blend of IP and serial networks like you’d see in most industrial control systems. It should be segregated, so that there’s an air gap or very strong logical segregation between the passenger network on one side and the bridge network on the other. Quite often we find that this gets eroded when changes are made by third parties. Does this sound like a familiar problem?

Let’s look at  the bridge system in detail. We’ve got IP devices such as the PCs driving the screens and so on, but they need to interact with serial connected devices- things like GPS, anemometers, speed loggers etc. It also has to interact with the ballast tank monitoring system, the fuel tank monitoring system and the hull stress monitoring system as well.

That requires IP-to-serial converters. They go from an IP network through to a serial network e.g. rs232, rs485, or Modbus so you can interact with these serial devices.

On one side you’ve got ethernet coming in on the other side there is serial going out. There are many different brands, though Moxa are probably one of the most popular ones. If you’ve done any work on industrial control system you’ll recognize these.

Back to the Load Computer? That has to get readings from the ballast tanks and the fuel tanks.  There’s a Load Computer server that’s buried in a machine room with its own IP-serial converter. It connects into one of the serial networks that’s on the bridge that interacts with all of the different monitoring systems.

The Load Computer UI is sat on the bridge. How do you connect the two of them together? If you’ve ever worked on a ship you know that you can’t just go drilling holes through the floor or walls. For safety reasons you have to go through specific cable penetrations and then put fire sealant around it, make change requests, the whole thing is really awkward. If you’ve got to go down three decks you probably don’t want to do it by running a cable.

This Load Computer was installed by third party. What they found was that they could plug into any wall port and connect it together. So, that Load Computer server down in the machine room had a wall port near it. They plugged into it, and they plugged the Load Computer into another wall port on the bridge and they found they could connect to each other. That’s a lot easier than making holes through multiple decks.

Now, on this vessel what happened was if you plugged into a wall port with an 802.1x certificate for the corporate network, and an 802.1x certificate for the PMS, you’d gain access to that network. But without a certificate you ended up in a tar pit – a specific VLAN and a specific network that didn’t have internet access didn’t have access to other networks on the ship, but it was its own network and devices could communicate with each other. This was what the Load Computer company had used.

They found they could just plug in, get tar pitted and communicate. Brilliant! Can anyone see the flaw here?

An attacker can come along and plug into a wall port, in the bar for example or next to the swimming pool and I gain access to that same tar pit. Now I have access to the Load Computer UI and server. As we’ve tested ships with this same Load Computer system before we know that there’s a username and password stored in an ini file.

With physical access to the machine you can read that username and password. A big problem on ships is that you can’t lock the computers on the bridge. They need to be used in an instant, so they stay unlocked rather than requiring complex passwords. Anyway, we found the default username and password on a previous test so we could connect to that Load Computer server and then use it to pivot to take control of the IP to serial converter.

So we’ve got those ballast tank levels, the fuel tanks, the whole stress monitoring system and I’ve now got the ability to inject messages onto there. Serial networks have got a bit of an issue here- you can just generally spoof messages. If the ballast tank is sending out a message of a given type you can send out another message of the same type onto that serial network, and there’s no way to tell that you’ve been spoofing that. The problem is that the bridge systems will trust that data. We found we could inject our own ballast tank levels or our own fuel tank levels onto this system.

The Load Computer system needed a network connection, the third party found that the wall ports were connected together. They used them and so made the Load Computer accessible from any wall port. A shared, default password that we learned on a previous test allowed us to gain access to that Load Computer. We could pivot to the IP-serial converter, then inject tank readings onto the control network and then we could spam the bridge ICMS. We could spam all of the screens on the bridge giving them wrong ballast tank readings.

What is the ICMS going to do when it’s receiving two different readings? It’s going to probably toggle between the two. There might be some filtering but what happens if you spam twice as fast, or if you change how those messages are being sent? When you’re on the bridge you want to concentrate on navigating, you want to concentrate on safety. If suddenly you’re getting loads and loads of alarms saying that a fuel tank is empty or that a ballast tank is full, or that something’s leaking, that would distract the navigators and cause a denial of service to certain services.

It might be the case that when this happens someone would have to go around and dip tanks manually. I had to do this occasionally when I was a ships engineer. You literally dip a weight on a string into the tanks to find out how much is in them. It’s time consuming, occupies valuable resource and makes other minor issues more likely to escalate in to major issues.

Part Two is available here https://www.pentestpartners.com/security-blog/speed-2-the-poseidon-adventure-when-cruise-ships-attack-part-2/