Speed 2, the Poseidon Adventure. Now this is a tale of how we tested one cruise ship over the
course of one week. There were two of us on the vessel, me and a colleague. Six engines on this
ship. It was quite a big one. There was a seven meter swell. Now the weather got quite rough at
one point, at which point I found out my colleague was actually quite seasick. Yeah, it was pretty
rough to be honest. There were 500 Wi-Fi access points distributed across the ship, 500 CCTV
cameras, 1,200 crew and over 2,000 passengers. So this is really really quite a big place.
And there were of course a pile of vulnerabilities, some of which I'm going to tell you about now.
So what is on a brand new cruise ship? Well it's not only a ship obviously, but it's also a hotel.
It's got to perform all those hotel functions. You've got shopping malls, so you've got shops,
you've got restaurants, you've got all of these different things going on, taking payments and so
on. And lots lots more when you think about it. When we break it down a bit further, we've got the
off-board communication. So we've got VSAT, Iridium and fleet broadband, things like that. The ship's
radio. We've got physical security, so how do we stop people getting onto the bridge, into the
machine rooms, into the engine room. We've got to keep the navigation systems up to date and secure
so the ship can navigate safely. You've got all the networking equipment spread across the vessel,
both passenger and industrial control side of things. You've got the load computer and the
load monitoring systems to make sure the stability of the vessel is good. You've got all the ICS
equipment. You're going to have a crew network. People can browse the internet on their laptops
and phones when they're away from home for long periods of time. And it just gets complex really
really fast. The attack surface is huge. So a modern cruise ship, and this isn't the one we
tested, it's just an image, is divided up into vertical fire zones. Now these are both fire and
water tight barriers. The idea is if there's a fire or a hole in the vessel it still stays safe,
so that fire can't spread quickly and water can't get from one compartment to another.
Now why is this relevant to us? Well it drives how the network is designed.
So the network is divided up into fire zones. So we've got something called an RDP,
a remote distribution point. It's essentially a very very large rack of Cisco gear.
There'll be multiple ones of these per fire zone. Now for each fire zone we need to split that
network out into other ones. So what we have are things called cabin switches. So we've got multiple
loops of cabin switches on each RDP. So those cabin switches are connected via wired ethernet,
the RDPs are connected via fiber. So we'll have big big loops of cabin switches, maybe 10 or 20
cabins. So each RDP will have multiple loops on it. Now to provide a degree of redundancy they
actually have port and starboard side RDPs as well. So they're all connected via a fiber network.
Now of course as well you're going to have servers. So you've got things like the TV,
you've got the Wi-Fi access, you've got the VSAT so you can gain access to the internet when you're
on the vessel. So this is kind of what it looks like. It's divided up into these fire zones and
you've got this massive loop of RDPs connected via fiber with lots of cabin switches connected
in loops. Now this is what one of those RDPs looks like. This is half of one of them. So you can see
the sheer scale here. Bear in mind each pair of ethernet cables coming out there, it's actually
going through a loop of cabins. So when you think about the sheer scale of this, it really is quite
huge. Now to look into one of those loops in more detail, I've broken one of those cabin switches
out. Now there'll be a cabin and we've got IPTV. So you can watch the TV in your cabin and
some of it's streamed from servers, there's live broadcasts of the shows on the ship, that will be
done over IP. And it's on a VLAN and it's connected into the cabin. You've got a VoIP phone as well,
so that's another network connection into the cabin. But then the really interesting one to me
was the cabin control system. And that controls the lighting, it controls the HVAC or the air
conditioning, it controls the door, the access control, and it controls the hot water as well.
It's really important that you heat the water up beyond a certain point periodically to prevent
Legionnaire's disease on ships. Now that's quite a lot of control. The reason they have it is when
a cabin's unoccupied, they can turn the lights off, they can turn the HVAC down so that they're
not using as much energy. And yeah, it's an important system. Now each cabin switch 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. So they had Wi-Fi access points,
500 Wi-Fi access points that were distributed across the vessel. Ships are made of metal, which
means you have to have a lot of access points to have good coverage. But we also had all of the CCTV
cameras. What that means is that that trunk that flows through the cabin switches contains the TV,
the cabin control, the Wi-Fi, and the CCTV. So it's quite an important trunk network.
So what is the threat model here? Well, I called this talk Speed 2. Why did I call it Speed 2?
Well, I don't know if you've seen Speed 2, but in Speed 2, an engineer of the shipping company
on the vessel, sailing on it, takes control. He also kills the captain, but we're going to ignore
that bit. He takes control of the ship and he programs it to crash into another ship.
So the important thing here is the attacker was already on board. It's not always remote attack
we're worried about here. When you regularly invite 2000 people onto your ship, there's a
chance that some of them might be malicious. Now, they might not be malicious enough to crash the
ship into another ship, but they still might want to do bad things. So what are the risks? Well,
Speed 2 highlighted control of the vessel. Now, if you've got physical access to the controls on
the ship, you can nearly always take control of it. But the thing is, the crew should nearly always
be able to stop that. Despite the fact that all of this fancy control systems connect everything
together, you can nearly always take manual control of things. You can at least stop them.
You can always take control of certain things. So control of the vessel also needs a fairly strong
motivation. For an attacker to want to steer a ship into another ship, particularly one with
2000 people on it, they've got to have a screw loose. So although the impact of this is huge,
the likelihood is probably quite low. But the other thing that cruise companies are worried about
is loss of passenger services. So if everybody's suddenly locked out of their cabin and has to
visit guest services, that's 2000 people queuing up to get new access cards. If the ship can't
sail from a port or the ship can't dock at a port, they're going to have to pay money. If people can't
pay for things in the shop, if they can't order in the restaurant, it costs the cruise company money.
And this is what we were trying to investigate, mainly on this test. What impact could we cause
by impacting the passengers? I'm going to talk about a few issues here. The first one,
the satisfying Wi-Fi. Now there was guest Wi-Fi on this ship, so these access points were spread
about the vessel. Now they gave access to the corporate network, they gave access to the
passenger management system that we'll talk about later, but they also had the guest Wi-Fi. Now we
could connect to that obviously, and then we could start exploring the network. Now one of the first
things that we do when we connect to a guest network like this is we do a trace route. And we
did a trace route out to Google DNS, and what we could see was the first few ping times were 25
milliseconds, give or take, which means we're on the vessel. The ones after that jump up to 700
plus milliseconds. That means we've gone over that VSAT link. VSAT satellite connections are latent,
we know those first three steps in the routes are on the vessel, so we decided to explore them
in more detail. And what we found was, in fact, that 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.
Now we've worked a lot on VSAT equipment in the past, so we know the default passwords for most
of the bits of equipment. So we found that we could log into the modem, we found that we could
log into the router, so we could log into the modem. Now the modem tunnels all traffic on and
off the vessel. What my colleague did was spend a period of time looking at the firmware, examining
how that device operated, and what he found was that he could gain route access to that device.
So now we've got route access on a device that all of the off-board traffic's going in and out of.
We could therefore intercept it, so we could intercept everything going on and off the vessel.
So any credentials in plain text, anything unencrypted, was ours to see. So this is quite a serious
problem, especially as we could do it from anywhere on the guest Wi-Fi. So the problem here was the
passenger Wi-Fi had access to the VSAT equipment. There were default passwords on the VSAT equipment.
There was a vulnerability that allowed route access, which allowed us to intercept all off-board
traffic. Now the thing was this could be solved at multiple stages. The network could be altered so
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 on those so that we couldn't
just trivially guess them. The vendor could have not had a vulnerability in their device, which
could have prevented us doing this. But you'll notice I mentioned the third party there. All of
the VSAT equipment is installed by a third party, not the cruise company. So that will come in
back in a few vulnerabilities. Issue two, just another hole in the wall.
Now one of the most important things for safety of a ship is stability. So you've got to make sure
that the fluid levels in all of your tanks keep the vessel stable. So if you ride too high in the
water, you could be unstable. If you ride too low in the water, the ship's inefficient. If you put
too much stress on the hull, the ship could become unsafe. Now ships are hugely complex now,
and you can't do these calculations on paper. So you use something called a load computer.
And this will take readings from all the tanks around the vessels. It will take things like the
passenger manifest. It will take things like the stores telling you how much food, beer,
wine is on board. And it will calculate if the vessel's stable or not and tell you what to do
to make it stable. Now it's vital for a modern ship that this is there. And we managed to
compromise it in this instance. But not only compromised the load computer, we also managed
to cause a denial of service to bridge systems that were important for day-to-day operations.
Now most of these ships have something called an integrated control and monitoring system.
So that's all the screens on the bridge. That's all the screens and HMIs, all the PLCs down in
the engine room. So it glues all of the industrial equipment on that ship together. So that'll be
the power, the generators, the propulsion, the rudder. Everything is glued together by this
massive system. Now it's a blend of IP and serial networks like you'd see in most industrial control
systems. Now ideally it should be segregated. There should be an air gap between those two of them.
So we've got the passenger network on one side and we've got the bridge network on the other.
But quite often we find that this gets eroded by changes that are made by third parties.
Now when we look into the bridge system in a bit more detail, we've got the IP devices. So the PCs
driving the screens and so on. But they also need to interact with serial connected devices. So that
would be things like GPS, anemometers, speed loggers, all of these different bits of equipment.
But it also has to interact with the ballast tank monitoring system, the fuel tank monitoring
system, and the hull stress monitoring system. So you've got these things called IP to serial
converters. They go from an IP network through to a serial network. RS-232, RS-485, Modbus,
something like that. So you can interact with these serial devices. They look like this. So on
one side you've got Ethernet coming in, on the other side you've got serial. There's lots and
lots of different brands. Moxa are probably one of the most popular ones. If you've done any
industrial control system work you'll recognize these. Now you remember I mentioned the load
computer? Now that has to get those readings from the ballast tanks and the fuel tanks.
So how does it do that? Well they've got a load computer server that's buried in a machine room
and it's got its own IP to serial converter that connects into one of the serial networks
that's on the bridge that interacts with all of these different monitoring systems.
Now to actually use the load computer there's got to be a UI, which is another computer set
up on the bridge. So you've got a problem. How do you connect the two of them together?
Now if you've ever worked on a ship you can't just go drilling holes through the floor, you can't
just make holes in walls. You've got to go through specific cable penetrations and then put fire
sealant around it, change requests, it's really really awkward. So if you've got to go down three decks
you probably don't want to have to run a cable. Now this load computer was installed by a third party
and what they found was that they could plug into any wall port and connect together.
So that load computer server down in a machine room, there's a wall port near it, they plugged
into it, they plugged the load computer into another wall port on the bridge and they found
they could connect to each other. So they used it. That's a lot easier than making a hole through
multiple decks. Now on this vessel what happened was if you plugged into a wall port, if you had
an 8021X certificate for the corporate network or an 8021X certificate for the PMS, you'd gain access
to that network. But if you didn't, 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. So this was what the load computer
company exploited. They found they could just plug in, get tar pitted and communicate. But that becomes
a bit of a problem because me as an attacker, I can come along and I can plug into a wall port in
the bar, I can plug into a wall port next to the swimming pool and I gain access to that same tar
pit. So now I had access to the load computer, UI and server. Now we've tested ships with this same
load computer system on it before and what we found was there's a default username and password stored
in an .ini file. Now with physical access to the machine, of course, you can read that username and
password. A big problem on ships is that you can't lock computers on the bridge because they've got
to be used and got to be used quickly. You can't be remembering a complex password, typing it in
to gain access to something. So they stay unlocked. So we found this default username and password on
a previous test. With that, what we could do was connect to that load computer server. We could
then pivot through it to take control of the IP to serial converter. Now you'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. Now 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. There's no way to tell that you've
been spoofing that. The problem here is, of course, is the bridge systems will trust that data. So what
we found is we could inject our own ballast tank levels, our own fuel tank levels, onto this system.
So the problem here, the load computer system needed a network connection and the third party
found that arbitrary wall ports connected together. So they used them. That meant the load computer is
accessible from any wall port. A shared 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. We could 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. Now what's 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. What happens if we spam twice as fast? What happens if we change how the messages are
sent? The thing here is 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 showing up saying that
a fuel tank's empty, that a ballast tank's full, that something's leaking, that would be really bad.
It distracts the navigators on the bridge. So it causes a denial of service to certain services.
It might be the case that when this happens someone would have to go around and do something
called manual tank dippings. You actually dip a weight with a string into the tanks to find out
how much is in them. It becomes time consuming, so something you want to avoid. Now issue three,
time and tide wait for no VLAN. Yeah these puns are bad, sorry. Now coming back to the idea of the
cabin switch, it's got that black trunk network flowing through it that's got all of these TV,
VoIP phones, Wi-Fi, all of these different VLANs that are quite interesting to us as an attacker.
Now the problem is this cabin switch was located in the passageway, the corridor between the cabins.
They're quite narrow on a cruise ship, so I had to open a panel, I had to open the box it was in,
I had to then physically unscrew the switch and then connect to it to mess about with it. The
problem with this is 500 CCTV cameras, people walking up and down the passageways, you're
getting in the way, you're going to get noticed. So we thought, well what can we do to make this
easier? What can we do to access this from our cabin? So coming back just down to one individual
cabin, what we did first off was we disconnected our TV and VoIP phone. So we just unplugged the
ethernet cables from the back of them. We then went to the cabinet in the wall in the passageway
and we bridged directly onto the trunk with those cables. So we took our cabin switch out of the
network. So it was feeding into our cabin via this structured cabling that was already installed.
We then put our own switch into that loop. So now we were part of that VLAN trunk. We were
connected in that big loop. What that meant was we could intercept all of the traffic flowing
about that VLAN and we could connect to all of the devices on those VLANs as well. So this gave us
a lot of power. We found out the TVs had default passwords. We couldn't really do much apart from
stop them working though. The VoIP phones, again default passwords, we could change their settings
so they didn't work. The Wi-Fi was actually really quite secure. There wasn't much we could do to that.
The CCTV however, the CCTV VMS, the video management system, connected out to all of the cameras
using RTSP, which is a plain text protocol. Now there was authentication, the cameras did require
login, but we could intercept as well as connect to the cameras. So we could see the password flying
about on the network, which meant we could connect to all of the cameras on the ship and view all of
them just from the comfort of our own cabins. So this was a bit of an issue. Now coming back to
that cabin control system that does the lighting, the HVAC, door and water. Now most systems like
this that have got hundreds of nodes will connect back to a server. So they make a connection from
the device through to the server. This one's a bit weird though. It worked the other way around.
The cabin control server established connections out to the cabin controls in the cabins. This was
a bit weird, but what that meant was we didn't have to compromise the cabin control server to
interact with the cabin controls. We were on the VLAN that they were all on. So we could come along
with our switch and we could actually compromise all of the cabin controls. So we could turn the
lights on and off. We could mess about with the aircon. We could lock people out of their cabins.
We could even open doors on the accessibility cabins, the ones with automated doors. Quite a
lot of power. Again, you're impacting the passengers. You're costing them. You're making
them uncomfortable, which means they're going to complain. It's going to cost you money.
The other thing we thought would be amusing would be writing something on the side of the ship.
Now, some ships have this functionality where through the cabin control system, you can actually
write things on the side of the vessel. This isn't the one we tested, but it'd be great to write
something on the side of a ship that big. The other problem with this cabin control system was
that the switches were physically accessible to us. Now, of course, we had to be in the passageway,
but there's an attack that we carry out against switches quite a lot of the time. Now, it does
require physical access. Most Cisco switches have something called password recovery mode.
What that means is you can reboot it, and through the serial console on it, you can dump the
existing config file off it. The idea of this mode is that you can change the password if you've
forgotten it with physical access. But we're relying on dumping the config off a device and
it containing interesting information. Now, it can take things like what VLANs are. It will also
contain hashes or possibly even encrypted versions of the passwords. So we managed to dump a config
off one of the cabin control switches. It took about two or three minutes to get this,
which isn't too bad, and they were hashed passwords. We put them on our cracking rig.
It took, I think, about two days of effort to recover the password. Now, the password wasn't
bad. It was a reasonably good password. I mean, I know two days isn't too long, but it wasn't Cisco.
It wasn't ship. And we tried that against the cabin switches, but none of them had a network
logon. So you could plug into them via serial and connect, but that's not particularly bad.
However, remember, we've got access to this trunk, which means we've got access to those RDPs.
And what we found was one of the RDPs had left its management interface exposed to the trunks
that we could access. And that RDP had left the web interface enabled. That username and password
recovered from one cabin switch worked on that single RDP. Now, it turns out that during
commissioning, that single RDP hadn't fully been commissioned. So they hadn't changed the password
on it. We gained access to that RDP, and that allowed us to intercept all of the traffic on
that fiber trunk. So it wasn't just the things on the cabin switch loops anymore. It was pretty
much everything on the vessel outside of the ICMS, the industrial control systems.
So these VLAN trunks run all over the ship, and you can connect from inside the cabin using the
phone cables. And it allows access to many, many systems. But it also allows sniffing to get any
plain text auth. So not using HTTPS actually had impact here. The cabin switches had that brute
forcible password, and that password worked on just one part of the core network. That allowed
us to intercept all of the VLAN trunks. So we've got a pretty significant compromise here. Now,
this was just an omission, and it did take quite a lot of effort to get to this point. But it was
a problem, a vulnerability. Issue four, I'm the captain now. Now, if you've been on a cruise
recently, you'll probably notice that a lot of the crew will carry tablets. So when you muster,
if there's a safety drill, they'll be taking muster on a tablet. If you order in one of the
restaurants, it will be on a tablet. If they come to your room with room service, they will have
a tablet. And this is quite broadly called a passenger management system, a PMS. And it deals
with lots of things. It does cabin assignment. It does access control. So quite often, it will
be linked into the access control system so that your card works on your cabin. It does restaurant
booking and the billing in the restaurant. It does mustering. And it also can hold your passport
details for immigration. It's kind of core to how the vessel operates. Now, what we found was all of
the tablets on this vessel used 8021X certificates for the Wi-Fi. And the tablets were actually
quite well hardened. We couldn't get anything off them easily. So we couldn't get those certificates
to gain access to the Wi-Fi. And we could have spent time doing something to possibly root one
of the tablets or gain the creds from somewhere else. But remember, we've got access to every
VLAN on the vessel, including the VLAN that carries the Wi-Fi traffic from all of the tablets.
And we can intercept that traffic, which is what we did. So we found that the tablets, although
they're using 8021X, that was actually implemented by the cruise company. They decided they wanted to
layer that security on top. However, the PMS used HTTP. There was no encryption between the tablets
and the server. That let us sniff credentials and other things going backwards and forwards.
What we found, of course, was that there was a SQL server which was passing its username and
password in the plane across this network. So once we gained access to those VLAN trunks,
we could get this username and password. We could then add our own user into the passenger
management system, and we could pretty much do what we want. So I could book myself into the
best restaurant on the ship and not have to pay for it, for example. But perhaps more fun was we
worked out how to log in as the captain on this system. So we could go to the restaurant,
we could order the most expensive bottle of wine, and we could bill it to the captain.
So this isn't good, really. This is a serious impact.
The PMS had good Wi-Fi security that was put in place by the cruise company,
but the PMS vendor used HTTP for the communications. It just wasn't secure enough.
We've covered those common SQL creds. We've not managed to test them on any other ships.
They could be the same across other ships. And with that, we could become anyone.
We could wipe details. We could order things in restaurants. It's pretty crazy.
So I think we pretty comprehensively owned this ship. It was a really, really good fun test.
So what is the conclusion here? Well, these attacks did require detailed knowledge.
We had to be on the vessel. We had to have a good level of understanding.
We weren't really strictly detected. One of the problems with a ship is it's hard to perform
things like intrusion detection remotely. So you might be able to sniff traffic and things like
that, but you've only got a limited amount of bandwidth to send that back to a SOC.
So no one really noticed us. We dressed smartly. And the couple of times that people noticed us
opening cabinets and things like that, no one said anything.
Now, interestingly, most of the risks on the ship were actually introduced by third parties.
The cruise company had done a lot to secure those networks, but it was third parties putting
systems in and making mistakes and not doing security properly that introduced most risks.
Now for a ship, denial of service is very costly. If you can stop a cruise ship leaving its berth,
especially in one of the smaller ports where there's only one or two berths,
and another ship's waiting to come in, the port can charge you huge sums of money.
We're talking tens or even possibly hundreds of thousands of dollars per day. You've got passengers
complaining. You're going to possibly have to reschedule flights, get hotels for people,
your next cruise may be delayed. So causing any denial of service, whether that's locking people
out their cabins or stopping the ship sailing, can cost you huge sums of money. So don't always
think about it as steering another ship into another ship. Think about how you can impact
the passengers. But lastly, cruise ships are massive amounts of fun. It's rare that you'd
be able to explore such huge complex machines with such level of detail. Definitely one of the
most fun tests I've been on this one. Thanks for listening. I'm Cyber Gibbons on Twitter.
If you've got any questions or you want to know anything more, just ping me a DM or
send me a message on Twitter. That'd be great. Thanks for listening. Bye.