Quick summary and timeline:
- I’ve been in contact with Stena since at least July 2022 to get a potential security issue fixed. The issue is not a big deal, but it does allow unauthenticated access / circumvention of their security/tracking measures onboard their ferries. Stena did (does?) not understand how Coordinated Vulnerability Disclosure works. Stena then attempted to get me to disclose personal information and pointed me to generic customer service. Their customer service did not understand CVD either; contact was only established after I managed to find a direct email address for their security officer. Stena continued to pass the buck to their supplier,
TeleNOR Maritime, which never answered either. - Stena stopped responding to emails asking for updates since August 25th 2022.
- I attempted to reach out on Oct. 2nd 2022: no reply.
- My final attempt to get in contact was on Dec. 14th 2022.
- Per Dec. 14th, I notified Stena I’d be giving up and disclosing the issue. This is that disclosure.
Issue Description
Stena uses a (partially) satellite-based TeleNOR Maritime setup with Fortinet (FortiGate?) firewalls aboard their ferries, in order to control what passengers can do with the WiFi/onboard Internet. Depending on the subscription you pay for, certain features/priorities (QoS) appear to be enabled/applied. As it turns out, the captive portal setup is somewhat easy to circumvent, even though it appears to do some limited TLS-inspection to control access. It is comparatively easy to escape tracking and tracing, because SSH is not being blocked/filtered.
In short: to circumvent their ‘captive portal’ and have unlimited access for free:
1) Spoof or use a randomly generated MAC address
2) Use the provided Stena DNS servers
3) Pick the ‘free WiFi’ choice
4) Use sshuttle (https://github.com/sshuttle/sshuttle) or similar to set up a SSH-based VPN and reroute the DNS
At this point, all internet traffic is unrestricted.
I confirmed that this worked reliably. Of course, in accordance with CVD guidelines, I DID NOT ABUSE or otherwise excessively use this circumvention and consequent internet access, and only established whether the circumvention was effective! I also did not attempt to further explore the network for other possibile resulting security weaknesses, such as potential lateral movement.
Obviously, there are tools to (largely) automate this setup. The risks of this issue are limited, but could nevertheless have significant effects:
1) Passengers can use normal internet access and circumvent your payment/subscription model (lost revenue)
2) Real ‘bad actors’ can abuse ship internet access without being properly traceable. I noted that the ‘exit IPs’ vary, depending on the ship’s location. This is arguably beneficial to a bad actor, though.
Final Thoughts
I really hope companies start to do better. Just because you’re not an IT company, doesn’t mean you do not have to implement proper security policies and that you get to pass the buck to your suppliers. At the very least, don’t give ‘white hat’ security researchers the cold shoulder: work with them instead.