This article will describe a Man in the Middle (MITM) attack on automotive applications, using SOME/IP protocol over in-vehicle Ethernet networks and how it can be mitigated.

Note: A MiTM attack involves the secret interception and manipulation of communications between two parties.

In order to facilitate effective and high bandwidth in-vehicle network connections, in-vehicle Ethernet links are becoming more common in-vehicle E/E architecture.

In order to use Ethernet in the automotive world, dedicated application layer protocols were developed, such as DoIP (Diagnostics over IP) and SOME/IP. In addition, a typical automotive Ethernet stack can also include common Ethernet protocols from the IT world, such as ICMP, ARP, and DHCP.

Typical In-Vehicle Ethernet Stack

Typical In-Vehicle Ethernet Stack

A general analysis of in-vehicle network security refers mainly to the following high-level impacts of Attack Patterns:

  1. Denial of service
  2. Tampering with ECU behavior
  3. Malicious triggering of vehicle behavior
  4. Falsify driver information
  5. User information disclosure
  6. Compromise intellectual property

Four of the above threats can be caused by this MiTM attack: denial of service, malicious triggering of vehicle behavior, falsify driver information, and user information disclosure.

Background to SOME/IP and Service Discovery

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is an automotive middleware protocol, designed to support in-vehicle communication needs such as high data rate, low transportation overhead, and short initiation time.

It is designed for Client-Server communication, where generally the server provides services to its clients. Services can supply notifications about in-vehicle events, and RPC (Remote Procedure Call) mechanisms, which allow a client to invoke functions on the server or request information.

SOME/IP has a Service Discovery feature (SOME/IP-SD), enabling dynamic subscription to services. Typically a server sends Offer messages to everyone in the network, telling them about the services it supplies. Clients then send Subscribe messages, subscribing to the services relevant for them. After the subscription is complete, the server will supply the service to the client, meaning it will send notifications and answer requests. This subscription process is periodic, usually once every 2 seconds.

SOME-IP Communication

Typical SOME/IP communication between client and server ECUs, including the SD messages

Reference Attack Setup

The attack setup represents a common use case in the automotive world, two ECUs, A and B, are connected via a switch and communicate over SOME/IP. ECU A is the server, supplying a service, S1, to ECU B, which is the client. In addition, there is another ECU connected to this switch, ECU C.

The attack scenario assumes that ECU C was compromised, and it is able to send spoofed messages to the network.


Attack setup- three ECUs connected through a switch

Attack Flow

In this attack, the attacker hijacks the service communication between ECU A and ECU B, forcing the communication to go through ECU C. Normally, ECU A sends Service Discovery Offer messages, offering S1 service. These messages are sent in multicast, therefore ECU C will receive them too. To execute the attack, for each Offer S1 message it receives, ECU C does two things: It subscribes to the service by sending a Subscribe S1 message to ECU A and then sends a spoofed Offer S1 message to ECU B.

ECU B receives both the original Offer S1 packet and the spoofed one, but it subscribes only to the second one, as it arrives just after the first one. In this way, two connections are initiated – ECU A (server) to ECU C (client), and ECU C (server) to ECU B (client).

ECU C then relays messages between ECUs A and B. For example, if ECU A sends a notification to its client ECU C, it will immediately forward its content to ECU B. The service subscription process and message relaying are repeated throughout the attack.


Attack description- ECU C performing SD subscription process with each ECU, and relays service messages

The adversary gains two things from executing such an attack. The first is the ability to eavesdrop on the communication between ECUs A and B. This communication is not visible to ECU C (thus the attacker) without the attack, as the switch forwards only the relevant packets to each switch port. The second is the ability to control and spoof the communication between the ECUs.

By performing this attack, the adversary is able to send false notifications to the client, invoke remote functions on the server, change messages data, or drop critical messages. All without causing any detectable communication errors on the server or client.

We were able to perform this attack using two simulated ECUs, connected through an automotive Ethernet switch, and an attack script.


Wireshark capture of the attack, describing the false subscription process and RPC messages relaying

Attack Mitigation

There are several ways to mitigate this kind of attack, the preferred choice depends mainly on the network properties. In some cases hardening the switch with proper TCAM rules or VLAN configuration might prevent the attack, but in other cases, it will not be enough. Generally speaking, it is highly recommended to use advanced security mechanisms, that will filter the traffic not only based on regular network parameters (MAC addresses, IP addresses, and UDP/ TCP ports), but also on automotive network parameters, such as SOME/IP service id and SOME/IP-SD message type.

Using authentication or encryption has a limited benefit in preventing this attack. SOME/IP-SD traffic has a multicast nature, so it can not be authenticated or encrypted using a standard protocol. The SOME/IP traffic can be authenticated or encrypted, but it will not prevent the attack, as the attacking ECU is sending SOME/IP messages on behalf of its own, after legitimately subscribing to the service.


In this article, we described a MITM attack exploiting the SOME/IP protocol. The scenario involves an adversary hijacking a connection between two applications on two separate ECUs, enabling the attacking ECU to eavesdrop on communications between them and manipulate the data sent. The type of mitigation methods that can be used depends on the network properties, but the use of advanced, automotive-specific, security mechanisms are highly recommended in order to prevent attacks like this one.


Author: Shir Mousseri, Product Manager of Ethernet Protection
at Argus Cyber Security

Subscribe to our blog

Recent Posts
remote attack telematicsArgus Automotive Use Cases Fleet Protection