Pen Testing Ships. A year in review

Partially driven by the upcoming inclusion of Cyber Security by the IMO (International Maritime Organisation), 2019 was a really busy year for maritime security testing at PTP.

What can we all learn from a year of evaluating the security of ships?

We’ve been involved in all sorts of ship testing, here are a few examples:

• A Moss Maritime CS55 deep water exploration drilling rig
• A Neo-Panamax container ship
• A re-supply vessel
• A seabed survey vessel
• A brand new cruise ship on its shakedown voyage

To name but a few.

What are the common (in)security themes we keep finding?

There is a distinct lack of understanding and interaction between IT and OT installers/engineers on board and in the yard.

The OT systems are often accessible from the IT systems and vice versa, often through deliberate bypass of security features by those on board, or through poor design / poor password management / weak patch management.

IT and bridge systems are often poorly configured or maintained.

Maritime technology vendors have a ‘variable’ approach to security. A few offer reasonable security of their products. Most are terrible.

We’ve even reviewed a maritime-specific security product that was vulnerable in itself, creating new security holes in a vessel rather than fixing them!

Documentation of networks and systems often has little correlation with what is actually on board.

Cruise ships add multiple new layers of technology, increasing the attack surface dramatically.

Hotel systems (IT, booking systems, inventory, guest Wi-Fi, infotainment, CCTV, lighting, phones et al) plus the actual vessel itself (bridge systems, satcoms, navigation, ballast, engine management etc).

We obviously can’t name the vessel owners but here’s some of the things we discovered and some of the technology and vendors affected:

When is an air-gap not an air-gap?

As you’d probably expect the newer vessels were generally far better documented with security having been a consideration from the outset… two of the vessels were under a year old (the cruise ship was brand spanking new) but on both tests we identified misconfigured systems and VLANs much as you’d expect. But we all make mistakes, that’s why we conduct an independent audit, right?

The more vessels we review, the more we see that ship operators genuinely believe there is an air gap between the traditional IT systems and the on-board OT. That is almost never the case. On only one of the fifteen or so vessels I’ve be on was there a genuine air gap.

Rigs usually have a data historian: things like its position, engine speeds and temperatures, drilling data, oil flow, almost anything that could be described as an Industrial Control System (ICS) pass information to the data historian. Guess what: it bridged both networks (OT and IT) as its HMI (Human Machine Interface) was on the IT network so this provided a bridge across which we were able to compromise the rig pretty much completely.

On the re-supply vessel we found a Voyage Data Recorder which bridged networks, allowing us to effect a very similar compromise…

We’ve also found dual-homed PCs bridging networks on a large number of vessels again in 2019. Some of these were done intentionally by installers, others clearly accidentally, others deliberately bridged by crew afterwards.

Who’s got access to the vessel?

As you’d expect different vessels have different risk profiles: a cruise liner is filled with the fare paying public, crew and temporary staff. Internet access is often expensive; stories of staff selling their airtime to guests are commonplace. Even staff trying to access bridge networks for unlimited internet access after they’ve burned through their allowance.

A rig has a core rotational crew but otherwise is filled with various contractors and sub-contractors – be that drilling, the mud-room, riggers… the list goes on and on. More and more people on board with the time and motivation to bypass your network segregation and security controls.

On the rig we found a Wi-Fi access point that was probably added by a member of the mud-room crew so they could listen to streamed music in a Wi-Fi free zone. The password was the contractor’s company name: guilty as charged! That Wi-Fi AP bridged critical security systems, exposing the security of the vessel.

One of the first things we do when we get onboard is to tap into the OT network and start sniffing the traffic. You would be shocked how often we find IP traffic that shouldn’t be there.

We’ve found supplier remote access systems in place that shouldn’t have been there. In one case, an engine management telemetry system was available on the public internet. It appears that the vendor no longer provided service to the vessel engine, but no-one had taken the connection to the internet offline! It would have been trivial to remotely shut down the engine.

In several audits in 2019 not only were these modems un-documented but they were frequently running outdated software and ridiculously easy to guess passwords; e.g. the vendors name!

We’ve also found TeamViewer installs on a number of occasions that the vessel owners and operators knew nothing about. Again these were vulnerable versions with really ridiculous credential choices.

Passwords and default installs

As with most Industrial Control Systems, password re-use across an environment is endemic and generally if you know the credentials for one PLC or industrial switch then you probably have access to them all. Moreover if you know it for one vessel then guessing the password for the rest of the fleet is often as simple as changing the vessels name. D’OH!

As with many traditional penetration tests, we are still finding .txt files and .docs with IP addressing information, naming conventions and user names / passwords.

One of the biggest surprises (not that I should have been at all surprised in hindsight) is the number of installations we still find running default credentials – think admin/admin or blank/blank- even on public facing systems.

Throughout the year we’ve looked at over dozen new or nearly new vessels. They all suffered from similar issues.

Example vulnerabilities:

• IP phone systems from Swan with default creds of Admin/9999
• Satcom terminals and antenna control units with default creds
• A door access control system
• Cisco switches (cisco/cisco)

We’ve found the admin panel of a CCTV system exposed to the public with default creds (as documented in their install guide) so anyone could access the entire system.

Lighting control systems suffered a similar fate on several occasions too.

Worryingly we’ve also found hard coded credentials (or as one of my colleagues calls them ‘back doors’) in a Satcom ACU (Antenna Control Unit) and also the VSAT modem.

Patching is still a problem – especially with OT and ICS

In IT Security land we’ve come to understand patching is a MUST DO and when it’s neglected it’s the cause of most serious incidents. Unfortunately, people still tend to think of Industrial Control Systems as ‘packages’ so once it’s been purchased an OT mentality kicks in as patching requires down time and as it’s “Air Gapped” it’s not at risk right?

Put another way: “if it ain’t broke then we ain’t gonna fix it”.

A great example of why this approach can add a significant risk is a really cool bit of research that my colleague Chris Wade did as part of a vessel audit earlier in the year. It all started because the Siemens RTU’s (Remote Terminal Unit) were poorly patched exposing the configuration in which Chis noticed something really odd: the Admin password had two ‘hashes’ which is very unusual and even more oddly, the ‘hashes’ changed in length depending on the password length. Hashes don’t change length!

It’s a great BLOG POST and his hard work resulted in Chris discovering a ‘key to control them all’… and that’s EVERY Siemens Scalance 200/300/400 ICS Switch ever produced! CVE-2019-6567.

When could a little bit of IT skill result in a very cheap cruise?

From our testing experience to date, a modern-day cruise (assuming you have a little technical know-how, and are that way inclined) could be a seriously cheap holiday.

We found (more than once) un-patched code injection vulnerabilities in a booking/inventory software suite used in the cruise industry… think FREE food and drinks. Couple this with default login credentials and you could add FREE Wi-Fi and unlimited FREE phone calls. Then add access to any cabin door lock anytime you want.

Take-aways for 2020

• It’s hard to tell what’s on a ship and it needs an experienced third party to find out for you.
• Finding consultants who genuinely understand vessel OT, IT and how they interact is difficult.
• There are plenty of people who understand IT security, but few who understand how it works in practice on a vessel
• There are risks associated with testing OT networks. If your supplier doesn’t understand that, don’t use them!
• Third-party systems add a significant risk and with the advent of cheap satcom based internet and the drive for connectivity, cloud services will only increase this risk.
• Maritime technology vendors rarely understand security. It’s not properly ‘on their radar’ despite marketing literature often talking about ‘cyber’
• What you think is on a vessel network is rarely what is actually on board

And don’t forget that ships don’t always arrive in dock on time! If you’re planning a vessel audit, add some contingency time as these are operational vessels… Weather, load problems and technical issues have no consideration for testing schedules or time planning.