In today’s modern world, CAN protocol is extensively used from medical devices to fighter jets. CAN is a vintage old protocol, thus should be properly tested and secured.
Synopsis:
- Introduction:
- CAN Bus organization in an automotive environment
- Security issues in In-vehicle networking systems
- Avoiding the obvious pitfalls
- Best security practices tested at BINT labs
- Conclusion
- How can Briskinfosec help you?
- Curious to read our case studies?
- Last but not the least
- You may be interested in
- Resources
Introduction:
Controller Area Network (CAN) is the widely used In-vehicle networking when seen from a normal point of view, CAN is really powerful in transmitting all the critical and non-critical systems data to all the ECU’s (Electronic Controller Unit) and other units. So, when it comes down to the understanding of CAN systems, it becomes a bit tedious.
The reason is, a single car now-a-days has at least 100 embedded systems ECU that are running inside them on a very low key note, at least 20-25 embedded ECU. This is the reason why analysis of CAN bus is quite complicated (huge flow of data in them). Apart from this, cars also can have multiple flavors of CAN Bus (ISOTP, GMLAN) running inside them. So, simply newer models of cars are just huge moving bare metal computers that are powered by battery running relatively old protocols. According to SANS, Can is also considered to be one of the in-secured protocols if security implementations are not configured properly.
CAN Bus organization in an automotive environment:
Thumb rule when seen from a High-Level, obtains classification into two major types. They are
- CAN-H (CAN-HIGH)
- CAN-L (CAN-LOW).
For example, let us say that there is a fuel level sensor in a car and it needs to periodically send the data to the car’s dashboard instrument cluster. There will be a microcontroller that has a CAN stack in it. It sends the periodic CAN packets to the microcontroller that’s present in the car’s dashboard instrument cluster, and thus, the incoming data is displayed. Now, this same message is continuously transmitted on the “twisted pair CAN cable” among other data.
Typically, these paths of data transfers are referred to as pipes. There are two types of them. They are High priority pipe and Low priority pipe.
High priority pipe is used to transmit
- Engine data
- Braking data
- TPMS (Tire Pressure Monitoring Sensor)
- Transmission
Similarly Low priority pipe is used to transmit
- Door control
- Lights
- Internal cabin control data.
So, the data that actually flows in the pipes is the control frame that’s controlling the entire automotive system. Concluding, a single automotive equipment can even have multiple pipes running inside them, with each simultaneously transmitting data to each ECU’s that are inside the system.
Security issues in In-vehicle networking systems:
Testing of CAN systems comes under the category of Dynamic Blackbox Analysis. This means, we need to establish a baseline data for normal system operation. Next, we need to perform some actions and obtain the event and status logs, and then find a difference between them. Then, we just need to simply replay the data to check for actions. This simple replay works in the case of CAN Bus that controls the ECU Low priority CAN communication. But for the manipulating data for high priority CAN’s, one needs to look out for the authentication procedures in the OBD2 pipe.
When compared to other systems, bypassing the engine pipe is comparatively complicated as the UDS (Unified Diagnostic Services) authentication is available for some of the vendors. But most of the UDS services deployed, does not have strong cryptographic implementations. Apart from the cryptographic complications, we have a seed key that is actually a part of the challenge passphrase for gaining authentication. Most of the times, these keys are the same. This means that the challenge passphrase and the seed key are also the same. Hence, gaining access to the engine’s data pipe is quite easy. Also, this same passphrase and seed key is then used in all cars. This is undoubtedly, the biggest security risk in it.
Once the intruder has access to this pipe, it is then possible to read the VIN (Vehicle Identification Number). It’s a 17-digit number that actually denotes the system and it’s details. This is the major security issue in CAN Bus. The main reason for this issue is that, there is no proper sanity check for the data packet which leads to replay attacks. Also, there is nothing, or only weak crypto implementations.
Avoiding the obvious pitfalls:
CAN systems when misused can cause severe damages. One defect in the CAN Bus is that, it requires the manufacturers to recall a lot of products that are currently deployed. This is bad for business in terms of costs. Hence, it is of prime importance for developers and manufacturers to maintain strict security policies and regulations in the production phase itself.
Best security practices tested at BINT labs:
Some of the security practices that we tested at BINT labs are cited below:
- Using dedicated co-processing integrated circuits for secure cryptographic implementations.
- Proper sanity checks and packet management on the CAN Bus.
- Testing designs for security flaws from the early stages of development.
- Limiting access to the functions and other debugging buses.
- Having dedicated firewalls for your embedded ECU infrastructure and design.
- Having and adhering to the well tested and practiced coding standards for CAN Bus implementation.
- Selecting better embedded controllers for ECU.
- Proper isolation of different CAN interfaces.
- Obfuscating the on-wire CAN Bus data (security through obscurity).
- Testing OEM equipment’s for previously known flaws, other unknown vulnerabilities and even possible zero days.
Conclusion:
Having proper boundaries for your hardware and firmware will actually take oneself, a long way for protecting assets. Other than this, not enabling all the debug interfaces and isolation of communication pipes also prevents unauthorized usage of the system. But the master key to solve all these problems in one-go, depends on how much policy enforcement is implemented while the system is under development.
How can Briskinfosec help you?
We, at Briskinfosec have a dedicated and intensely researching security team working on CAN Bus implementations. We regularly conduct security audits on recently deployed standards of SAE, NIST and NHTSA for automotive cybersecurity. BINT labs work on CAN Bus fuzzing with custom written modules in order to induce faults and exploit CAN Bus systems. Apart from this, we use an in-detail attack surface map that is tailored to suit every CAN Bus demands for our clients, based on their distinctive requirements.
Curious to read our case studies?
In this digital era, when you think about data, you cannot forget security. To know how a proper security quality is accomplished, you need to know the security strategies used behind it. Well to know how a proper security implementation is done, then our case studies would be the ideal examples. They contain the successful security assessment strategies used to eliminate the distinguished security vulnerabilities that were lurking in our client’s security environment. Just check them out now!
Last but not the least:
Give yourself some happy claps because you have found something that countless wouldn’t have. Pondering what’s that?
Well, I would now break the suspense.
Here we present you our Threatsploit Adversary report. It is a report that contains the collection of globally occurred cyberattacks, the consequences they had imposed, the reputations lost by organizations as well as individuals, and much more. Even the preventive measures are mentioned by us, solely to help you for escaping from such threats. Trust me. Instead of searching in search engines and websites about all these, our report is a far better choice. Just read it. For sure, you’ll never have regrets over it!
You may be interested in:
Resources
