Hacking Hotels via Smart Stationary Bikes: How Unsecured Gym Equipment Can Lead to RCE
Internet of Things (IoT) systems in hospitality environments are often overlooked as harmless amenities, but in reality, they can operate within highly interconnected networks, turning them into surprisingly effective gateways for broader system compromise.
During an on-site assessment at a hospitality property, a network segmentation test unexpectedly evolved into an attack scenario inspired by tradecraft associated with UNC3524, particularly its use of non-traditional infrastructure as access points. In this article, LevelBlue SpiderLabs demonstrates how an unconventional device like an IoT bike can serve as an initial foothold, enabling lateral movement into internal admin networks, and shows how modern covert access operations can exploit overlooked IoT systems, and evade traditional detection tools.
Executive Summary
SpiderLabs conducted an on-site penetration test at a hospitality property, where a network segmentation assessment unexpectedly resulted in an internal admin network compromise originating from an IoT smart bike. It should be noted that the gym facility was open 24/7 and did not require a guest keycard.
The Technogym smart stationary bike is closer to an IoT fitness terminal rather than just a bike with a screen. Its core user-facing features were workout tracking, interactive training sessions, and connectivity to fitness platforms. Other features can include IoT management, such as USB access for firmware, API calls to external fitness services, and web-based management.
SpiderLabs discovered that these systems behaved like general-purpose embedded computers with rich network access and took advantage of the unauthenticated web browser. From this foothold, internal systems were enumerated, exposing sensitive internal resources. Internal resources access included PCI servers on the admin network, and two admin servers that exposed their file system through path traversal. This attack was carried out from the smart bike.
SpiderLabs was limited to the payloads it can generate through the smart bike itself. The USB option was available but not seen as a viable option so as not to brick the IoT object. SpiderLabs found another way to obtain a deeper hold into the network.
Due to the lack of switch port security (e.g., Cisco Port Security enforcement), SpiderLabs was able to access unauthorized endpoint connections without detection or automatic blocking. The connection was reused on a test laptop, significantly expanding access, and enabling full validation of internal reachability. This ultimately led to the identification and exploitation of a vulnerable Oracle WebLogic server resulting into authentication bypass and remote code execution (RCE).
Technical Analysis
SpiderLabs noticed that the fitness gym facility was open for 24 hours, has all-guest access (no-lock, no room card required), and hosts network-connected exercise machines. SpiderLabs went back to the fitness club at an opportunistic time and began using the smart stationary bike's web browser. SpiderLabs began accessing the devices from a guest VLAN and tried all admin network VLANs. This led to us ultimately accessing two PCI servers.
Figure 1. This image shows the reachable servers on the smart bike. Also shown are the Technogym bike’s other connectivity options.
Figure 2. An admin-segmented server.
SpiderLabs then attempted to exploit a path traversal vulnerability on the affected servers. Figure 3 shows that the returned browser page is a truncated/malformed HTML page. This is because the server returned a non-HTML structured HTTP response, indicating that the attack worked.
Figure 3. The web browser showed a malformed HTML page after exploiting a path traversal vulnerability on the smart bike.
Due to the limited nature of the smart bike browser, SpiderLabs then moved on to connecting the attack machine to the port of the stationary bike, as well as the spare port of the gym. Both Ethernet ports obtained an IP for the guest VLAN through DHCP. No switch port security was implemented on the property, allowing the IPv4 assignment on the attack machine. Figure 4 shows the path traversal vulnerability being re-exploited, and Figure 5 shows the enhanced image of the data obtained from the Linux passwd file. Using the current access, SpiderLabs was also able to identify and exploit another admin server's Oracle WebLogic RCE vulnerability on its second round of simulated intrusion.
Figure 4. Switch port intrusion and retesting of the path traversal vulnerability.
Figure 5. RCE on an accessible admin network server.
For the third round of simulated intrusion, the property’s security team successfully un-segmented the fitness gym network, resulting in the SpiderLabs attack machine no longer being able to establish a route to the admin network. It’s important to note that SpiderLabs can further improve on this simulated attack and execute it on one round of intrusion without triggering detection. However, SpiderLabs was given a limited time to conduct an on-site assessment, reconnaissance, and execution, whereas threat actors do not face such limitations and can execute at an opportune time with surgical precision.
Conclusion and Recommendations
Managing hundreds of IoT devices is often challenging, but it is critical that property owners maintain full visibility of all assets connected to their network. Even in a comprehensive asset-tracking scenario, some IoT devices may be missed, partly because they were not active during inventory or simply not in use. The worst case is that they were not detected during asset inventory and were reactivated and then possibly connected to an internal network after the fact.
To protect IOT devices from evolving threats and risks, security teams should adopt layered defense strategies, such as adding switch port security on all guest-accessible ports, and proactively discover exploitable IoT weaknesses and gaps through expert knowledge from LevelBlue SpiderLabs. Learn more about securing your IOT landscape here.