[00:00.000 --> 00:05.760] Speed 2, the Poseidon Adventure. Now this is a tale of how we tested one cruise ship over the [00:05.760 --> 00:11.060] course of one week. There were two of us on the vessel, me and a colleague. Six engines on this [00:11.060 --> 00:15.780] ship. It was quite a big one. There was a seven meter swell. Now the weather got quite rough at [00:15.780 --> 00:21.260] one point, at which point I found out my colleague was actually quite seasick. Yeah, it was pretty [00:21.260 --> 00:28.060] rough to be honest. There were 500 Wi-Fi access points distributed across the ship, 500 CCTV [00:28.060 --> 00:35.940] cameras, 1,200 crew and over 2,000 passengers. So this is really really quite a big place. [00:36.200 --> 00:40.540] And there were of course a pile of vulnerabilities, some of which I'm going to tell you about now. [00:40.660 --> 00:47.240] So what is on a brand new cruise ship? Well it's not only a ship obviously, but it's also a hotel. [00:47.240 --> 00:51.580] It's got to perform all those hotel functions. You've got shopping malls, so you've got shops, [00:51.580 --> 00:55.300] you've got restaurants, you've got all of these different things going on, taking payments and so [00:55.300 --> 01:00.520] on. And lots lots more when you think about it. When we break it down a bit further, we've got the [01:00.520 --> 01:05.200] off-board communication. So we've got VSAT, Iridium and fleet broadband, things like that. The ship's [01:05.200 --> 01:10.560] radio. We've got physical security, so how do we stop people getting onto the bridge, into the [01:10.560 --> 01:15.640] machine rooms, into the engine room. We've got to keep the navigation systems up to date and secure [01:15.640 --> 01:20.720] so the ship can navigate safely. You've got all the networking equipment spread across the vessel, [01:20.720 --> 01:25.520] both passenger and industrial control side of things. You've got the load computer and the [01:25.520 --> 01:30.420] load monitoring systems to make sure the stability of the vessel is good. You've got all the ICS [01:30.420 --> 01:34.460] equipment. You're going to have a crew network. People can browse the internet on their laptops [01:34.460 --> 01:39.960] and phones when they're away from home for long periods of time. And it just gets complex really [01:39.960 --> 01:45.600] really fast. The attack surface is huge. So a modern cruise ship, and this isn't the one we [01:45.600 --> 01:52.160] tested, it's just an image, is divided up into vertical fire zones. Now these are both fire and [01:52.160 --> 01:57.980] water tight barriers. The idea is if there's a fire or a hole in the vessel it still stays safe, [01:57.980 --> 02:02.570] so that fire can't spread quickly and water can't get from one compartment to another. [02:03.000 --> 02:09.060] Now why is this relevant to us? Well it drives how the network is designed. [02:09.620 --> 02:14.940] So the network is divided up into fire zones. So we've got something called an RDP, [02:15.040 --> 02:19.820] a remote distribution point. It's essentially a very very large rack of Cisco gear. [02:20.040 --> 02:25.940] There'll be multiple ones of these per fire zone. Now for each fire zone we need to split that [02:25.940 --> 02:32.120] network out into other ones. So what we have are things called cabin switches. So we've got multiple [02:32.120 --> 02:37.880] loops of cabin switches on each RDP. So those cabin switches are connected via wired ethernet, [02:37.880 --> 02:43.580] the RDPs are connected via fiber. So we'll have big big loops of cabin switches, maybe 10 or 20 [02:43.580 --> 02:50.160] cabins. So each RDP will have multiple loops on it. Now to provide a degree of redundancy they [02:50.160 --> 02:56.360] actually have port and starboard side RDPs as well. So they're all connected via a fiber network. [02:56.480 --> 03:01.240] Now of course as well you're going to have servers. So you've got things like the TV, [03:01.240 --> 03:05.840] you've got the Wi-Fi access, you've got the VSAT so you can gain access to the internet when you're [03:05.840 --> 03:10.280] on the vessel. So this is kind of what it looks like. It's divided up into these fire zones and [03:10.280 --> 03:15.860] you've got this massive loop of RDPs connected via fiber with lots of cabin switches connected [03:15.860 --> 03:22.860] in loops. Now this is what one of those RDPs looks like. This is half of one of them. So you can see [03:22.860 --> 03:26.480] the sheer scale here. Bear in mind each pair of ethernet cables coming out there, it's actually [03:26.480 --> 03:31.540] going through a loop of cabins. So when you think about the sheer scale of this, it really is quite [03:31.540 --> 03:38.100] huge. Now to look into one of those loops in more detail, I've broken one of those cabin switches [03:38.100 --> 03:44.360] out. Now there'll be a cabin and we've got IPTV. So you can watch the TV in your cabin and [03:44.360 --> 03:50.540] some of it's streamed from servers, there's live broadcasts of the shows on the ship, that will be [03:50.540 --> 03:56.120] done over IP. And it's on a VLAN and it's connected into the cabin. You've got a VoIP phone as well, [03:56.120 --> 04:00.560] so that's another network connection into the cabin. But then the really interesting one to me [04:00.560 --> 04:05.240] was the cabin control system. And that controls the lighting, it controls the HVAC or the air [04:05.240 --> 04:10.280] conditioning, it controls the door, the access control, and it controls the hot water as well. [04:10.320 --> 04:15.160] It's really important that you heat the water up beyond a certain point periodically to prevent [04:15.660 --> 04:20.800] Legionnaire's disease on ships. Now that's quite a lot of control. The reason they have it is when [04:20.920 --> 04:25.460] a cabin's unoccupied, they can turn the lights off, they can turn the HVAC down so that they're [04:25.460 --> 04:31.020] not using as much energy. And yeah, it's an important system. Now each cabin switch actually [04:31.020 --> 04:36.640] worked on a pair of cabins A and B. They were almost identical in almost all situations. But [04:36.640 --> 04:42.300] some cabin switches also had other networks hanging off them. So they had Wi-Fi access points, [04:42.300 --> 04:47.720] 500 Wi-Fi access points that were distributed across the vessel. Ships are made of metal, which [04:47.720 --> 04:52.180] means you have to have a lot of access points to have good coverage. But we also had all of the CCTV [04:52.180 --> 04:58.680] cameras. What that means is that that trunk that flows through the cabin switches contains the TV, [04:58.680 --> 05:04.320] the cabin control, the Wi-Fi, and the CCTV. So it's quite an important trunk network. [05:05.100 --> 05:10.940] So what is the threat model here? Well, I called this talk Speed 2. Why did I call it Speed 2? [05:10.940 --> 05:15.500] Well, I don't know if you've seen Speed 2, but in Speed 2, an engineer of the shipping company [05:15.500 --> 05:21.660] on the vessel, sailing on it, takes control. He also kills the captain, but we're going to ignore [05:21.660 --> 05:26.960] that bit. He takes control of the ship and he programs it to crash into another ship. [05:26.960 --> 05:31.600] So the important thing here is the attacker was already on board. It's not always remote attack [05:31.600 --> 05:36.480] we're worried about here. When you regularly invite 2000 people onto your ship, there's a [05:36.480 --> 05:40.760] chance that some of them might be malicious. Now, they might not be malicious enough to crash the [05:40.760 --> 05:46.340] ship into another ship, but they still might want to do bad things. So what are the risks? Well, [05:46.340 --> 05:51.140] Speed 2 highlighted control of the vessel. Now, if you've got physical access to the controls on [05:51.140 --> 05:56.600] the ship, you can nearly always take control of it. But the thing is, the crew should nearly always [05:56.600 --> 06:02.400] be able to stop that. Despite the fact that all of this fancy control systems connect everything [06:02.400 --> 06:06.980] together, you can nearly always take manual control of things. You can at least stop them. [06:06.980 --> 06:13.960] You can always take control of certain things. So control of the vessel also needs a fairly strong [06:13.960 --> 06:17.680] motivation. For an attacker to want to steer a ship into another ship, particularly one with [06:17.680 --> 06:23.740] 2000 people on it, they've got to have a screw loose. So although the impact of this is huge, [06:23.740 --> 06:29.480] the likelihood is probably quite low. But the other thing that cruise companies are worried about [06:29.480 --> 06:34.960] is loss of passenger services. So if everybody's suddenly locked out of their cabin and has to [06:34.960 --> 06:40.460] visit guest services, that's 2000 people queuing up to get new access cards. If the ship can't [06:40.460 --> 06:46.060] 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 [06:46.060 --> 06:50.960] pay for things in the shop, if they can't order in the restaurant, it costs the cruise company money. [06:50.960 --> 06:55.700] And this is what we were trying to investigate, mainly on this test. What impact could we cause [06:55.700 --> 07:01.640] by impacting the passengers? I'm going to talk about a few issues here. The first one, [07:01.640 --> 07:08.160] the satisfying Wi-Fi. Now there was guest Wi-Fi on this ship, so these access points were spread [07:08.160 --> 07:12.180] about the vessel. Now they gave access to the corporate network, they gave access to the [07:12.180 --> 07:17.260] passenger management system that we'll talk about later, but they also had the guest Wi-Fi. Now we [07:17.260 --> 07:21.700] could connect to that obviously, and then we could start exploring the network. Now one of the first [07:21.700 --> 07:25.860] things that we do when we connect to a guest network like this is we do a trace route. And we [07:25.860 --> 07:31.480] did a trace route out to Google DNS, and what we could see was the first few ping times were 25 [07:31.480 --> 07:36.500] milliseconds, give or take, which means we're on the vessel. The ones after that jump up to 700 [07:36.500 --> 07:43.120] plus milliseconds. That means we've gone over that VSAT link. VSAT satellite connections are latent, [07:43.120 --> 07:48.640] we know those first three steps in the routes are on the vessel, so we decided to explore them [07:48.640 --> 07:54.700] in more detail. And what we found was, in fact, that second to last hop allowed us access to [07:54.700 --> 08:00.960] equipment in the VSAT rack. So from the guest Wi-Fi, we can connect through to the VSAT rack. [08:01.040 --> 08:07.940] Now we've worked a lot on VSAT equipment in the past, so we know the default passwords for most [08:07.940 --> 08:11.640] of the bits of equipment. So we found that we could log into the modem, we found that we could [08:11.640 --> 08:17.520] log into the router, so we could log into the modem. Now the modem tunnels all traffic on and [08:17.520 --> 08:22.180] off the vessel. What my colleague did was spend a period of time looking at the firmware, examining [08:22.180 --> 08:28.220] how that device operated, and what he found was that he could gain route access to that device. [08:28.420 --> 08:34.340] So now we've got route access on a device that all of the off-board traffic's going in and out of. [08:34.340 --> 08:38.520] We could therefore intercept it, so we could intercept everything going on and off the vessel. [08:38.520 --> 08:43.760] So any credentials in plain text, anything unencrypted, was ours to see. So this is quite a serious [08:43.760 --> 08:49.120] problem, especially as we could do it from anywhere on the guest Wi-Fi. So the problem here was the [08:49.120 --> 08:54.480] passenger Wi-Fi had access to the VSAT equipment. There were default passwords on the VSAT equipment. [08:54.540 --> 08:59.080] There was a vulnerability that allowed route access, which allowed us to intercept all off-board [08:59.080 --> 09:04.360] traffic. Now the thing was this could be solved at multiple stages. The network could be altered so [09:04.360 --> 09:09.600] the passenger Wi-Fi couldn't access all of these management interfaces on those devices. [09:09.880 --> 09:15.280] The VSAT installer, a third party, could have changed the passwords on those so that we couldn't [09:15.280 --> 09:19.700] just trivially guess them. The vendor could have not had a vulnerability in their device, which [09:19.700 --> 09:24.460] could have prevented us doing this. But you'll notice I mentioned the third party there. All of [09:24.460 --> 09:30.260] the VSAT equipment is installed by a third party, not the cruise company. So that will come in [09:30.780 --> 09:37.120] back in a few vulnerabilities. Issue two, just another hole in the wall. [09:38.320 --> 09:44.080] Now one of the most important things for safety of a ship is stability. So you've got to make sure [09:44.080 --> 09:50.400] that the fluid levels in all of your tanks keep the vessel stable. So if you ride too high in the [09:50.400 --> 09:56.500] water, you could be unstable. If you ride too low in the water, the ship's inefficient. If you put [09:56.500 --> 10:02.720] too much stress on the hull, the ship could become unsafe. Now ships are hugely complex now, [10:02.720 --> 10:07.420] and you can't do these calculations on paper. So you use something called a load computer. [10:07.440 --> 10:10.820] And this will take readings from all the tanks around the vessels. It will take things like the [10:10.820 --> 10:15.520] passenger manifest. It will take things like the stores telling you how much food, beer, [10:15.520 --> 10:19.800] wine is on board. And it will calculate if the vessel's stable or not and tell you what to do [10:19.800 --> 10:26.480] to make it stable. Now it's vital for a modern ship that this is there. And we managed to [10:26.480 --> 10:31.200] compromise it in this instance. But not only compromised the load computer, we also managed [10:31.200 --> 10:37.900] to cause a denial of service to bridge systems that were important for day-to-day operations. [10:38.520 --> 10:42.600] Now most of these ships have something called an integrated control and monitoring system. [10:42.600 --> 10:47.400] So that's all the screens on the bridge. That's all the screens and HMIs, all the PLCs down in [10:47.400 --> 10:52.420] the engine room. So it glues all of the industrial equipment on that ship together. So that'll be [10:52.420 --> 10:57.860] the power, the generators, the propulsion, the rudder. Everything is glued together by this [10:57.860 --> 11:03.600] massive system. Now it's a blend of IP and serial networks like you'd see in most industrial control [11:03.600 --> 11:10.240] systems. Now ideally it should be segregated. There should be an air gap between those two of them. [11:10.240 --> 11:14.700] So we've got the passenger network on one side and we've got the bridge network on the other. [11:14.780 --> 11:20.800] But quite often we find that this gets eroded by changes that are made by third parties. [11:20.800 --> 11:26.020] Now when we look into the bridge system in a bit more detail, we've got the IP devices. So the PCs [11:26.020 --> 11:32.240] driving the screens and so on. But they also need to interact with serial connected devices. So that [11:32.240 --> 11:37.720] would be things like GPS, anemometers, speed loggers, all of these different bits of equipment. [11:37.720 --> 11:41.820] But it also has to interact with the ballast tank monitoring system, the fuel tank monitoring [11:41.820 --> 11:46.580] system, and the hull stress monitoring system. So you've got these things called IP to serial [11:46.580 --> 11:53.260] converters. They go from an IP network through to a serial network. RS-232, RS-485, Modbus, [11:53.260 --> 12:00.140] something like that. So you can interact with these serial devices. They look like this. So on [12:00.140 --> 12:04.160] one side you've got Ethernet coming in, on the other side you've got serial. There's lots and [12:04.160 --> 12:07.900] lots of different brands. Moxa are probably one of the most popular ones. If you've done any [12:07.900 --> 12:14.100] industrial control system work you'll recognize these. Now you remember I mentioned the load [12:14.100 --> 12:18.140] computer? Now that has to get those readings from the ballast tanks and the fuel tanks. [12:18.500 --> 12:22.800] So how does it do that? Well they've got a load computer server that's buried in a machine room [12:22.800 --> 12:27.920] and it's got its own IP to serial converter that connects into one of the serial networks [12:27.920 --> 12:32.800] that's on the bridge that interacts with all of these different monitoring systems. [12:33.920 --> 12:39.440] Now to actually use the load computer there's got to be a UI, which is another computer set [12:39.440 --> 12:43.560] up on the bridge. So you've got a problem. How do you connect the two of them together? [12:43.560 --> 12:48.320] Now if you've ever worked on a ship you can't just go drilling holes through the floor, you can't [12:48.320 --> 12:53.800] just make holes in walls. You've got to go through specific cable penetrations and then put fire [12:53.800 --> 12:59.280] sealant around it, change requests, it's really really awkward. So if you've got to go down three decks [12:59.880 --> 13:05.800] you probably don't want to have to run a cable. Now this load computer was installed by a third party [13:06.580 --> 13:13.820] and what they found was that they could plug into any wall port and connect together. [13:14.220 --> 13:18.060] So that load computer server down in a machine room, there's a wall port near it, they plugged [13:18.060 --> 13:22.600] into it, they plugged the load computer into another wall port on the bridge and they found [13:22.600 --> 13:28.080] they could connect to each other. So they used it. That's a lot easier than making a hole through [13:28.080 --> 13:35.040] multiple decks. Now on this vessel what happened was if you plugged into a wall port, if you had [13:35.040 --> 13:40.460] an 8021X certificate for the corporate network or an 8021X certificate for the PMS, you'd gain access [13:40.460 --> 13:46.640] to that network. But if you didn't, you ended up in a tar pit, a specific VLAN and a specific network [13:46.640 --> 13:51.800] that didn't have internet access, didn't have access to other networks on the ship, but it was [13:51.800 --> 13:58.100] its own network and devices could communicate with each other. So this was what the load computer [13:58.100 --> 14:04.360] company exploited. They found they could just plug in, get tar pitted and communicate. But that becomes [14:04.520 --> 14:10.980] a bit of a problem because me as an attacker, I can come along and I can plug into a wall port in [14:10.980 --> 14:17.140] the bar, I can plug into a wall port next to the swimming pool and I gain access to that same tar [14:17.140 --> 14:24.300] pit. So now I had access to the load computer, UI and server. Now we've tested ships with this same [14:24.300 --> 14:30.180] load computer system on it before and what we found was there's a default username and password stored [14:30.180 --> 14:35.480] in an .ini file. Now with physical access to the machine, of course, you can read that username and [14:35.480 --> 14:41.840] password. A big problem on ships is that you can't lock computers on the bridge because they've got [14:41.840 --> 14:47.200] to be used and got to be used quickly. You can't be remembering a complex password, typing it in [14:47.200 --> 14:51.660] to gain access to something. So they stay unlocked. So we found this default username and password on [14:51.780 --> 14:57.320] a previous test. With that, what we could do was connect to that load computer server. We could [14:57.320 --> 15:03.240] then pivot through it to take control of the IP to serial converter. Now you've got those ballast [15:03.240 --> 15:07.560] tank levels, the fuel tanks, the whole stress monitoring system and I've now got the ability [15:07.560 --> 15:12.740] to inject messages onto there. Now serial networks have got a bit of an issue here. You can just [15:12.740 --> 15:18.520] generally spoof messages. If the ballast tank is sending out a message of a given type, you can send [15:18.520 --> 15:23.060] out another message of the same type onto that serial network. There's no way to tell that you've [15:23.060 --> 15:29.800] been spoofing that. The problem here is, of course, is the bridge systems will trust that data. So what [15:29.800 --> 15:34.820] we found is we could inject our own ballast tank levels, our own fuel tank levels, onto this system. [15:36.380 --> 15:40.700] So the problem here, the load computer system needed a network connection and the third party [15:40.700 --> 15:45.640] found that arbitrary wall ports connected together. So they used them. That meant the load computer is [15:45.640 --> 15:50.120] accessible from any wall port. A shared password that we learned on a previous test allowed us to [15:50.120 --> 15:55.320] gain access to that load computer. We could pivot to the IP serial converter. We could inject tank [15:55.320 --> 16:01.480] readings onto the control network and then we could spam the bridge ICMS. We could spam all of the [16:01.480 --> 16:06.160] screens on the bridge, giving them wrong ballast tank readings. Now what's the ICMS going to do when [16:06.160 --> 16:10.160] it's receiving two different readings? It's going to probably toggle between the two. There might be [16:10.160 --> 16:14.780] some filtering. What happens if we spam twice as fast? What happens if we change how the messages are [16:14.780 --> 16:20.460] sent? The thing here is when you're on the bridge you want to concentrate on navigating. You want to [16:20.460 --> 16:25.460] concentrate on safety. If suddenly you're getting loads and loads of alarms showing up saying that [16:25.640 --> 16:30.580] a fuel tank's empty, that a ballast tank's full, that something's leaking, that would be really bad. [16:30.580 --> 16:36.660] It distracts the navigators on the bridge. So it causes a denial of service to certain services. [16:36.680 --> 16:40.280] It might be the case that when this happens someone would have to go around and do something [16:40.280 --> 16:44.420] called manual tank dippings. You actually dip a weight with a string into the tanks to find out [16:44.420 --> 16:51.300] how much is in them. It becomes time consuming, so something you want to avoid. Now issue three, [16:51.300 --> 16:58.000] time and tide wait for no VLAN. Yeah these puns are bad, sorry. Now coming back to the idea of the [16:58.000 --> 17:03.760] cabin switch, it's got that black trunk network flowing through it that's got all of these TV, [17:03.760 --> 17:08.720] VoIP phones, Wi-Fi, all of these different VLANs that are quite interesting to us as an attacker. [17:08.780 --> 17:13.480] Now the problem is this cabin switch was located in the passageway, the corridor between the cabins. [17:13.480 --> 17:18.160] They're quite narrow on a cruise ship, so I had to open a panel, I had to open the box it was in, [17:18.160 --> 17:22.520] I had to then physically unscrew the switch and then connect to it to mess about with it. The [17:22.520 --> 17:28.340] problem with this is 500 CCTV cameras, people walking up and down the passageways, you're [17:28.340 --> 17:32.640] getting in the way, you're going to get noticed. So we thought, well what can we do to make this [17:32.640 --> 17:37.440] easier? What can we do to access this from our cabin? So coming back just down to one individual [17:37.440 --> 17:43.360] cabin, what we did first off was we disconnected our TV and VoIP phone. So we just unplugged the [17:43.360 --> 17:48.860] ethernet cables from the back of them. We then went to the cabinet in the wall in the passageway [17:48.860 --> 17:55.720] and we bridged directly onto the trunk with those cables. So we took our cabin switch out of the [17:55.720 --> 18:00.980] network. So it was feeding into our cabin via this structured cabling that was already installed. [18:01.140 --> 18:07.140] We then put our own switch into that loop. So now we were part of that VLAN trunk. We were [18:07.140 --> 18:12.800] connected in that big loop. What that meant was we could intercept all of the traffic flowing [18:12.800 --> 18:17.960] about that VLAN and we could connect to all of the devices on those VLANs as well. So this gave us [18:18.180 --> 18:22.900] a lot of power. We found out the TVs had default passwords. We couldn't really do much apart from [18:22.900 --> 18:27.140] stop them working though. The VoIP phones, again default passwords, we could change their settings [18:27.140 --> 18:32.280] so they didn't work. The Wi-Fi was actually really quite secure. There wasn't much we could do to that. [18:32.440 --> 18:39.080] The CCTV however, the CCTV VMS, the video management system, connected out to all of the cameras [18:40.300 --> 18:45.420] using RTSP, which is a plain text protocol. Now there was authentication, the cameras did require [18:45.420 --> 18:50.600] login, but we could intercept as well as connect to the cameras. So we could see the password flying [18:50.600 --> 18:55.360] about on the network, which meant we could connect to all of the cameras on the ship and view all of [18:55.360 --> 19:01.840] them just from the comfort of our own cabins. So this was a bit of an issue. Now coming back to [19:01.840 --> 19:07.620] that cabin control system that does the lighting, the HVAC, door and water. Now most systems like [19:07.620 --> 19:12.380] this that have got hundreds of nodes will connect back to a server. So they make a connection from [19:12.380 --> 19:17.080] the device through to the server. This one's a bit weird though. It worked the other way around. [19:17.080 --> 19:23.120] The cabin control server established connections out to the cabin controls in the cabins. This was [19:23.560 --> 19:27.920] a bit weird, but what that meant was we didn't have to compromise the cabin control server to [19:27.920 --> 19:32.980] interact with the cabin controls. We were on the VLAN that they were all on. So we could come along [19:32.980 --> 19:38.700] with our switch and we could actually compromise all of the cabin controls. So we could turn the [19:38.700 --> 19:43.380] lights on and off. We could mess about with the aircon. We could lock people out of their cabins. [19:43.380 --> 19:48.920] We could even open doors on the accessibility cabins, the ones with automated doors. Quite a [19:48.920 --> 19:54.760] lot of power. Again, you're impacting the passengers. You're costing them. You're making [19:54.760 --> 19:59.020] them uncomfortable, which means they're going to complain. It's going to cost you money. [19:59.020 --> 20:02.440] The other thing we thought would be amusing would be writing something on the side of the ship. [20:02.440 --> 20:07.700] Now, some ships have this functionality where through the cabin control system, you can actually [20:07.700 --> 20:11.820] write things on the side of the vessel. This isn't the one we tested, but it'd be great to write [20:11.820 --> 20:18.000] something on the side of a ship that big. The other problem with this cabin control system was [20:18.000 --> 20:22.440] that the switches were physically accessible to us. Now, of course, we had to be in the passageway, [20:22.440 --> 20:26.580] but there's an attack that we carry out against switches quite a lot of the time. Now, it does [20:26.580 --> 20:32.060] require physical access. Most Cisco switches have something called password recovery mode. [20:32.060 --> 20:37.200] What that means is you can reboot it, and through the serial console on it, you can dump the [20:37.200 --> 20:42.040] existing config file off it. The idea of this mode is that you can change the password if you've [20:42.040 --> 20:46.780] forgotten it with physical access. But we're relying on dumping the config off a device and [20:46.780 --> 20:52.100] it containing interesting information. Now, it can take things like what VLANs are. It will also [20:52.100 --> 20:58.320] contain hashes or possibly even encrypted versions of the passwords. So we managed to dump a config [20:58.320 --> 21:02.360] off one of the cabin control switches. It took about two or three minutes to get this, [21:02.360 --> 21:07.040] which isn't too bad, and they were hashed passwords. We put them on our cracking rig. [21:07.040 --> 21:11.940] It took, I think, about two days of effort to recover the password. Now, the password wasn't [21:11.940 --> 21:16.340] bad. It was a reasonably good password. I mean, I know two days isn't too long, but it wasn't Cisco. [21:16.340 --> 21:24.940] It wasn't ship. And we tried that against the cabin switches, but none of them had a network [21:24.940 --> 21:29.080] logon. So you could plug into them via serial and connect, but that's not particularly bad. [21:29.260 --> 21:34.640] However, remember, we've got access to this trunk, which means we've got access to those RDPs. [21:34.640 --> 21:39.820] And what we found was one of the RDPs had left its management interface exposed to the trunks [21:39.820 --> 21:45.700] that we could access. And that RDP had left the web interface enabled. That username and password [21:45.700 --> 21:51.020] recovered from one cabin switch worked on that single RDP. Now, it turns out that during [21:51.020 --> 21:56.440] commissioning, that single RDP hadn't fully been commissioned. So they hadn't changed the password [21:56.440 --> 22:02.240] on it. We gained access to that RDP, and that allowed us to intercept all of the traffic on [22:02.240 --> 22:06.620] that fiber trunk. So it wasn't just the things on the cabin switch loops anymore. It was pretty [22:06.620 --> 22:11.500] much everything on the vessel outside of the ICMS, the industrial control systems. [22:12.440 --> 22:17.180] So these VLAN trunks run all over the ship, and you can connect from inside the cabin using the [22:17.180 --> 22:23.180] phone cables. And it allows access to many, many systems. But it also allows sniffing to get any [22:23.180 --> 22:29.560] plain text auth. So not using HTTPS actually had impact here. The cabin switches had that brute [22:29.560 --> 22:34.600] forcible password, and that password worked on just one part of the core network. That allowed [22:34.600 --> 22:39.640] us to intercept all of the VLAN trunks. So we've got a pretty significant compromise here. Now, [22:39.640 --> 22:43.520] this was just an omission, and it did take quite a lot of effort to get to this point. But it was [22:43.920 --> 22:50.780] a problem, a vulnerability. Issue four, I'm the captain now. Now, if you've been on a cruise [22:50.780 --> 22:58.160] recently, you'll probably notice that a lot of the crew will carry tablets. So when you muster, [22:58.160 --> 23:02.960] if there's a safety drill, they'll be taking muster on a tablet. If you order in one of the [23:02.960 --> 23:07.320] restaurants, it will be on a tablet. If they come to your room with room service, they will have [23:07.540 --> 23:14.160] a tablet. And this is quite broadly called a passenger management system, a PMS. And it deals [23:14.160 --> 23:17.720] with lots of things. It does cabin assignment. It does access control. So quite often, it will [23:17.720 --> 23:22.180] be linked into the access control system so that your card works on your cabin. It does restaurant [23:22.180 --> 23:26.760] booking and the billing in the restaurant. It does mustering. And it also can hold your passport [23:26.760 --> 23:33.020] details for immigration. It's kind of core to how the vessel operates. Now, what we found was all of [23:33.020 --> 23:37.780] the tablets on this vessel used 8021X certificates for the Wi-Fi. And the tablets were actually [23:37.780 --> 23:42.540] quite well hardened. We couldn't get anything off them easily. So we couldn't get those certificates [23:42.540 --> 23:48.960] to gain access to the Wi-Fi. And we could have spent time doing something to possibly root one [23:48.960 --> 23:54.500] of the tablets or gain the creds from somewhere else. But remember, we've got access to every [23:54.500 --> 23:59.500] VLAN on the vessel, including the VLAN that carries the Wi-Fi traffic from all of the tablets. [23:59.500 --> 24:06.140] And we can intercept that traffic, which is what we did. So we found that the tablets, although [24:06.140 --> 24:12.100] they're using 8021X, that was actually implemented by the cruise company. They decided they wanted to [24:12.100 --> 24:18.480] layer that security on top. However, the PMS used HTTP. There was no encryption between the tablets [24:18.480 --> 24:24.640] and the server. That let us sniff credentials and other things going backwards and forwards. [24:25.460 --> 24:30.460] What we found, of course, was that there was a SQL server which was passing its username and [24:30.460 --> 24:36.060] password in the plane across this network. So once we gained access to those VLAN trunks, [24:36.060 --> 24:40.780] we could get this username and password. We could then add our own user into the passenger [24:40.780 --> 24:46.400] management system, and we could pretty much do what we want. So I could book myself into the [24:46.400 --> 24:53.000] best restaurant on the ship and not have to pay for it, for example. But perhaps more fun was we [24:53.000 --> 24:58.180] worked out how to log in as the captain on this system. So we could go to the restaurant, [24:58.180 --> 25:02.160] we could order the most expensive bottle of wine, and we could bill it to the captain. [25:02.500 --> 25:06.380] So this isn't good, really. This is a serious impact. [25:08.520 --> 25:12.780] The PMS had good Wi-Fi security that was put in place by the cruise company, [25:12.780 --> 25:18.300] but the PMS vendor used HTTP for the communications. It just wasn't secure enough. [25:18.360 --> 25:22.500] We've covered those common SQL creds. We've not managed to test them on any other ships. [25:22.500 --> 25:27.160] They could be the same across other ships. And with that, we could become anyone. [25:27.500 --> 25:32.360] We could wipe details. We could order things in restaurants. It's pretty crazy. [25:32.740 --> 25:38.180] So I think we pretty comprehensively owned this ship. It was a really, really good fun test. [25:38.600 --> 25:44.080] So what is the conclusion here? Well, these attacks did require detailed knowledge. [25:44.480 --> 25:48.360] We had to be on the vessel. We had to have a good level of understanding. [25:48.360 --> 25:56.180] We weren't really strictly detected. One of the problems with a ship is it's hard to perform [25:56.180 --> 26:01.260] things like intrusion detection remotely. So you might be able to sniff traffic and things like [26:01.260 --> 26:05.220] that, but you've only got a limited amount of bandwidth to send that back to a SOC. [26:05.460 --> 26:12.840] So no one really noticed us. We dressed smartly. And the couple of times that people noticed us [26:12.840 --> 26:15.960] opening cabinets and things like that, no one said anything. [26:15.960 --> 26:20.800] Now, interestingly, most of the risks on the ship were actually introduced by third parties. [26:20.800 --> 26:25.280] The cruise company had done a lot to secure those networks, but it was third parties putting [26:25.280 --> 26:31.160] systems in and making mistakes and not doing security properly that introduced most risks. [26:31.480 --> 26:37.440] Now for a ship, denial of service is very costly. If you can stop a cruise ship leaving its berth, [26:37.440 --> 26:41.080] especially in one of the smaller ports where there's only one or two berths, [26:41.080 --> 26:45.380] and another ship's waiting to come in, the port can charge you huge sums of money. [26:45.380 --> 26:50.500] We're talking tens or even possibly hundreds of thousands of dollars per day. You've got passengers [26:50.500 --> 26:54.740] complaining. You're going to possibly have to reschedule flights, get hotels for people, [26:54.740 --> 26:59.860] your next cruise may be delayed. So causing any denial of service, whether that's locking people [26:59.860 --> 27:04.660] out their cabins or stopping the ship sailing, can cost you huge sums of money. So don't always [27:04.660 --> 27:08.540] think about it as steering another ship into another ship. Think about how you can impact [27:08.540 --> 27:13.460] the passengers. But lastly, cruise ships are massive amounts of fun. It's rare that you'd [27:13.460 --> 27:20.260] be able to explore such huge complex machines with such level of detail. Definitely one of the [27:20.260 --> 27:26.620] most fun tests I've been on this one. Thanks for listening. I'm Cyber Gibbons on Twitter. [27:26.620 --> 27:31.880] If you've got any questions or you want to know anything more, just ping me a DM or [27:31.880 --> 27:35.880] send me a message on Twitter. That'd be great. Thanks for listening. Bye.