How Insecure M2M Routers Turn Public Transit Into a Surveillance Network

TLDR: Researchers at DEF CON 2025 demonstrated how a lack of network isolation and weak authentication in M2M routers allows attackers to compromise entire public bus fleets. By exploiting command injection and unencrypted APIs, an attacker can access real-time GPS, video feeds, and manipulate vehicle status. This research underscores the critical need for strict network segmentation and token-based authentication in industrial IoT deployments.

Public transportation systems are increasingly becoming massive, interconnected IoT networks, yet the security architecture behind them often resembles a home router from 2005. The recent research presented at DEF CON 2025 on smart bus infrastructure proves that when you connect critical operational technology to a public-facing network without proper segmentation, you are not just exposing a single device; you are handing over the keys to the entire fleet.

The Anatomy of the Compromise

The attack chain begins with the M2M router, the central nervous system of the bus. These devices are designed for machine-to-machine communication, often handling telemetry, GPS, and passenger Wi-Fi. In this specific research, the router was running an outdated version of the BOA web server, a classic target for researchers due to its well-documented vulnerabilities.

By simply connecting to the bus's public Wi-Fi, the researchers were able to reach the router's management interface. The device lacked basic security controls, and the researchers quickly identified a command injection vulnerability. Because the router was misconfigured to allow access to sensitive system commands through the web interface, they could execute arbitrary code with root privileges.

Once inside the router, the network was wide open. The researchers performed a port scan using RustScan and discovered a treasure trove of internal services. The most critical finding was an MQTT broker that lacked proper authentication. MQTT is the backbone of many IoT systems, and by gaining access to this broker, the researchers could subscribe to all topics, effectively sniffing real-time GPS data and vehicle telemetry for the entire fleet.

Exploiting the ADAS Ecosystem

The Advanced Driver-Assistance System (ADAS) is intended to improve safety, but it became the primary vector for data exfiltration in this engagement. The ADAS system relied on a web interface running on port 80 with zero encryption. The researchers found that the system used a simple, hardcoded "admin/admin" credential set, which is unfortunately still a common reality in industrial hardware.

After bypassing the authentication, the researchers accessed a hidden directory structure. The /media path contained raw video recordings from the bus cameras, while the /api/otp path exposed an unauthenticated Open Trip Planner API. This API provided full access to the bus's operational data, including driver names, route schedules, and real-time location coordinates.

The technical failure here is twofold: the lack of Broken Access Control and the use of cleartext protocols for sensitive data. When you have an API that returns JSON objects containing live vehicle status without requiring a session token, you have essentially built a public dashboard for your internal operations. The researchers demonstrated that they could even forge packets to manipulate the bus status, potentially triggering false "Emergency Help" alerts or marking vehicles as "Out of Service" to disrupt transit operations.

Real-World Implications for Pentesters

For a penetration tester, this engagement highlights the danger of assuming that "internal" network segments are secure. When you are testing an IoT environment, your first goal should be to identify the M2M gateway. If you can compromise the router, you have effectively bypassed the perimeter.

During your next assessment of a similar environment, prioritize the following:

1. Service Discovery: Use Nmap or RustScan to identify all running services on the internal subnet, specifically looking for MQTT brokers, web management interfaces, and DVR systems.
2. Credential Stuffing: Always test for default credentials on industrial hardware. Vendors often ship devices with the same password across an entire product line.
3. Traffic Analysis: Use Wireshark to capture traffic between the onboard computer and the central server. If you see cleartext HTTP or unencrypted MQTT, you have a clear path to data manipulation.
4. API Fuzzing: If you find an API, check for documentation pages. Developers often leave "help" pages exposed that list all available endpoints, which can save you hours of manual discovery.

Securing the Fleet

Defending these systems requires a shift in how we approach industrial IoT. The most effective mitigation is strict network isolation. The passenger Wi-Fi should never be on the same network segment as the vehicle's operational telemetry. If a guest network is required, it must be firewalled off from the internal management plane.

Furthermore, all communication between the bus and the central control system must be encrypted using modern protocols like TLS. If the protocol does not support encryption, it should be wrapped in a VPN tunnel. Finally, move away from static, hardcoded credentials. Implement Identity and Access Management that requires unique, token-based authentication for every service, ensuring that even if one device is compromised, the attacker cannot pivot to the rest of the infrastructure.

The next time you find yourself on a bus with "free Wi-Fi," remember that the convenience of connectivity often comes at the cost of the system's integrity. As researchers, our job is to keep pushing these vendors until they treat their industrial hardware with the same security rigor as their enterprise software.