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:
To name but a few.
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:
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.
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.
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:
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.
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.
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.
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.