Embitel

white logo
Search
Close this search box.

Cyber Attacks on UDS Protocol and DoIP Powered Modern Vehicular Networks: An Analysis

In recent times, as vehicles grow more complex, the software that powers their many functions has burgeoned in scale. This escalating complexity in automotive software systems has made the usage of diagnostic communication protocols indispensable.

Historically, protocols such as Diagnostic over Controller Area Network (DoCAN) and Unified Diagnostic Services (UDS) have been crucial. While DoCAN addresses layers 1-4 of the OSI model, UDS protocol zeroes in on layers 5 and 7.

However, to achieve a higher efficiency in diagnostic communications—especially when updating large-scale vehicle software—the industry is now pivoting towards UDS on Diagnostic over IP (DoIP). This protocol combination caters to layers 1-4 of the OSI model. Yet, this new frontier in vehicle ECU communication brings with it the lurking dangers of cyber-attacks.

Our latest article is an endeavour to delve deep into the potential threats posed by UDS protocol on DoIP, especially when exploited by advanced cyber attackers.

DoIP OSI Model

The Changing Landscape of UDS Protocol Vehicle Diagnostics

Modern vehicles are a confluence of advanced software and sophisticated functionality. As the software housed within ECUs has expanded, the need for diagnostic protocols that can handle large-scale updates efficiently has become evident. Enter UDS on DoIP: a combination, designed for precisely this challenge.

The Threat Matrix – Understanding the threats on UDS Protocol

The inherent capabilities of UDS on DoIP, which allow for efficient software updates, paradoxically, also make vehicles susceptible to malicious intrusions. Malefactors can exploit these protocols, potentially overwriting legitimate vehicle software with unauthorized versions or even assuming complete control over the vehicle.

This article assumes that attackers can exploit remote DoIP communications with diagnostic tools. This assumption is based on various historical data and our automotive team’s experience that ECUs can be hacked if their vulnerabilities are properly exploited. Thus, an attacker might share an in-vehicle network with a tester and manipulate UDS on DoIP communications.

Potential Threats Faced by UDS Protocol and DoIP

At Embitel, a dedicated team works on communication and diagnostic protocols such as UDS, DoIP, CAN etc. Having developed and integrated such protocol stacks in scores of series production, the team has a crisp understanding of the evolving threats. Let’s explore them.

  1. Exploiting Specification Discrepancies: The vulnerabilities arise from the disparities in communication scenarios and session management between DoIP and UDS. For instance, UDS may not have stringent session management stipulations, even though DoIP does, especially when handling communications with multiple testers. This oversight can be exploited in an ‘authentication avoidance attack’, where malicious entities can sidestep authentications put in place by the SecurityAccess
  2. Harnessing DoIP Vulnerabilities: Adept attackers can also exploit the inherent vulnerabilities of DoIP to target UDS protocol. This results in two variants of man-in-the-middle (MITM) based session hijacking. Such attacks, when successfully executed, grant intruders the power to supplant authentic vehicle software with unauthorized versions, or even worse, to commandeer the vehicle entirely.

Diving Deeper into UDS on DoIP Vulnerabilities

To truly understand the gravity of threats that UDS on DoIP may encounter, let us present a detailed analysis. This comprehensive assessment was anchored on two core vulnerabilities.

  1. Authentication Avoidance Attack:
  2. Fundamental Issues:
    The crux of the issue lies in the discrepancy between the protocols: while DoIP has specific provisions for diagnostic communications with multiple testers, UDS protocol might lack comprehensive session management guidelines. This lacuna potentially paves the way for lapses in session management by vehicle manufacturers, manifesting as a weak link ripe for exploitation by attackers.

    How it Works:
    This attack hinges on a key vulnerability – the session management, primarily answering the question: “Who was authenticated?” The tester starts by assigning an IP address, followed by vehicle discovery, and routing activation to the target ECU. Post this, the tester engages in session transition and authentication procedures.

    The attacker then mimics these steps and sends a requestSeed to the target ECU.

    💡When an external diagnostic tool wishes to gain access to secured functions within an ECU, it sends a “requestSeed” command. In response, the ECU generates and sends back a random “seed” value.

    The tester then uses this seed to compute a “key” based on a predefined algorithm. This computed “key” is then sent back to the ECU. If the ECU verifies that the key is correct (i.e., matches its own internal calculation), it grants the tester access to the protected services.

  3. Man-In-The-Middle (MITM) based Session Hijacking:
  4. Via Tampered Vehicle Announcement:
    This mode of attack takes advantage of a flaw in DoIP, allowing the address map of a tester to be manipulated using a tampered vehicle announcement.

    The corrupted address map skews the destination of diagnostic messages, leading to a Man-In-The-Middle (MITM) based session hijacking. The attacker kickstarts the process with IP address assignment and vehicle discovery. Post this, a tampered vehicle announcement is crafted, which is eventually used to corrupt the address map of the tester.

    The tester unknowingly routes an activation request to the attacker based on the compromised address map. The attacker intercepts this and establishes a connection with the tester, mediating and possibly tampering with the messages exchanged between the tester and the target ECU.

    Via Tampered Vehicle Identification Response:
    In another variation of the MITM attack, the vulnerability in DoIP lets the tester’s address map be corrupted using a tampered vehicle identification response. Like the above method, this corrupted map redirects diagnostic messages, creating a scenario for MITM session hijacking.

    Subsequently, all diagnostic messages, influenced by this corrupted map, can be intercepted and manipulated by the attacker.

Countermeasures Against Attacks on UDS on DoIP

Now that we have discussed some of the major vulnerabilities of UDS protocol on DoIP communication, lets shift our focus towards mitigating them.

Based on our understanding of UDS Protocol, different UDS services and DoIP, here are a few countermeasures to the threats discussed before.

  1. Rejecting Diagnostic Communications from Suspicious Devices
  2. To prevent the attacker’s efforts right at the outset, it’s essential to halt any communications from suspicious sources. Implementing mutual authentication protocols between testers and ECUs and using encrypted communication methods, will thwart attackers. Detecting compromised ECUs can further add an extra layer of security, neutralizing all three attacks.

  3. Countermeasures Against Authentication Avoidance Attack
    • Proper Session Management
      This attack takes advantage of improperly managed sessions. Proper session management will remedy this vulnerability. For instance, ECUs can maintain a status log detailing the authentication status for every tester, ensuring that attackers cannot exploit lapses in session management.

    • Investigate Inconsistencies in RequestSeed and SendKey Transmissions
      By monitoring and comparing the number of requestSeed and sendKey transmissions, it’s possible to detect unusual patterns. Discrepancies in the transmission numbers can signal an active authentication avoidance attack.

    • Monitor Negative Response Transmissions
      If an attacker sends unauthorized requests, the ECU will likely generate a negative response. By actively monitoring and tallying these negative responses, unauthorized activities can be swiftly detected.

  4. Countermeasures Against the MITM Based Session Hijacking

    • Monitor Source IP/MAC Addresses for Duplicate Logical Addresses
      In a MITM attack, both the attacker and the genuine ECU send responses. By screening for duplicate logical addresses from different IP/MAC sources, this type of attack can be quickly detected.

    • Track the Total Number of Vehicle Announcement Transmissions
      A sudden influx of vehicle announcements, especially beyond the specified limit, can be a red flag for a MITM attack.

A Summary of Countermeasures Against Attack on UDS Protocol

The first countermeasure offers a comprehensive solution against all three potential attacks, making it highly recommended for implementation in vehicles. However, given the resource constraints in some ECUs, this countermeasure might not always be feasible. In such instances, focusing on the second countermeasure- B becomes crucial. This measure is not resource-intensive and ensures the software within each ECU is devoid of session management bugs.

For a multi-layered defence strategy, it’s imperative to incorporate all three countermeasures described above.

Conclusion

Modern vehicular diagnostic communication systems, like UDS on DoIP, though sophisticated, can be susceptible to various attacks. Our analysis has unveiled three primary attack avenues, with the most concerning being the authentication avoidance attack. The MITM-based session hijacking attacks, both through tampered vehicle announcements and vehicle identification responses, also present significant vulnerabilities.

However, with the proposed countermeasures, these vulnerabilities can be addressed, resulting in a more secure and resilient UDS powered vehicle diagnostic communication system.

Vaibhav

About the Author

Vaibhav is a digital-marketing professional with a deep-rooted interest in everything automotive. Regular collaborations with automotive tech guys keep him apprised of all new trends in the automotive industry. Besides digital marketing, Vaibhav is fond of writing and music.

Scroll to Top