Hijacking SOME/IP Protocol with Man in the Middle Attack

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.

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.

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.

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 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.

Attack Mitigation

There are several ways to mitigate this kind of attack, the preferred choice depends mainly on the network properties. 

In some cases applying a basic firewall using the eswitch capabilities (e.g TCAM rules) might prevent the attack, but in other cases, it will not be enough.

It is highly recommended to use advanced security mechanisms as an Intrusion detection  prevention system (IDPS) or advanced firewall, like in the AUTOSAR firewall standard, that will filter the traffic not only based on regular network parameters (MAC addresses, IP addresses, and UDP/ TCP ports), but also on automotive specific 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.

Conclusion

The role that the SOME\IP in the E/E architecture continues to grow, and the susceptibility to cyber threats is exemplified by the described 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.

This concerning trend underscores the critical need for robust  cybersecurity measures. The type of mitigation methods that can be used depends on the network properties, but the use of advanced, automotive-specific, security mechanisms is highly recommended to prevent attacks like this one.

Mitigating such vulnerabilities requires the implementation of advanced, automotive-specific security mechanisms to thwart potential attacks. Moreover, this looming risk associated with SOME/IP has not gone unnoticed within regulatory frameworks. For example, the Jaspar Japanese regulation has duly identified and highlighted this vulnerability, emphasizing the imperative for stringent security protocols in automotive communication standards. Safeguarding against exploits in systems utilizing SOME/IP remains a pivotal concern, warranting proactive measures to fortify these frameworks against evolving cyber threats.