How to Protect Against Remote Multi-Vehicle Attacks

Hacker Gains Access to Thousands of Cars Worldwide

In April 2019, a hacker gained access to thousands of cars around the world via a location and fleet management service. In this blog, we’ll drill down into what happened and how this type of attack can be detected before causing any serious damage.

Overview

According to Motherboard, a hacker called L&M, took advantage of a security vulnerability in two GPS tracker apps, iTrack and ProTrack, used to manage and monitor connected cars. L&M used a script to brute-force “millions of usernames” via the apps’ API and was able to gain access to 27000 accounts, which gave him the ability to track the location of tens of thousands of vehicles around the world. He was able to access sensitive PII and even send commands such as “Stop Engine” that carry severe security implications.

A screenshot from iTrack product demo with the remote command’s options including “Stop Engine”

L&M shed light on four challenges

Early detection can enable service providers to stop such a hack or prevent it altogether. There are four main challenges we identified in this specific event:

1. How do you protect vehicles already on the road when they do not have a dedicated cyber security solution installed in them?
2. How do you protect vehicles that are connected to the internet via an aftermarket device like an OBD-II dongle installed by a service provider (not the car manufacturer)?
3. How do you prevent multi-vehicle attacks when access to the server (like in this use case) grants access to the entire fleet?
4. How do you protect against an attack on a service, like iTrack and ProTrack? By accessing the service’s servers, a hacker can control the vehicles remotely.

Let’s take a closer look at each of the above challenges and how to overcome them.

Connected vehicles already on the road and vehicles with aftermarket devices

The first two challenges go together and may utilize the same solution. In both cases, you need a solution that doesn’t require physically deploying technology in the vehicles. These vehicles are already connected and communicate telematics and location data to backend servers. By monitoring and analyzing the data that is already being collected, you can detect anomalies and possible threats.

Multi-vehicle attacks

Early detection of a multi-vehicle attack requires an “eye in the sky” view of the entire fleet of connected cars. The solution here would be a system that can monitor and analyze the fleet while using behavioral analytics to detect anomalies, or inconsistent behavior for the OEM or fleet. For example, a connected car service would have data that can be aggregated in order to learn the behavioral patterns of the vehicle and communications behavior. If a system is monitoring all of the data collected from the connected cars for anomalies, it could detect an unexpected command pattern, application behavior anomaly or vehicle behavior anomaly. L&M’s hack, in this case, would be detected, giving the service providers the opportunity to take action before any damage is done.

Attacks on services

As we saw in this case, a hacker can access and control connected vehicles from a service provider. So it’s not enough for a system to understand normal behavior for the vehicles; it needs to understand the service. This includes every single part of the service – the mobile app, telematics services, vehicle communication, etc. By understanding the communication being monitored, the system can detect anomalies and potential attacks. Do system-wide remote software updates (e.g. OTA updates) usually happen at specific times? Is it normal for a “Stop Engine” command to be sent when a vehicle is moving?

In this case, L&M gained access to the services’ servers and could send commands from there. Normally, commands to stop an engine would be sent from the mobile app user portal, so a system that understands “normal” behavior would alert the service of an anomaly when such a command is being sent directly from the server.

Upstream’s C4 platform

Upstream is a cloud-based cybersecurity solution designed to address the challenges of securing connected car services against a multitude of attack vectors including the ones in this post. The solution is entirely cloud-based and agent-less – this means that no components need to be installed in the vehicles to be protected. Instead the C4 platform analyzes and monitors data already collected from the connected car infrastructure (vehicles, application servers, mobile apps, APIs) using a normalized universal data format. Being cloud-based enables the solution to detect activity of vehicles already on the road as well as new vehicles. By establishing a normal baseline of connected service operation, the platform is then able to detect anomalous behavior on any part of the connected car infrastructure, including suspicious activity that affects multiple vehicles at the same time.

Upstream’s C4 platform is able to detect anomalies in real-time by using various classification techniques working in parallel and then issuing alerts to the security analysts in the Vehicle Security Operations Center (vSOC). The product fully integrates with existing SOC solutions such as SIEM and Workflows and allows the security analysts to leverage the C4 dashboard and incident investigation timelines to perform triage, investigate the incident, make informed decisions, and take necessary action.

For more information on how C4 works, watch our webinar “Automotive Cybersecurity: Protecting the Car from the Cloud” or schedule a demo.