Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paper Discussion 10a: Experimental Security Analysis of a Modern Automobile #85

Open
reesealanj opened this issue Mar 11, 2020 · 9 comments
Labels
paper discussion s20 The discussion of a paper for the spring 2020 class.

Comments

@reesealanj
Copy link
Contributor

reesealanj commented Mar 11, 2020

Thank you all for your questions and critiques!

  • @albero94, Alvaro Albero, Critical: Is the OBD-II Connector the only point of attack, and is there a way to keep attack after disconnected from the connector?
  • @AkinoriKahata, Akinori Kahata, Critical: How is it possible that there are instances where the vehicle does not prioritize the manual input (re: Tables II - V on page 10).
  • @grahamschock, Graham Shock, Comprehension: It seems fairly easy to protect the system by changing challenges from 16 bits to something higher like 32 bits, what are the tradeoffs of doing this?
  • @grahamschock, Graham Shock, Comprehension: Explain the CAN packet further, what exactly do all of the portions of the packet mean?
  • @grahamschock, Graham Shock, Comprehension: Exposing all of this information seems unethical.
  • @bushidocodes, Sean McBride, Comprehension: Has this poor standard of operation improved since the paper's release?
  • @bushidocodes, Sean McBride, Comprehension: How do you strike a balance between secure systems and the "right to repair" our own cars?
  • @s-hanna15, Sam Hanna, Comprehension: Is there a difference between companies and their security levels, especially when discussing access control?
  • @lrshpak, Lily Shpak, Comprehension: The paper says quite a bit about the problems, but not so much about any proposed solutions, what are possible solutions to these problems?
  • @lrshpak, Lily Shpak, Comprehension: How do they test components that rely on other components not being compromised?
  • @nikorev, Niko Reveliotis, Critical: Are there laws regarding with tampering with a vehicle's software similar to how there are laws regarding tampering with other parts of a vehicle?
  • @nikorev, Niko Reveliotis, Critical: Using V2V or V2X networks could a company maliciously implant software into another company's vehicles?
  • @nikorev, Niko Reveliotis, Critical: Would it be possible to add addressing to CAN and would that help to remove or mitigate certain attacks?
  • @huachuan, Huachuan Wang, Comprehension: CAN's broadcast nature is listed as one of its security challenges, but this design is for efficiency. Would adding more security through extra complexities create too much overhead?
  • @huachuan, Huachuan Wang, Comprehension: Why is detection and correction of anomalies better than prevention and locking down capabilities?
  • @RyanFisk2, Ryan Fisk, Critical: Why do ECU's have to be independent?
  • @RyanFisk2, Ryan Fisk, Critical: Are there any systems within a car that can only be attacked physically? Or are they all accessible wirelessly?

Shared Comments/Concerns:

  • The authors mention that this process was "easy" but it does not feel like it was easy in reality.
  • Why is it that manufacturers are permitted to NOT follow the CAN standard that they say they're following, that seems fraudulent.
  • The paper lacks in depth solutions to all of the problems they explain. What are the possible solutions to these issues?
@gparmer gparmer added the paper discussion s20 The discussion of a paper for the spring 2020 class. label Mar 22, 2020
@albero94
Copy link
Contributor

Reviewer: Alvaro Albero
Review Type: Analytical

Problem Domain

Modern cars have multiple digital systems for control and monitorization, they are no longer just mechanical devices. These systems allow different advantages and performance, many times have been introduced for increasing safety such as ABS, but at the same time they can be a security leak from where attackers can take control or destabilize the system.

Main Contributions

The authors perform an in-depth analysis of a modern automobile that makes use of digital systems to show how weak their security is, and the different actions that an attacker with control of the car could attempt. They perform several experiments in the lab and in road tests and they also discuss challenges in addressing these vulnerabilities in the current ecosystem

Questions

  • Is not implementing the standards that are supposed to be followed (CAN in this case), and probably advertised as followed, some kind of crime or fault? Is this a common practice? I thought that when you say you follow a standard there was a way to check that you are really following it.
  • Is the OBD connector the only way to perform the attacks? Can the attacks keep happening once the device is disconnected form this connector?
  • They mention that in some cases it was an “easy” task, but to me it seems they did a lot of work, how long did it take them to compromise the security of the system?

Critiques

  • I found the paper very interesting and really well explained. I believe every section has a reason and it drives you to the next one, explaining the concepts you need and then using them in the following section. From the background, to explaining the CAN bus as the key component, to showing the vulnerabilities of the standard, compromising the security of every component and doing a road test. Maybe after the damage caused by single components, the multi component interactions seems a bit weak, as we would expect more harmful attacks and they actually just play a bit with the functionality.
  • I understand the control they can take of the system is huge and it can perfectly cause severe accidents. At the same time, they mention that is very easy to take control of it, the security is poor. The thing here is, it seems you need physical access to the OBD connector at some point, and even constant access to perform many of the attacks. This seems complicated. We have seen in class IoT attacks counted by the thousands/millions, in this paper they mention that the security of the car is really low too, but how many attacks have actually been performed? I have barely heard of any and there are millions of cars running out there. So I think that even if the security is that poor, the lack of these attacks shows that is not that easy to perform them due to the requirements of constant physical access.

@AkinoriKahata
Copy link
Contributor

Reviewer: Akinori Kahata
Review type: Critical

  1. The problem being solved.
  • Recently, automobiles become a kind of gathering of computers. Each car consists of many Electric Control Units (ECU) and Control area networks, and these devices support not only informational function but also some safety functions. Unfortunately, the security level of those components is low; then, it is essential to clarify what is the problem of automobiles' security.
  1. The main contributions.
  • The researchers did experiments of cyberattacks under three occasions; bench, stationary car, and on the road. The research focuses on the device level, component level and multi-component level. As a result of the experiments, the researchers proved that the recent automobiles car has security problems, adversaries can affect automobiles’ function by some attack such as sending malicious data.
  1. Questions.
  • Although many car companies use the standard, I guess that the real structure of cars is different from each other. Generally speaking, how much ratio is common between car companies about the components’ list table 1 and the packet structure in figure 5?
  • I cannot understand well that if manual overrides are not permitted at page 10, what is happened when an adversary’s attack and manual control happen simultaneously? Which is prioritized? In my understanding, car industries prioritize the manual maneuver.
  1. Critiques.
  • The researchers assumed that adversaries could connect with telematics systems by some method. But I think that making connection with cars is one of most important point of car hacking. If the researches discuss the security issues, I think they should consider telecommunication issues. Of course, it is very important the evaluation of component level security, but car safety function is so complicated, then I think real attack scenario is very important.

@grahamschock
Copy link
Contributor

Reviewer: Graham Schock
Review Type: Comprehensive

Problem Being Solved
Cars have evolved a tremendous amount within a very short period of time. They have gone from old mechanical beasts to having new modern computers. However, this new technology has left our automobiles complex and vulnerable to a wide variety of attacks. To make matters more complex soon cars will be open to the entire infrastructure and other vehicles. Sadly, not a lot of research has been done in this topic which allows these attacks to be even more potent and dangerous.

Contributions
The goal of this paper is to illuminate the dark cave of automobile security. In order to accomplish this the paper uses experiments on a wide variety of car components to show that they can be attacked and that the car’s security is not strong enough to protect against an attack. The paper also looks at the network of components as a whole and shows there are some systemic vulnerabilities. The paper then goes on to determine what underlying mechanisms are the reasons for these types of vulnerabilities.

Questions

  1. It seems like an easy way to protect the network and the Electronic Control Unit is to change the challenge and response keys from 16 bits to something like 32. What would the trade offs of something like this be? How would it affect performance?
  2. I think understanding the CAN packet structure is the essence of understanding automobile network security. The paper breaks down the CAN packet into a neat diagram. What do the different components of the packets mean? Why is it different from other network packets? What is “CRC”?
  3. Are there ethical implications of making the information public? The paper essentially gives the architectures and the tools necessary in order to seriously hurt people in their vehicles.

@bushidocodes
Copy link
Contributor

Reviewer: Sean McBride

Review Type: Comprehension Review

Problem Being Solved:

Modern cars are powered by numerous embedded systems connected by multiple buses and standard interfaces. Many of these Electronic Control Units (ECUs) have been added over the years to improve energy efficiency, reduce pollution, and provide driver assistive technologies to improve road safety. This paper seeks to provide the first-ever hands-on penetration test of the numerous embedded systems that compose a modern car. It seeks to example the ways that these systems reduce safety once an adversary is able to gain access to a car's internal bus.

Main Contributions:

  1. Demonstrates that cars circa 2009 have not been designed with security in mind. Every system is vulnerable and can be fatally exploited to harm the physical world. The few security controls were easily defeated, including bridging separate buses with different security postures. Numerous regulatory requirements were detailed as not being followed in practice.
  2. Develops CarShark, a custom bus analyzer and packet injection tool, that is capable of executing numerous exploits over the CAN bus and standardized OBD-II port.
  3. Demonstrated and filmed exploits raised in an garage and live with a human driver at an abandoned airport to raise public awareness of the danger of the status quo in cars.

Questions:

  1. Has there been improvement from this pitifully low baseline over the past decade?
  2. What is the appropriate social tradeoff between a more locked down system that provides additional security controls and the social expectations of "right to repair" around cars?
  3. Why haven't more people died because of this? This paper makes it sound trivially easy to murder someone with their car and wipe all evidence? If that's the case, why hasn't Putin been murdering dissidents with this? Why hasn't Al-Qaeda been hacking Automatic accounts use auto-attacks as terrorism?

@s-hanna15
Copy link
Contributor

Reviewer: Sam Hanna
Review Type: Comprehension

Problem Being Solved:
This paper talks about the increase in the connectivity of automobiles and the security implications of this. Cars are more connected than ever and the Electronic Control Units (ECUs) connect vital parts of the automobile functions. Unfortunately, the rise of connectedness does not come with a rise in security which leaves these cars vulnerable to attack.

Important Areas:
The focus of this paper was on the ability to take control of various automobile functions remotely. They utilized the Controller Area Network (CAN) which communicated between the electronic components of the vehicle. They also created a tool similar to Wireshark called Carshark, to analyze these CAN packet and inject more packets. They tested the car's response to different stimuli in three environments: stationary, on jacks, and on the road. They were able to effectively control the car in a variety of ways with limited difficulty.

Questions:

  1. If there are access control standards, why can companies get away with not using/securing them? This seems like the very least they can do considering the possible threats that are posed.
  2. They used the CAN and OBD-II connector to facilitate these attacks, is it reasonable to assume that an attacker could do the same? They mentioned that disconnecting the connector would stop any attack, would there be a way to assure that an attacker would be able to keep it connected, during the scope of an attack?
  3. They don’t talk about what type of cars they tested, they say they tested two cars, but do not give the company, make or model. I understand this is to preserve the safety of the cars, but are these just two unsecured companies/cars? Is there a difference in the different companies in their security, especially in compliance with the access control?

@lrshpak
Copy link
Contributor

lrshpak commented Mar 23, 2020

Reviewer: Lily Shpak
Review Type: Comprehension

Problem Being Solved

This paper attempts to expose the lack of security in embedded systems in automobiles. Cars are becoming increasingly more computerized and most of these computerized components do not have much security. This leads to vulnerabilities that could hurt the car or even worse, the people in the car.

Main Contributions

The authors of this paper note how they avoid the standard threat model, instead they focus on what attacks could happen if the attack already has access to the system. They tested electrical components, such as the HVAC system, of a car to assess potential threats.

Questions

  1. The authors mention that they stay away from the standard threat model, why do they do this? I think they show how an attacker gets into the system initially.
  2. They explain their experiment and how they went about testing but it seems they do very little to explain a solution. What would a solution be to these threats?
  3. There seems to be a lot of components on a car that work together, how do they test components that rely on other components to not be compromised?

@nikorev
Copy link
Contributor

nikorev commented Mar 23, 2020

Reviewer: Niko Reveliotis
Review Type: Critical

Problem Being Solved

More and more vehicles are relying on electronic control units (ECUs) to control different parts of the vehicle. Although the use of ECUs have aided the development of many safety systems, this paper outlines the security flaws of these systems through multiple tests. These flaws allow malicious code to drastically affect the operation of the vehicle; one created attack even has the ability to delete itself post-attack to make detection more difficult.

On top of this, the attack surface is being broadened wirelessly for vehicles as more communication networks are being created for vehicle to communicate with other vehicles (V2V) or infrastructure (V2X). In terms of physical connections, the Onboard Diagnostics Port (OBDII) and media players also open more attack vectors as their capabilities are broadened (ex: app stores for media players).

Main Contributions

  • Multiple vehicular attacks to demonstrate the vulnerabilities of their underlying systems
  • Evaluation of "the security properties of each of the key components within our cars, and we analyze the security properties of the underlying network substrate"
  • Carshark Tool: "a custom CAN bus analyzer and packet injection tool"

Three Questions

  1. Are there incredibly strict laws regarding messing with the software of a vehicle (as a mechanic)? I understand that if a mechanic intentionally breaks a part of the vehicle there are strict penalties, but has the law caught up with the software yet or is it implied?
  2. Remember when VW had their diesel engine scandal with their emissions? Many of the attacks relate to a single victim in this paper. But would it be possible for a rival company to push a malicious program onto one of the future communication networks of a competitor (V2V / V2X) which would mess with their emissions? removes tinfoil hat
  1. Would adding addressing to CAN be logistically possible? Would addressing be able to remove some sniffing attacks by not broadcasting the packets all nodes? Could it also mitigate attacks by creating a "whitelist of valid senders/ECUs" which can send valid controls only to certain recipients/ECUs.

Three Critiques

  1. Although they state the reason for not identifying the two vehicles tested on (of same make and model), I believe the reason provided is pretty weak. This is a bit nit-picky, but knowing which specific vehicle this was tested on could paint a better picture of the breadth of flawed vehicles. By this, what if the vehicle was a common Toyota/BMW which leverages similar infrastructure between many models vs a "no-name" brand which wouldn't relate to nearly as many vehicles on the road today. The scope of which vehicles are affected by their specific attacks isn't outlined clearly here. They could be testing on the easiest and least-common target for all we know.
  2. The paper talks about the ability to reflash ECUs by brute-force within 7.5 days (or 3.5 if you physically remove it). They discuss this ability as a feasible attack when the average American uses their car for ~1 hour a day. How would you even have the ability to reflash the ECU unless someone is leaving their vehicle in an insecure location for nearly a week? I feel this vector of attack is not nearly as serious unless you're someone like Floyd "Money" Mayweather with a spare Bugatti sitting in your garage for extended periods of time. But likely, this garage would be incredibly secure, which wouldn't even allow for an attacker to gain physical access to the vehicle anyway.
    • In the case where they begin reflashing the ECU while the vehicle is moving, the attacker would need to maintain connection to the vehicle. Either by being nearby and accessing the vehicle remotely or by a physical device being attached to the vehicle, which for the same flaw as above would require access to the vehicle in an insecure location.
  3. Most of these vehicular attacks require specific work to one vehicle (getting a connection, sniffing packets, flashing ECUs, etc). I feel until we have a V2V or V2X network between these vehicles, the risk of attack isn't significantly high unless you're a target. I believe that this paper serves an important purpose in explaining the risks these vehicles have currently, and how putting them on a network will exacerbate the issues to more vehicles. But as of right now, the risk of someone attacking the vehicle parked in your driveway is very low.

@huachuan
Copy link
Contributor

huachuan commented Mar 23, 2020

Reviewer: Huachuan Wang
Review Type: Comprehension

Overview

This paper experimentally evaluates the safety issues on a modern automobile and demonstrate the fragility of the underlying system structure. It also demonstrates that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. This paper also presents composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car’s telematics unit and completely erase any evidence of its presence after a crash.

Contribution

This paper has present an empirical approach and provides a unique perspective to reflect on the actual vulnerabilities of modern cars as they are built and deployed today. This paper has illustrated the findings and addressed the challenges in addressing them, these findings include external damage, ease of attack, enforced access control and attack amplification.

Questions

  1. This paper mentioned that many of the vulnerabilities are from weak or unenforced protections of the diagnostic and refreshing services. The core problem is the lack of access control for the use of these services. Could the improvement of the security of the CAN protocol help with this situation?

  2. CAN's broadcast nature is listed as the security challenges, however, these designs are for the efficiency purpose, does it necessary to add more complexity and overhead to the broadcast to improve security?

  3. Why detection and correction of anomalies are better than prevention and locking down of capabilities for the cyber-physical system?

@RyanFisk2
Copy link
Contributor

Reviewer: Ryan Fisk

Review Type: Critical

Problem:

Modern vehicles contain a lot of IoT technology and use it in unique and in most cases safety-preserving ways. However, the increase of digital technology in automobiles creates many new safety problems even though the systems themselves are designed to keep a driver and passengers safe. Many of the systems are very vulnerable to malicious actors and the consequences of these systems failing can be potentially life-threatening. This paper tests the current security features of vehicle systems in lab and flied conditions to show the problems that these systems can cause.

Contribution:

This paper tested the individual components of a IoT enabled car in a lab as well as the whole system on the road. The authors thoroughly discuss the security flaws with each system, including the network these devices use to communicate with each other. The authors present the security flaws for each individual component, allowing for specific analysis of each component.

Questions:

  1. Why do the ECU's on a car need to be independent?

  2. Would a processing unit on the car that coordinated and monitored the ECU's fix any of the problems the paper presents?

  3. Are there systems on a car that an attacker can only access physically (i.e. with the OBD-II port) or are all of these systems accessible wirelessly?

Critiques

  1. In their research, the authors say they purchased third-party ECU's when necessary to facilitate their research but doesn't say which ones they used or who those third parties were. Is it possible that these replacement ECU's have different vulnerabilities than the car's native ones.

  2. The paper presents the experiments as a general look at how digital devices can be compromised in automobiles, however not all of the components and protocols are standardized and different companies use different devices. Since the paper used two cars of the same make a model, I'm not sure if this is a totally accurate look at the security of these devices in a general sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
paper discussion s20 The discussion of a paper for the spring 2020 class.
Projects
None yet
Development

No branches or pull requests