Your Car is a Corporate Spy: How GM, Toyota, and Allstate Sold Your Driving Data to Insurers + Video

Listen to this Post

Featured Image

Introduction:

Modern vehicles are no longer just modes of transportation; they are sophisticated data-gathering platforms connected to corporate networks and third-party data brokers. The recent revelations that GM sold driver data to LexisNexis, Toyota shared telematics with Progressive, and Allstate embedded hidden trackers in applications like Sirius XM illustrate a massive, largely invisible surveillance economy where your driving habits are monetized without your explicit consent. This article explores the technical mechanisms behind automotive telematics data harvesting, the privacy implications, and the practical steps security professionals can take to audit and mitigate this unauthorized data exfiltration.

Learning Objectives:

  • Understand how telematics control units (TCUs) and in-vehicle infotainment (IVI) systems transmit driving behavior data to third-party brokers.
  • Identify the network protocols (MQTT, HTTPS, CAN bus) and API endpoints used by automakers to exfiltrate sensitive location and driving data.
  • Implement network-level and hardware-level countermeasures to block unauthorized data transmission from connected vehicles.

You Should Know:

1. Telematics Data Harvesting: The Technical Architecture

The core of automotive data surveillance lies in the Telematics Control Unit (TCU) and the In-Vehicle Infotainment (IVI) system. These components are essentially Linux or Android-based embedded computers with cellular modems (4G/5G) that connect directly to the manufacturer’s cloud. When a user consents to a vague “vehicle services” agreement, the TCU begins transmitting CAN (Controller Area Network) bus data—including GPS coordinates, speed, acceleration, braking force, and even seatbelt usage—to cloud endpoints.

To see this in action from a security research perspective, you can simulate a vehicle’s network traffic by intercepting the cellular uplink. While physical interception requires a Faraday bag or a controlled cellular base station (like a YateBTS or BladeRF), one can analyze the API calls made by the vehicle’s companion mobile app.

Step‑by‑step guide to analyzing telematics API traffic:

  1. Set up a proxy: Install Burp Suite or OWASP ZAP on a laptop. Configure your Android or iOS device to route traffic through the proxy (using a VPN or manual proxy settings).
  2. Install the vehicle’s app: Log in to the official app (e.g., MyGM, Toyota, or Sirius XM) and grant all permissions.
  3. Capture API calls: While using the app, observe the endpoints. Look for domains like .telematics.com, .connectedcar.com, or .lexisnexis.com. Pay attention to POST requests containing JSON payloads with fields like vehicleSpeed, latitude, longitude, and hardBrakingEvents.
  4. Decode the data: Use `curl` to replicate the API request to verify the data flow. For example, you might see:
    curl -X POST https://api.telematics.gm.com/v1/vehicle/status \
    -H "Authorization: Bearer [bash]" \
    -H "Content-Type: application/json" \
    -d '{"vehicleId":"VIN123","timestamp":"2026-03-24T12:00:00Z","speed":65,"location":{"lat":40.7128,"lon":-74.0060}}'
    
  5. Intercept the cellular connection: For advanced users, setting up a rogue cellular base station (using a USRP and OpenBTS) in a Faraday cage can capture raw GSM/LTE traffic directly from the vehicle’s TCU without going through the app, revealing unencrypted or poorly secured telemetry.

2. Embedded Tracking in Third-Party Apps

Allstate’s integration with Sirius XM represents a sophisticated supply chain attack on privacy. Instead of installing a dongle, they leveraged a legitimate application with high user engagement to collect telemetry every 15 seconds. This data is likely collected via software development kits (SDKs) embedded within the Sirius XM app. These SDKs run in the background, accessing GPS and motion sensors, and transmit data to Allstate’s servers for risk scoring.

Step‑by‑step guide to detecting and blocking embedded trackers:

  1. Network monitoring: Use a tool like Wireshark or tcpdump on your home network to monitor the vehicle’s Wi-Fi connection (if the vehicle connects to home Wi-Fi). Filter for traffic to domains associated with data brokers.
    On a Linux gateway, run tcpdump to capture traffic from the vehicle's MAC address
    sudo tcpdump -i eth0 -w vehicle_traffic.pcap host 192.168.1.100
    
  2. DNS filtering: Implement a Pi-hole or use a DNS filter to block domains known for data brokering. Common domains to block include:
    – `lexisnexis.com`
    – `allstate.com` (for tracking endpoints)
    – `progressive.com` (telematics endpoints)
    – `verisk.com`
    – `telematics.net`
    3. Disable telematics via OBD-II: For vehicles where the TCU is integrated with the OBD-II port, you can use a physical blocker. Some security researchers use an OBD-II splitter that powers the port but interrupts the CAN bus lines (CAN-H and CAN-L) to the TCU. This prevents the TCU from reading the vehicle’s internal data while allowing diagnostic tools to function.

3. Mitigating Data Exposure: Cloud Hardening and Opt-Outs

While physical and network controls are effective, the data already shared is stored in third-party data broker repositories like LexisNexis’s “Risk Solutions” or Verisk’s “Telematics Data Exchange.” Security professionals must also understand how to exercise data subject access rights (DSAR) under regulations like GDPR or CCPA to request deletion.

Step‑by‑step guide to auditing and removing existing data:

  1. Request a consumer report: Visit LexisNexis Risk Solutions’ consumer disclosure page. Submit a request for your “CLUE” (Comprehensive Loss Underwriting Exchange) report or Telematics report. This process usually requires identity verification via government ID.
  2. Analyze the report: The report will list every trip, speed event, and hard brake recorded, often linked to your vehicle identification number (VIN).
  3. File a deletion request: Under CCPA, if you reside in California, you can request deletion. Many automakers have portals (e.g., GM’s Privacy Portal) where you can revoke consent for “connected services.” Revoking consent often requires a factory reset of the infotainment system to delete the data transmission certificates.
  4. Disable the TCU physically: As a last resort, locate the TCU (often behind the dashboard, under seats, or in the trunk) and disconnect the cellular antenna or the main power harness. On some models, this may trigger a check engine light or disable remote features, but it effectively stops exfiltration.

4. API Security Failures and Exploitation

The telematics ecosystem is rife with API security vulnerabilities. Researchers have frequently found that automakers use weak authentication, such as relying solely on a VIN (Vehicle Identification Number) to grant access to vehicle data. This allows attackers to remotely track, unlock, or start vehicles.

Step‑by‑step guide to testing API security (for penetration testers):
1. Identify the API endpoints: Using the proxy method described earlier, collect API endpoints from the mobile app.
2. Test for IDOR (Insecure Direct Object References): Change the `vehicleId` or `VIN` parameter in the request to another vehicle’s VIN. If the API returns data without re-authenticating, it’s vulnerable.

 Example IDOR test using curl
curl -X GET "https://api.telematics.gm.com/v1/vehicle/location?vehicleId=1G1XXXXX123456789" \
-H "Authorization: Bearer [bash]"
 Change the VIN to 1G1XXXXX987654321 and observe if data is returned.

3. Check JWT (JSON Web Token) validation: Decode the JWT token from the app using `jwt_tool` or jwt.io. Look for weak signing algorithms (e.g., none) or misconfigured claims that allow privilege escalation.

5. Windows and Linux Commands for Network Forensics

To audit whether your vehicle or a compromised device is leaking data, you can use standard operating system tools to monitor network connections.

On Windows (using PowerShell):

 Monitor active connections to known telematics domains
Get-NetTCPConnection | Where-Object { $<em>.RemoteAddress -like "lexisnexis" -or $</em>.RemoteAddress -like "progressive" } | Format-Table
 Capture traffic on a specific interface
netsh trace start capture=yes tracefile=c:\vehicle_traffic.etl
 Stop trace
netsh trace stop

On Linux (using iptables and tcpdump):

 Block all traffic to LexisNexis IP ranges (example)
sudo iptables -A OUTPUT -d 192.0.2.0/24 -j DROP
 Monitor all traffic from a specific MAC address (vehicle)
sudo tcpdump -i wlan0 ether host AA:BB:CC:DD:EE:FF -w vehicle.pcap
 Use tshark to filter for specific telemetry protocols (e.g., MQTT)
tshark -r vehicle.pcap -Y "mqtt"

What Undercode Say:

  • Key Takeaway 1: The automotive industry has effectively normalized mass surveillance, converting driving behavior into a commodity sold to insurers without explicit, granular consent, often burying permissions in lengthy terms of service.
  • Key Takeaway 2: Defending against this requires a multi-layered approach combining network-level controls (DNS filtering), hardware-level intervention (disabling TCUs), and legal mechanisms (DSARs and opt-out requests) to reclaim privacy.

The scale of this data collection is staggering. The fact that applications like Sirius XM, ostensibly entertainment apps, are repurposed as surveillance nodes highlights the dangers of SDK integration and data sharing agreements that users never see. For cybersecurity professionals, this presents a new frontier: defending not just servers and endpoints, but the embedded systems in vehicles that now operate as unmanaged IoT devices on corporate and personal networks. The kill switch mentioned in the original post refers to the potential for the government or corporations to remotely disable vehicles—but the reality is that the surveillance is already active, running silently in the background of every drive.

Prediction:

As consumer awareness grows, we will see a surge in class-action lawsuits against automakers and data brokers for violations of privacy laws like the CCPA and the forthcoming federal privacy legislation. Technically, we will witness a rise in open-source hardware solutions (e.g., CAN bus firewalls) that sit between the OBD-II port and the TCU, allowing users to whitelist legitimate diagnostic traffic while blocking telemetry. Automakers will face increasing pressure to provide physical kill switches for telematics units, shifting the market toward “privacy-as-a-service” features that will likely come at a premium cost.

▶️ Related Video (74% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Sam Bent – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky